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: CUETools and AccurateRip disagreeing (Read 1824 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools and AccurateRip disagreeing

Hi, I'm super new this, so apologies if this is a newbie question. When I use EAC or CUERipper to rip my CDs, I've noticed that some times AR would return "cannot be verified as accurate" for all of the tracks, but then CTDB would return matches for all the tracks. The converse also happens occasionally. Below is a an example of logs for the same CD. Why does this happen, and which result should I believe? Thanks in advance for any help you can give.

Quote
AccurateRip summary
Track  1  cannot be verified as accurate (confidence 2)  [F4386EAA], AccurateRip returned [9C41A1CD]
Track  2  cannot be verified as accurate (confidence 2)  [01D393E0], AccurateRip returned [CD5170C5]
Track  3  cannot be verified as accurate (confidence 2)  [D91E4773], AccurateRip returned [45277B9C]
Track  4  cannot be verified as accurate (confidence 2)  [2567B63C], AccurateRip returned [168A648A]
Track  5  cannot be verified as accurate (confidence 2)  [2234F4DA], AccurateRip returned [34FFEC43]
Track  6  cannot be verified as accurate (confidence 2)  [61B1A7C2], AccurateRip returned [22B63ED0]
Track  7  cannot be verified as accurate (confidence 2)  [37EDB375], AccurateRip returned [0E7E3B2D]
Track  8  cannot be verified as accurate (confidence 2)  [66B5AB94], AccurateRip returned [AA58C4DD]
Track  9  cannot be verified as accurate (confidence 2)  [B95CA893], AccurateRip returned [36F5DE5A]
Track 10  cannot be verified as accurate (confidence 2)  [3F5F7601], AccurateRip returned [08063B1D]
Track 11  cannot be verified as accurate (confidence 2)  [BFC50150], AccurateRip returned [91C0DEA6]
Track 12  cannot be verified as accurate (confidence 2)  [9235B57A], AccurateRip returned [3F74A571]
Track 13  cannot be verified as accurate (confidence 2)  [49C0B79F], AccurateRip returned [B8C9B759]
Track 14  cannot be verified as accurate (confidence 2)  [B2FE3B86], AccurateRip returned [79963115]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

Quote
[CTDB TOCID: sGBpmtqwx5FnN60i90KZw5P16Rw-] found.
        [ CTDBID ] Status
        [5d1ba681] (4/4) Accurately ripped
Track | CTDB Status
  1   | (4/4) Accurately ripped
  2   | (4/4) Accurately ripped
  3   | (4/4) Accurately ripped
  4   | (4/4) Accurately ripped
  5   | (4/4) Accurately ripped
  6   | (4/4) Accurately ripped
  7   | (4/4) Accurately ripped
  8   | (4/4) Accurately ripped
  9   | (4/4) Accurately ripped
 10   | (4/4) Accurately ripped
 11   | (4/4) Accurately ripped
 12   | (4/4) Accurately ripped
 13   | (4/4) Accurately ripped
 14   | (4/4) Accurately ripped

Re: CUETools and AccurateRip disagreeing

Reply #1 –
I've seen this several times, too. As the log says, your pressing may not be in the EAC database. I do a test in burst mode, then a rip in secure mode, and if the test and read checksums in EAC match, I'll accept it. Having CUETools verification is an extra layer of security.

Re: CUETools and AccurateRip disagreeing

Reply #2 –
AccurateRip and the CUETools DB are two different databases. A rip could be in one and not in another.

One would believe that since AR has been the more supported solution over time, that number should be higher - but there are several reasons why CTDB sometimes give higher count:
* CTDB is updated live with every submission, while AR takes some time for the next edition. If the CD is newly released, the CTDB count could increase
* AR has traditionally purged results from unreliable drives. (That scrutiny is also, I think, the reason whey it isn't updated live.)
* CTDB has allowed for certain updates from scanned files. No problem if you actually rip CDs then it suffices that someone else has gotten the same rip as you - and who cares that pyracee gets a false "OK"?

Re: CUETools and AccurateRip disagreeing

Reply #3 –
For the accuurate rip database, the results for unknown releases or pressings are not stored directly in the main DB, They are stored separately. Only after an amount of same results they will be moved to the main DB.

Re: CUETools and AccurateRip disagreeing

Reply #4 –
Thank you everyone who's responded. This is super helpful. A couple follow up questions:

1) Am I understanding it correctly then that as long as one of AR or CTDB returns a match it's safe to assume I'm good to go? (Sometimes I get the reverse situation where AR returns a match, albeit a low confidence one, and CTDB shows 0/x match.)

2) For CDs with very few records in AR or CTDB, is it more reliable to just do a test and copy to see if the two matches?

3)
Quote from: Aleron Ives on
I do a test in burst mode, then a rip in secure mode, and if the test and read checksums in EAC match, I'll accept it.
Is there a way to do this automatically in EAC? As far as I can tell, it always tests and reads in whatever mode set in drive options, so either I test in secure mode too, or I'd have to keep toggling the option between test and read. Is there a setting I'm missing that could automatically test in burst and rip in secure?

Re: CUETools and AccurateRip disagreeing

Reply #5 –
1) Yes.

2) One should be enough. But in exceptional cases it could be that test and copy is a good thing. There are CDs with pressing defects which may lead these drives to read this byte and those drives to read that byte, and sometimes even this drive to happily and consistently read this in burst, while consistently (not necessarily happily) read that in secure mode.
I had a case of a Pink Floyd album that had all tracks but one with very high AR score, and TGGITS had about half. That means that two pressings disagreed. By looking that the signal, I saw that it was mine that had a single sample wrong. Never ever had a chance to detect it by ear, but ... fascinating.

This was no case of "low" score. Had it been 4, 4, 2, 4, 4, 4 then I would just have shrugged it off as coincidence.


Which leads to the "test in burst, rip secure" ... most often it is not necessary, but:

3) I don't know, I ripped with dBpoweramp, but that one tests in burst and accepts if AccurateRip matches.
So your workflow could be test in Burst, accept if database hits - and if not, switch to Secure.

Re: CUETools and AccurateRip disagreeing

Reply #6 –
Quote from: ReclusiveOne on
Is there a way to do this automatically in EAC? As far as I can tell, it always tests and reads in whatever mode set in drive options, so either I test in secure mode too, or I'd have to keep toggling the option between test and read.
EAC supports the creation of profiles with various settings, so I have Fast and Secure profiles that I toggle depending on which mode I want to use for ripping. It's marginally faster than going into the menu and changing the setting manually, and it ensures that I don't accidentally change any other settings in the process. When my CD isn't in AR or CTDB, this is the best method I've found for ensuring I got a correct rip, assuming the CD is pristine enough to rip properly in burst mode.