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.
This is actually a matter of the device driver
and not so much of drive and media. The size of
a logical track as obtained by MMC commands is
reliable. One just has to be aware that not all
types of sectors can be read by the SCSI command
for reading data blocks.
In the special case of CD TAO data tracks there are
two such non-data blocks at the end of each track.
(Not related to Darth Bane's Rule Of Two.)
With CD SAO data tracks there are no such non-data
blocks in the range of the official track size.
All DVD types seem to be clean in that aspect, too.
(No non-data sectors are defined for non-CD in MMC.)
- 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.
... when transitioning between tracks having different modes ...
The behavior of the Linux block device driver
created several urban legends.
To my theory it reads in larger chunks up to
the track end. When the last chunk of a TAO track
is read, the two unreadable sectors are encountered
and let the whole chunk fail.
If the driver would retry with a chunk size that
is two sectors smaller, then it would be ok.
But the driver does not. It just declares i/o error.
The readahead size can be set by the 'blockdev' command, but smaller
sizes hurt performance.
Chunk size is smaller than 300 kB. That's why that
size of padding is a traditional remedy for track
content which can recognize its proper end.
Whatever, if you read the CD TAO track by own SCSI
read commands it is easy to retrieve the exact amount
of data which has been written to that track.
libburn test program telltoc can demonstrate that.
The readable amount includes any padding by formatter
and burn program, of course.
So padding, which helps with the block device driver,
is rather counterproductive if you have a reader
which works flawless.
With a correct reader one has to memorize the amount
of padding and ignore that many bytes at the end of
the data.
Padding at write time and ignoring pad bytes at read
time is just a guess how to fool the CD TAO bug in the
Linux driver.
Bill Davidsen wrote:
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
Having data aligned to a size larger than 2 blocks
(= 4 kB) can be another remedy for the driver
problem. It depends on the assumption that the driver
will not attempt to read ahaead of the data amount
which is demanded by the user space program.
Large alignment size will probably help to fulfill
that assumption.
Have a nice day :)
Thomas