Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests' slicing and
coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game (please note that I'm not claiming that I know all the
rules
Wow! Someone who knows what he's talking about - I'm impressed.
> - CD lead-out position is documented to be inaccurate [with 75 blocks
> inaccuracy?]
Silly question - where/how? How do you arrive at 75?
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the bo
On Wed, Oct 15, 2003 at 12:33:12AM +1300, Volker Kuhlmann wrote:
> > If we're talking about ISO9660 layout prepared by mkisofs,
> > then those "more blocks" are known to be insignificant and
> > you can as well checksum every file instead of the whole
> > filesystem image, can't you?
>
> No. Check
> > - 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
>From: Volker Kuhlmann <[EMAIL PROTECTED]>
>Thanks for all your thoughts. I'll combine the reply.
>> Why are you mailing cdwrite? If it's a kernel bug, you should send a
>> bug report to linux-kernel I'd say.
>I am not sure where the bug is, but it affects CDs. This is a CD writing
>list?
>> (a
>From: Ambrose Li <[EMAIL PROTECTED]>
>(From someone who doesn't know much about CD's)
>I used to checksum all the files (after finding that
>checksumming the whole disk doesn't work -- something beyond
>my understanding). This stopped abruptly after I upgraded my
>Linux kernel to 2.4, when moun
>From: Andy Polyakov <[EMAIL PROTECTED]>
>> > 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
> >> > If you really have to
> >> > checksum the whole image, then make sure to bypass the block buffer
> >> > *and* provide sane block count value. A.
> >>
> >"Sane block count" is obviously the number of last *significant* block.
> >Yes, for mkisofs mastered images the value returned by isoinfo s
On Tue 14 October 2003 12:30, Andy Polyakov wrote:
> Meet the players in the field:
>
> - block buffer which provides for read-ahead, I/O requests'
> slicing and coalescing;
> - value returned by READ CAPACITY command, hereafter simply READ
> CAPACITY;
> - actual lead-out position;
>
> Rules of the
> 75 sectors is one second CD-DA, right?
Yes.
> > 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
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests' slicing and
coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game (please note that I'm not claiming that I know all the
rules
Wow! Someone who knows what he's talking about - I'm impressed.
> - CD lead-out position is documented to be inaccurate [with 75 blocks
> inaccuracy?]
Silly question - where/how? How do you arrive at 75?
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the bo
On Wed, Oct 15, 2003 at 12:33:12AM +1300, Volker Kuhlmann wrote:
> > If we're talking about ISO9660 layout prepared by mkisofs,
> > then those "more blocks" are known to be insignificant and
> > you can as well checksum every file instead of the whole
> > filesystem image, can't you?
>
> No. Check
> > - 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
>From: Volker Kuhlmann <[EMAIL PROTECTED]>
>Thanks for all your thoughts. I'll combine the reply.
>> Why are you mailing cdwrite? If it's a kernel bug, you should send a
>> bug report to linux-kernel I'd say.
>I am not sure where the bug is, but it affects CDs. This is a CD writing
>list?
>> (a
>From: Ambrose Li <[EMAIL PROTECTED]>
>(From someone who doesn't know much about CD's)
>I used to checksum all the files (after finding that
>checksumming the whole disk doesn't work -- something beyond
>my understanding). This stopped abruptly after I upgraded my
>Linux kernel to 2.4, when moun
>From: Andy Polyakov <[EMAIL PROTECTED]>
>> > 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
> >> > If you really have to
> >> > checksum the whole image, then make sure to bypass the block buffer
> >> > *and* provide sane block count value. A.
> >>
> >"Sane block count" is obviously the number of last *significant* block.
> >Yes, for mkisofs mastered images the value returned by isoinfo s
On Tue 14 October 2003 12:30, Andy Polyakov wrote:
> Meet the players in the field:
>
> - block buffer which provides for read-ahead, I/O requests'
> slicing and coalescing;
> - value returned by READ CAPACITY command, hereafter simply READ
> CAPACITY;
> - actual lead-out position;
>
> Rules of the
> 75 sectors is one second CD-DA, right?
Yes.
> > 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
20 matches
Mail list logo
