Spotify and loudness normalization - how can normalizaed track have higher DR than non-normalized

[danadam]

are the >0 dBFS peaks from playing music with normalization off now recoverable with Spotify’s volume control?

And actually, it might not be the spotify app that is doing the clamping.

After some investigation (pulseaudio 14.2), AFAICT they are both clamping samples to 1.0.

First, pulseaudio. The sample format in the sink-input (i.e., the stream that I am sending) is float32le. The sample format in the sink (i.e., DAC) is s32le. Because of that difference a resampler is created and added to the sink-input (see sink-input.c:463). It is a simple "copy" resampler, which means it doesn't change sampling rate but only converts samples from one format to another. You can see this in the logs:

D: [pulseaudio] sink-input.c: Negotiated format: pcm, format.sample_format = "\"float32le\""  format.rate = "44100"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
I: [pulseaudio] sink-input.c: Trying to change sample spec
D: [pulseaudio] sink.c: Suspending sink alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo due to changing format, desired format = float32le rate = 44100
I: [pulseaudio] alsa-sink.c: Sink does not support sample format of float32le, set it to a verified value

...

I: [pulseaudio] resampler.c: Forcing resampler 'copy', because of fixed, identical sample rates.
D: [pulseaudio] resampler.c: Resampler:
D: [pulseaudio] resampler.c:   rate 44100 -> 44100 (method copy)
D: [pulseaudio] resampler.c:   format float32le -> s32le (intermediate float32le)
D: [pulseaudio] resampler.c:   channels 2 -> 2 (resampling 2)

The problem is, that in the pulseaudio pipeline the resampler is normally run before the volume change. So the resampler clamps the samples during the conversion to s32le, before they have a chance to be attenuated. But there is one case when that processing order is reversed. This happens when the channel_maps of sink-input and sink differ (see sink-input.c:916). To test that, I generated two float32le WAV files with 30 sec of 220 Hz tone:

• mono, with amplitude +9 dBFS
• stereo, with amplitude +3 dBFS

ffmpeg -hide_banner -f lavfi -i "sine=frequency=220:duration=30,volume=27.06dB" -c pcm_f32le sin.mono.wav
ffmpeg -hide_banner -f lavfi -i "sine=frequency=220:duration=30,volume=24.06dB" -c pcm_f32le -ac 2 sin.stereo.wav

(they are in the attachment, so you can test it too)
The mono file, when re-mapped by pulseaudio to stereo, will also result in +3 dBFS in each channel. I played them using "paplay" command and I changed the volume using "pavucontrol". Reducing the volume while playing the stereo file did not help. Reducing the volume while playing the mono file stopped the clipping at the expected -3 dB.

I came up with a somewhat hacky idea to trigger this behavior even for stereo files. I added the "remap-sink" module with "right,left" channel map:

]$ MASTER_SINK="alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo"
]$ pacmd load-module module-remap-sink sink_name=Channels_Switcheroo sink_properties=device.description=Channels_Switcheroo \
master="${MASTER_SINK}" channels=2 remix=no format=float32le \
channel_map=front-right,front-left master_channel_map=front-right,front-left

Any "normal" stream (i.e. one with "left,right" mapping) sent to this sink will swap channels and by doing so it will apply volume change too. Then the stream from this sink to the master sink will swap channels again and it will do the sample format conversion. So now, when I choose "Channels_Switcheroo" for "paplay" in "pavucontrol", reducing the volume while playing the stereo file also stops the clipping.

And now to spotify. I did set "Channels_Switcheroo" for spotify too and reduced the volume but it did not help . The "Physical" captures with and without normalization still show the same clipping difference as before. That makes me think that they clamp the samples too, but I don't know if on purpose or by accident.

 

[Feelas]

Digging this old thread out, from today's reading I've figured out (didn't take long) that supposedly Spotify has stopped using limiter as of sometime in the mid 2021s, see Spotify for Artists "Loudness normalization" article - the only mention of limiter being used is now in the "Loud" (aka -11dB LUFS target) setting of the normalizer.

 

[Old_School_Brad]

I've read through the entire thread, and the conclusion seemed to be that "quiet" was the best option for cross-genre listening -better than "normal," "loud," and even having normalization turned off.

It looks like Spotify has since made changes.

So, what’s the verdict two and a half years later? Is it better to use normalization or leave it off?

 

[AnalogSteph]

Looks like either Normal or Quiet should not degrade anything, you would merely get a greater degree of level variation in Normal as the normalization is less effective when shooting for a higher average level with clipping protection enabled. So in essence, Quiet remains the best setting assuming your system has the gain / dynamic range reserve for it.

 

[Old_School_Brad]

Looks like either Normal or Quiet should not degrade anything, you would merely get a greater degree of level variation in Normal as the normalization is less effective when shooting for a higher average level with clipping protection enabled. So in essence, Quiet remains the best setting assuming your system has the gain / dynamic range reserve for it.

Is this based on the old thread discussion, or is it something you've observed with how Spotify works recently?

 

[dasdoing]

here it is: https://support.spotify.com/us/artists/article/loudness-normalization/

loud: setting will engage the limiter, so this is a no-no
normal: could lead to some quiet tracks not being loud enough because of the ceiling....this shouldn't happen with popular music though.
quiet: is therefore a good choice for classical music, or perhaps jazz

 

[Old_School_Brad]

here it is: https://support.spotify.com/us/artists/article/loudness-normalization/

loud: setting will engage the limiter, so this is a no-no
normal: could lead to some quiet tracks not being loud enough because of the ceiling....this shouldn't happen with popular music though.
quiet: is therefore a good choice for classical music, or perhaps jazz

Thanks. I’ve read that, but I generally take some company information with a bit of skepticism. My playlist varies a lot, and since my Wiim Pro Plus doesn’t currently support Spotify’s loudness normalization, I’ll just enable it on "Quiet" for my earbuds and listen for any anomalies.

 

[dasdoing]

Thanks. I’ve read that, but I generally take some company information with a bit of skepticism. My playlist varies a lot, and since my Wiim Pro Plus doesn’t currently support Spotify’s loudness normalization, I’ll just enable it on "Quiet" for my earbuds and listen for any anomalies.

they do actualize these articles. there was a time when the normal setting could engage the limiter for example...which is no longer the case

 

[Old_School_Brad]

they do actualize these articles. there was a time when the normal setting could engage the limiter for example...which is no longer the case

Ah, so I think I’ll try the "Normal" setting first. The quiet songs are already quiet, so if, for example, five tracks are in the queue and one is significantly louder while the others are very quiet, the loud track would be brought down to -14 LUFS, but the quieter ones would remain unchanged. Is that the correct understanding?

 

[dasdoing]

the quieter ones would remain unchanged. Is that the correct understanding?

no...they will be brought up. BUT only up to where their peak hits -1dBFS. So a very quiet, but also very dynamic track couldn't be lifted up to -14LUFS and would sit below that. But again, with popular genres, this shouldn't ever happen.