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: How would you interpret my accurate rip results? (Read 1657 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How would you interpret my accurate rip results?

Track | CTDB Status
  1   | (150/161) Accurately ripped
  2   | (160/161) Accurately ripped
  3   | (160/161) Accurately ripped
  4   | (160/161) Accurately ripped
  5   | (159/161) Accurately ripped
  6   | (139/161) Differs in 31 samples @04:08:58-04:08:60
  7   | (160/161) Accurately ripped
  8   | (160/161) Accurately ripped
  9   | (157/161) Accurately ripped
 10   | (144/161) Accurately ripped
 11   | (160/161) Accurately ripped
 12   | (158/161) Accurately ripped
 13   | (  7/161) Accurately ripped, or (139/161) differs in 2 samples @03:03:44

It says I match 7 other people's rip, but the MAJORITY do not match?

I've ripped about 30 CD's before this, and have never had an error, so this is bugging me that track 6 is having an issue, but the last track matches other people's. I did Test and Copy after detecting gaps (non-compliant) and use the automatically detected offset correction of +6 which matches the database for if I wanted to manually enter it..

Question 1 ) Do I have a different variant of the pressing if track 13 matches 7 other rips? The Read and Test CRC's match for this track (but not #6)

Question 2) Any suggestions for track 6? This was an unopened CD, just opened it. First time I've had an error.

Re: How would you interpret my accurate rip results?

Reply #1 –
Track 6 matches 0 out of 161 rips (differs by 31 samples for 139 out of 161 rips).

This could be a pressing not yet in the CUETools Database (CTDB). If so you could give it some time and try verifying again.

You said the Test and Copy CRC's don't match for Track 6. Another option is to attempt a repair with CUETools.
korth

Re: How would you interpret my accurate rip results?

Reply #2 –
Quote from: korth on
Track 6 matches 0 out of 161 rips (differs by 31 samples for 139 out of 161 rips).

This could be a pressing not yet in the CUETools Database (CTDB). If so you could give it some time and try verifying again.

You said the Test and Copy CRC's don't match for Track 6. Another option is to attempt a repair with CUETools.

https://www.discogs.com/release/31910872-Lady-Gaga-Harlequin

It was released in 2024, and purchased 2 months ago direct from the Artist, as I'm sure many people have.

Also, would CueTools "Fix" my track #13 even though it matched some people's? Or how would that work?
Track 13's length is 3:04:38 and the 2 different samples are at 3:03:44 so it isn't just an offset kind of problem I assume. I just want to rule out any problem with my hardware or setup. It kind of raises eyebrows that it's the very last second of the whole CD, but weird that other people had this result.

Re: How would you interpret my accurate rip results?

Reply #3 –
So I tried doing it all again, and now I got different samples on 13. How is it that the first time, I got the same wrong answers as 7 other readings? Shouldn't that be like an impossibility? Now it matches 0. How is it possible to have the SAME errors once around as others? Now I'm more confused than ever.

Re: How would you interpret my accurate rip results?

Reply #4 –
what results do you get for accuraterip? This is CTDB. I usually just call it good when one of the two checks out. ^^

Id guess that it would fix ur track but with those results i wouldnt know if the fix would actually be more correct. If one checks out then i would suspect some ocd stuff that is not relevant to musical integrity. Then again i dont know what you are after.
And so, with digital, computer was put into place, and all the IT that came with it.

Re: How would you interpret my accurate rip results?

Reply #5 –
Quote from: Kartoffelbrei on
what results do you get for accuraterip? This is CTDB. I usually just call it good when one of the two checks out. ^^

Id guess that it would fix ur track but with those results i wouldnt know if the fix would actually be more correct. If one checks out then i would suspect some ocd stuff that is not relevant to musical integrity. Then again i dont know what you are after.

It got moved to the CTDB forums.

Accuraterip reports the same results.

I just think it's strange that I got same read and test CRCs, followed by matching 7 other rips, and now I get read errors on track 13. I thought matching even 1 was considered proof of a good rip, but apparently not.

I'm after a bit-perfect cd rip.

If I use the repair tool, I find when checking with accuraterip, some of my songs are +12, and some are -12. Is it using 2 separate recovery records? Before the repair, they're all +0 for the ones that wrre accurare.

Re: How would you interpret my accurate rip results?

Reply #6 –
Quote from: anteater545 on
Also, would CueTools "Fix" my track #13 even though it matched some people's? Or how would that work?
There's only one recovery record for that CD (CTDBID DD7BC2BE, current confidence 139)
CUETools should repair 33 samples
  6  | (139/161) differs in 31 samples @04:08:58-04:08:60
 13  | (139/161) differs in 2 samples @03:03:44

Quote from: anteater545 on
Track 13's length is 3:04:38 and the 2 different samples are at 3:03:44 so it isn't just an offset kind of problem I assume. I just want to rule out any problem with my hardware or setup.
You could post a complete extraction log

Quote from: anteater545 on
If I use the repair tool, I find when checking with accuraterip, some of my songs are +12, and some are -12. Is it using 2 separate recovery records? Before the repair, they're all +0 for the ones that wrre accurare.
You're not posting logs so we can see what you're referring to. Repair would only change the samples I referenced above.
X
korth

Re: How would you interpret my accurate rip results?

Reply #7 –
Differences in 2 samples at the very end of the last track - did you rip with the same drive?
And/or: did you change any settings like lead-out?

Re: How would you interpret my accurate rip results?

Reply #8 –
So I went at it again, made sure the disc was flawless, no scratches at all. This time, the last track "worked" again, but still showing 7/161 matches.

I understand it could be a "different" pressing, but the rip before this, the test and read CRC's did not match, so there is SOME kind of CONSISTENT error that other people are getting. How did I "match" 7 other rips, but sometimes, get errors for that particular track? Is  this some kind of copyright protection?

Track 6 is still a total washout with 31 samples wrong every time.

Code: [Select]
Exact Audio Copy V1.8 from 15. July 2024

EAC extraction logfile from 25. March 2025, 17:55

Lady Gaga / Harlequin

Used drive  : Dell    DVD+/-RW DW316   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 6
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

Used output format              : User Defined Encoder
Selected bitrate                : 768 kBit/s
Quality                         : High
Add ID3 tag                     : No
Command line compressor         : C:\Program Files (x86)\Exact Audio Copy\FLAC\FLAC.EXE
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "PERFORMER=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "ALBUMARTIST=%albumartist%" -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" -T "COMMENT=%comment%" %source% -o %dest%


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  2:46.22 |         0    |    12471   
        2  |  2:46.22 |  3:11.53 |     12472    |    26849   
        3  |  5:58.00 |  3:42.45 |     26850    |    43544   
        4  |  9:40.45 |  2:37.65 |     43545    |    55384   
        5  | 12:18.35 |  2:41.55 |     55385    |    67514   
        6  | 15:00.15 |  4:09.35 |     67515    |    86224   
        7  | 19:09.50 |  3:38.54 |     86225    |   102628   
        8  | 22:48.29 |  2:54.55 |    102629    |   115733   
        9  | 25:43.09 |  2:58.53 |    115734    |   129136   
       10  | 28:41.62 |  2:51.49 |    129137    |   142010   
       11  | 31:33.36 |  2:44.13 |    142011    |   154323   
       12  | 34:17.49 |  4:05.33 |    154324    |   172731   
       13  | 38:23.07 |  3:04.38 |    172732    |   186569   


Track  1

     Filename D:\LG\CDs\Harlequin [602475066491]\01 - Good Morning.wav

     Pre-gap length  0:00:02.00

     Peak level 99.9 %
     Extraction speed 1.6 X
     Track quality 100.0 %
     Test CRC 3EBC91EE
     Copy CRC 3EBC91EE
     Accurately ripped (confidence 13)  [9F02C746]  (AR v2)
     Copy OK

Track  2

     Filename D:\LG\CDs\Harlequin [602475066491]\02 - Get Happy (2024).wav

     Peak level 99.9 %
     Extraction speed 1.8 X
     Track quality 100.0 %
     Test CRC C06870E9
     Copy CRC C06870E9
     Accurately ripped (confidence 14)  [92785A3F]  (AR v2)
     Copy OK

Track  3

     Filename D:\LG\CDs\Harlequin [602475066491]\03 - Oh, When The Saints.wav

     Peak level 99.9 %
     Extraction speed 2.0 X
     Track quality 100.0 %
     Test CRC 8ABD364E
     Copy CRC 8ABD364E
     Accurately ripped (confidence 14)  [B19813E2]  (AR v2)
     Copy OK

Track  4

     Filename D:\LG\CDs\Harlequin [602475066491]\04 - World On A String.wav

     Peak level 99.9 %
     Extraction speed 2.0 X
     Track quality 100.0 %
     Test CRC B70BAB29
     Copy CRC B70BAB29
     Accurately ripped (confidence 14)  [CE4233D1]  (AR v2)
     Copy OK

Track  5

     Filename D:\LG\CDs\Harlequin [602475066491]\05 - If My Friends Could See Me Now.wav

     Peak level 99.9 %
     Extraction speed 2.1 X
     Track quality 100.0 %
     Test CRC 2B574327
     Copy CRC 2B574327
     Accurately ripped (confidence 15)  [6735EF8C]  (AR v2)
     Copy OK

Track  6

     Filename D:\LG\CDs\Harlequin [602475066491]\06 - That’s Entertainment.wav

     Suspicious position 0:04:08

     Peak level 99.9 %
     Extraction speed 0.8 X
     Track quality 99.7 %
     Test CRC ACE987E5
     Copy CRC E38BEDCE
     Cannot be verified as accurate (confidence 14)  [2D31EAC1], AccurateRip returned [1487DF88]  (AR v2)
     Copy finished

Track  7

     Filename D:\LG\CDs\Harlequin [602475066491]\07 - Smile.wav

     Peak level 99.9 %
     Extraction speed 2.5 X
     Track quality 100.0 %
     Test CRC EAEB8560
     Copy CRC EAEB8560
     Accurately ripped (confidence 15)  [FB4FE45C]  (AR v2)
     Copy OK

Track  8

     Filename D:\LG\CDs\Harlequin [602475066491]\08 - The Joker.wav

     Peak level 100.0 %
     Extraction speed 2.5 X
     Track quality 100.0 %
     Test CRC 3031AB27
     Copy CRC 3031AB27
     Accurately ripped (confidence 15)  [84D075E1]  (AR v2)
     Copy OK

Track  9

     Filename D:\LG\CDs\Harlequin [602475066491]\09 - Folie à Deux.wav

     Peak level 99.9 %
     Extraction speed 2.6 X
     Track quality 100.0 %
     Test CRC 47A966E3
     Copy CRC 47A966E3
     Accurately ripped (confidence 15)  [141BD626]  (AR v2)
     Copy OK

Track 10

     Filename D:\LG\CDs\Harlequin [602475066491]\10 - Gonna Build A Mountain.wav

     Peak level 99.9 %
     Extraction speed 1.9 X
     Track quality 99.9 %
     Test CRC B6857733
     Copy CRC B6857733
     Accurately ripped (confidence 12)  [4B548B4C]  (AR v2)
     Copy OK

Track 11

     Filename D:\LG\CDs\Harlequin [602475066491]\11 - Close To You.wav

     Peak level 100.0 %
     Extraction speed 2.7 X
     Track quality 100.0 %
     Test CRC FF3611E2
     Copy CRC FF3611E2
     Accurately ripped (confidence 15)  [9C4759FB]  (AR v2)
     Copy OK

Track 12

     Filename D:\LG\CDs\Harlequin [602475066491]\12 - Happy Mistake.wav

     Peak level 99.9 %
     Extraction speed 3.0 X
     Track quality 100.0 %
     Test CRC 629CDE38
     Copy CRC 629CDE38
     Accurately ripped (confidence 15)  [B111D2F5]  (AR v2)
     Copy OK

Track 13

     Filename D:\LG\CDs\Harlequin [602475066491]\13 - That’s Life.wav

     Peak level 100.0 %
     Extraction speed 2.9 X
     Track quality 100.0 %
     Test CRC 4A1A83C3
     Copy CRC 4A1A83C3
     Accurately ripped (confidence 3)  [60B0370E]  (AR v2)
     Copy OK


12 track(s) accurately ripped
 1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

There were errors

End of status report

---- CUETools DB Plugin V2.2.6

[CTDB TOCID: sPfh.oNMQi59Y4e4S0z.uwwaYfQ-] found
Submit result: insufficient quality
Track | CTDB Status
  1   | (150/161) Accurately ripped
  2   | (160/161) Accurately ripped
  3   | (160/161) Accurately ripped
  4   | (160/161) Accurately ripped
  5   | (159/161) Accurately ripped
  6   | (139/161) Differs in 31 samples @04:08:58-04:08:60
  7   | (160/161) Accurately ripped
  8   | (160/161) Accurately ripped
  9   | (157/161) Accurately ripped
 10   | (144/161) Accurately ripped
 11   | (160/161) Accurately ripped
 12   | (158/161) Accurately ripped
 13   | (  7/161) Accurately ripped, or (139/161) differs in 2 samples @03:03:44
If you are sure that your rip contains errors, you can use CUETools to repair it.


==== Log checksum 9C69295F088B6C7C54039F88A40AC1400020DF2E8BEFF73DF6C49C50D9588481 ====

Re: How would you interpret my accurate rip results?

Reply #9 –
Here is what Foobar says when I try to verify THE FIXED cuetools version of the CD with its built-in accurate rip check:

Code: [Select]
Track 1: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 74129445]
Track 2: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 24094DB7]
Track 3: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 9F3A6012]
Track 4: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC D7CF7CAB]
Track 5: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 6735EF8C]
Track 6: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 1487DF88]
Track 7: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC FB4FE45C]
Track 8: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 84D075E1]
Track 9: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 141BD626]
Track 10: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 0334FBF8]
Track 11: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 9C4759FB]
Track 12: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC B111D2F5]
Track 13: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 4F8749DE]


Some of them report offset -12, while most are zero. As I've said, my Dell 316W CD reader is a +6, which I have in the settings of EAC. Maybe this can help someone narrow down what the issue is?

And BEFORE I fixed the errors with CueTools:
Code: [Select]
Track 1: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 74129445]
Track 2: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 24094DB7]
Track 3: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 9F3A6012]
Track 4: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC D7CF7CAB]
Track 5: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 6735EF8C]
Track 6: Track InAccurate
Track 7: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC FB4FE45C]
Track 8: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 84D075E1]
Track 9: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 141BD626]
Track 10: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 0334FBF8]
Track 11: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 9C4759FB]
Track 12: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC B111D2F5]
Track 13: AccurateRip Verified Confidence 3, Pressing Offset +0 [ARv2 CRC 60B0370E]

Re: How would you interpret my accurate rip results?

Reply #10 –
I see the only tracks that changed were the repaired 6 & 13.
I'm not familiar with the tool in foobar2000 but it looks like it's giving the first match with the highest confidence for each track (not limiting all results to the same pressing).

Do you have the log from the repair in CUETools?
Or try verifying the repaired rip in CUETools and post that
korth

Re: How would you interpret my accurate rip results?

Reply #11 –
Quote from: korth on
I see the only tracks that changed were the repaired 6 & 13.
I'm not familiar with the tool in foobar2000 but it looks like it's giving the first match with the highest confidence for each track (not limiting all results to the same pressing).

Do you have the log from the repair in CUETools?
Or try verifying the repaired rip in CUETools and post that

Code: [Select]
[CUETools log; Date: 3/25/2025 6:39:16 PM; Version: 2.2.6]
CUETools DB: corrected 33 errors.
[AccurateRip ID: 0013c319-00c6393a-9f09b70d] found.
Track   [  CRC   |   V2   ] Status
 01     [05753ad1|9f02c746] (00+13/27) Accurately ripped
 02     [c8cf5f2f|92785a3f] (00+14/28) Accurately ripped
 03     [a0d4aa39|b19813e2] (00+14/28) Accurately ripped
 04     [c23c1046|ce4233d1] (00+14/28) Accurately ripped
 05     [fd172f3f|6735ef8c] (00+15/29) Accurately ripped
 06     [7e785920|10c5ad86] (00+10/24) Accurately ripped
 07     [7d8fbba1|fb4fe45c] (00+15/29) Accurately ripped
 08     [3c824bf7|84d075e1] (00+15/29) Accurately ripped
 09     [05535f5f|141bd626] (00+15/29) Accurately ripped
 10     [bf67f2f5|4b548b4c] (00+12/26) Accurately ripped
 11     [b70f715e|9c4759fb] (00+15/29) Accurately ripped
 12     [89b12254|b111d2f5] (00+15/29) Accurately ripped
 13     [30f71963|5fb922b7] (00+09/26) Accurately ripped
Offsetted by -12:
 01     [d7f43cbd] (00/27) No match (V2 was not tested)
 02     [57702db7] (00/28) No match (V2 was not tested)
 03     [8aff96a9] (00/28) No match (V2 was not tested)
 04     [c9664b3a] (00/28) No match (V2 was not tested)
 05     [65bafe3f] (00/29) No match (V2 was not tested)
 06     [7e5e810c] (00/24) No match (V2 was not tested)
 07     [a990e075] (00/29) No match (V2 was not tested)
 08     [19ded593] (00/29) No match (V2 was not tested)
 09     [dec2aaf3] (00/29) No match (V2 was not tested)
 10     [74a42c45] (00/26) No match (V2 was not tested)
 11     [d5a67a1a] (00/29) No match (V2 was not tested)
 12     [e551e19c] (00/29) No match (V2 was not tested)
 13     [1df1118f] (00/26) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [1AD930FC] [DFBC6E1B]           
 01   99.9 [3EBC91EE] [CFA78545]   CRC32   
 02   99.9 [C06870E9] [1C8AE399]   CRC32   
 03   99.9 [8ABD364E] [92DB6E85]   CRC32   
 04   99.9 [B70BAB29] [16437EBF]   CRC32   
 05   99.9 [2B574327] [44E7EBAA]   CRC32   
 06   99.9 [DDA226A0] [519536FE] [E38BEDCE]
 07   99.9 [EAEB8560] [F36D4C61]   CRC32   
 08  100.0 [3031AB27] [9D52CA02]   CRC32   
 09   99.9 [47A966E3] [35484B4F]   CRC32   
 10   99.9 [B6857733] [DE1473A2]   CRC32   
 11  100.0 [FF3611E2] [9D7844FD]   CRC32   
 12   99.9 [629CDE38] [104EFA7B]   CRC32   
 13  100.0 [A22F45F9] [52BF8D5D] [4A1A83C3]

Re: How would you interpret my accurate rip results?

Reply #12 –
All AccurateRip results match your EAC log except for tracks 6 & 13.
Track 6 is now accurate & 13 has a higher confidence with the new result.
korth

Re: How would you interpret my accurate rip results?

Reply #13 –
Yeah I definitely get that, but im puzzled how my rip of 13 can still match 7 other rips but still be wrong. Makes me think i have a hardware software issue that is consistently giving a skewed result, and POTENTIALLY that being the reason track 6 has issues.

In addition, I'm still a little confused why some tracks have -12 offset. Does that mean my rip has SOME songs with 12 added bits of silence to them compared to most rips?

Re: How would you interpret my accurate rip results?

Reply #14 –
Quote from: anteater545 on
How did I "match" 7 other rips, but sometimes, get errors for that particular track? Is  this some kind of copyright protection?
More likely a flaw on the CD where the drive reads one area 2 or 3 different ways consistently. I've had several CDs like this.

Quote from: anteater545 on
In addition, I'm still a little confused why some tracks have -12 offset. Does that mean my rip has SOME songs with 12 added bits of silence to them compared to most rips?

The CUETools result DOES NOT show any tracks with -12 offset. It does show you there's another pressing in the database that is offsetted by -12.

You're just misinterpreting the foobar2000 result. It is not telling you the track has an offset. It's telling you it found the highest confidence for a pressing that is offset from your rip by -12.
korth
 

Re: How would you interpret my accurate rip results?

Reply #15 –
If you have got access to a different CD drive you can give it a try and see how track 6 and 13 are ripped there.

Re: How would you interpret my accurate rip results?

Reply #16 –
Quote from: c72578 on
If you have got access to a different CD drive you can give it a try and see how track 6 and 13 are ripped there.
I got the same results, plus problems with 10. I guess the quality control for this CD is just terrible.

You can see the correlation, track 10 has more issues relatively speaking.

Re: How would you interpret my accurate rip results?

Reply #17 –
Quote from: korth on
Quote from: anteater545 on
How did I "match" 7 other rips, but sometimes, get errors for that particular track? Is  this some kind of copyright protection?
More likely a flaw on the CD where the drive reads one area 2 or 3 different ways consistently. I've had several CDs like this.

Quote from: anteater545 on
In addition, I'm still a little confused why some tracks have -12 offset. Does that mean my rip has SOME songs with 12 added bits of silence to them compared to most rips?

The CUETools result DOES NOT show any tracks with -12 offset. It does show you there's another pressing in the database that is offsetted by -12.

You're just misinterpreting the foobar2000 result. It is not telling you the track has an offset. It's telling you it found the highest confidence for a pressing that is offset from your rip by -12.

I might be wrong, however before searching for offsets it tries to match a non-offset, otherwise on a disc with lots of pressings all the tracks could be all over the place.

Re: How would you interpret my accurate rip results?

Reply #18 –
How is there different offsets for each track if theres only 1 cd in the database that cueTools repairs off of? Is my VD an updated version compared to the original pressings? If anyone burned their own copy of a cd, wouldn't the offset be a fixed number per track?

Re: How would you interpret my accurate rip results?

Reply #19 –
Did you read the section of the wiki page I linked in my previous post on pressings in AccurateRip?

And there are 2 databases discussed in this thread.
AccurateRip database currently has Checksums for at least 2 pressings of this CD. One at +0 (relative offset of your rip) and one at -12 (relative to your rip).
CUETools DataBase (CTDB) does not store Checksums separately by pressing. The repair option is for CDs that have a recovery record and submitted to CTDB only. The repair script does not alter the offset of any part of your rip.
foobar2000 shows results from AccurateRip database only.
CUETools Repair log shows results from AccurateRip database only (the only info shown from CTDB in that log is that the script repaired 33 samples). To see new CTDB results after a repair, you need to manually run Verify in CUETools on the repaired file(s).
CUETools/CTDB cannot submit anything to the AccurateRip database.
korth

Re: How would you interpret my accurate rip results?

Reply #20 –
I've ripped the disc in CueRipper for the first time, and got no errors this time.

1) Does CueRipper automatically fix them before encoding them? I have no clue why the 10+ other rips on EAC all had errors, this was surprising!

2) Do these offset pressings mean that some songs are losing 12 samples of data at the beginning or end since my tracks seem to alternate? If I understand correctly, some of my songs start "12 samples before" other versions of the disc, and 12 samples after sometimes. Would this not mean very tiny parts are cut off?

3) Assuming I have a disc that other people should have gotten the same bit perfect rip, what does it actually take for my rip to be in the database to show +0 offset match for all the tracks?

So in conclusion, I feel like I have a bit perfect rip of the disc I own, but the pressing company messed up and caused some tracks to lose a tiny bit of data... does this sound right?

CueTools log
Code: [Select]
[CUETools log; Date: 4/5/2025 11:06:53 PM; Version: 2.2.6]
[CTDB TOCID: sPfh.oNMQi59Y4e4S0z.uwwaYfQ-] found.
Track | CTDB Status
  1   | (159/170) Accurately ripped
  2   | (169/170) Accurately ripped
  3   | (169/170) Accurately ripped
  4   | (169/170) Accurately ripped
  5   | (168/170) Accurately ripped
  6   | (149/170) Accurately ripped
  7   | (169/170) Accurately ripped
  8   | (169/170) Accurately ripped
  9   | (166/170) Accurately ripped
 10   | (153/170) Accurately ripped
 11   | (169/170) Accurately ripped
 12   | (167/170) Accurately ripped
 13   | (155/170) Accurately ripped
[AccurateRip ID: 0013c319-00c6393a-9f09b70d] found.
Track   [  CRC   |   V2   ] Status
 01     [05753ad1|9f02c746] (00+13/27) Accurately ripped
 02     [c8cf5f2f|92785a3f] (00+14/28) Accurately ripped
 03     [a0d4aa39|b19813e2] (00+14/28) Accurately ripped
 04     [c23c1046|ce4233d1] (00+14/28) Accurately ripped
 05     [fd172f3f|6735ef8c] (00+15/29) Accurately ripped
 06     [7e785920|10c5ad86] (00+10/24) Accurately ripped
 07     [7d8fbba1|fb4fe45c] (00+15/29) Accurately ripped
 08     [3c824bf7|84d075e1] (00+15/29) Accurately ripped
 09     [05535f5f|141bd626] (00+15/29) Accurately ripped
 10     [bf67f2f5|4b548b4c] (00+12/26) Accurately ripped
 11     [b70f715e|9c4759fb] (00+15/29) Accurately ripped
 12     [89b12254|b111d2f5] (00+15/29) Accurately ripped
 13     [30f71963|5fb922b7] (00+09/26) Accurately ripped
Offsetted by -12:
 01     [d7f43cbd] (00/27) No match (V2 was not tested)
 02     [57702db7] (00/28) No match (V2 was not tested)
 03     [8aff96a9] (00/28) No match (V2 was not tested)
 04     [c9664b3a] (00/28) No match (V2 was not tested)
 05     [65bafe3f] (00/29) No match (V2 was not tested)
 06     [7e5e810c] (00/24) No match (V2 was not tested)
 07     [a990e075] (00/29) No match (V2 was not tested)
 08     [19ded593] (00/29) No match (V2 was not tested)
 09     [dec2aaf3] (00/29) No match (V2 was not tested)
 10     [74a42c45] (00/26) No match (V2 was not tested)
 11     [d5a67a1a] (00/29) No match (V2 was not tested)
 12     [e551e19c] (00/29) No match (V2 was not tested)
 13     [1df1118f] (00/26) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] 
 --  100.0 [1AD930FC] [DFBC6E1B]           
 01   99.9 [3EBC91EE] [CFA78545]           
 02   99.9 [C06870E9] [1C8AE399]           
 03   99.9 [8ABD364E] [92DB6E85]           
 04   99.9 [B70BAB29] [16437EBF]           
 05   99.9 [2B574327] [44E7EBAA]           
 06   99.9 [DDA226A0] [519536FE]           
 07   99.9 [EAEB8560] [F36D4C61]           
 08  100.0 [3031AB27] [9D52CA02]           
 09   99.9 [47A966E3] [35484B4F]           
 10   99.9 [B6857733] [DE1473A2]           
 11  100.0 [FF3611E2] [9D7844FD]           
 12   99.9 [629CDE38] [104EFA7B]           
 13  100.0 [A22F45F9] [52BF8D5D]           


Foobar

Code: [Select]
Track 1: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 74129445]
Track 2: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 24094DB7]
Track 3: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 9F3A6012]
Track 4: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC D7CF7CAB]
Track 5: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 6735EF8C]
Track 6: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 1487DF88]
Track 7: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC FB4FE45C]
Track 8: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 84D075E1]
Track 9: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 141BD626]
Track 10: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 0334FBF8]
Track 11: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC 9C4759FB]
Track 12: AccurateRip Verified Confidence 15, Pressing Offset +0 [ARv2 CRC B111D2F5]
Track 13: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 4F8749DE]

Re: How would you interpret my accurate rip results?

Reply #21 –
1) Your EAC extraction log shows you are using Secure Mode and not making use of C2 pointers.
- Secure mode rereads each section of the CD. Error correction is based on the consistency of the data read.
- C2 pointers can be used to detect errors but EAC will no longer reread each section of the CD.
   - Note that not all computer optical drives report C2 errors accurately. It is usually recommended to disable this feature in EAC if you are unsure of the accuracy of the drive to report C2 or if errors are consistently incorrectly reported.

There are additional tools in EAC Drive Options to detect the drive's Read Features and to closer Examine C2 Feature support.  

The default settings in CUERipper uses Secure Mode and automatically tries to make use of C2 pointers. CUERipper also handles rereads a little differently than EAC does.
- Note that the C2 feature can also be disabled in CUERipper.
- The current version of CUERipper does not automatically apply the repair script used in CUETools.

2) For reference purposes, your rip has an offset of 0 (or +0). Every track from your rip has the same reference offset of 0.
Using your rip as a starting point, there is another pressing found in the AccurateRip database when a mathematical offset of -12 is applied to your rip. Every track in that pressing is mathematically offset by -12 when compared to the tracks of your rip.
When an offset is mathematically applied, it is applied to the entire rip as if it is one continuous file. Any missing samples are either from the very beginning of the first track or the very end of the last track. These areas are usually silent (or inaudible). All samples between are shifted. All track lengths remain the same.
If applying offset removes samples from the end of the first track, the samples are not lost, they get moved to the beginning of the second track.
Going the other way, if applying offset removes samples from the beginning of the second track, the samples are moved to the end of the first track.

3) You're still misinterpreting the foobar2000's 'Verify album with AccurateRip' results. Your rip has a reference offset of +0. All tracks from your rip are +0.
The utility seems to prioritize the first result it finds that has the highest Confidence number.
Code: [Select]
Track 1: AccurateRip Verified Confidence 14, Pressing Offset -12 [ARv2 CRC 74129445]
For Track 1 the result tells you that when a Pressing Offset of -12 is mathematically applied to your rip, there is a Confidence of 14.

If you look at the CUETools/CUERipper result
Code: [Select]
Track   [  CRC   |   V2   ] Status
 01     [05753ad1|9f02c746] (00+13/27) Accurately ripped
The Confidence is only 13 when referenced at +0
The utility in foobar2000 appears to be showing you the -12 Pressing Offset result because the Confidence is higher.
I do not know if there is a setting in foobar2000's utility to prioritize +0 Pressing Offset in lieu of highest Confidence.

This section of the CUETools/CUERipper log is showing your rip's AccurateRip results at +0 Pressing Offset
Code: [Select]
[AccurateRip ID: 0013c319-00c6393a-9f09b70d] found.
Track   [  CRC   |   V2   ] Status
 01     [05753ad1|9f02c746] (00+13/27) Accurately ripped
 02     [c8cf5f2f|92785a3f] (00+14/28) Accurately ripped
 03     [a0d4aa39|b19813e2] (00+14/28) Accurately ripped
 04     [c23c1046|ce4233d1] (00+14/28) Accurately ripped
 05     [fd172f3f|6735ef8c] (00+15/29) Accurately ripped
 06     [7e785920|10c5ad86] (00+10/24) Accurately ripped
 07     [7d8fbba1|fb4fe45c] (00+15/29) Accurately ripped
 08     [3c824bf7|84d075e1] (00+15/29) Accurately ripped
 09     [05535f5f|141bd626] (00+15/29) Accurately ripped
 10     [bf67f2f5|4b548b4c] (00+12/26) Accurately ripped
 11     [b70f715e|9c4759fb] (00+15/29) Accurately ripped
 12     [89b12254|b111d2f5] (00+15/29) Accurately ripped
 13     [30f71963|5fb922b7] (00+09/26) Accurately ripped
korth

Re: How would you interpret my accurate rip results?

Reply #22 –
Thanks Korth. I understand now how the logs describe my rip. Foobar is referencing more than 1 rip when comparing, which added a ton of confusion for me. So for half the songs, either "most" people had their drive offset correction 12 bits off, OR the more likely situation, there exists a disc that is 12 samples shifted than the one I have, but rest assured, I've ripped it perfectly and have all of the samples of the disc.

The whole offset being applied to the whole disc makes perfect sense to me now, and I can see now how the track lengths are all the same and no data from the entire rip will be lost. I think this means, that the other pressing that someone else got of -12, that for them, every track has 12 samples of the next song in its self, however, every sample is still in the entire disc for them.

It's almost as if the company that makes the pressing just didn't get the image burned perfectly to where the TOC defines each track position (for whatever reason, it must not be easy) resulting in different offsets.

Upon reading the log sheet generated by CueRipper, it says "Make use of C2 pointers : No"

So I'm not sure how CueRipper got it to rip error free, but I won't question it too much as I understand the results now. I appreciate you explaining it all to me!

Re: How would you interpret my accurate rip results?

Reply #23 –
Quote from: anteater545 on
Upon reading the log sheet generated by CueRipper, it says "Make use of C2 pointers : No"

That line never changes in the 'EAC Style' extraction log provided by CUERipper. The intent was to simulate the EAC log without adding text that isn't in the EAC log.
The developer decided to make it always 'No'.
The actual choices (added later) are 'Auto', 'Mode294', 'Mode296', or None and do not show in the log.
korth

Re: How would you interpret my accurate rip results?

Reply #24 –
Code: [Select]
Offsetted...
-_-
And so, with digital, computer was put into place, and all the IT that came with it.