Re: Thoughts on writing CD from stdin
Dave Platt wrote:
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 remember that with old Linux kernels readahead needed to be disabled,
I haven't seen this problem in a while so it seems that the kernel fixes
are working.
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.
Rather than one of the "raw" modes? I found several posts suggesting
that the magic was 'raw96r' or similar. I believe I tried that, as well
as -sao, -tao, and -dao, but I can repeat the test easily.
- 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).
Recent kernels seem to return a valid partial data count for the last
read, and then an error on the next read. Reading 6400 bytes at a time
seems working, although this may only mean the media and firmware are
friends.
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.
The last 64k block has the "end of data" flag set, so it's unambiguous.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
Reply to: