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: A quick question burning a rip ARv1 vs ARv2 (Read 2939 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A quick question burning a rip ARv1 vs ARv2

I was wondering if someone would answer a quick question on burning a CD. My drive read offset is +6 (iHAS124-F). I created an offset test CD and it showed 6 duplicate samples with a zero offset and the timing was something similar to 0:00:00.538 so I set my write offset to -6.

For my test I used the maxi-single Metallica-One/Eye Of The Beholder. Track 2 on the original CD matches ARv1 but on the write/re-rip CD track 2 matches ARv2. What's the difference between the two or is there no difference? When comparing the original WAV to the re-rip WAV with the Tool menu option it shows blank info which I would guess is they match fine. I also ripped it via FLAC and the test/copy CRC match the original but I was curious why v1 for the original vs v2 for the re-rip on track 2? I also tried the Moana soundtrack (my youngest girl has discovered a new soundtrack which is a blessing as I think I have every track of Frozen memorized) and that one matched ARv2 from track 1 to track 40 on both the original and re-rip.

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

EAC extraction logfile from 30. November 2016, 15:03

Metallica / One - Eye Of The Beholder

Used drive  : ATAPI   iHAS124   F   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

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.32 |  7:24.70 |        32    |    33401   
        2  |  7:25.27 |  6:26.25 |     33402    |    62376   


Range status and errors

Selected range

     Filename E:\EAC Rips\Metallica - One - Eye Of The Beholder.wav

     Peak level 99.5 %
     Extraction speed 2.2 X
     Range quality 100.0 %
     Copy CRC BF3915A6
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 2)  [4FC0A2A1]  (AR v2)
Track  2  accurately ripped (confidence 2)  [1A223714]  (AR v1)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: AT7hS1Dbox4qPGjXXYqyUDXtmUw-] found
Submit result: already submitted
Track | CTDB Status
  1   | (6/6) Accurately ripped
  2   | (6/6) Accurately ripped


==== Log checksum 63124EA74638F6D3765CA62A0066678B39FEC30BBB007C286D1CF0858AAE488F ====

Written/re-ripped CD:
Code: [Select]
Exact Audio Copy V1.3 from 2. September 2016

EAC extraction logfile from 11. May 2017, 23:12

Metallica / One - Eye Of The Beholder

Used drive  : ATAPI   iHAS124   F   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

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.32 |  7:24.70 |        32    |    33401   
        2  |  7:25.27 |  6:26.25 |     33402    |    62376   


Range status and errors

Selected range

     Filename E:\EAC Rips\Metallica - One - Eye Of The Beholder.wav

     Peak level 99.5 %
     Extraction speed 6.1 X
     Range quality 100.0 %
     Copy CRC BF3915A6
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 3)  [4FC0A2A1]  (AR v2)
Track  2  accurately ripped (confidence 2)  [100E21AB]  (AR v2)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: AT7hS1Dbox4qPGjXXYqyUDXtmUw-] found
Submit result: already submitted
Track | CTDB Status
  1   | (8/8) Accurately ripped
  2   | (8/8) Accurately ripped


==== Log checksum 0B3FDD81667CF162A715EAEC373AB8E5EBF671AC2C502DE44F887AAAAE6B1FB5 ====
 

Re: A quick question burning a rip ARv1 vs ARv2

Reply #1 –
First: they are identical.

The reason why the numbers are reported different, is that the number of hits in the AccurateRip database will change as more are submitted, and half a year has passed. Maybe even the hit is your own rip, I do not know how well EAC knows that it isn't.

For various reasons, the AccurateRip calculation algorithm was changed, hence v1 and v2. They live side-by-side in the database. In November, the best hit for track #2 was 2 looking up the AR v1 checksum. In May, there were two hits with the AR v2 checksum as well. If I am right, EAC chooses to report only a score of 2, but it doesn't bother to tell you that it could have obtained it in two ways.

If you try to retro-verify using CUETools, you will see both ARv1 and ARv2 hits (as long as it does not have to shift offset).

Re: A quick question burning a rip ARv1 vs ARv2

Reply #2 –
Quote from: Porcus on
If you try to retro-verify using CUETools, you will see both ARv1 and ARv2 hits (as long as it does not have to shift offset).
You can manually apply an offset to get a match against V2 entries in the AR database.

The offset field is borked in 2.1.5, however (try entering a negative number).  2.1.4 works correctly and provides for a much wider range.

Re: A quick question burning a rip ARv1 vs ARv2

Reply #3 –
Ah, I think the light bulb turned on, well explained if I understand it correctly. If I go back and re-rip the original CD it would probably show v2 for both tracks now in May (even if it's my own submissions doing it as EAC isn't tracking or using some unique identifier for each instance of EAC in production)? I think I remember in an older post Greynol pointed out that the database is fairly malleable.

In November it was a v1 match but with regular new submissions it's perpetually dynamic and in May when I did a burn/rip test v2 is now what matches with at a minimum of 2? Does it try for a v2 match first and then v1? I mean if it can obtain it in two different ways does v2 take precedence in the match results? For some reason I have stuck in my head that v1 had issues with certain rips or something so v2 is preferred or corrected those issues. Or is that wrong and both v1 and v2 are generated and uploaded to the database for each rip?

I do use CUETools often and keep a shortcut on my desktop. I remember Korth having me try some different offsets to show how something worked. How do you retro-verify or is that what you mean by shifting the offset is to retro-verify? Is there a way to gauge the numbers to use or just random a few hundred each way trying larger numbers as you go?


Re: A quick question burning a rip ARv1 vs ARv2

Reply #4 –
Quote from: greynol on
The offset field is borked in 2.1.5, however (try entering a negative number).
It just takes a little extra work. You can add a positive number then move the reference inside the box left of the number before you add the symbol for negative.
korth

Re: A quick question burning a rip ARv1 vs ARv2

Reply #5 –
Yep, well aware of that. It doesn't diminish either of my expressed concerns: behavior is borked and allowable offset range has been significantly reduced.

Re: A quick question burning a rip ARv1 vs ARv2

Reply #6 –
Porcus, I know you knew how this would look already but here's the CUETools log from the CD. I never occurred to me to run CUETools on both the original and re-rip and they would comeback identical. I was just comparing the original EAC log to the re-rip EAC log thinking I have done something incorrectly or they should match values. That was the first CD I actually tried burning and your explanation was truly pivotal or I would have just continued on never understanding at all what was happening. Also thanks Korth has tirelessly explained several things too. You guys are truly rock stars and I hope you have a great week! :)

Code: [Select]
[CUETools log; Date: 5/14/2017 10:55:31 PM; Version: 2.1.5]
Pregap length 00:00:32.
[CTDB TOCID: AT7hS1Dbox4qPGjXXYqyUDXtmUw-] found.
Track | CTDB Status
  1   | (8/8) Accurately ripped
  2   | (8/8) Accurately ripped
[AccurateRip ID: 00017643-0003e00f-11033f02] found.
Track   [  CRC   |   V2   ] Status
 01     [719b9939|4fc0a2a1] (3+3/8) Accurately ripped
 02     [1a223714|100e21ab] (2+2/6) Accurately ripped
Offsetted by -670:
 01     [dde9cbd9] (0/8) No match (V2 was not tested)
 02     [2acb7ff2] (0/6) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99.5 [BF3915A6] [109A0EA6]   CRC32   
 01   98.0 [EA478F8E] [B1E30D9D]           
 02   99.5 [9D8FFAA2] [7E96FE89]