Re: growisofs should have a method for padding
On Thu, 2005-05-12 at 01:26 -0400, D. Hugh Redelmeier wrote:
> The conventional work-around is to always pad when writing a CD/DVD.
> Ugly, but true. (I agree that this isn't the correct fix, but the
> problem has not been fixed in a year, so it isn't going away soon.)
As a matter of fact, for CDs it is exactly the right solution. As
discussed on this list in April 2000 under the subject "Reading out
data CDs" (not sure whether any public archive has those emails),
the Yellow Book standard for data CDs requires data tracks to end
in 150 empty blocks (300KB).
Therefore a CD writing file system is allowed to read ahead up to
150 blocks after the end of the last block with real data
and should not run into read errors there. How it should handle
read errors is a different question, but it doesn't change the fact
that it only occurs with broken CDs or when reading valid CDs
beyond the end of the last block with user data.
In my opinion the software which creates an image should ensure
that the track ends with proper padding, because neither cdrecord
nor growisofs can tell whether the end of the input data is padding
or user data. In 2000 padding was not done properly by mkisofs
(as far as I remember, it padded to a multiple of 16 blocks and even
that was disabled by default), but on Feb 15 2003 padding by
exactly the required 150 blocks was added (according to mkisofs'
changelog).
--
Bye, Patrick Ohly
--
Patrick.Ohly@gmx.de
patrick@core.de (MakeCD related mails)
http://home.pages.de/~ohly/
http://makecd.core.de/ (MakeCD home page)
Reply to: