* safer version comparison
* regex bytes directly
* handle b'\x08 ...' case
* test_replaygain.py: injected command output should match the type of the actual output
* Fix unspecified `gain_adjustment` when method defined in config
* Fix difference between dB and LUFS values in case of mismatched `target_level`/`method`:
```
db_to_lufs( target_level <dB> ) - lufs_to_dB( -23 <LUFS> )
```
* Ignore single assertion in case of bs1770gain
(cherry picked from commit 2395bf224032c44f1ea5d28e0c63af96a92b96df)
Apply improvements suggested in GitHub PullRequest #3065:
- be idiomatic
- 0 is falsy
- check enum equality, not identity
- mutate list by constructing a new one
- improve documentation
- fix a typo
- do not mention deprecation of a config option
Configure the replaygain analysis by passing arguments to the Backends. This
avoids the difference between ReplayGain and EBU r128 backends; every Backend
can now fulfil both tasks. Additionally it eases Backend development as the
difference between the two tag formats is now completely handled in the main
Plugin, not in the Backends.
Use the POSIX character class instead of `\s` to match all whitespace in a
regular expression describing the language of valid inputs, in order to avoid a
test failure for the invalid escape sequence `\s` in Python strings.
This commit mostly addresses feedback:
- remove some unused parenthesis
- fix a typo
- expand some docstrings
- document that ffmpeg is usually easy to install
Add replaygain backend using ffmpeg's ebur128 filter.
The album gain is calculated as the mean of all BS.1770 gating block powers.
Besides differences in gating block offset, this should be equivalent to a
BS.1770 analysis of a proper concatenation of all tracks.
Just calculating the mean of all track gains (as implemented by the bs1770gain
backend) yields incorrect results as that would:
- completely ignore track lengths
- just using length in seconds won't work either (e.g. BS.1770 ignores
passages below a threshold)
- take the mean of track loudness, not power
When using the ffmpeg replaygain backend to create R128_*_GAIN tags, the
targetlevel will be set to -23 LUFS. GitHub PullRequest #3065 will make this
configurable.
It will also skip peak calculation, as there is no R128_*_PEAK tag.
It is checked if the libavfilter library supports replaygain calculation. Before
version 6.67.100 that did require the `--enable-libebur128` compile-time-option,
after that the ebur128 library is included in libavfilter itself. Thus we
require either a recent enough libavfilter version or the `--enable-libebur128`
option.
Previously using EBU R128 forced the use of the bs1770gain backend.
This change adds a whitelist of backends supporting R128. When the configured
backend is in that list it will also be used for R128 calculations. Otherwise
bs1770gain is still used as a default.
This should not change the overall behaviour of the program at all, but allow
for further R128-supporting backends to be added.
Return a namedtuple CommandOutput(stdout, stderr) instead of just stdout from
util.command_ouput, allowing separate access to stdout and stderr.
This change is required by the ffmpeg replaygain backend (GitHub
PullRequest #3056) as ffmpeg's ebur128 filter outputs only to stderr.
Since commit 95e569a, mediafile takes care of the float -> Q7.8 conversion in
R128 GAIN tags by itself.
From `store_album_r128_gain` this conversion was already missing, remove it from
`store_track_r128_gain`, too.
fixes#3311
bs1770gain is sorting the filenames internally, so in some corner cases it returns the results in a different order from the command-line arguments.
This patch uses the --xml option of bs1770gain (introduced in 0.4.6) in order to read the filenames reliably.
This is now handled by the central logging infrastructure; no need to change
it here. I think this must be a leftover from the era when plugins had to
explicitly muck with their verbosity level, but even still it doesn't make
sense to do set the level to INFO unconditionally...
