[Paranoia] Understanding the output from --stderr-progress

[Peter Jones]

On Sun, 2005-01-02 at 23:46 -0800, Jonathan Morace wrote:
> I've been playing with the --stderr-progress cdparanoia flag to try to
> determine how reliable the rip was with a wrapper program.  I think I
> understand some of what it's reporting, but I'm wondering if someone
> can help confirm my assumptions and fill in some gaps.
> 
> - jitter: After reading around a bit, from what I understand these are
> the result of addressing errors from the drive.  My understanding is
> that cdparanoia will completely correct these errors and they should
> never result in problems with the rip, is this correct?

Unless you get a "!" or a "V", it should be correcting them.

> - correction: I'm assuming this occurs when there are differences
> between the "read" and "verify" pass.  Are errors of this type usually
> the result of scratches and damaged cds?

They could be, or they could be because some drives do a really crappy
job of actually reading all the bits, or...  

> Is it possible that corrections are still inaccurate reads from the cd?

Yes, it's possible, if the drive is giving consistently inaccurate data.
If multiple reads say the same thing, we tend to believe them.

> How does cdparanoia determine that the ripped data is "correct"?

It does multiple reads, starting at different addresses near the same
place, and tries to line them up.  Either it succeeds, and we call the
data good, or we try bigger blocks at once, etc, until we call it good
or give up.  Or at least I think that's what that part of the code
does ;)

> - skip: Unreadable data that cannot be corrected.  The resulting rip
> will contain interpolations over the missing data.

Skips should be digital silence, IIRC.

> - drift and overlap: These are the two I really don't understand.  Can
> someone explain what these indicate?  Are they correctable errors or
> are they going to result in a bad rip?  Is this caused by cd damage or
> a drive that is misbehaving?

Essentially, this is a related problem to jitter.  Jitter is "we've
asked for data at an address and got something nearby because the
drive's not very good at finding the right spot", this is "our real
addresses need to be offset by X", where X is relatively (if not
actually) constant.

-- 
        Peter