Change `Use Replay Gain metadata if it is available` checkbox
into a radio button and add button to disable any loudness normalization.
Add second group(+radio button), for EBU R 128 loudness normalization.
There is only one tunable: Target Level,
defaulting to EBU R 128-recommended `-23 LUFS`.
Care should be taken when changing Target Level!
You probably don't want to go outside of `-30..-16` range!
At least as implemented, there is only support for per-song normalization,
i.e. no per-album normalization.
We do not do anything with loudness range,
although i have some further thoughts about compression.
We do not do anything about clipping / peak level.
NOTE: we do not need `libebur128` to *perform* the audio normalization,
only for the initial analysis.
Co-authored-by: Jonas Kvinge <jonas@jkvinge.net>
Much like song fingerprinting, performing EBU R 128 analysis is optional.
If you will want to enable EBU R 128 loudness normalization
(which does not depend on the presence of `libebur128`!)
you will probably want to enable it, but it is not enabled by default.
There will be support for rescanning songs for which it is missing.
We are going to use said library to calculate the two measures in question
from decoded audio.
I am adding this in default-on state, since this library
should be well-packaged everywhere, and this is something that,
i presume, we want.
Still mostly boilter-plate-y. It is somewhat interesting to see that info
in playlist view, so add the two fileds as columns.
At least for Integrated loudness, since it's normally negative,
we need to add a specialized Delegate.
They end up being used in a quite a number of places later on,
it makes sense to have them in a common place.
Integrated Loudness (LUFS) is *usually* negative, so we really want to
always print a sign. But Loudness Range is non-negative.
I think it makes sense to print one or at most two decimal places for these.
Again, pretty boring boilerplate, rather identical to the handling of
other fields. We do need to be careful when [de]serializing it, though,
we don't want to accidentally loose the `NULL` (i.e. unknown) state!
Nothing really ground-breaking, just add those two fields
to each table that already has `bitrate`/`samplerate`/`bitdepth` fields.
Those new fields do need to be able to represent an invalid state
which is their default state, thus they are non-`NOT NULL`.
In principle, the actual field type could be `INTEGER`
(i.e. fixed point w/ 2 fractional digits), but unless we really want to
save a few bytes, it doesn't seem worthwhile.
FIXME: i'm not sure if `device-schema` should be changed too.
Roman Lebedev
Jonas Kvinge
Strawbs Bot
dependabot[bot]
Dakes
Andrei Stepanov