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.
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.
