Understanding CUETools' Repair Feature Options

[heyo_speaker]

I have been ripping my CD collection over the last few days and I just came upon the first CD that could not produce a perfect rip for every track. Though none of the tracks could be verified by AccurateRip, 12 out of 13 tracks were verified as accurate by CTDB with a confidence of 7/7. Track #8 is the problem track -- it produces a different Test CRC and Copy CRC every time I try to rip it (which is strange because the CD is not badly scratched at all) and CTDB said this track "Differs in 342 samples."

I decided to attempt to repair the erroneous samples using CUETools, but I had never used CUETools before. After reading a wiki guide, I think I have CUETools configured the way I want it, and now I just have a few questions about the results of the repair I ran on my ripped FLAC tracks.

After the repair is run, CUETools displays the following message:
.\The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue: AR: offset 191, rip accurate (7/7).

(That's right.... It's a weird Asian Zelda CD. You got a problem with that?)

I assume the above message is in reference to my repaired tracks as a whole (since not all of the original ripped tracks were accurate), and is saying they are accurate with a confidence of 7/7. Is this correct?
Does "AR" mean "AccurateRip"? (But isn't the verification coming from CTDB, not AccurateRip?)
Why exactly does it say "offset 191"? Was the "offset" changed during the repair? Or do the repaired tracks need to be bit-shifted to get them to match the database records? .....I don't really know what I'm talking about.

I then looked at the .accurip log produced by CUETools. At the top of the log it says:
CUETools DB: corrected 342 errors.
[AccurateRip ID: 0013e941-00c722b4-aa0a0a0d] found.
It lists each track and says "No match" for each one. Then it re-lists them a few more times with various offsets. For "Offsetted by 191" I get a verification confidence of 5/7, and for "Offsetted by 714" I get a verification confidence of 2/7. ("Offsetted by 203" and "Offsetted by 1395" result in "No match (V2 was not tested)" for each track.)

Since Track #8 is showing up as accurate along with the rest of the tracks (for offsets of 191 and 714), I assume this log is also referring to the repaired (output) track files, not the source files, because the original Track #8 file contains errors. Is this correct?

Also, I'm not sure what this offsetting means exactly. Do my original ripped track FLAC files themselves contain shifted bits (when decoded) due to me having a weird pressing of the CD? Or does it have something to do with a difference in the TOC of my pressing? (But the TOC is not actually recorded in any of my ripped tracks, or in the cue sheet, right? So how could that have any effect on my ripped tracks?) So did CUETools actually "offset" my ripped tracks somehow when creating the repaired copies? (I thought maybe I would just see a difference in the output cue sheet, but it almost exactly matches the original cue sheet generated by Exact Audio Copy.) Again.... I just don't know what I'm talking about.

The last part of the .accurip log lists each track again:

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100.0 [9E883418] [6FBC8EC3]
01 96.2 [C5ABD73E] [6C65BB69] CRC32
02 100.0 [ACE173A7] [B02048D3] CRC32
03 98.5 [4BB67110] [6DE58396] CRC32
04 73.6 [E1513EFA] [27EA9AB4] CRC32
05 40.4 [406DA794] [3B7C4FC1] CRC32
06 77.2 [3567D55A] [599A9C65] CRC32
07 88.0 [38FC292F] [B9D63192] CRC32
08 85.3 [0CD2A808] [A3EBC895] [FE8930B8]
09 97.4 [68C95FBA] [EFD8DF3A] CRC32
10 100.0 [FA726AEE] [9AA0F404] CRC32
11 39.8 [FEE35CE0] [CA074D9B] CRC32
12 69.5 [9020B730] [3CA6205B] CRC32
13 100.0 [2E8E95C7] [61B21350] CRC32

As you can see, the problematic Track #8 stands out by having a third CRC listed. The CRC under the "LOG" column is the one that matches the CRC generated by EAC for the original rip. So I assume the other 2 CRCs were calculated for the new repaired copy of the track. So does this section of the log just serve the purpose of showing me the new CRCs for any repaired tracks? What is the purpose of each column?

Ultimately, I am mainly wondering whether my tracks are now repaired, and am wondering if the "offset" of the tracks was changed at all and what that means, and am wondering how confident I can be in the accuracy of the output FLAC track files. (Is it 7/7 confidence or is it really 5/7 confidence, or 0/7 confidence? I'm not sure how the offset plays in.) I also just want to generally understand what I'm seeing when I work with CUETools.

I have one last, possibly totally unrelated question for anyone who can answer it. It's probably nothing I should be concerned about, but... I noticed something strange. The log file for the original rip created by EAC (a .log file) is 18.6 KB in size. ...The .log file copy created by CUETools (which is word-for-word IDENTICAL to the original .log file) is only 9.33 KB in size. If I copy and paste ALL the text from the 18.6 KB .log file into a new .txt file and save it, it is only 9.33 KB. .... So what is EAC doing when it creates its log files that is almost exactly doubling the size? ....It's just a weird thing that is confusing my understanding of the digital universe and making me feel ignorant.

Thank you very much to anyone who can help with any of my questions.

This post has been edited by heyo_speaker: Dec 31 2012, 09:22