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: Correct older rip with combined red/write offset of 0 - how to? (Read 1972 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Correct older rip with combined red/write offset of 0 - how to?

I have an older rip (2007) of a CD set, that for various reasons, we can assume will not be able to be ripped again. It was ripped on a much older version of EAC and at a time when perhaps people using EAC were less knowledgeable about how to correctly configure it.

As such, the log indicates that an HL-DT-ST GDR8164B was used - a drive known to have a +102 sample read offset. Though the log indicates that EAC was set to have a combined read/write offset of 0 samples.

If I’m not mistaken this means that no read offset compensation was applied at all during the rip, correct? As the assumption was that copies of this rip would be burnt by the same drive that read it, and thus all copies made on that particular drive would naturally end up with no sample offset after burning? But now those files are technically offset from the baseline/standard as is commonly used for all other rips in most modern FLAC collections? Am I somewhere along the right track?


If I split the old single-track image APE files to separated FLACs in CueTools, should I also enter +102 in the “Offset” setting in the box under “Extra”? Would this effectively apply the correct offset?

Re: Correct older rip with combined red/write offset of 0 - how to?

Reply #1 –
In short, the combined read/write offset is simply the read offset + write offset, so if your drive has a read offset of 102 and a combined read/write offset of 0 was applied then yes, you "need" to correct it with 102 in CUETools.
Assuming it's a commercial CD, if you run a verify pass against the files with an offset of 0 you should see something like:
Code: [Select]
Offsetted by 102:
 01     [884490c8] (200/1874) Accurately ripped
 02     [578f97ba] (200/1876) Accurately ripped
 03     [d8b66554] (200/1870) Accurately ripped
In the accuarterip results. If you then apply 102 into the Offset field and verify it again those matches should now appear directly under the 'AccurateRip ID:' heading (because you're now matching other rips with 0 offset).

Code: [Select]
[AccurateRip ID: 00132fd0-00b23daf-ab0a3a0c] found.
Track   [  CRC   |   V2   ] Status
 01     [884490c8|917351dc] (200+200/1874) Accurately ripped
 02     [578f97ba|ac936d0a] (200+200/1876) Accurately ripped
 03     [d8b66554|69b9a05f] (200+200/1870) Accurately ripped

That's assuming you're not doing it to create the "perfect" CD-R, otherwise you'd need to determine your drives write offset and modify it accordingly.

Obviously it doesn't really make any difference whether you correct it or not, but I would ;-)

Re: Correct older rip with combined red/write offset of 0 - how to?

Reply #2 –
Quote from: SimBun on
In short, the combined read/write offset is simply the read offset + write offset, so if your drive has a read offset of 102 and a combined read/write offset of 0 was applied then yes, you "need" to correct it with 102 in CUETools.
Assuming it's a commercial CD, if you run a verify pass against the files with an offset of 0 you should see something like:
Code: [Select]
Offsetted by 102:
 01     [884490c8] (200/1874) Accurately ripped
 02     [578f97ba] (200/1876) Accurately ripped
 03     [d8b66554] (200/1870) Accurately ripped
In the accuarterip results. If you then apply 102 into the Offset field and verify it again those matches should now appear directly under the 'AccurateRip ID:' heading (because you're now matching other rips with 0 offset).

Code: [Select]
[AccurateRip ID: 00132fd0-00b23daf-ab0a3a0c] found.
Track   [  CRC   |   V2   ] Status
 01     [884490c8|917351dc] (200+200/1874) Accurately ripped
 02     [578f97ba|ac936d0a] (200+200/1876) Accurately ripped
 03     [d8b66554|69b9a05f] (200+200/1870) Accurately ripped

That's assuming you're not doing it to create the "perfect" CD-R, otherwise you'd need to determine your drives write offset and modify it accordingly.

Obviously it doesn't really make any difference whether you correct it or not, but I would ;-)


Thank you for your reply. for the first disc in this set, I ran the verification with the offset set to 0 and unfortunately got the following

Code: [Select]
Offsetted by 102:
 01     [5b534664] (0/5) No match (V2 was not tested)
 02     [c942ffca] (0/5) No match (V2 was not tested)
 03     [a0a623b6] (0/5) No match (V2 was not tested)
 04     [3319bf4d] (0/5) No match (V2 was not tested)
 05     [fe127506] (0/5) No match (V2 was not tested)
 06     [da8be313] (0/5) No match (V2 was not tested)
 07     [ae0be86c] (0/5) No match (V2 was not tested)
 08     [ddc19d4a] (0/5) No match (V2 was not tested)
 09     [b8475400] (0/5) No match (V2 was not tested)
 10     [a6713553] (0/5) No match (V2 was not tested)
 11     [29dac4c9] (0/5) No match (V2 was not tested)
 12     [263b5352] (0/5) No match (V2 was not tested)
 13     [7f4d948b] (0/5) No match (V2 was not tested)
 14     [16940a76] (0/5) No match (V2 was not tested)

...which I think only speaks to the rarity of this set. When I run the verification with the offset as 102, I do get this

Code: [Select]
[AccurateRip ID: 00298bb7-018ece0f-c70dfe0e] found.
Track   [  CRC   |   V2   ] Status
 01     [5b534664|39addc7e] (0+2/5) Accurately ripped
 02     [c942ffca|c54e7855] (0+2/5) Accurately ripped
 03     [a0a623b6|8c794fa3] (0+2/5) Accurately ripped
 04     [3319bf4d|fabd7af2] (0+2/5) Accurately ripped
 05     [fe127506|bb4e12c8] (0+2/5) Accurately ripped
 06     [da8be313|1dea202c] (0+2/5) Accurately ripped
 07     [ae0be86c|e6466265] (0+2/5) Accurately ripped
 08     [ddc19d4a|e618befb] (0+2/5) Accurately ripped
 09     [b8475400|3736efb9] (0+2/5) Accurately ripped
 10     [a6713553|34db05b5] (0+2/5) Accurately ripped
 11     [29dac4c9|740b018f] (0+2/5) Accurately ripped
 12     [263b5352|4ac52a8d] (0+2/5) Accurately ripped
 13     [7f4d948b|a1d9ff7a] (0+2/5) Accurately ripped
 14     [16940a76|407a3943] (0+2/5) Accurately ripped

I think the +2 is the ARv2 verification? If so I guess this means there may have been a couple of rips performed of this disc in the time after ARv2 became a thing.
The low number of hits post-correction doesn't inspire great confidence but since we do know model of drive used thanks to the EAC log, and know the proper offset of 102 for that drive wasn't applied as far as that log indicates, I will go ahead and correct all 16 CDs this way.
I need to convert them from single-track APEs to split FLACs anyway, so I'd agree its better to do so correctly than leave them with the wrong offset for no reason.

Re: Correct older rip with combined red/write offset of 0 - how to?

Reply #3 –
Quote from: MrRom92 on
I think the +2 is the ARv2 verification?
Yes.

In the first run, where you didn't align offset, it would check v1 and indicate that there is something to be checked with v2, but CUETools never got as far as to actually run the offset alignment unless you tell it to (your second run). For that you could have used https://www.dbpoweramp.com/Help/perfecttunes/accuraterip.htm (from the creator of AccurateRip), but you know already by now.
With offset manually set to 102, CUETools finds 0+2 (i.e. zero ARv1 hits and 2 ARv2 hits).

From your information on the log, you did not apply the 102, so none of the hits are yours - ah good, they are verified then. Also, if you actually ripped the CD in 2007, that was before ARv2 so there would be no chance of the ARv2 being yours.

Re: Correct older rip with combined red/write offset of 0 - how to?

Reply #4 –
Quote from: Porcus on
Quote from: MrRom92 on
I think the +2 is the ARv2 verification?
Yes.

In the first run, where you didn't align offset, it would check v1 and indicate that there is something to be checked with v2, but CUETools never got as far as to actually run the offset alignment unless you tell it to (your second run). For that you could have used https://www.dbpoweramp.com/Help/perfecttunes/accuraterip.htm (from the creator of AccurateRip), but you know already by now.
With offset manually set to 102, CUETools finds 0+2 (i.e. zero ARv1 hits and 2 ARv2 hits).

From your information on the log, you did not apply the 102, so none of the hits are yours - ah good, they are verified then. Also, if you actually ripped the CD in 2007, that was before ARv2 so there would be no chance of the ARv2 being yours.



Thank you, this disc is from a Melodiya boxset that I had to, ahem, find alternative sources for, so I can’t say I ripped this one myself - wish I could. It doesn’t even have a discogs entry as far as I can find, and I think even if I could find a copy for sale, importing anything from Russia into the US is probably another matter entirely these days… so the 15 year old misconfigured EAC rip it is.