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:
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:
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 ====
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).
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.
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?
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.
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.
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! :)
[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]