Ok, it does appear that it is that simple.
In principle this (even the non-update case) results in volume jumps,
so maybe we'll want gradual gain change...
Notably, i thought we'd always seek if the pipeline
was already operating on the same URL as the new one,
but apparently only for adjacent songs?
The magic: if EBU R 128 loudness normalization is enabled,
just insert `volume` GST element into the pipeline
(where ReplayGain would be inserted) and configure it.
We currently don't support changing said gain after the pipeline
was created. We might need to, though, for a number of reasons.
This is a bit of a gotcha, there should be a point (where we seek?)
where we'd be able to change said gain, but for now this is a simple[r]
stop-gap fix.
The idea is that Integrated Loudness is an integral part
of the song, much like knowing it's beginning / ending
in the file, and we must handle it the exact same way,
and pipe it through all the way.
At the same time, `EngineBase` knows Target Level (from settings),
and these two combined tell us the Gain needed to normalize the
Loudness of the particular Song (`EngineBase::Load()` does that).
So the actual backend only needs to handle the Volume.
We don't currently support changing Target Level on the fly.
We don't currently support changing Loudness-normalizing Gain on the fly.
This does not handle the case when the song is loaded from URL
and thus the EBU R 128 measures, that exist, are not nessesairly correct.
This improves the performance of the analysis (by 2x!),
by offloading non-`libebur128`-computations (i.e. decode-convert)
to a separate thread, thus reducing walltime.
Again, somewhat pretty similar to the existing fingerprint analysis,
we must support performing it both for the new files,
and re-performing it on (some of) already-existing songs,
because it might have been disabled before.
Admittedly, i quite don't like some of this code,
maybe this can be done in a more concise way.
NOTE: this only supports scanning each separate songs.
Should we ever want to support per-album loudness normalization,
this will need massive changes...
The most juicy bit!
This is based on Song Fingerprint Analysis,
but here we must know the actual song, and not just the file.
The library supports only interleaved S16/S32/F32/F64,
so we must be sure we insert `audioconvert` into pipeline.
One point of contention here for me, is whether we should
feed the frames to the library the moment we get them
in `NewBufferCallback`, or collect them in a buffer
and pass them all at once. I've gone with the former,
because it seems like that is not the worst choice:
https://github.com/strawberrymusicplayer/strawberry/pull/1216#issuecomment-1610075876
In principle, the analysis *could* fail,
so we want to handle that gracefully.
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.
Jonas Kvinge
Roman Lebedev