.\The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue: AR: offset 191, rip accurate (7/7).
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.
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.
AR stores records this way
What is the purpose of each column?
There is a potential problem. You did the repair using a 'batch mode'. Had there been more than one recovery record, CUETools couldn't display a choice window (popups disabled in batch modes) and the repair script would have aborted. You need to select a file (cue, m3u) or file grouping (FLACs grouped by CUETools) with "Input" in Folder browser' mode when doing a repair.
As above, this is just showing the 'expected' result of the repair. Verification wasn't actually run.
...but to avoid problems I should have selected the "The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue" cue sheet?
Does this mean that, to be safe, after creating a repaired copy of my tracks, I should run CUETools' "Verify" feature on the repaired tracks?
How does the starting position have an effect on the bits that get copied to my hard drive?
So I'm guessing AccurateRip does not look for matching records with different offsets, but CTDB does. Is this correct?
The CTDB plugin for EAC must not tell you in the EAC rip log when your rip had to be offset to match any database records. For example, for the Zelda CD I initially posted about, it reported "(7/7) Accurately ripped" for each track except the bad one, but it wasn't until after processing the tracks with CUETools and looked at the .accurip log that I learned an offset was required to find any matching records in the database.