In <[EMAIL PROTECTED]>,
Karl-Heinz Herrmann <[EMAIL PROTECTED]> noticed:
> On 27-Jul-00 Danilo Godec wrote:
> > What could be the cause of that? Dirty lens or something similary
> > trivial?
> If it happens with 'all' blanks maybe -- so I would suppose the burned
> would loose the track and give an error while burning in that case.
>
> > Or maybe a firmware bug (just btw., writing audio in 2x speed always
> > results in random clicks in the recording; while 1x speed seems to be
> > fine) even?
>
> Could be the same problem -- random clicks could also be produced by
> bad media, not bad enough for write errors, but to many errors while
> reading. Since audio data has no error-correction data I woul assume clicks
> -- a lot more then you would find errors in data.
>
> I'm astonished that you can read the bad data simply in, without any errors
> reported from the kernel -- I usually got read errors and couldn't read the
> file at all. If you have *no* errors reported but still see them in the
> files this could mean a burning problem after all (where the errors get in
> before they arrive on the CD and the error correction code can't help).
That point sounds right to me. If data (as opposed to audio, video,
etc) is read clean, I would have to think that it was written originally
bad, and has a CRC which matches the error.
The only time I've seen this, and it was on a SCSI system, was with a
system running without parity RAM. Replacement of the RAM and enabling
ECC made the problem stop. The upgrade was for size, not because I
figured it out, I just use ECC as a matter of policy.
Obviously lots of things could corrupt that data, but memory problems
can happen, and only on i/o (if you use DMA). Can you turn off DMA and
try again?
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
