Re: cdrtools-2.01a37 ready

[scdbackup@gmx.net]

me>>
>> cdrecord: Must specify track size(s).
>> Next i set the CDR_SECURITY variable and shwoops 
>> my pipe did work. It is reproducible: unset CDR_SECURITY
>> spoils it again.
Joerg >
> Without CDR_SECURITY, a max size if 1 GB os allowed....

I see your point. 


> The tracksize was unknown -> man cdrecord tells you how to
> deal with this problem.

I have read that. But the man page as well as cdrecord
tradition suggest that TAO mode does not need to know the
track size in advance.

There is the technical problem that i do not necessarily
know the size of the track in advance if i format and write
on the fly. This is especially true with compressed archives
but also with mkisofs -print-size on directory trees which
are not absolutely frozen.


For my purpose, with TAO from stdin, it would be better to
simulate a media overrun at 1 GB rather than to demand the
size in advance.

This would bring  cdrecord-ProDVD  without CDR_SECURITY nearer to
the behavior of home compiled cdrecord as long as usual CDs
are to be burned. 

I myself got no problem with setting CDR_SECURITY .
But it is about twice as complicated to describe how to
install  
  cdrecord-prodvd.sh  as  cdrecord
and
  cdrecord-prodvd-2.01b31-i686-pc-linux-gnu as cdrecord-ProDVD
rather than just to overwrite the old binary and set the s-bit.

Since my original proposal was to provide a substitution binary
for the mis-patched SuSE "cdrecord"s, it would be essential to
have the installation instructions as simple as possible.


>> ... found some typos
> Thank you

May i ask for a little favor ? 
I do not know where to dig for the answer to the following question :

Are there objections against having the only track of a CD
ending with 300+ kB of _ non-zero _ pad bytes rather than the
padding provided by  cdrecord padsize=...  or  mkisofs -pad  ?

A short "is ok" or "better pad 300 kB zeros" would be of help.


The track shall be written with -data -tao, no -multi, 
300+ kB of non-zero padding provided by me as data input to cdrecord,
no -pad or padsize= 

What i read :

You mentioned on August 6 in connection with read-ahead bugs :
 "The CD-standard requires 300 kB (150 sectors) of padding"

Contemporary man mkisofs -pad mentions 300 kB to appease buggy
reader software. (I checked: these 300 kB are zeros)

man cdrecord speaks of a "2 second silence before each track".

This leaves open wether it must be zeros if no further track is
following.
Would non-zero data possibly violate specs on which authors of
(data) CD device drivers or producers of (data) CD drives might
legitimately rely ?


Have a nice day :)

Thomas


PS:
I do not use cdrecord-ProDVD for DVD burning currently.
That is more due to your last year's position towards
DVD+RW rather than due to license concerns, nevertheless.

I am now using cdrecord-prodvd-2.01b31-i686-pc-linux-gnu
for CD-RW. No further problems encountered.