Skip to main content
Topic: CUETools AR verification (Read 6350 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
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).

Should it be because the disc id's are the same?

No, it's because the checksums match.

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?
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

CUETools AR verification

Reply #4
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.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

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
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
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.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

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.
High Voltage socket-nose-avatar

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.
High Voltage socket-nose-avatar

CUETools AR verification

Reply #12
...oh how I wish we were never offered the option to calculate a CRC over just a portion of the audio data.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

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.)
High Voltage socket-nose-avatar

 
SimplePortal 1.0.0 RC1 © 2008-2020