Re: Using dd to verify a dvd and avoid the readahead bug.
- To: email@example.com
- Subject: Re: Using dd to verify a dvd and avoid the readahead bug.
- From: "Thomas Schmitt" <firstname.lastname@example.org>
- Date: Wed, 03 Oct 2007 20:23:17 +0200
- Message-id: <email@example.com>
- In-reply-to: <1191430603.17069.84.camel@ip6-localhost>
- References: <1191430603.17069.84.camel@ip6-localhost>
> I don't doubt your observations, I know that the run-out blocks are not
> readable. I think that's because at the level below blocks, data on the
> CD is spread across a wider range to mitigate the effect of scratches:
The run-out blocks seem to belong to packet writing mode
of which TAO is a special case.
MMC-5 , 18.104.22.168 Recording Data
Since it is necessary to locate exact boundaries of user blocks,
additional padding is inserted around the linkage frame. The collection
of the link block, the pad blocks, and the user blocks is called a Packet.
The format of the packet is shown in Figure 23."
Figure 23 shows a chain of boxes with the texts:
Link Block | Run-in Block 1 | Run-in Block 2 | Run-in Block 3 |
Run-in Block 4 | User Data Blocks | Run-out Block 1 | Run-out Block 2
What bites us are Run-out Block 1 and Run-out Block 2.
> there is the guaranteed post-gap after them.
That's what i believe is the mistaken remedy.
Surely the 300 kB of data are a generous sacrifice
to the flaw in the OS drivers.
But i believe that this works because 300 kB is
larger than the largest buffer chunk used by
the driver for SCSI reading.
Not because it coincides with the size of post-gap
as prescribed for track type changes.
Have a nice day :)