Re: Thoughts on writing CD from stdin

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Dave Platt wrote:
> > > 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.

I wrote:
> > This is actually a matter of the device driver
> > and not so much of drive and media.

Rob Bogus wrote:
> The readahead size can be set by the 'blockdev' command, but smaller
> sizes hurt performance.

I would expect a smaller chunk size to increase
the probability of accidential success.
Nevertheless the actual problem seems to be that
no retry is made after a read chunk turned out to
be partially unreadable.
The driver has few chance to predict that unreadability
as the blocks are located within the track's size range.
But it could either retry with single block steps after
a failure or be cautious not to read the last two blocks
of a CD track in a single SCSI command together with
other blocks.


Rob Bogus wrote:
> I believe the error was fixed a few kernel versions ago, so that a
> clean partial read count is returned. I haven't validated that for
> all write modes, and perhaps I should for purposes of discussion.

Decisive is to test with CD TAO tracks.
A similar bug with a CD SAO track or a DVD track
would be a surprise to me.

One should try to write a track with a number of
data blocks that is a product of odd numbers. Like 
 3*5*7*11*13 = 15015
and avoid any padding.
That way it is unlikely that a chunk read ends
exactly before the two non-data sectors.
(This is the rare case when all data bytes are
 readable despite the problem.)


Bill Davidsen wrote:
> Rather than one of the "raw" modes? I found several posts suggesting that
> the magic was 'raw96r' or similar.

Last time i tried to read a raw mode CD
the block device driver of Linux 2.4 failed.
The same with audio sectors.
Those sectors do not have a payload of 2048
bytes. About the same problem as with the
two sectors at the end of a TAO track.


> Recent kernels seem to return a valid partial data count for the last read,
> and then an error on the next read.

It would be a great relief if the annoyance
with reading CD TAO tracks was finally gone.


Have a nice day :)

Thomas