[Paranoia-dev] C2 error support.

[xiphmont at xiph.org]

> Here is an initial patch.  It would be nice if people could test
> this and give feedback.

C2 error information is on the short-term feature list (along with
more sophisticated reconstruction than offered by the redbook spec),
so allow me to try to bend this all into that direction :-)

> Some comments about the patch:
> - I've merged all the i_read_mmc() functions to 1 function
>  so that not all of them need to be modified.

The dispatch design currently there is cute and badly out of date, and
the next major release with new features (including C2) should ditch
the old interface entirely.

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.

> - rs was set wrong in verify_read_command().  They all had
>  the DAP bit inverted.

Oh, ha, you're right.  I had to look three times to see it even after
you told me. "Functional testing does not necessarily find
cosmetic/informational errors"

> - There are still a few TODOs in it.

Good to get it working, play with it, and submit for review before
going too all out.

> 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.

> - 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?

>  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?

> - 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 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.

>  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.

Monty