Whipper uses cdrdao during its ripping process. With this commit it will now store cdrdao's generated tocfile in the ripping path.
Preserving the tocfile allows users to easily burn ripped discs having a non-compliant cue sheet.
Fixes#214.
* Update failing AccurateRipResponse tests [1/2]
The failures seem to be caused by a remote metadata change (metadata from AccurateRip about a release ID changed) which means some of the asserts related to a specific release ID are failing. I've fixed this issue with two commits.
This is part 1: here I've updated the confidence values of two tracks making it agree with AccurateRip's remote.
* Update failing AccurateRipResponse tests [2/2]
This is part 2: here I've replaced the outdated AccurateRip bin file with a freshly downloaded one.
Whipper offset find needs a (remote) matching AccurateRip entry to perform its task and confirm the drive offset: if none is found, return early to prevent exception.
Fixes#208.
Commit 9c72ebccd3 introduced a bug: all template strings are validated against the disc template RegEx (which, for example, is wrong if we're testing the track template).
If the template string contains variables which aren't valid for whipper, raise ValueError exception listing all the included unrecognized variables.
I've also corrected the example template configuration lines in the README.
Fixes#279.
`os.pathconf()` expects a bytes object, but the path is stored as a
unicode object. Since there's no specified encoding, Python chokes when
trying to convert it to a bytes object. Explicitly encoding it as UTF-8
allows Python to change it to a bytes object smoothly.
Fixes https://github.com/whipper-team/whipper/issues/315
Now Docker adopters can use whipper trough Docker Hub's automatically built images.
Thanks to user "anarcat" for proposing and thoroughly explaining how to reach this goal.
Closes#301.
* Limit length of filenames
If whipper generated filenames are longer thant the maximum value supported by the filesystem, the I/O operations are going to fail.
With this commit filenames which may be too long are truncated to the maximum allowable length.
Fixes#197.
The values stored in variables _inARDatabase and _accuratelyRipped were double incremented when both AR v1 and AR V2 entries were present e/o matched, leading to a wrong calculation and potentially erroneous summary reporting.
After this fix, in case of double matches only one is counted against each track.
