[Paranoia] Automating "secure" ripping

[Paulo Jose da Silva e Silva]

Hello,

After reading the old thread on "CD Ripping Uncertainty Principle?" and
"CD Ripping Uncertainty Again" and looking at rubyripper, and its
documents

http://rubyforge.org/projects/rubyripper/
http://rubyforge.org/docman/?group_id=1284

I have decided to scratch my own itch and have recoded a slight variant
of rubyripper in Python (I don't know ruby and the code was simple
anyway). I had some main objectives:

1) Drop in replacement of cdparanoia. It should accept all the same
switches.

2) No GUI. Since it can be used in place of cdparanoia, I can use a GUI
that wraps it, like grip.

3) "Correction" by re-ripping a sector with where a problem occurred
until it is the same twice in a row. This idea was borrowed from from
rubyripper, but it is implemented asking for slightly more (two
consecutive rips should be equal, not two out of "many")

4) If any correction is necessary, leave a log with the corrected
positions, so the user can more easily verify the bad parts by him self.
Note that the log is written whenever a correction is necessary, even if
at the end the correction os possible.

I have achieved everything with a slight constraint on (1): the last
argument passed to secure-cdparanoia.py should be the name of the ripped
track in the HD (so it doesn't support the -B option).

If you want to take a look at the code or use it, grab it at

http://www.ime.usp.br/~pjssilva/secure-cdparanoia.py

All you need is Python (2.3 or newer) + cdparanoia in your PATH.

Note that there is no guarantee that a "corrected track" is actually the
correct track in the CD. It is simply based on the principle that if
some bits are unstable in the disk, it should be more likely that they
will map more often to the real, correct, bits. Then, if you see the
same pattern twice in a row, it is more likely to be correct. Actually,
I have a badly scratched CD with a track that sometimes pass this test
for each sector after some trials, but that still generate different
ripped files. EAC can not rip this track correctly either. This is
possible because I only re-check sectors that presented differences in
the first two rips. This is why a log file is *always* create when a
difference is found, even if it is "corrected" at the end.

Any thoughts?

Paulo

Obs: To avoid cache problems, the program always rip the entire track,
even if it only want to correct one sector. 

Obs2: Bug reports are welcome.