by adding files which are not completely silent, thus hitting a different
code path in some calculations
The sample files were generated using
> sox -n whitenoise.flac synth 00:00:02 whitenoise
> ffmpeg -i whitenoise.flac whitenoise.opus
> ffmpeg -i whitenoise.flac whitenoise.mp3
This is a preparation for moving the Gst calculation to multiprocessing
worker threads. Passing only the file paths to the worker threads instead of
synchronizing the entire `Item`s (i.e. minimizing the data that is
shared between the processes) hopefully helps to prevent any issues with
this approach.
...album gains. This is in preparation for parallelizing the track
analysis, and computing the album values in the plugin's "main thread"
once all items are done.
The parallelism strategy in #3478, in retrospect, used a pretty funky
way to deal with exceptions in the asynchronous work---since
`apply_async` has an `error_callback` parameter that's meant for exactly
this. The problem is that the wrapped function would correctly log the
exception *and then return `None`*, confusing any downstream code.
Instead of just adding `None`-awareness to the callback, let's just
avoid running the callback altogether in the case of an error.
Also, add a convenience function `store()` that dispatches two the
either of the two methods. This will be useful later, when rewriting the
parallel code (but doesn't simplify the code now).
Renames *GainHandler -> *Task and instead of having a singleton
instance, creates a *Task object for each album/item to process. The
advantage is that now, related data can be bundled in the instance,
instead of passing multiple arguments around.
The plugin has loads of indirection and nested functions which make it
really hard to reason about. The larger picture here is that I'd like to make
the code more manageable before reworking the parallelism issues.
In particular, instead of manually implementing an interface using a
function that returns a tuple of function pointers, this commit creates proper
classes. Again, no functionality is changed, this only moves code
around.
References in the documentation to this plugin were removed in
beetbox/beets#3127 (beetbox/beets#3130) but no actual code
changes were made.
This PR removes support for this dependency entirely.
