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 AR verification (Read 8700 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools AR verification

I have a problem understanding the status window of CUE Tools when I've checked a disc against the AR database.

Let me show you an example. I have two versions of Porcupine Tree's Deadwing. I checked both with their cuesheet. The logs of CUETools look as follows:





Does this mean both rips are correct and bit-identical but the latter is shifted by an offset of 30?

CUETools AR verification

Reply #1 –
Both rips have the same Disc ID. The CRC values for the first rip match the CRC values for the second "Offsetted by 30" rip. So yes, the latter is shifted by an offset of 30. However, the two rips are not bit-identical because they are offset by 30 samples.

I would say your first rip is "correct" because it has a somewhat high AccurateRip confidence of around 89. Your second rip could be a different pressing compared to the two in the AccurateRip database, or possibly a read sample offset correction was not used.

CUETools AR verification

Reply #2 –
Thanks for clarifying this. Because of the offset it's difficult to say if the audio data is bit identical. Should it be because the disc id's are the same? Or could a different pressing vary?

CUETools AR verification

Reply #3 –
Quote from: foo_on_air on
Because of the offset it's difficult to say if the audio data is bit identical.

It's quite easy to say that the audio data is bit identical (minus the shift, of course).

Quote from: foo_on_air on
Should it be because the disc id's are the same?

No, it's because the checksums match.

Quote from: foo_on_air on
Or could a different pressing vary?

The pressings can vary to the point were at least some of the checksums don't match, yes.

Are these legal downloads for which you're requesting help?

CUETools AR verification

Reply #4 –
Quote from: greynol on
Are these legal downloads for which you're requesting help?

Is this relevant for the topic? But to answer your question - one is my personal rip, the other is from one of my friends. None is downloaded!

CUETools AR verification

Reply #5 –
Good, then you should be able to adjust the offset of your disc to match the rip you got from your friend if you like (or vice-versa), though I have no idea why you'd want to do this.

That is all.

CUETools AR verification

Reply #6 –
30 samples / 44,100 samples per second = 0.00068 seconds. I don't think that your and your friend's music being out of phase by 0.00068 seconds is anything to worry about.

Can't your friend correct his/her read sample offset correction value (assuming he's using a program such as Exact Audio Copy, foobar2000, or dBpoweramp that lets you specify this)?

CUETools AR verification

Reply #7 –
Quote from: NightOwl on
Can't your friend correct his/her read sample offset correction value (assuming he's using a program such as Exact Audio Copy, foobar2000, or dBpoweramp that lets you specify this)?

Yes, he can. I wanted to know if my rip is the correct one. Given that with my corrected offsets roughly 90 results are correlating with my rip it should be safe to say that my setup seems ok.
 

CUETools AR verification

Reply #8 –
Quote from: NightOwl on
I don't think that your and your friend's music being out of phase by 0.00068 seconds is anything to worry about.

Out of fear of misleading people into thinking that offsets create an audible difference, I would refrain from characterizing offsets using the term, "out of phase."

Regarding which rip is the *correct* one, there is no reason there only needs to be one *correct* rip.  Besides, the precision of the reference used to determine offsets was brought into question a few years back.  Ironically, the suggestion is that the second rip that you presented has the more precise offset.  Still, there is no reason to say that the other two submissions with an offset of -664 samples relative to the one 90 submissions are incorrect; no reason whatsoever.

CUETools AR verification

Reply #9 –
Hi guys, i'm also a beginner with CUETools and having difficulties to interpret it's verification results. Example:
Code: [Select]
[CUETools log; Date: 11.05.2011 22:10:56; Version: 2.1.1]
[CTDB TOCID: 3elGProhCMBkJe4d0GE0pP99gII-] disk not present in database.
[AccurateRip ID: 0025e4c3-0197b5c7-c411990e] found.
Track   [ CRC    ] Status
 01     [6c39d6db] (0/8) No match
 02     [cc03f401] (0/8) No match
 03     [9559f4c4] (0/8) No match
 04     [08af4e99] (0/8) No match
 05     [85f7355a] (0/8) No match
 06     [e8c62fb4] (0/8) No match
 07     [c0c0d3b2] (0/8) No match
 08     [33ac7318] (0/8) No match
 09     [2fb3941a] (0/8) No match
 10     [0003e70a] (0/8) No match
 11     [b9adec82] (0/8) No match
 12     [7433092a] (0/7) No match
 13     [36910ebb] (0/8) No match
 14     [bcf80935] (0/8) No match
Offsetted by 676:
 01     [2ab70edf] (8/8) Accurately ripped
 02     [d690706d] (8/8) Accurately ripped
 03     [5186ff06] (8/8) Accurately ripped
 04     [c14f595a] (8/8) Accurately ripped
 05     [e34243f4] (8/8) Accurately ripped
 06     [fc67102b] (8/8) Accurately ripped
 07     [c23430f9] (8/8) Accurately ripped
 08     [414e2c40] (8/8) Accurately ripped
 09     [52e4e5ca] (8/8) Accurately ripped
 10     [a3e2e7c1] (8/8) Accurately ripped
 11     [988c03c6] (8/8) Accurately ripped
 12     [9aa26663] (7/7) Accurately ripped
 13     [627ce68f] (8/8) Accurately ripped
 14     [aaaf5a0a] (8/8) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --   97,7 [477E3AAD] [C0168583]           
 01   96,6 [469C25D0] [4153744E]           
 02   96,6 [4702CA2F] [79189DD3]           
 03   96,6 [1462AA9E] [2F01ED97]           
 04   96,6 [24BFB783] [FCC932B3]           
 05   96,6 [D44AC357] [C2E8B8D2]           
 06   97,7 [38B90B8A] [96BD7D8A]           
 07   96,6 [4DD4FAE8] [162F8A11]           
 08   96,6 [146B3B84] [7ACCE357]           
 09   96,6 [89FF5CB0] [3A3426B3]           
 10   97,7 [B087CACC] [00F31F4A]           
 11   96,6 [CFA40626] [799B9650]           
 12   96,6 [4EB97D2B] [963DC1F4]           
 13   97,7 [64FEDD74] [F7B055EA]           
 14   97,7 [D4870D53] [DB1EA60C]

I've got here 3 different columns, so what exactly does each say about my copy?
If there's an offset issue how could i fix it in CUETools?
Hope someone could explain this as simple as possible, thanx in advance!

CUETools AR verification

Reply #10 –
First section says that there is no match with the CD as-is.
Second section says that if you shift the entire bitstream 676 samples (forward or backward, I don't recall), then it matches 8 of 8 (except 7 of 7 for track 12).

Such results are frequent, and are due to the fact that CD burners (and readers) don't start at precisely the same point. Therefore, if the same file is burnt to two different masters (say, one at an American CD manufactorer and one at a Japanese) on two different pieces of equipment, the bitstream will probably be offset.

So either that happened (you have a less prevalent pressing, but after shifting it matches to all the other entries) -- or possibly you did not use CD ripping software which adjusts for the similar difference in CD ROM readers.


Changing offset? Not necessary. The only thing different is that the music starts 676 samples (0.015 seconds, right?) earlier or later, and ends 676 samples later or earlier than the other presses.

CUETools AR verification

Reply #11 –
And the third section first calculates a "finer" checksum (in terms of less probability of collision, if I understand right) in the CRC32 column, and then in the rightmost column a CRC32 with zero samples removed. The latter is usual if you compare two albums which you suspect are true shifts of each other AND start and end with nulls (some don't, and even the slightest -60 dB fadeout noise cut off a millisecond too early, will change the CRC) -- they will have equal checksum. However, the likelihood of false identification also increases by removing nulls.

CUETools AR verification

Reply #13 –
I actually find this somewhat useful, as it turns out that some pressing-pairs seem to differ in offset on only some files. (I was unwise not to sort my CDs in «Remasters» (i.e., visibly marked as such), «Reissues» and others upon ripping.)