Loudness Nomalization seems to be clipping even when using F32 format about strawberry

[jonaski]

Thanks @LebedevRI
I don't want to remove bs2b, I use it at work to play music through headphones.
So there are two alternatives as far as I can see, either disable loudness normalization when bs2b is checked, or submit the patch fixing bs2b to upstream and different distros.
If alexmarsev/libbs2b@5ca2d59 is the correct way of fixing it, I suggest we patch bs2b, I can submit the patch to Fedora and openSUSE and ask Arch and Debian if they can add it.
The official repository is here: https://sourceforge.net/p/bs2b/code/HEAD/tree/trunk/libbs2b/ and the last time there was any real activity was in 2009, so not much chance a new version will be released.

[diizzyy]

fwiw, already submitted to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275403
This will likely be committed during the weekend due to maintainer timeout (port/package policies)

[jonaski]

@LebedevRI Can you look into this?

[LebedevRI]

@v-fox are you able to reliably reproduce the issue?

[LebedevRI]

Also, can you please show a screenshot of Settings -> Backend?
My only guess here is that somehow the strawberry's own gstreamer pipeline
somehow ends up needing to convert from floating-point in the middle of the process...

[v-fox]

are you able to reliably reproduce the issue?

Yes, in fact, it's more aggressive than I thought. It triggers more often with less loud tracks, so I had to decrease target further to -16 dB (after initial -6 to -9 to -12) while increasing limiter's boost. It was really bad with a quiet piano track.
Don't remember which one was it (maybe "Piano Collections NieR Gestalt & Replicant - Kainé" or "Hills of Radiant Wind") but it had a low "Integrated Loudness" of like -12 to -24.

Also, can you please show a screenshot of Settings -> Backend?

Sure but whole thing is not getting on screen.

[LebedevRI]

Could you please try narrowing it a bit, namely, try disabling all of the:

• Enable volume control
• Improve headphone listening <...> (bs2b)
• All of fading

Does it still reproduce with all of them disabled?
(Do fully restart the strawberry after changing settings before trying to reproduce!)

If not, does it reproduce with one specific setting enabled?
Or perhaps a combination of settings?

[v-fox]

Could you please try narrowing it a bit, namely, try disabling all of the:

I've set target to LN -6 and limiter to -4 (more like -1, considering -3 on input). The distortion became immediately apparent on "Kainé" piano track (IL=-15.85 LUFS and LR=10.67 LU; input spectrum smashes 0 dB in limiter). And you were right, disabling bs2b and just restarting playback made it stop sounding like as if headphone wires are about to fall off.

And I would have bet on fading effects instead, since they make slight "crunching" glitch under pipewire, at least when manually pausing. But this seems to be unrelated.

[LebedevRI]

Aha.
I think this is working as intended:
https://salsa.debian.org/debian/libbs2b/-/blob/2cd2edd45aa0736642c9b3181731ab0d1548de0a/src/bs2b.c#L504-508
Smart, i know, right?

I would certainly suggest that you ask the upstream to stop doing that.

[LebedevRI]

@jonaski i'm not really sure how this can be addressed on strawberry's side.
gstreamer lists bs2b in "bad" category, and original upstream is dead.

(I could supply a patch to remove bs2b from strawberry, if that's what is preferred :) )

[LebedevRI]

@v-fox thank you for the report! This is indeed a very not-nice issue.

[v-fox]

@v-fox thank you for the report! This is indeed a very not-nice issue.

@LebedevRI Thanks for pointing me to the right direction.
Could simply patching out the offending code do the trick or the whole logic for bs2b is hardcoded for integers?

[LebedevRI]

@v-fox thank you for the report! This is indeed a very not-nice issue.

@LebedevRI Thanks for pointing me to the right direction. Could simply patching out the offending code do the trick or the whole logic for bs2b is hardcoded for integers?

I think, simply patching out the offending code (i.e. clamping) is enough,
and the actual processing is done on double's. That being said,
theoretically such clamping might be required, but that is not likely.

Thanks @LebedevRI
I don't want to remove bs2b, I use it at work to play music through headphones.
So there are two alternatives as far as I can see, either disable loudness normalization when bs2b is checked, or submit the patch fixing bs2b to upstream and different distros.

Just to spell it out explicitly: the fact that Loudness Normalization can result in values > 1.0 (> +0 dB / > +0 dBFS)
is NOT a bug, is very intentional, and the fact that there is no limiter / clamping
after Loudness Normalization is NOT a bug. The whole pipeline should never internally limit.

If alexmarsev/libbs2b@5ca2d59 is the correct way of fixing it, I suggest we patch bs2b, I can submit the patch to Fedora and openSUSE and ask Arch and Debian if they can add it.

I think that could be the best way forward,
but there's a lot of distros/packages of bs2b :)

The official repository is here: https://sourceforge.net/p/bs2b/code/HEAD/tree/trunk/libbs2b/ and the last time there was any real activity was in 2009, so not much chance a new version will be released.

Yup. It kind-of sounds like it's time for an official fork for the project.