Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: How "sure" is the CUETools repair result? (Read 412 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How "sure" is the CUETools repair result?

Hi,

I am amazed with the 'repair' functionality of CUETools. It helped me correct a few inacurate rips of my old CDs.

However, I wanted to ask (because I can't verify it myself, as the CDs don't rip consistently) if the repair result is 100% bit-perfect with the original? I mean... provided that the repair succeeded, of course.

I have verified with the AccurateDB that the corrected rips are accurate, but in fact this verification checks that the checksums are the same, which means that the data is the same with SOME probability. Does the repair process implementation details guarantee that the repair, if successful, is 100% bit-perfect?

Best,
Glorifyday
 

Re: How "sure" is the CUETools repair result?

Reply #1 –
Here's a few things I know:
AccurateRip ignores the first 5 sectors and last 5 sectors of a rip.
CTDB ignores the first 10 sectors and last 10 sectors of a rip.
The 'repair' is based on CTDB. It is possible to repair a rip and still show inaccurate in AccurateRip between sectors 5 and 10 in from either end.
A recovery record stored in CTDB is uploaded along with the offset-finding checksum and CRC32 (excludes ignored sectors) of the first unique rip submitted with sufficient quality. So it is possible to repair your rip to a one-off bad rip. It is suggested not to use recovery records for repair that are 1/x .
The recovery record used for repair is similar to parchive.
The repair script does not verify the files after repair. The result log only shows the 'expected' result.
korth