Interest in switching to correct driver offset corrections?

[JustinTArthur]

AccurateRip has an inconvenient truth that every entry is likely offset by 30 extra samples. Would project maintainers be interested in a largely backwards-incompatible change to use the real-life drive offset correction values?

It would mean uglier AccurateRip v1 and v2 checksum calculating, where we will sometimes have to pre-read samples from the prior track or do some null-filling tricks in order to match the AccurateRip DB entries.

I may be willing to contribute to the PR if the team is on-board and I get time.

[github-actions]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

[eshattow]

One way around this is to more generally support a rolling window of the checksum. Python Audio Tools (unmaintained upstream I think or the author lost interest) has this kind of lookup so you can discover by how many samples offset a match is in the AR1 and AR2 database. There's a practical range of offsets for which disc reading hardware exists within this range, and then you're calculating everything trying to find a match in one go.