Variable offset detected

[ghost]

I'm using whipper 0.7.0 on a Gentoo Linux system. My optical drive is a Plextor PX-830UF. It's a USB device.

I tried the whipper offset find command with 3 different audio CDs, and I obtained 3 different results: 30, 96 and 102.

Is this a bug in whipper? Is my drive defective? Should I buy a different drive?

My drive is not on this list, but there's a probably similar "PLEXTOR - DVDR PX-830SA" device which is reported to have a 96 offset.

[MerlijnWajer]

What CDs did you use? It's possible that the accurate rip db contains some false results too, confusing the offset finding.

[ghost]

Take Off Your Pants and Jacket by Blink182 returns an offset of 30 Halcyon Days by Ellie Goulding returns an offset of 96 Unapologetic by Rihanna returns an offset of 102

Should I test more audio CDs? I own a total of 15 CDs at the moment, so that could take a lot of time...

[ghost]

I just finished testing 13 CDs. Results:

• 8 CDs have 96 as offset
• 2 CDs have 30 as offset
• 2 CDs have 102 as offset
• 1 CD has 48 as offset

I also tried running the whipper offset find -o +96 command on the last 5 CDs. Strangely, it turns out that whipper is happy with 96 as a value as well.

[ghost]

Some more info:

$ whipper drive list
drive: /dev/cdrom, vendor: PLEXTOR , model: DVDR   PX-830SA , release: 1.01
       Configured read offset: 96
       Can defeat audio cache: True

[MerlijnWajer]

Sounds like 96 is the offset you should use, then. My assumption is that the accuraterip database simply contains some checksums that were uploaded by someone with a wrong offset, and this makes whipper assume a different offset (e.g. 30) is better. 30, 102, and 48 are all tried before 96:

OFFSETS = ("+6, +667, +48, +102, +12, +30, +103, +618, +96, +594, "
           "+738, +98, -472, +116, +733, +696, +120, +691, +685, "
           "+99, +97, +600, +676, +690, +1292, +702, +686, -24, "
           "+704, +697, +572, +1182, +688, +91, -491, +145, +689, "
           "+564, +708, +86, +355, +79, -496, +679, -1164, 0, "
           "+1160, -436, +694, +684, +94, +1194, +106, +681, +117, "
           "+692, +943, +92, +680, +678, +682, +1268, +1279, +1473, "
           "-582, -54, +674, +687, +1272, +1263, +1508, +675, "
           "+534, +740, +122, -489, +974, +976, +1303, +108, +1130, "
           "+111, +739, +732, -589, -495, -494, +975, +961, +935, "
           "+87, +668, +234, +1776, +138, +1364, +1336, +1262, "
           "+1127")

(from command/offset.py)

So I am not sure if this is a whipper bug per se, but rather a buggy database. We could perhaps look at the various ARDB confidence levels and decide that a match is the wrong one.

[JoeLametta]

Sounds like 96 is the offset you should use, then.

I agree. To be 100% sure, if you have another drive with an offset already included in that list, you could rip a CD with that other drive (using the known offset), then rip it again with your USB drive (offset 96). Choose a track (for example track 2) and sha1sum both track 2 from drive 1 rip and track 2 from USB drive rip: if the hashes are the same then you know you've chosen a consistent read offset.

:wink:

[ghost]

Unfortunately I don't have another CD drive. I'll use +96. Thanks for the help!