CUETools log weirdness: AccurateRip v1 and v2 give opposite results, [TOS #6: moved from FLAC] Options

[nerdyluke]

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

CODE

[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

This post has been edited by greynol: Jun 5 2012, 16:13

Reason for edit: codeBOX

[greynol]

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.

This post has been edited by greynol: Jun 5 2012, 16:35

[nerdyluke]

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?

This post has been edited by nerdyluke: Jun 5 2012, 16:43

[greynol]

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.

This post has been edited by greynol: Jun 5 2012, 17:20

[Goratrix]

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.

[nerdyluke]

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

[greynol]

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!

This post has been edited by greynol: Jun 6 2012, 00:02

[korth]

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

[greynol]

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.

This post has been edited by greynol: Jun 7 2012, 20:09

[korth]

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.

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

[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

[nerdyluke]

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) ?

[korth]

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]

will make the app crash

Sorry, meant it will throw an error message (not crash).