IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Understanding CUETools' Repair Feature
heyo_speaker
post Dec 31 2012, 08:45
Post #1





Group: Members
Posts: 51
Joined: 15-August 07
Member No.: 46215



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
Go to the top of the page
+Quote Post
korth
post Dec 31 2012, 14:57
Post #2





Group: Members
Posts: 417
Joined: 13-March 11
Member No.: 88969



Your repair looks successful. Offset was not changed. Here's another wiki page to look at.
QUOTE
.\The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue: AR: offset 191, rip accurate (7/7).
This single-line summary is just showing the 'expected' result of the repair. Verification wasn't run. AR is for AccurateRip and CTDB isn't displayed after repair. The 'offset' means you matched an alternate pressing. There were no matches to your pressing in the AR database (your drive's 'read offset correction' was set by AccurateRip in EAC). AR stores records this way, CTDB ignores offsets.
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.

This post has been edited by korth: Dec 31 2012, 15:52


--------------------
korth
Go to the top of the page
+Quote Post
korth
post Dec 31 2012, 16:23
Post #3





Group: Members
Posts: 417
Joined: 13-March 11
Member No.: 88969



QUOTE
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?
As above, this is just showing the 'expected' result of the repair. Verification wasn't actually run.
QUOTE
Also, I'm not sure what this offsetting means exactly.
Reading this and this might help your understanding of offsets.
QUOTE
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.
Original EAC log was UNICODE and the one by CUETools is ANSI. Known issue.

To expand on my statement
QUOTE
AR stores records this way
in the above reply, I meant ARv1. CUETools doesn't fully support all features of ARv2 at this time.

This post has been edited by korth: Dec 31 2012, 16:32


--------------------
korth
Go to the top of the page
+Quote Post
korth
post Dec 31 2012, 17:25
Post #4





Group: Members
Posts: 417
Joined: 13-March 11
Member No.: 88969



QUOTE
What is the purpose of each column?
To expand on what the wiki page I linked above says about the EAC-style info section, older versions of EAC could include or exclude null samples in CRC calculation based on a setting. The [ CRC32 ] and [W/O NULL] columns represent the CRC values of your rip for each possible setting.

This post has been edited by korth: Dec 31 2012, 17:25


--------------------
korth
Go to the top of the page
+Quote Post
heyo_speaker
post Jan 1 2013, 02:02
Post #5





Group: Members
Posts: 51
Joined: 15-August 07
Member No.: 46215



Thanks again for all the help, korth!


QUOTE
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.

Do you mean that in the CUETools folder browser, I had selected the "The Legend of Zelda- Ocarina of Time Hyrule Symphony" folder, but to avoid problems I should have selected the "The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue" cue sheet?


QUOTE
As above, this is just showing the 'expected' result of the repair. Verification wasn't actually run.

[^ in reference to the .accurip log produced by CUETools]
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?


Offsets:
I know that a different pressing can have a different starting position on the CD, and this difference could be referred to as an "offset", but what I don't understand is how this offset can affect the ripped tracks. In two different pressings which are identical except for the offset, shouldn't the ripped tracks be 100% identical, despite the tracks having a different starting position on the CD? How does the starting position have an effect on the bits that get copied to my hard drive?

This post has been edited by heyo_speaker: Jan 1 2013, 02:02
Go to the top of the page
+Quote Post
korth
post Jan 1 2013, 02:13
Post #6





Group: Members
Posts: 417
Joined: 13-March 11
Member No.: 88969



QUOTE
...but to avoid problems I should have selected the "The Legend of Zelda- Ocarina of Time Hyrule Symphony.cue" cue sheet?
Yes.
QUOTE
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?
I would. At least until you're confident it works correctly.
QUOTE
How does the starting position have an effect on the bits that get copied to my hard drive?
Changes the CRC. The position of the data has changed within the frame by [offset amount] samples.

This post has been edited by korth: Jan 1 2013, 02:15


--------------------
korth
Go to the top of the page
+Quote Post
heyo_speaker
post Jan 1 2013, 04:42
Post #7





Group: Members
Posts: 51
Joined: 15-August 07
Member No.: 46215




It's all so clear now! So if I understand it correctly, EAC (and other CD rippers?) rip on a frame-by-frame basis, not a sample-by-sample basis, and a difference in the starting position between two pressings is likely to cause the audio data to be shifted within every frame on the CD. When the ripped track is submitted to an online database, CRCs are calculated for various offsets to look for a match that simply has a different offset.

Thanks.
Go to the top of the page
+Quote Post
mjb2006
post Jan 1 2013, 06:51
Post #8





Group: Members
Posts: 760
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Well, rippers do read whole frames at a time, but the offsets are measured in samples. An offset-correcting ripper shifts each frame's worth of samples by a certain amount such that reading the same frame from that CD always yields the same set of samples, no matter what drive is used.

The problem is that a ripper can be misconfigured with the wrong offset correction, or the CD being ripped might actually be a CD-R copy (or virtually mounted ISO) made without both read & write offset correction, or the CD can be a different pressing (as explained in the wiki article korth linked to). In all three of those situaitons, you'll get the same set of samples, but shifted a little one way or the other. The databases are able to cope with this, as you surmised. I'm not sure it's by the exact method you guessed, but that's the end result.
Go to the top of the page
+Quote Post
heyo_speaker
post Jan 1 2013, 11:56
Post #9





Group: Members
Posts: 51
Joined: 15-August 07
Member No.: 46215




Thanks. ....I just learned from vgmdb.net that this set of Zelda CDs I have are all bootlegs, which would explain the offset difference. (I had no idea because they look pretty professional.) Looking at the EAC rip logs, it looks like none of the tracks from any of the CDs could be verified by AccurateRip, but almost all of them were verified by CTDB.

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.

I'm glad to know that, except for the one bad track that I had to repair, and a handful of tracks on a different CD that had no match in the CTDB database, all the tracks had matches in the database, albeit with an offset that should have no noticeable effect on playback.
Go to the top of the page
+Quote Post
korth
post Jan 1 2013, 15:53
Post #10





Group: Members
Posts: 417
Joined: 13-March 11
Member No.: 88969



QUOTE
So I'm guessing AccurateRip does not look for matching records with different offsets, but CTDB does. Is this correct?
EAC's built-in AccurateRip app doesn't check ARv1 at other offsets. I have not experienced it checking ARv2 at other offsets.
The CTDB stores one record for all offsets so The EAC CTDB plugin doesn't need to check CTDB at other offsets.
QUOTE
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.
The EAC CTDB plugin only contacts CTDB (CUETools database). EAC's built-in AccurateRip app only contacts the AccurateRip database. The EAC CTDB plugin and EAC's built-in AccurateRip app don't share data.
The CUETools app can contact both the AccurateRip database and CTDB (CUETools database). The CUETools app can check ARv1 at other offsets. The CUETools app can not check ARv2 at other offsets.


--------------------
korth
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th July 2014 - 01:37