Unable to find offset with a single-track cd

[mtdcr]

When running whipper offset find with a CD containing only one audio track, whipper fails to find the correct offset.

Track 1 finished, found 1397 Q sub-channels with CRC errors
INFO:whipper.command.offset:trying read offset 6...
INFO:whipper.command.offset:trying read offset 667...
INFO:whipper.command.offset:offset of device is likely 667, confirming...
WARNING:whipper.command.offset:only 1 of 1 tracks matched, continuing...
INFO:whipper.command.offset:trying read offset 48...
INFO:whipper.command.offset:trying read offset 102...
[...]

I suppose whipper treats a single track as insufficient data, but if that's the case, whipper could abort early and inform the user. In my case, the track's length was 49:33, so the amount of data should have been sufficient.

[JoeLametta]

Hi, thanks for reporting this issue!
Unfortunately whipper's offset find command is quite poor and I often suggest skipping it entirely (it's faster and easier to perform a manual search in AccurateRip's CD Drive Offsets page). The logic whipper follows to confirm the offset should be as such:

1. Whipper analyzes the CD using cdrdao to obtain the ToC (Table of Contents) of the CD
2. Whipper queries AccurateRip to get an entry for the given CD (aborting and reporting a failure if nothing is found)
3. Whipper rips the first track at various offsets (static list or user provided), calculating AccurateRip CRC, and matching it against the retrieved ones. If a match is found that offset is chosen for the following tests, if no offset produces a match the command stop and an error is issued.
4. Whipper tries to rip the first audio track of the CD (no HTOA) with differing offsets (taken from a static list or user provided) and keep going until it founds an accurate match (AccurateRip)
5. Whipper tries to rip all other tracks, except for the last one (to avoid readers that can't do overread), using the offset found in the previous step: if all the tested tracks are reported as being accurate (AccurateRip lookup), then the offset is confirmed, otherwise go back to step rip cd info seems to fail #3 with a different offset.

I suppose whipper treats a single track as insufficient data, but if that's the case, whipper could abort early and inform the user.

That's right: it's a worthwhile improvement and should be easy to implement too.