Hi, Patrick Ohly: > Writing 150 empty blocks after the last block with user data is required > by the data CD standard - they are called "post-gap".
Yep. But as the publicly available standard MMC-5 clarifies: "6.33.3.19 Post-gap If a Data track is followed by another kind of track (such as an audio track), this Data track ends with a post-gap. A post-gap is placed at the end of a Data track, and is part of the Data Track. A post-gap does not contain actual user data. The minimum length of post-gap is 2 seconds. The Drive does not perform any action for a Post-gap. " This is not the situation we have with a single TAO track on closed media, unless you call the end of media "another kind of track". Also: i do not have this "readahead" problem with SAO sessions. And all my drives can read TAO tracks up to the last 2 non-data sectors if i apply SCSI command READ 10. All payload and all padding is retrievable up to the last byte ! It is not an issue of the drives but of the operating system. To me it appears like the block device driver of the kernel is overly trusting towards the TOC of the media. The TOC says payload+2 sectors, the driver tries to read that many sectors, the last buffer chunk encounters an error, the driver does not re-try to read the last payload sectors in 2 kB steps but pretends they are ill. This explains nicely why the number of missing bytes varies on my system with the CD media i insert. It also explains why SAO data sessions do not show the problem for me. The standard and the tradition of this whole issue is so messy, nevertheless, that the man page of my burn backend cdrskin advises padsize=300k in all its examples with data tracks. > Later (Feb 15 2003) Joerg changed mkisofs so that it always adds 150 > blocks. Seems to be a wise decision, although the problem is a media+drive issue and actually belongs into the realm of the burn software. But the whole mess is intransparent enough that 150 extra sectors are a low price for universal readability. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
