Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently (on develop), ripping using an offset > 587 always warns you about the upstream cd-paranoia bug. It tells you the warning that will be logged when cd-paranoia fails in that way, and then you see the warning when it fails. Here's that output when using cd-paranoia versions 10.2+2.0.1, which still has the offset bug:
This branch changes the offset warning to appear after the rip fails with size zero with a large offset, and it suppresses the other warnings about 0 not being equal and the non-integer number of frames. Here's that new output, again with 10.2+2.0.1:
Therefore, when I upgrade cd-paranoia to a version that fixes the offset bug, I can rip my CD without getting the warning about large offsets at all. This resolves issue #635 without trying to figure out whether a fixed version of cd-paranoia is installed. Here's proof with the updated cd-paranoia (10.2+2.0.2), same drive, same CD, but now there's no offset warning between the Q channel CRC check and the successful rip:
Additional fix in this branch: One of the AccuRip tests pulls an entry from the live database and asserts the parsed values match the test-defined values, but the entry has been updated with new confidence numbers since the test was written. I've addressed this by changing the assertion about the confidence count to be "greater than or equal" instead of "equal" so that it won't break with future changes to the AccuRip that are outside this project's direct control.
Considered but not done: I considered moving the warning for the bug on track count 99 in the same way, but I don't have such a CD on hand to test.