No errors reported, but inconsistent audio results each time - a couple observations/suggestions about it

[magicgoose]

cyanrip 0.9.0 (9558fa3) - cyanrip-git from AUR, latest commit a.t.m.

Context: I have a difficult-but-probably-salvageable CD which has many bad blocks, and apparently some of these blocks can occasionally read OK, but it's almost impossible to read a full track in one go without returning wrong data. Maybe it is possible in theory to create a perfect copy by combining the good parts of multiple attempts - even though the errors are many, most samples are OK, and there is no drift at all. https://musicbrainz.org/cdtoc/JEcwpGJdYJUgezdvLqzV3w21rhg- - this disk on MB.

With EAC (secure mode), while it often produces a subjectively worse output than cyanrip, an important advantage is that it detects these bad pieces as errors and shows them in the log with an approximate location ("Suspicious position #:##:##").

Cyanrip doesn't seem to detect them as errors, even though the resulting audio data is different on each attempt. It only reports this for example (after ripping this CD with -r 80):

Paranoia status counts:
  READ:          30734
  VERIFY:        15074
  FIXUP_ATOM:    24277
  OVERLAP:       2480

Ripping errors: 0

(with the default retry count, it gives a similar result, only with somewhat higher numbers, and non-zero SKIP.)

README says that:

FIXUP_EDGE/FIXUP_ATOM usually happen if cdparanoia is somewhat struggling, but both are recoverable and lossless

which means there must have been some other kinds of (lossy) errors, not indicated in the log.

1. Would be a big improvement if cyanrip detected such anomalies as ripping errors, even with the default settings. As it is, there's potential of making a rip which seems OK at first glance, but actually isn't.
2. With -Z # >= 1, ripping such a disc basically never completes, because every time at least some of these blocks will be wrong. But what if cyanrip had a mode like -Z but on a block by block basis? Where it would retry until a number of consistent outputs is reached, but on smaller pieces, instead of the entire track. I have a hunch that it could have a much better probability of finishing on such problematic CDs.

[cyanreg]

Would be a big improvement if cyanrip detected such anomalies as ripping errors, even with the default settings. As it is, there's potential of making a rip which seems OK at first glance, but actually isn't.

We tell what cdparanoia tells us. If it reported no errors, we continue. This is why AccuRip exists. According to the author of cdparanoia, the status it outputs is more or less not something to be interpreted, unless there are errors.

With -Z # >= 1, ripping such a disc basically never completes, because every time at least some of these blocks will be wrong. But what if cyanrip had a mode like -Z but on a block by block basis? Where it would retry until a number of consistent outputs is reached, but on smaller pieces, instead of the entire track. I have a hunch that it could have a much better probability of finishing on such problematic CDs.

It would be slower and possibly less reliable, as cdparanoia does not process each block individually, but tends to look at previous and following block as well. Purging its cache on every block and seeking the drive will also be likely massively slower. Patches welcome, though. I HATE the current repeat ripping mode, it is a massive hack.