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 log weirdness: AccurateRip v1 and v2 give opposite results (Read 6833 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Hello everyone, I'm a bit confused by the following cuetools log on one of my cds:

Code: [Select]
[CUETools log; Date: 05/06/2012 15:39:59; Version: 2.1.2a]
[CTDB TOCID: 2Gb8FWncAEW3IeiKp9rpgj97JRU-] found.
[ CTDBID ] Status
[9a911150] (4/5) Accurately ripped
[b45209c2] (1/5) No match
[AccurateRip ID: 00197708-01236c7a-c80ac80f] found.
Track  [ CRC ] Status
 01 [5f54e96a] (0/3) No match but offset
 02 [57646b16] (0/3) No match but offset
 03 [9e7280e5] (0/3) No match but offset
 04 [abf1582d] (0/3) No match but offset
 05 [4958716f] (0/3) No match but offset
 06 [ba4e9cc3] (0/3) No match but offset
 07 [cf19ab65] (0/3) No match but offset
 08 [cded7c72] (0/3) No match but offset
 09 [6eb8314e] (0/3) No match but offset
 10 [deaf9934] (0/3) No match but offset
 11 [f8f82bc9] (0/3) No match but offset
 12 [71468541] (0/3) No match but offset
 13 [6aebd38a] (0/3) No match but offset
 14 [5e37dd55] (0/3) No match but offset
 15 [8a72fb61] (0/3) No match but offset
AccurateRip v2:
 01 [abbe5c49] (3/3) Accurately ripped
 02 [929abf5e] (3/3) Accurately ripped
 03 [8cff04b3] (3/3) Accurately ripped
 04 [7f6d6db0] (3/3) Accurately ripped
 05 [21eb9d70] (3/3) Accurately ripped
 06 [cd1124b0] (3/3) Accurately ripped
 07 [c40976e7] (3/3) Accurately ripped
 08 [c791fa1d] (3/3) Accurately ripped
 09 [bf796ba4] (3/3) Accurately ripped
 10 [5f7e4aab] (3/3) Accurately ripped
 11 [13e219c8] (3/3) Accurately ripped
 12 [1497578b] (3/3) Accurately ripped
 13 [4815a506] (3/3) Accurately ripped
 14 [d6b65032] (3/3) Accurately ripped
 15 [62e15848] (3/3) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG  ]
 --  99,9 [95D77F94] [63C88A32]  
 01  88,7 [D0EBD16A] [D8C106D5]  CRC32 
 02  99,2 [6DF964C0] [22452ED8]  CRC32 
 03  96,7 [0FD5184D] [CB6E42F1]  CRC32 
 04  96,7 [11EB2AE4] [83194BAF]  CRC32 
 05  96,7 [BF2F35F4] [F5008D3C]  CRC32 
 06  96,7 [48F0FF16] [3A09D3B7]  CRC32 
 07  96,7 [31B962F2] [61394E3C]  CRC32 
 08  96,7 [4E13EC85] [9D8D60E9]  CRC32 
 09  96,7 [AEC45513] [34497790]  CRC32 
 10  96,7 [2F1AF553] [28BB0F0F]  CRC32 
 11  91,9 [2A5E5A2D] [9889EC37]  CRC32 
 12  96,5 [31EFE655] [97BD9820]  CRC32 
 13  99,9 [A336638C] [AE81766F]  CRC32 
 14  58,8 [4B901188] [B5A9AF96]  CRC32 
 15  96,7 [684F9000] [F5F3576D]  CRC32

As you can see, AccurateRip v1 gives a `No match but offset' on every tracks, meaning AFAIK that the start offset is right but the content isn't accurate, when AccurateRip v2 says `Accurately ripped' on every tracks...

How is this possible ? how can a rip not be accurate in v1 and be accurate in v2?

If it was because of a pressing issue, AR v1 would only tell me the data is accurate but offset right ? Also the album was released in 2011 if it can help... Im confused here, thanks for your help

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #1
How is this possible ? how can a rip not be accurate in v1 and be accurate in v2?
Your specific pressing has a v2 entry in the database but not a v1 entry in the database.

If it was because of a pressing issue, AR v1 would only tell me the data is accurate but offset right ?
Apparently the v1 entry has the same offset hash but the data elsewhere is different.  To me this suggests the v1 and v2 versions come from unique and different pressings where the audio data itself is not actually offset.

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #2
hmm ok thanks, that sounds logical and simple, thanks !

EDIT: one thing just to make everything clear, do recent versions of EAC or CUERipper send the V2 CRCs only or both V1 and V2 are computed and sent to the DB?

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #3
CUERipper does not submit to database.  I am pretty sure EAC and dBpoweramp are the only ones to do that and I'm pretty sure the current versions only submit v2.

I do not know if the database is even accepting v1 submissions from older versions of AR.  I doubt it does and suspect that current v1 submissions will eventually be purged.  To me this would be a real shame since v1 is better suited to cross-checking against alternate pressings while v2 is likely no more effective at preventing collisions than v1 which was already good enough for the real world.  It would be bad enough if new titles only enter the database as v2 submissions.

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #4
Apparently the v1 entry has the same offset hash but the data elsewhere is different.  To me this suggests the v1 and v2 versions come from unique and different pressings where the audio data itself is not actually offset.


Actually, I think it's simpler than that. The data is the same, but the AR1 checker sees the AR2 checksums and those are different, even when the data is the same. But the offset hash is the same, so it reports "No match but offset". Essentialy, it thinks it sees a different pressing in the database, when in fact it sees the AR2 checksums for the same pressing. This is something that always happens with new albums, which only have an AR2 submission in the database, but no AR1 submission.

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #5
^ if this is true, then it is really confusing for a random user

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #6
really confusing for a random user

Agreed!

I take it that inside the AR record there is no distinction between v1 hashes and v2 hashes?  If so then I'm not as worried that v1 hashes may be removed from the database.

Even still, checking against alternate pressings for these new titles with CUETools will not be possible unless or until the program is updated, or has this already been done?

Thanks Goratrix!

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #7
^ if this is true, then it is really confusing for a random user

The log has been updated in v2.1.4 to show ARv1 & ARv2 side-by-side at zero offset. CUETools still doesn't support ARv2 cross-pressing verification so at other offsets it now shows 'No match (V2 was not tested)' instead of 'No match but offset' if a non-matching record is found. If all tracks show 'No match (V2 was not tested)' at another offset then there's a chance ARv2 results can be found there.
korth

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #8
That doesn't do anything about the log presented by the OP.

Have there been any changes to help this particular case make more sense?

CUETools still doesn't support ARv2 cross-pressing verification
Thanks for this.

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #9
That doesn't do anything about the log presented by the OP.
No can't do anything about the log without upgrading and verifying again to get the new log.
Quote
Have there been any changes to help this particular case make more sense?
Sorry if the link given above didn't help. I wrote the page mainly to explain the new log. I thought it would show you that the double values (0/3) and (3/3) are now combined in the new side-by-side format to (0+3/3) to show there were only 3 records of which 0 are ARv1 "+"  3 are ARv2 "/" out of 3 total records. 'No match but offset' is no longer shown. A sample of the new log based on what the OP posted would look like this:
Code: [Select]
[AccurateRip ID: 00197708-01236c7a-c80ac80f] found.
Track  [  CRC  |  V2  ] Status
01      [5f54e96a|abbe5c49] (0+3/3) Accurately ripped
02      [57646b16|929abf5e] (0+3/3) Accurately ripped
03      [9e7280e5|8cff04b3] (0+3/3) Accurately ripped
04      [abf1582d|7f6d6db0] (0+3/3) Accurately ripped
05      [4958716f|21eb9d70] (0+3/3) Accurately ripped
06      [ba4e9cc3|cd1124b0] (0+3/3) Accurately ripped
07      [cf19ab65|c40976e7] (0+3/3) Accurately ripped
08      [cded7c72|c791fa1d] (0+3/3) Accurately ripped
09      [6eb8314e|bf796ba4] (0+3/3) Accurately ripped
10      [deaf9934|5f7e4aab] (0+3/3) Accurately ripped
11      [f8f82bc9|13e219c8] (0+3/3) Accurately ripped
12      [71468541|1497578b] (0+3/3) Accurately ripped
13      [6aebd38a|4815a506] (0+3/3) Accurately ripped
14      [5e37dd55|d6b65032] (0+3/3) Accurately ripped
15      [8a72fb61|62e15848] (0+3/3) Accurately ripped
korth

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #10
ok thanks for everything guys, one last thing though, I read v2.1.4 is still in beta, thats why i didn't use it. Is it stable enough to be safely used (ripping + checking) ?

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #11
The new features are stable but one new bug. The new Advanced Settings: Advanced: CTDB: Detailed log = True will make the app crash on some discs with a CD-Extra data track. It is suggested to leave the setting at False for now. I'm still working on a page for the GUI but the Advanced Settings pages are pretty much done. Finished the GUI page for CUERipper and the new Options button.
korth

 

CUETools log weirdness: AccurateRip v1 and v2 give opposite results

Reply #12
Quote
will make the app crash
Sorry, meant it will throw an error message (not crash).
korth