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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]