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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
