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: Two questions about EAC rip AccurateRip verify (Read 5667 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Two questions about EAC rip AccurateRip verify

I was wondering if someone could explain this rip? It seems to rip fine but doesn't match anything in the AccurateRip database when verifying it with CUETools. I tried it on a few drives and there's no errors when ripping with EAC. Is it saying there's not a single submission that matches the CD in the AccurateRip database? Did I rip it incorrectly or missing something?

Also a second non-related question I noticed in the EAC log file that I see this "error" where it prints the ...has been confirmed... message twice in the log randomly but regularly. It seems to happen when the PC sleeps. Often I start a CD and walk away. When I come back I hit the space bar, click ok and that's whats in the log file. It doesn't seem to affect anything but I was just curious if after it wakes up it's a snafu that it goes online and verifies the rip again or something along those lines?

Submit result: r5RrGorkuPLgwrgB2Hj0UBbFJMI- has been confirmed; Submit result: r5RrGorkuPLgwrgB2Hj0UBbFJMI- has been confirmed

Code: [Select]
[CUETools log; Date: 2/10/2017 12:40:24 PM; Version: 2.1.5]
[CTDB TOCID: 5DGHNjM4DmdQamsaBQmkknjGnDM-] found.
Track | CTDB Status
  1   | (18/77) Accurately ripped
  2   | (18/77) Accurately ripped
  3   | (18/77) Accurately ripped
  4   | (18/77) Accurately ripped
  5   | (18/77) Accurately ripped
  6   | (18/77) Accurately ripped
  7   | (18/77) Accurately ripped
  8   | (18/77) Accurately ripped
  9   | (18/77) Accurately ripped
 10   | (18/77) Accurately ripped
 11   | (18/77) Accurately ripped
 12   | (18/77) Accurately ripped
 13   | (18/77) Accurately ripped
 14   | (18/77) Accurately ripped
 15   | (18/77) Accurately ripped
[AccurateRip ID: 00205ebb-016f58b9-cc0d900f] found.
Track   [  CRC   |   V2   ] Status
 01     [1d8ad672|9c085bc8] (00+00/82) No match
 02     [aa80612f|774bb232] (00+00/81) No match
 03     [9e91a219|c0db1597] (00+00/80) No match
 04     [4fc27131|08b24b80] (00+00/85) No match
 05     [2b237b5b|782ca5ef] (00+00/82) No match
 06     [44b425c0|88884467] (00+00/85) No match
 07     [77b006c0|bc17ec96] (00+00/83) No match
 08     [07bf1a81|22e08458] (00+00/83) No match
 09     [5f3262b0|029d604f] (00+00/82) No match
 10     [9c792698|65cab66e] (00+00/81) No match
 11     [c41b8e98|f1f6ea5b] (00+00/82) No match
 12     [2cc7a6a0|2ece59c8] (00+00/84) No match
 13     [49e1dd0b|e7be1b54] (00+00/81) No match
 14     [64071139|7651ecae] (00+00/79) No match
 15     [943f6e26|999c7ced] (00+00/81) No match

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99.9 [FC2FA3ED] [3EB7D0C5]           
 01   96.7 [D65867BA] [3F480096]   CRC32   
 02   99.9 [99D0362E] [A698D327]   CRC32   
 03   99.9 [DC222C85] [609C0CCD]   CRC32   
 04   99.3 [4B441071] [D96D2D21]   CRC32   
 05   99.9 [125868AA] [40C4CC23]   CRC32   
 06   99.8 [F2130DA7] [66844CB7]   CRC32   
 07   99.9 [5DF79D9C] [01B31970]   CRC32   
 08   99.9 [8910C61F] [A8530B04]   CRC32   
 09   99.9 [10C3E609] [B403FF90]   CRC32   
 10   99.9 [9BA48AE0] [98B6DFDA]   CRC32   
 11   99.9 [F6260DAD] [F901BB55]   CRC32   
 12   99.9 [C4FD26F0] [62A27068]   CRC32   
 13   99.9 [85B3A1B7] [0EE508C3]   CRC32   
 14   99.9 [8F8DBF7C] [7FE8CBBC]   CRC32   
 15   99.9 [8B167DE4] [5A43F34E]   CRC32  

Code: [Select]
Exact Audio Copy V1.3 from 2. September 2016

EAC extraction logfile from 9. February 2017, 9:55

Various Artists / Detroit Rock City

Used drive  : hp      CDDVDW SN-208FB   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
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                : 1024 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 "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "ALBUMARTIST=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" %hascover%--picture="%coverfile%"%hascover% %source% -o %dest%


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  4:05.65 |         0    |    18439   
        2  |  4:05.65 |  2:47.20 |     18440    |    30984   
        3  |  6:53.10 |  3:34.00 |     30985    |    47034   
        4  | 10:27.10 |  3:48.15 |     47035    |    64149   
        5  | 14:15.25 |  5:54.00 |     64150    |    90699   
        6  | 20:09.25 |  3:46.67 |     90700    |   107716   
        7  | 23:56.17 |  4:28.43 |    107717    |   127859   
        8  | 28:24.60 |  3:35.42 |    127860    |   144026   
        9  | 32:00.27 |  4:00.15 |    144027    |   162041   
       10  | 36:00.42 |  4:22.10 |    162042    |   181701   
       11  | 40:22.52 |  4:25.23 |    181702    |   201599   
       12  | 44:48.00 |  2:57.20 |    201600    |   214894   
       13  | 47:45.20 |  2:51.50 |    214895    |   227769   
       14  | 50:36.70 |  3:10.60 |    227770    |   242079   
       15  | 53:47.55 |  4:04.20 |    242080    |   260399   


Track  1

     Filename C:\EAC Rips\01 The Boys Are Back In Town.wav

     Pre-gap length  0:00:02.00

     Peak level 96.7 %
     Extraction speed 4.3 X
     Track quality 100.0 %
     Test CRC D65867BA
     Copy CRC D65867BA
     Cannot be verified as accurate (confidence 38)  [9C085BC8], AccurateRip returned [FBD309F1]  (AR v2)
     Copy OK

Track  2

     Filename C:\EAC Rips\02 Shout It Out Loud.wav

     Peak level 100.0 %
     Extraction speed 4.6 X
     Track quality 100.0 %
     Test CRC 99D0362E
     Copy CRC 99D0362E
     Cannot be verified as accurate (confidence 36)  [774BB232], AccurateRip returned [30CDD0A6]  (AR v2)
     Copy OK

Track  3

     Filename C:\EAC Rips\03 Runnin’ With The Devil.wav

     Peak level 100.0 %
     Extraction speed 4.9 X
     Track quality 100.0 %
     Test CRC DC222C85
     Copy CRC DC222C85
     Cannot be verified as accurate (confidence 36)  [C0DB1597], AccurateRip returned [F5EF64B1]  (AR v2)
     Copy OK

Track  4

     Filename C:\EAC Rips\04 Cat Scratch Fever.wav

     Peak level 99.3 %
     Extraction speed 5.3 X
     Track quality 100.0 %
     Test CRC 4B441071
     Copy CRC 4B441071
     Cannot be verified as accurate (confidence 38)  [08B24B80], AccurateRip returned [04D5BC30]  (AR v2)
     Copy OK

Track  5

     Filename C:\EAC Rips\05 Iron Man.wav

     Peak level 100.0 %
     Extraction speed 5.7 X
     Track quality 100.0 %
     Test CRC 125868AA
     Copy CRC 125868AA
     Cannot be verified as accurate (confidence 37)  [782CA5EF], AccurateRip returned [1E5E25C2]  (AR v2)
     Copy OK

Track  6

     Filename C:\EAC Rips\06 Highway To Hell.wav

     Peak level 99.8 %
     Extraction speed 6.0 X
     Track quality 100.0 %
     Test CRC F2130DA7
     Copy CRC F2130DA7
     Cannot be verified as accurate (confidence 39)  [88884467], AccurateRip returned [54538153]  (AR v2)
     Copy OK

Track  7

     Filename C:\EAC Rips\07 20th Century Boy.wav

     Peak level 100.0 %
     Extraction speed 5.5 X
     Track quality 99.9 %
     Test CRC 5DF79D9C
     Copy CRC 5DF79D9C
     Cannot be verified as accurate (confidence 37)  [BC17EC96], AccurateRip returned [31451270]  (AR v2)
     Copy OK

Track  8

     Filename C:\EAC Rips\08 Detroit Rock City.wav

     Peak level 100.0 %
     Extraction speed 6.2 X
     Track quality 100.0 %
     Test CRC 8910C61F
     Copy CRC 8910C61F
     Cannot be verified as accurate (confidence 37)  [22E08458], AccurateRip returned [3CC74961]  (AR v2)
     Copy OK

Track  9

     Filename C:\EAC Rips\09 Jailbreak.wav

     Peak level 100.0 %
     Extraction speed 6.4 X
     Track quality 100.0 %
     Test CRC 10C3E609
     Copy CRC 10C3E609
     Cannot be verified as accurate (confidence 37)  [029D604F], AccurateRip returned [20FE69D5]  (AR v2)
     Copy OK

Track 10

     Filename C:\EAC Rips\10 Surrender (Live).wav

     Peak level 100.0 %
     Extraction speed 6.7 X
     Track quality 100.0 %
     Test CRC 9BA48AE0
     Copy CRC 9BA48AE0
     Cannot be verified as accurate (confidence 36)  [65CAB66E], AccurateRip returned [C6F91813]  (AR v2)
     Copy OK

Track 11

     Filename C:\EAC Rips\11 Rebel Rebel.wav

     Peak level 100.0 %
     Extraction speed 6.9 X
     Track quality 100.0 %
     Test CRC F6260DAD
     Copy CRC F6260DAD
     Cannot be verified as accurate (confidence 37)  [F1F6EA5B], AccurateRip returned [8BA74AD7]  (AR v2)
     Copy OK

Track 12

     Filename C:\EAC Rips\12 Strutter.wav

     Peak level 100.0 %
     Extraction speed 6.2 X
     Track quality 99.9 %
     Test CRC C4FD26F0
     Copy CRC C4FD26F0
     Cannot be verified as accurate (confidence 37)  [2ECE59C8], AccurateRip returned [25F9934F]  (AR v2)
     Copy OK

Track 13

     Filename C:\EAC Rips\13 School Days.wav

     Peak level 100.0 %
     Extraction speed 6.2 X
     Track quality 99.9 %
     Test CRC 85B3A1B7
     Copy CRC 85B3A1B7
     Cannot be verified as accurate (confidence 36)  [E7BE1B54], AccurateRip returned [016CB13A]  (AR v2)
     Copy OK

Track 14

     Filename C:\EAC Rips\14 Little Willy.wav

     Peak level 100.0 %
     Extraction speed 7.2 X
     Track quality 100.0 %
     Test CRC 8F8DBF7C
     Copy CRC 8F8DBF7C
     Cannot be verified as accurate (confidence 34)  [7651ECAE], AccurateRip returned [F5CA3D96]  (AR v2)
     Copy OK

Track 15

     Filename C:\EAC Rips\15 Nothing Can Keep Me From You.wav

     Peak level 100.0 %
     Extraction speed 7.4 X
     Track quality 100.0 %
     Test CRC 8B167DE4
     Copy CRC 8B167DE4
     Cannot be verified as accurate (confidence 35)  [999C7CED], AccurateRip returned [A1A8EC5D]  (AR v2)
     Copy OK


No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: 5DGHNjM4DmdQamsaBQmkknjGnDM-] found
Submit result: 5DGHNjM4DmdQamsaBQmkknjGnDM- has been confirmed
Track | CTDB Status
  1   | (17/75) Accurately ripped
  2   | (17/75) Accurately ripped
  3   | (17/75) Accurately ripped
  4   | (17/75) Accurately ripped
  5   | (17/75) Accurately ripped
  6   | (17/75) Accurately ripped
  7   | (17/75) Accurately ripped
  8   | (17/75) Accurately ripped
  9   | (17/75) Accurately ripped
 10   | (17/75) Accurately ripped
 11   | (17/75) Accurately ripped
 12   | (17/75) Accurately ripped
 13   | (17/75) Accurately ripped
 14   | (17/75) Accurately ripped
 15   | (17/75) Accurately ripped


==== Log checksum 5D0D2CB37E06A2A61237390A0392EFE513C9F6F0FB0F916C805D62E2C24D7226 ====

Re: Two questions about EAC rip AccurateRip verify

Reply #1 –
The pressing of the CD you have may not be in the AR database yet. Your rip is likely fine.
There is a limit to the offset that CUETools can check for alternate pressings. An alternate pressing of your CD could be in the AR database but out of range for CUETools to show.
https://www.discogs.com/master/87942

The second question has been asked before but I can't say why it is happening.
korth

Re: Two questions about EAC rip AccurateRip verify

Reply #2 –
Quote from: korth on
There is a limit to the offset that CUETools can check for alternate pressings.

Thanks Korth, I know you answered some other questions I had when I started this last November. You mean for example CUETools can check for a 2700 sample maximum offset but the CD is offset by 2800 samples or something like that?

Quote
An alternate pressing of your CD could be in the AR database but out of range for CUETools to show.

Is this similar to above meaning it's just out of the max range offset tested? Is sample offset based on a zero offset CD? Out of curiousity how is the zero offset CD determined, the first CD entered in the database?

Looking at the jacket it shows the copyright and print year to be 1999. It's 18 years old and it doesn't look like a new pressing. Does that mean, if I understand it correctly, it is outside the max offset tested it should never be able to be verified with CUETools?

Is it possible, with enough entries, eventually it will be with AccurateRip or is EAC with AccurateRip based on the same limitation of CUETools with a max offset checked/tested?

Quote
The second question has been asked before but I can't say why it is happening.

I did find that thread and saw it was asked but didn't see the answer. I appreciate it Korth. I didn't think it was a big deal by no means as CUETools shows them as being fine but worth asking. It does seem to be somehow related to when the PC sleeps/wakes though.

Re: Two questions about EAC rip AccurateRip verify

Reply #3 –
Quote from: Riverstorm on
You mean for example CUETools can check for a 2700 sample maximum offset but the CD is offset by 2800 samples or something like that?
Something like that.

Quote
Is this similar to above meaning it's just out of the max range offset tested?
It was a continuation of the above.

Quote
Is sample offset based on a zero offset CD? Out of curiousity how is the zero offset CD determined, the first CD entered in the database?
The read offset correction is to make sure each rip starts reading the CD from at the same point (you could call that point zero). For each release or pressing, the actual audio may start playing at a different position. If the audio is identical but starts at different positions then one release or pressing is offset from the other. Zero would be the rip of the CD you have and the offset would be the other one found in the AR database. Each offset, release or pressing with the same layout are grouped separately by CRC match and stored side by side by side under the same ID in the AR database. To keep it simple, CUETools tests your rip at different offsets for matches in each group.

Quote
Looking at the jacket it shows the copyright and print year to be 1999. It's 18 years old and it doesn't look like a new pressing.
When they repress a CD that doesn't mean the label or packaging has to change.

Quote
Does that mean, if I understand it correctly, it is outside the max offset tested it should never be able to be verified with CUETools? Is it possible, with enough entries, eventually it will be with AccurateRip or is EAC with AccurateRip based on the same limitation of CUETools with a max offset checked/tested?
Once your rip is submitted to the AR database, there will be at least one pending entry for each track of your pressing (and would get stored along side of the others). Future submissions could follow.

http://wiki.hydrogenaud.io/index.php?title=AccurateRip
http://cue.tools/wiki/CUETools_Database
korth

Re: Two questions about EAC rip AccurateRip verify

Reply #4 –
Quote
The read offset correction is to make sure each rip starts reading the CD from at the same point (you could call that point zero). For each release or pressing, the actual audio may start playing at a different position. If the audio is identical but starts at different positions then one release or pressing is offset from the other. Zero would be the rip of the CD you have and the offset would be the other one found in the AR database. Each offset, release or pressing with the same layout are grouped separately by CRC match and stored side by side by side under the same ID in the AR database. To keep it simple, CUETools tests your rip at different offsets for matches in each group.

Ok, I think I understand and I do appreciate your patience. That completely changes my reference point of view. I didn't know the CD being ripped was the zero offset. I am still missing a piece (probably several of the big picture). So when it can't be verified it's saying I found a matching layout but no matching offset. Using the example above of the Detroit Rock City soundtrack it shows only one offset and it's not my matching offset, so what is that one? It's roughly 80 submissions (00+00/80) of AR1 and AR2 of only one offset?

It seems every rip has a zero offset whether it matches something or not. I guess the part I don't understand is when it's not matching like above. It's saying it's a matching layout but all the CRC's are incorrect?

Quote
When they repress a CD that doesn't mean the label or packaging has to change.
Ah, that makes sense. I wondered about that. It seems some CD's that seem to old for the ISRC information are suddenly filled in, I think.

Re: Two questions about EAC rip AccurateRip verify

Reply #5 –
Quote from: Riverstorm on
It's saying it's a matching layout but all the CRC's are incorrect?
Yes but that doesn't mean there's anything wrong with your rip. As it states in the EAC extraction logfile, "You may have a different pressing from the one(s) in the database"

Note: This is just for fun to demonstrate. You won't need to do this again as it doesn't give accurate results.
For fun, if you want to see if there are other results just out of CUETools' range you could put a high value in the 'offset' box of CUETools and Verify (verify won't change the audio in your files). Try 2900 then -2900. Other results may show up or have matches but the first or last track may NOT have a match because you'll be shifting the audio further than the number of samples AR ignores. Make sure you set the 'offset' box back to zero when you're done playing.

edit: not
korth

Re: Two questions about EAC rip AccurateRip verify

Reply #6 –
Quote from: Riverstorm on
It's saying it's a matching layout but all the CRC's are incorrect?For fun, if you want to see if there are other results just out of CUETools' range you could put a high value in the 'offset' box of CUETools and Verify (verify won't change the audio in your files). Try 2900 then -2900. Other results may show up or have matches but the first or last track may NOT have a match because you'll be shifting the audio further than the number of samples AR ignores. Make sure you set the 'offset' box back to zero when you're done playing.

Hey Korth this was interesting and helped a lot. Shifting -2900 yielded no change (except the peak range shows it's off every time) but shifting +2900 I received 2 hits. Even more interesting (or not ;)) is all tracks were verified as accurate with an offset of like 1482 and 2353 (something close to those numbers). Can you keep shifting the offset until it's zero?

So if I can take another stab at it. The pressing I have is now entered into the AR database but it will be "queued off to the side" until at least one more(?) pressing is entered/uploaded that matches?

CUETools really has nothing to do with the AR database or does it? I am still struggling with the CUETools offset range used for testing. If let's say for example that same pressing all of the sudden has 25 entries in the database and can be AR verified would CUETools use that new offset pressing as a valid range for testing for lack of better words? If not it would never be verifiable with CUETools as it sits. I mean does CUETools know there are say for example 5 different offsets for a particular pressing and will test a range around all 5 offset pressings or only one range that covers the largest portion of offsets? I guess what I am asking if what is the criteria for the CUETools range offset if that makes sense?

Re: Two questions about EAC rip AccurateRip verify

Reply #7 –
1) 2900+1482=4382

2) It will likely be placed in limbo until confirmed by another rip.

3) https://forum.dbpoweramp.com/showthread.php?20641-AccurateRip-CRC-Calculation
Quote
Read the track CRC records (multiple CRCs from different pressings are saved in the same file, walk the list until one matches)
Quote
Advanced Usage: Offset finding CRC

The offset CRC is a drive offset finding CRC, it is an AccurateRip CRC calculation 450 frames in and is calculated with one frames data. This can be used when offset adjusted for the drive to find the matching CRCs of other possible pressings, finding their offset. When the offset of a pressing is known an additional CRC can be calculated using data which is offsetted by the pressing amount (using data from the adjacent tracks). The maximum offset can be +-5 frames, otherwise the first or last track would fail to verify against the pressing.
5 frames = 2940 samples
korth
 

Re: Two questions about EAC rip AccurateRip verify

Reply #8 –
Korth, I truly appreciate all the help in understanding the process and how it works a little better. You sir are a scholar and a gentlemen and I do hope you have a wonderful weekend. Thank you. :)