For historical reasons there is some confusion between Tracks[1] and
Recordings[2] in MusicBrainz. Essentially what should be saved to
`MUSICBRAINZ_TRACKID` is the Recording MBID—which is what whipper is
correctly doing, but the value storing this value was called `mbidTrack`
rather than `mbidRecording`, which could potentially cause confusion.
[1] https://musicbrainz.org/doc/Track
[2] https://musicbrainz.org/doc/Recording
Signed-off-by: Frederik “Freso” S. Olesen <freso.dk@gmail.com>
In general, "albums" in everyday usage is what on MusicBrainz would be
considered a release group[1] while as far as I can tell, every single
instance of it being used in whipper is referring to a single "edition"
of an album, which is what would be called a "release" in
MusicBrainz terminology[2].
[1] https://musicbrainz.org/doc/Release_Group
[2] https://musicbrainz.org/doc/Release
Signed-off-by: Frederik “Freso” S. Olesen <freso.dk@gmail.com>
- Replace print statement with function call
- Replace except ..., ...: syntax with except ... as ...:
- Simplify obsolete try ... except ... code block
- Replace some unicode calls with u-prefixed strings
- Do not use `len(SEQUENCE)` to determine if a sequence is empty
- Replace dictionary creation
- Drop support for GObject static bindings
- Fix PEP8's line too long warning
- Remove useless parentheses
- Use triple quotes for docstring
- Address pylint's 'inconsistent-return-statements'
- Specify string format arguments as logging function parameters
- Comment out already disabled block of code
- Remove useless else (after return)
- Remove useless statement
- Do not import already imported module
* Begin work on moving cdrdao to a task
* Add code to start cdrdao task
* Allow cdrdao output to be asynchronously parsable
* Provide progress of cdrdao read toc/table to console
* Flake8 fixes, Freso's advices
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).
