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: Understanding offset in CUETools (Read 4336 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Understanding offset in CUETools

Please take a look at the CUETools report I got from one of my CDs.
While the CTDB results are pretty clear to me (found a good match in the database), the AccurateRip DB found no match for my disc.
Now, looks like  offsetted by -17, there are 46/312 entries found.
Question: should i correct for this offset or just leave it as is? 17 samples in close to nothing at 44.1 kHz sampling rate...
I'm still new to this program and trying to figure things out.

Code: [Select]
[CUETools log; Date: 10/10/2018 1:10:06 AM; Version: 2.1.6]
[CTDB TOCID: LMwyq2DF4boqDVLvNstLKgSj9I4-] found.
Track | CTDB Status
  1   | (310/313) Accurately ripped
  2   | (311/313) Accurately ripped
  3   | (310/313) Accurately ripped
  4   | (310/313) Accurately ripped
  5   | (310/313) Accurately ripped
  6   | (310/313) Accurately ripped
  7   | (310/313) Accurately ripped
  8   | (309/313) Accurately ripped
  9   | (309/313) Accurately ripped
 10   | (309/313) Accurately ripped
 11   | (226/313) Accurately ripped, or (80/313) differs in 6222 samples @03:08:32-03:08:42
[AccurateRip ID: 0011ecf3-0098e922-8909d00b] found.
Track   [  CRC   |   V2   ] Status
 01     [4e2fabc3|45e429da] (000+000/312) No match
 02     [f89eed5d|18fb90b2] (000+000/314) No match
 03     [b9d9e9e5|137209a0] (000+000/312) No match
 04     [f3888c93|53c0400a] (000+000/313) No match
 05     [6d83d60a|6a95875d] (000+000/312) No match
 06     [ab17bedc|36582ac4] (000+000/311) No match
 07     [5c2ccc4b|88808a59] (000+000/313) No match
 08     [7e92bfb9|0c49c271] (000+000/313) No match
 09     [c9b2373b|97d94acd] (000+000/313) No match
 10     [fbfecc62|2c406913] (000+000/310) No match
 11     [b6316338|ecc0c0b2] (000+000/308) No match
Offsetted by -17:
 01     [e65a42d9] (046/312) Accurately ripped
 02     [e24c2660] (046/314) Accurately ripped
 03     [05228da3] (046/312) Accurately ripped
 04     [6362c1fc] (046/313) Accurately ripped
 05     [bcc13c21] (046/312) Accurately ripped
 06     [cb97fef6] (046/311) Accurately ripped
 07     [032abfb2] (046/313) Accurately ripped
 08     [8eee814c] (046/313) Accurately ripped
 09     [950b8d45] (045/313) Accurately ripped
 10     [1a7094b3] (045/310) Accurately ripped
 11     [df329fd7] (045/308) Accurately ripped
Offsetted by 659:
 01     [e9261641] (004/312) Accurately ripped
 02     [f0912d34] (004/314) Accurately ripped
 03     [adda0f6b] (004/312) Accurately ripped
 04     [6d0548f8] (004/313) Accurately ripped
 05     [1373f725] (004/312) Accurately ripped
 06     [ec60dcce] (004/311) Accurately ripped
 07     [12c78776] (004/313) Accurately ripped
 08     [d7446fe0] (004/313) Accurately ripped
 09     [b3a3995d] (004/313) Accurately ripped
 10     [9c0f590f] (004/310) Accurately ripped
 11     [173dadbb] (004/308) Accurately ripped
Offsetted by -5:
 01     [89fff651] (000/312) No match (V2 was not tested)
 02     [2e4a587c] (000/314) No match (V2 was not tested)
 03     [c0ef473b] (000/312) No match (V2 was not tested)
 04     [d83223d0] (000/313) No match (V2 was not tested)
 05     [93e1304d] (000/312) No match (V2 was not tested)
 06     [2d1f593e] (000/311) No match (V2 was not tested)
 07     [8d4a501e] (000/313) No match (V2 was not tested)
 08     [0ae9f8a8] (000/313) No match (V2 was not tested)
 09     [e763144d] (000/313) No match (V2 was not tested)
 10     [503e61a7] (000/310) No match (V2 was not tested)
 11     [fe7d0ba3] (000/308) No match (V2 was not tested)
Offsetted by 929:
 01     [4b365c4d] (000/312) No match (V2 was not tested)
 02     [9e6894aa] (000/314) No match (V2 was not tested)
 03     [2f585f47] (000/312) No match (V2 was not tested)
 04     [313f621a] (000/313) No match (V2 was not tested)
 05     [fbc2ed03] (000/312) No match (V2 was not tested)
 06     [7ec64c22] (000/311) No match (V2 was not tested)
 07     [b68db8f4] (000/313) No match (V2 was not tested)
 08     [3cde6d76] (000/313) No match (V2 was not tested)
 09     [7054f791] (000/313) No match (V2 was not tested)
 10     [d6a5dc81] (000/310) No match (V2 was not tested)
 11     [d7482729] (000/308) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [4AB26E6F] [E9664C2F]           
 01   89.7 [655E6323] [CDDC5485]           
 02   90.3 [8D1D4F8E] [C9E7F51E]           
 03   60.8 [2695A620] [04206984]           
 04   83.1 [48117DF4] [341FA37C]           
 05   80.6 [1B283788] [5B1B7235]           
 06  100.0 [84FF5BAA] [CCC557ED]           
 07   82.7 [17263C4B] [C36610B8]           
 08   53.9 [30E48F39] [601B103B]           
 09  100.0 [812E2D13] [CA43257A]           
 10   77.1 [64225A03] [9C8364E0]           
 11   56.0 [45CCB9E4] [4B5DE26A]          


Also, should I bother fixing the 11th track? Seems like 6222 samples are found to be different from the database @03:08:32-03:08:42. I did notice that only 80 out of 313 entries have this difference so maybe I shouldn't even worry about it?

Just for the sake of the argument (I'm trying to learn how to fix errors if there are any), I tried using repair function in the CUETools but after processing I get this result for 11th track - there is no longer a match. How can this be?

Code: [Select]
[CUETools log; Date: 10/10/2018 7:46:29 PM; Version: 2.1.6]
CUETools DB: corrected 6222 errors.
[AccurateRip ID: 0011ecf3-0098e922-8909d00b] found.
Track   [  CRC   |   V2   ] Status
 01     [e65a42d9|e48f617d] (046+164/312) Accurately ripped
 02     [e24c2660|089b8033] (046+164/314) Accurately ripped
 03     [05228da3|63a592a5] (046+164/312) Accurately ripped
 04     [6362c1fc|c891f213] (046+164/313) Accurately ripped
 05     [bcc13c21|bee1b3cd] (046+165/312) Accurately ripped
 06     [cb97fef6|5cc140e5] (046+165/311) Accurately ripped
 07     [032abfb2|329e0069] (046+165/313) Accurately ripped
 08     [8eee814c|21384ea7] (046+165/313) Accurately ripped
 09     [950b8d45|67afd527] (045+165/313) Accurately ripped
 10     [1a7094b3|5155fa76] (045+165/310) Accurately ripped
 11     [c74fd343|9edf5979] (000+000/308) No match

Then I ran "verify" function on the repaired file and I got another result:
Code: [Select]
[CUETools log; Date: 10/10/2018 7:55:31 PM; Version: 2.1.6]
[CTDB TOCID: LMwyq2DF4boqDVLvNstLKgSj9I4-] found.
Track | CTDB Status
  1   | (311/314) Accurately ripped
  2   | (312/314) Accurately ripped
  3   | (311/314) Accurately ripped
  4   | (311/314) Accurately ripped
  5   | (311/314) Accurately ripped
  6   | (311/314) Accurately ripped
  7   | (311/314) Accurately ripped
  8   | (310/314) Accurately ripped
  9   | (310/314) Accurately ripped
 10   | (310/314) Accurately ripped
 11   | ( 83/314) Accurately ripped, or (226/314) differs in 22 samples @03:08:32
[AccurateRip ID: 0011ecf3-0098e922-8909d00b] found.
Track   [  CRC   |   V2   ] Status
 01     [e65a42d9|e48f617d] (046+164/312) Accurately ripped
 02     [e24c2660|089b8033] (046+164/314) Accurately ripped
 03     [05228da3|63a592a5] (046+164/312) Accurately ripped
 04     [6362c1fc|c891f213] (046+164/313) Accurately ripped
 05     [bcc13c21|bee1b3cd] (046+165/312) Accurately ripped
 06     [cb97fef6|5cc140e5] (046+165/311) Accurately ripped
 07     [032abfb2|329e0069] (046+165/313) Accurately ripped
 08     [8eee814c|21384ea7] (046+165/313) Accurately ripped
 09     [950b8d45|67afd527] (045+165/313) Accurately ripped
 10     [1a7094b3|5155fa76] (045+165/310) Accurately ripped
 11     [c74fd343|9edf5979] (000+000/308) No match
Offsetted by 12:
 01     [89fff651] (000/312) No match (V2 was not tested)
 02     [2e4a587c] (000/314) No match (V2 was not tested)
 03     [c0ef473b] (000/312) No match (V2 was not tested)
 04     [d83223d0] (000/313) No match (V2 was not tested)
 05     [93e1304d] (000/312) No match (V2 was not tested)
 06     [2d1f593e] (000/311) No match (V2 was not tested)
 07     [8d4a501e] (000/313) No match (V2 was not tested)
 08     [0ae9f8a8] (000/313) No match (V2 was not tested)
 09     [e763144d] (000/313) No match (V2 was not tested)
 10     [503e61a7] (000/310) No match (V2 was not tested)
 11     [e616af47] (000/308) No match (V2 was not tested)
Offsetted by 676:
 01     [e9261641] (004/312) Accurately ripped
 02     [f0912d34] (004/314) Accurately ripped
 03     [adda0f6b] (004/312) Accurately ripped
 04     [6d0548f8] (004/313) Accurately ripped
 05     [1373f725] (004/312) Accurately ripped
 06     [ec60dcce] (004/311) Accurately ripped
 07     [12c78776] (004/313) Accurately ripped
 08     [d7446fe0] (004/313) Accurately ripped
 09     [b3a3995d] (004/313) Accurately ripped
 10     [9c0f590f] (004/310) Accurately ripped
 11     [a792f29a] (000/308) No match (V2 was not tested)
Offsetted by 946:
 01     [4b365c4d] (000/312) No match (V2 was not tested)
 02     [9e6894aa] (000/314) No match (V2 was not tested)
 03     [2f585f47] (000/312) No match (V2 was not tested)
 04     [313f621a] (000/313) No match (V2 was not tested)
 05     [fbc2ed03] (000/312) No match (V2 was not tested)
 06     [7ec64c22] (000/311) No match (V2 was not tested)
 07     [b68db8f4] (000/313) No match (V2 was not tested)
 08     [3cde6d76] (000/313) No match (V2 was not tested)
 09     [7054f791] (000/313) No match (V2 was not tested)
 10     [d6a5dc81] (000/310) No match (V2 was not tested)
 11     [65178de0] (000/308) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [56D7D3C4] [5BA01976] [4AB26E6F]
 01   89.7 [AAEE127C] [CDDC5485]           
 02   90.3 [58128A6D] [C9E7F51E]           
 03   60.8 [42E80E83] [04206984]           
 04   83.1 [63D22640] [341FA37C]           
 05   80.6 [DEBAB056] [5B1B7235]           
 06  100.0 [C5136E6A] [CCC557ED]           
 07   82.7 [52208962] [C36610B8]           
 08   53.9 [A31B371B] [601B103B]           
 09  100.0 [9103695C] [CA43257A]           
 10   77.1 [EC70FB45] [9C8364E0]           
 11   56.0 [03424031] [8BB263CB]          
Now only 22 samples are different in the last track. Can someone please explain to me what happened here?
Thanks in advance!

Re: Understanding offset in CUETools

Reply #1 –
No need to permanently change the offset. CUETools is showing you alternate pressings so you can see if the RIP is accurate even though your pressing may not have an entry in the AR database (yet).

There wasn't anything wrong with track 11 before you fixed it.
Track | CTDB Status
[...]
11   | (226/313) Accurately ripped

edit: I'll look at the new questions you added while I was typing a little later. I don't time right now.
korth

Re: Understanding offset in CUETools

Reply #2 –
Quote
Also, should I bother fixing the 11th track? Seems like 6222 samples are found to be different from the database @03:08:32-03:08:42. I did notice that only 80 out of 313 entries have this difference so maybe I shouldn't even worry about it?
Track 11 was accurate "(226/313) Accurately ripped" (and confirmed by two alternate pressings in the AccurateRip DB) so there's nothing to fix. The other recovery record is for a version of the CD that is a slightly different from yours. It happens. Sometimes the difference is only a few samples.

Quote
Just for the sake of the argument (I'm trying to learn how to fix errors if there are any), I tried using repair function in the CUETools but after processing I get this result for 11th track - there is no longer a match. How can this be?
That recovery record wasn't for your rip so the last track now has a different checksum.

Quote
Now only 22 samples are different in the last track. Can someone please explain to me what happened here?
I'll defer. Perhaps the developer has an answer.

korth
 

Re: Understanding offset in CUETools

Reply #3 –
It looks weird for CUETools to report no match upon doing the "repair", and then something different right after. But did you set an offset manually?

Note though: Differences start at 3:08.32.  According to the CT database, the track is 3:08.45 long. Roundoff can make that close to 0.14 of a second, which is just above 6000 samples. Hunch: those samples at the end are silent in one of the submissions.

Can you compare the "before" and "after" files? Foobar2000 with foo_bitcompare will give you a peak. I bet it is low.

Re: Understanding offset in CUETools

Reply #4 –
Quote from: Porcus on
It looks weird for CUETools to report no match upon doing the "repair", and then something different right after. But did you set an offset manually?

Note though: Differences start at 3:08.32.  According to the CT database, the track is 3:08.45 long. Roundoff can make that close to 0.14 of a second, which is just above 6000 samples. Hunch: those samples at the end are silent in one of the submissions.

Can you compare the "before" and "after" files? Foobar2000 with foo_bitcompare will give you a peak. I bet it is low.

Thank you both for your input! I really appreciate it.
No, I used fix offset function first, then I fixed the different samples. So it was a two step process.
Here are the results of bit-compare before and after the repair:
Code: [Select]
Differences found in compared tracks.
Zero offset detected.

Comparing:
"C:\Users\Music\Converted\Charlie Parker\1988 - Bird_ Original Motion Picture Soundtrack (2)\Charlie Parker - Bird_ Original Motion Picture Soundtrack.cue" / index: 11
"C:\Users\Music\Converted\Charlie Parker\1988 - Bird_ Original Motion Picture Soundtrack (1)\Charlie Parker - Bird_ Original Motion Picture Soundtrack.cue" / index: 11
Compared 8317260 samples.
Differences found: 6222 values, starting at 3:08.436508, peak: 0.0000305 at 3:08.436508, 1ch
Channel difference peaks: 0.0000305 0.0000305
File #1 peaks: 0.5609436 0.5455017
File #2 peaks: 0.5609436 0.5455017
Detected offset as 0 samples.

Total duration processed: 3:08.600
Time elapsed: 0:01.396
135.09x realtime

Seems like both files have the same peaks?

Re: Understanding offset in CUETools

Reply #5 –
Quote from: LazyBorzoi on
Here are the results of bit-compare before and after the repair:
Code: [Select]
[...]
Compared 8317260 samples.
Differences found: 6222 values, starting at 3:08.436508, peak: 0.0000305 at 3:08.436508, 1ch
Channel difference peaks: 0.0000305 0.0000305

That was a well-known figure. Converted to dB: https://www.google.no/search?q=20*log10(0.0000305)
-90 dB.
It affects (*calculating*) the 7210 latest samples of each channel. 6222 of them 2*7210 samples differ, and none of the differences are more than one least-significant bit. My hunch is that the peak over that approx 0.016 seconds isn't much higher, if you bothered to cut it out and peak-scan it.

If so: the song is over, there is 0.5 bit of dithering noise left (1 bit differing half the time, that fits approximately 3111 samples per channel) - and one of the rips stops 0.016 seconds earlier than the other. This isn't abnormal, and AccurateRip disregards the last 5 frames = 2940 samples ~ 0.0067s of the last track in order to handle such things - but in this case, it happens 0.016s before the end.  More than usual.

I bet someone with more knowledge about lead-out issues could correct some details here.

Quote from: LazyBorzoi on
Seems like both files have the same peaks?
Yes. The differences are somewhere else than where the music is ;-)
(Assuming, again, that there is no music left in the last 0.017s. Listen carefully to the last couple of hundredths of a second and correct me if I'm wrong ;-)  )

Re: Understanding offset in CUETools

Reply #6 –
Quote from: Porcus on
Yes. The differences are somewhere else than where the music is ;-)
(Assuming, again, that there is no music left in the last 0.017s. Listen carefully to the last couple of hundredths of a second and correct me if I'm wrong ;-)  )

Haha, that is so true!
I keep forgetting that even 6000 samples are still a small fraction of a second!
Thank you both for your input - I learned a lot.

Re: Understanding offset in CUETools

Reply #7 –
Quote from: LazyBorzoi on
I keep forgetting that even 6000 samples are still a small fraction of a second!

And if you forget 6222 samples differing isn't 6222/44100 seconds unless all the differences are in the same channel ... ;-)
Yes, it is a bit strange: If you have two files of 1/75th second CD quality, fb2k will say "Compared 588 samples". But if absolutely no samples match, it will say: "Differences found: 1176 values," Because it is stereo. And the first figure counts "samples per channel" while the differences figure counts each individual difference.
CUETools also counts total number of different samples.

Now in this case, the CUETools log you first posted said "differs in 6222 samples @03:08:32-03:08:42", and you can just check track length and verify that it is at the very end of the CD. (If it is the end of some other track, it is a different story.) With only a couple of hundredths of a second left, there is typically no music. (Even if the music stops abruptly! It is well known that there are such shenanigans in the CD (re)production process, so one would/should not cut the tape just there. No reason to, before one started to rip CDs to file - then there would not be any next track playing until the CD was changed.)

Re: Understanding offset in CUETools

Reply #8 –
Quote from: korth on
Quote
Now only 22 samples are different in the last track. Can someone please explain to me what happened here?
I'll defer. Perhaps the developer has an answer.
It's tricky because the difference between the two variants in the database is all at the very end of the disc, and the two variants probably have a significant offset difference - probably the only difference between them is the offset, one having more of that noise in the end. Changing offset of your copy didn't help the situation either :)
CUETools 2.1.6