I still kinda feel it is like, if you already had Tux smiling at you, why not rip it in Linux and try to retro-verify it by CUETools or something else?

Does cdparanoia have offset correction? If not, what are the odds that I'd be able to verify the rip after the fact with CUETools?

       -t --toc-offset number
              Use this option to force the entire disc LBA addressing to shift by  the  given
              amount;  the  value  is added to the beginning offsets in the TOC.  This can be
              used to shift track boundaries for the whole disc manually on sector  granular-
              ity.  The next option does something similar...

       -T --toc-bias
              Some  drives (usually random Toshibas) report the actual track beginning offset
              values in the TOC, but then treat the beginning of track 1 index 1 as sector  0
              for all read operations.  This results in every track seeming to start too late
              (losing a bit of the beginning and catching a  bit  of  the  next  track).   -T
              accounts  for  this  behavior.   Note that this option will cause cdparanoia to
              attempt to read sectors before or past the known user data area  of  the  disc,
              resulting  in  read  errors at disc edges on most drives and possibly even hard
              lockups on some buggy hardware.

       -O --sample-offset number
              Use this option to force the entire disc to shift sample position output by the
              given  amount;  This  can  be used to shift track boundaries for the whole disc
              manually on sample granularity. Note that this will cause cdparanoia to attempt
              to  read  partial  sectors before or past the known user data area of the disc,
              probably causing read errors on most drives and possibly even hard  lockups  on
              some buggy hardware.

       The  span  argument may be a simple track number or an offset/span specification.  The
       syntax of an offset/span takes the rough form:

       1[ww:xx:yy.zz]-2[aa:bb:cc.dd]

       Here, 1 and 2 are track numbers; the numbers in brackets provide a finer grained  off-
       set  within a particular track. [aa:bb:cc.dd] is in hours/minutes/seconds/sectors for-
       mat. Zero fields need not be specified: [::20], [:20],  [20],  [20.],  etc,  would  be
       interpreted  as twenty seconds, [10:] would be ten minutes, [.30] would be thirty sec-
       tors (75 sectors per second).

       When only a single offset is supplied, it is interpreted as a starting offset and rip-
       ping  will  continue to the end of the track.  If a single offset is preceeded or fol-
       lowed by a hyphen, the implicit missing offset is taken to be the start or end of  the
       disc, respectively.

abcde -1 -o flac -a default,cue

I would not trust the offsets reported by CUETools, as it almost always reports multiple alternative offsets with no indication as to which one is the correct one.

I would not trust the offsets reported by CUETools, as it almost always reports multiple alternative offsets with no indication as to which one is the correct one.

Whipper looks interesting, but I don't know enough about Linux to install it, since it isn't available in my distro's repositories, and the installation scripts are giving me multiple errors. I guess I'll try abcde.

You also might try Fre:ac.

None of the logs are telling you which offset is correct - it's the matching rip numbers that give you this indication - they're just presenting other rips relative to yours.

Quote from: zordaz on 2022-08-21 19:58:22

You also might try Fre:ac.

Thanks for the tip. I assume it only supports verifying rips against AR and not submitting new results? I don't see any mention of AR or CTDB support on the website, so I guess rip verification is not a touted feature.

Nowhere in the CUETools results did it tell me that I needed to apply an offset of +102 to account for the read offset of my CD drive. Yes, CUETools suggests alternative offsets in the results, but it doesn't say which offset is correct for my particular CD drive.

+102 with an AR match will get you: file sent to CD writer #1 which applies offset P, CD is pressed, played in your drive that applies -102, +102 zeroes out the latter - but does not zero out the "P", which is unknown.
+xyz with an AR match will get you: file sent to CD writer #2, which applies offset Q etc - and all for sudden you are matching the output from CD writer #2, which is Q-P off the output from CD writer #1.

But you don't know which one is closer to the original file.

I don't understand your point. Why would I use +xyz offset when I know that the offset of my drive is +102?

There is no reason to try any other value since the correct value is known and will give the best result for this particular drive on all rips.

AFAIK that's the whole point of having a database of CD drive read offsets.

I think I was a bit unclear in my original statement. I know that there is no universally correct offset; what I mean is that I ripped the disc without any offset correction using abcde, and then I tried to verify it using CUETools on a different computer. CUETools reported CTDB results that my rip was accurate, but AR did not recognise the disc at all, because the offset of my rip was uncorrected.

[AccurateRip ID: 0011590f-008dc7c1-9b0dcc0b] found.
Track   [  CRC   |   V2   ] Status
 01     [74a308c0|f823650c] (200+200/404) Accurately ripped
 02     [22770025|b6ebba80] (200+200/404) Accurately ripped
 03     [23a8ac4f|1b4f4b30] (200+200/404) Accurately ripped
...

[AccurateRip ID: 0011590f-008dc7c1-9b0dcc0b] found.
Track   [  CRC   |   V2   ] Status
 01     [4a5640cb|d2115bf7] (000+000/404) No match
 02     [d9d496d2|c5b4c939] (000+000/404) No match
 03     [f5363be8|dae8b933] (000+000/404) No match
...
Offsetted by -594:
 01     [74a308c0] (200/404) Accurately ripped
 02     [22770025] (200/404) Accurately ripped
 03     [23a8ac4f] (200/404) Accurately ripped

I used CUETools to apply the +102 offset and to split the giant FLAC file into individual tracks, at which point CUETools warned me that I would be deleting 102 samples, as expected. Now when I verify the WAV files I split, both CTDB and AR report that my rip is accurate, because AR can only verify a rip that has offset correction.

Nowhere in the CUETools results did it tell me that I needed to apply an offset of +102 to account for the read offset of my CD drive. Yes, CUETools suggests alternative offsets in the results, but it doesn't say which offset is correct for my particular CD drive.

I had to look up my drive model in the AR database to get the +102 number that I needed. That's what I meant about "not trusting" the CUETools results.

In order to properly verify a rip, you must account for your drive's read offset, and CUETools can't tell you what it is when you ripped the CD on a different computer. The AR database of drive offsets can.

Quote from: Aleron Ives on 2022-08-22 00:06:18

AFAIK that's the whole point of having a database of CD drive read offsets.

That is the old and insufficient way. Offset correction was implemented before one realized the need for cross-pressing verification. The latter came about around 2010 or so.

Are you saying that there's an alternative to setting your drives offset?

But here is the point: of two CDs contain the same audio, but different offsets, nothing says that yours is the "correct" one. (I'm not sure if there even exist CD writers with an offset of zero.)