[Paranoia-dev] C2 error support.

[Kurt Roeckx]

On Wed, May 27, 2009 at 04:58:28PM -0400, xiphmont at xiph.org wrote:
> We need to make sure to probe for the capability carefully, pay
> attention to whether or not it is actually working, and not attempt to
> use it on dives that don't support it correctly.  It's less common
> that newer drives will brick if you ask them for something they can't
> do, but it's a regular problem in old drives.

The current code looks at the (legacy) 2A page to see if C2 is
supported or not, and then always turns it on.  There are a few
things wrong with it:
- If you look at the mmc1 spec it says that being able to request
  it is mandatory, but drives that don't support it should just
  return 0 bits, giving you the impression that there is no
  error.  But it's not because that's what the spec says, that
  that is what all drives do.  So we might need a test to see
  how much data we really receive when we requested it.
- If your drive fully supports it, you might want to test the
  effect of having it turned on or off
- We should probably not rely on the legacy code page to detect
  it for new drives.

> > I've been testing this with a CD with lots of scratches.  What
> > I've seen:
> > - My plextor reads this CD at full speed (40x) every time, always
> >  identical, never returns C2 errors.
> 
> That sounds problematic.  Unless it's changed, the Plextors should be
> among the drives that return full corrected and uncorrected C2
> information.  Even a pristine disc has corrected errors.

C2 error information is only uncorrected errors, there is no
indication of corrected errors.

Looking at documentation of plextor software, it seems they can
also read C1 and C2 error rates, but they probably get that using
vendor specific commands.

Also not that you do not get the C1/C2 error correcting bytes
themself (8*98=784), just 1 bit for every byte, so 24/8*98=294
bytes.

> > - The other drives have problems reading this, even at speed 1.
> >  Without this patch I got 20+ different files.
> 
> I have not yet looked at what you're doing with the C2 information you
> collect-- how is the matching/verification algorithm modified?

The only thing it does it marking samples that had an error
as unread.  The code does the same thing if the whole read
wasn't complete.  I did not really look into how all the
algorithmes work, but it seems this was enough for me to get
it working.

> >  Once I got a total of 1.8 million
> >  C2 errors for 1 track, but the result was still good.
> 
> That sounds about right :-)  Are you leveraging any sort of your own
> reconstruction or relying on the drive to interpolate?

As far as I know, based on the debug info I added, cdparanoia just
reads it multiple times until it got all samples (twice?) without
an error.

If it realy fails to read only some bytes, we could interpolate
ourself.

> > - The current patch marks all samples belonging to 1 byte of c2
> >  error information as having a problem while it should probably
> >  be possible to only mark the sample that is affected.
> 
> *yes*.  Especially as, on a general purpose CPU, we have access to far
> more powerful audio reconstruction techniques than the drive can do in
> firmware.  The better job we do seperating the good samples from the
> bad (even the good bits from the bad bits within samples!), the
> better.

The C1/C2 error correction works on byte basis.  Either the whole
byte is good or bad.  It's designed to handle burst errors and not
single bit errors.

> The physical structure of the CD is going to scatter adjacent samples
> to different parts of the surface such that runs of bad bytes are
> rare.  usually you get interleaved errors, which naturally makes
> recovery earlier.  We must not toss that advantage away.

If I remember correctly, they have sample 0, 2, 4, 6 in subframe 0
and 1, 3, 5, 7 in the next.  If subframe 0 can't be recovered, you
can interpolate the samples based on the other subframe.

> >  For some
> >  reason that's currently unclear to me this always results in a
> >  good file and trying to mark only the bad one resulted in a bad
> >  file.  (Maybe I should mark both left and right instead of only
> >  left or right?)
> 
> Well, we'd need to figure that out :-)  Probably has to do with
> exactly how the matching's been modified to deal with the flags.

I was thinking that maybe the matching now only looks at the left
channel and assumes that if you have a sample for left you also
have the right sample.  But I'll look into that.


Kurt