Re: Thoughts on writing CD from stdin
Bill Davidsen wrote:
This is not ISO9660 data. I want the burner program to take my bits and
put them on the media, nothing else. The data is in 64k chunks, so all
writes are sector complete. I haven't had any issues with reading the
data off DVD, or off CD in the case where I write it to something which
allows me to know the size, but in general I don't. Nor can I run the
data generation repeatedly to get the size, it's one of those "it
depends" things.
Unfortunately, determining the end-of-data (end-of-track) location on a
data CD is one of those things which is difficult-to-impossible to do
reliably.
This seems to be due to the way in which the 2048-byte-block data format
is "layered on top of" the original Red Book audio CD format. On a
data CD written in the usual way (one data track), the transition between
the data-layered blocks and the leadout area is difficult for CD players
to handle reliably, and different players tend to behave differently.
If you're lucky, your CD-ROM drive will read the last data block reliably,
and the attempt to read one block beyond that will result in an immediate
I/O error of some sort, allowing you to detect end-of-data reliably and
quickly.
This rarely seems to be the case, unfortunately. Other scenarios I have
seen include:
- The last data block reads back reliably. Attempting to read the
block following it does return an error, but only after a substantial
delay.
- The last data block (or even the last couple of data blocks) are
unreadable. Attempting to read them results in an I/O error.
I believe that I remember some discussion on the list, which turned up
a spec requirement that when transitioning between tracks having different
modes (and the leadout is a different mode than a data track) you're
actually required to pad the data... or, if you don't, the transition
blocks between tracks are formally unreadable. I don't remember the
exact details.
In practice, in order to be able to read your last real sector(s) of
data reliably, it's necessary to pad the burn with a few sectors of
unwanted filler data. I believe that cdrecord and/or mkisofs were
changed, a few years ago, to apply this sort of padding automatically
to ensure that the final portion of an ISO9660 image would always
be readable.
Since you aren't using ISO9660, and since you have prior knowledge
of your data's fundamental block size (64kB), I think there's a
reasonable solution for you.
- Use cdrecord (or one of the plug-compatible substitutes) in TAO
burning mode.
- Use the "-pad" option, with "padsize=16" option (16 sectors or
32kB of padding).
- Read your CD-ROM disk back 64k bytes at a time.
- You'll get an I/O error when you try to read the 64kB byte
chunk which extends past the end of what you actually burned.
Ignore any fragmentary data (partial chunk).
You can probably use the track size in the TOC as an indication
of the amount of data actually written - just round it down to
a multiple of 32 sectors.
Reply to: