Re: linux kernel error reading end of cd/dvd
> > - CD lead-out position is documented to be inaccurate [with 75 blocks
> > inaccuracy?]
> Silly question - where/how?
Note the question mark in the [comment]. It means I'm not sure where I
read/heard this and I admit that I might be wrong about this:-)
> How do you arrive at 75?
75 sectors is one second CD-DA, right?
> I have observed the same problem with DVD+R burnt by Nero (different
> box), reading on the box as previously stated, so I don't think it's
> limited to CDs - it affects DVDs in the same manner.
Can you confirm that the value returned by isoinfo on Nero mastered disk
did not cross the address of lead-out? Then it naturally can vary from
one DVD recorder manufacturer to another. What I'm trying to say is that
I can't confirm your experience with DVD+R, not with ISO9660 layouts
generated by mkisofs. Which is why I wrote "DVD lead-out position *is
believed* to be accurate."
> > If you really have to
> > checksum the whole image, then make sure to bypass the block buffer
> > *and* provide sane block count value. A.
> Obvious question ;): is there an easy way to bypass the block buffer?
Well, already mentioned readcd effectively bypasses the block buffer,
but you can trick Linux kernel to bypass it by binding the device to
/dev/raw/rawN and referring to the latter instead of real device
(there're limitations though, consult the manual page).
> What value do you call "sane" - count=N with N <= isoinfo -d?
"Sane block count" is obviously the number of last *significant* block.
Yes, for mkisofs mastered images the value returned by isoinfo suffices.