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

[Soniclife]

What is the least bad way to use Spotify if your music taste does not include to many crushed masters ?

Everyone should leave it on, unless you run out of gain with it on. It might not make much difference for some peoples collections, but the more people that leave this activated the more the record industry will back away from crushing masters, as they have started doing.

 

[hyperplanar]

Right . I just felt that fact got lost in all the discussion and could use emphasizing. The thread is barely about normalization at all, even though the word keeps getting used.

Well I agree, but the matter being specifically discussed here is Spotify's implementation of it, and the option is labeled "Normalize volume" after all. And in any case, whenever the song is louder than the specified target level (around -14 LUFS for Normal and -23 LUFS for Quiet), it is correct to say that no processing will be done other than a simple gain reduction (and dither to 16 bit).

Again, the problem is that with normalization off, the >0 dBFS peaks generated as an artifact of the encoding process get clipped during playback, and the only way to avoid this at the moment is to enable normalization in order to reduce the gain.

I'm a big fan of Spotify and most other streaming services having normalization enabled by default--as alluded to above, it discourages artists/labels from smashing their masters as there is nothing to be gained by mastering louder than -14 LUFS anymore. The far more consistent loudness from song to song is also appreciated when shuffling my library. Of course, the con is that songs quieter than -14 LUFS will get limited on default settings, but the Quiet setting will virtually always turn the gain down, except for certain pathological cases (there's one Hans Zimmer soundtrack that comes to mind). Maybe a good compromise would be to have a setting which only allows the normalization to reduce the gain of songs, but never increase it.

 

[Mnyb]

This forum is great . was under the impression that it was the other way around now have it on on all my players .

Wonder how their new hifi offering will work , have not found a very compelling reason to change from premium .befoe this , this could be a good reason if their new hir res service is beter implemented .

 

[danadam]

but the Quiet setting will virtually always turn the gain down, except for certain pathological cases (there's one Hans Zimmer soundtrack that comes to mind).

And even when the Quiet setting turns the gain up, it doesn't necessarily mean that the limiter will be triggered. If by "Hans Zimmer soundtrack" you mean "Interstellar", then:

• in album mode even the Normal level turns the gain down
• in playlist/shuffle mode the Quiet level, AFAICT, will play 5 tracks with the gain up, but only one will engage the limiter in one place.

 

[napilopez]

And even when the Quiet setting turns the gain up, it doesn't necessarily mean that the limiter will be triggered. If by "Hans Zimmer soundtrack" you mean "Interstellar", then:

• in album mode even the Normal level turns the gain down
• in playlist/shuffle mode the Quiet level, AFAICT, will play 5 tracks with the gain up, but only one will engage the limiter in one place.

Well I agree, but the matter being specifically discussed here is Spotify's implementation of it, and the option is labeled "Normalize volume" after all. And in any case, whenever the song is louder than the specified target level (around -14 LUFS for Normal and -23 LUFS for Quiet), it is correct to say that no processing will be done other than a simple gain reduction (and dither to 16 bit).

Again, the problem is that with normalization off, the >0 dBFS peaks generated as an artifact of the encoding process get clipped during playback, and the only way to avoid this at the moment is to enable normalization in order to reduce the gain.

I'm a big fan of Spotify and most other streaming services having normalization enabled by default--as alluded to above, it discourages artists/labels from smashing their masters as there is nothing to be gained by mastering louder than -14 LUFS anymore. The far more consistent loudness from song to song is also appreciated when shuffling my library. Of course, the con is that songs quieter than -14 LUFS will get limited on default settings, but the Quiet setting will virtually always turn the gain down, except for certain pathological cases (there's one Hans Zimmer soundtrack that comes to mind). Maybe a good compromise would be to have a setting which only allows the normalization to reduce the gain of songs, but never increase it.

So, would it be correct to say that if your only priority is sound quality/preventing clipping as much as possible, in as many genres as possible, and you don't care whether tracks are sometimes too quiet and you have to fiddle with the volume knob, the safest bet is to use Normalization on 'Quiet'?

EDIT: just saw that @hyperplanar recommended quiet as safest bet in the prior page.

 

[danadam]

I'd rather say they increase peak levels, at which point it is up to the decoder and playback chain to provide sufficient processing headroom for the output to not clip.

Yes, that's what I meant and should have written that way. Thanks.

I did a bit of digging on Spotify’s output before with DigiCheck and the TotalMix level meters on my Babyface Pro and am pretty sure I have the explanation for what was seen in the OP.

Sounds similar to what I wrote earlier: https://www.audiosciencereview.com/...her-dr-than-non-normalized.20601/#post-681672

As @hyperplanar notes, the encoding process inherently attempts to reconstruct the true peaks that have been clipped off

Huh? I don't think that's what's in his notes at all. The encoding does not attempt to reconstruct peaks clipped in the master. But the encoding is lossy, so by definition it changes the waveform. Changing the waveform means that some samples will get smaller and some will get bigger. If those samples that get bigger were already near or at 0 dBFS, now they will be above 0 dBFS. Decoder, working in float, will produce those >0 dBFS samples just fine. Only when outputting them as integer, when the volume normalization is disabled, it will clip them.

So it is not that the encoding or volume normalization tries to reconstruct peaks. It is no volume normalization that deconstructs peaks.

And technically it is not directly connected to how dynamically compressed the master is. You can have a DR4 track, which is peak normalized to -3 dBFS before encoding and it won't clip after decoding. You can also have a DR15 track, which is peak normalized to 0 dBFS before encoding and it will clip after decoding (see Brothers in Arms and Paper Motion examples in the next post). Obviously in real life a DR4 track will usually be peak normalized to 0 dBFS and will have many near 0 dBFS samples and will clip more than a less compressed track.

 

[danadam]

I think there's enough analysis now to say it's the only Spotify option that both preserves dynamic range and avoids limiting?

Reduces the risk of limiting. Does not avoid it. See the last two examples in the following list.

Here are the tracks I mentioned earlier, when I described the process of checking the volume normalization effects: https://www.audiosciencereview.com/...-than-non-normalized.20601/page-3#post-683533

For each track there is a spotify url, some metrics for each captured file and peak and RMS of nulls. Nulls are between no volume normalization and: different modes (album, playlist/shuffle), different levels (Normal, Quiet). Not each mode and each level in every case. When matching the volume, it was always the gain of the louder track that was reduced. The absolute value of "Vol. norm." indicates by how many dB the gain was reduced.

There are also nulls' waveforms here and there, in linear and dB scale. They are thumbnails, so click to enlarge.

Naming should be obvious: none - no volume normalization, albm.normal - Album mode and Normal level, plst.quiet - Playlist mode and Quiet level, etc.

"But how does it sound, you ask?"
"I didn't, but fine, how?"
"Er... well, like anyone on the Internet will tell you, the normalization is bad. Bass gets bloated, mids get muffled, highs get harsh."
"Really?"
"No , but shush. Just between the two of us, cause you know, I don't want them to revoke my audiophile badge. I did some switching in Audacity between volume matched tracks. When there is no clipping and no limiter then obviously there are no differences. As for the other cases, I think (think, not claim):

• I couldn't ABX even that massive clipping in Dua Lipa track,
• I could just tell (i.e. without AB switching) if normalization was ON or OFF in the Interstellar track with those couple of seconds before 3:00,
• I could ABX a couple of those tracks with limiter at Normal level, if I knew the places where the limiter is triggered. Could I find those places, I don't know.
• I couldn't just tell (i.e. without AB switching) if normalization was ON or OFF in those same tracks with limiter at Normal level,
• I couldn't ABX, let alone just tell, those tracks with limiter at Quiet level."

Phil Collins / Face Value (2016 Remaster) / 01. In the Air Tonight - 2015 Remaster
url: open.spotify.com/track/6MjfEIHOMW6MaDO3LpFcmW

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.24 dBFS   -19.15 dBFS   -15.9 LUFS   14.2 LU   -0.18 dBFS   DR10    0.0000 dB   1rec.none.flac
 -4.10 dBFS   -23.01 dBFS   -19.8 LUFS   14.2 LU   -4.04 dBFS   DR10   -3.8606 dB   1rec.albm.normal.flac
 -0.98 dBFS   -17.86 dBFS   -14.6 LUFS   13.5 LU   -0.73 dBFS   DR9    +1.9307 dB   1rec.plst.normal.flac
 -7.31 dBFS   -26.22 dBFS   -23.0 LUFS   14.2 LU   -7.25 dBFS   DR10   -7.0693 dB   1rec.plst.quiet.flac

Sample peak,          RMS
-90.38 dBFS,  -98.77 dBFS - albm.normal.null.flac
-11.74 dBFS,  -37.37 dBFS - plst.normal.null.flac
-90.34 dBFS,  -98.04 dBFS - plst.quiet.null.flac

albm.normal.null: a negative gain, so no limiting. A perfect null.

plst.normal.null: a positive gain, results in limiting:

A 1.5 second zoom:


plst.quiet.null: a negative gain, so no limiting. A perfect null:


Dire Straits / Brothers In Arms / 01. So Far Away - Full Version
url: open.spotify.com/track/3QHThjKGMW7y89xIEvB0J4

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.00 dBFS   -18.54 dBFS   -15.8 LUFS    3.6 LU   +1.60 dBFS   DR14    0.0000 dB   1rec.none.flac
 -1.87 dBFS   -20.42 dBFS   -17.7 LUFS    3.6 LU   -0.28 dBFS   DR14   -1.8808 dB   1rec.albm.normal.flac
 -0.98 dBFS   -16.92 dBFS   -14.2 LUFS    3.4 LU   +0.67 dBFS   DR11   +1.7896 dB   1rec.plst.normal.flac
 -7.20 dBFS   -25.75 dBFS   -23.0 LUFS    3.6 LU   -5.61 dBFS   DR14   -7.2107 dB   1rec.plst.quiet.flac

Sample peak,          RMS
-59.57 dBFS,  -98.64 dBFS - albm.normal.null.flac
-11.24 dBFS,  -42.55 dBFS - plst.normal.null.flac
-65.05 dBFS,  -97.76 dBFS - plst.quiet.null.flac

albm.normal.null: a negative gain, so no limiting. Almost a perfect null. Big sample peak indicates clipping when normalization is disabled. Only 2 samples in this case (only dB scale):

A 0.1 second zoom (only dB scale):


plst.normal.null: a positive gain, results in limiting:


plst.quiet.null: a negative gain, so no limiting. Same as earlier, big sample peak indicates clipping.

Dua Lipa / Physical / 01. Physical
url: open.spotify.com/track/4U3u4qHEAmm4Jb2J3GAfuV

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.00 dBFS    -8.92 dBFS    -6.5 LUFS    5.1 LU   +0.44 dBFS    DR4    0.0000 dB   1rec.none.flac
 -6.89 dBFS   -16.38 dBFS   -14.0 LUFS    5.1 LU   -6.82 dBFS    DR5   -7.4606 dB   1rec.albm.normal.flac
-15.89 dBFS,  -25.38 dBFS   -23.0 LUFS    5.1 LU  -15.82 dBFS    DR5  -16.4607 dB   1rec.albm.quiet.flac
 -6.89 dBFS   -16.38 dBFS   -14.0 LUFS    5.1 LU   -6.82 dBFS    DR5   -7.4606 dB   1rec.plst.normal.flac

Sample peak,          RMS
-30.83 dBFS,  -71.52 dBFS - albm.normal.null.flac
-39.83 dBFS,  -80.46 dBFS - albm.quiet.null.flac
-30.83 dBFS,  -71.52 dBFS - plst.normal.null.flac
-90.31 dBFS,  -97.44 dBFS - albm.normal__albm.quiet.null.flac *

It is a single, so obviously the album and the track normalization is the same.

albm.normal.null: a negative gain, so no limiting. So many samples are clipping when normalization is disabled that it elevates RMS anyway:

A 0.5 second zoom:


albm.normal__albm.quiet.null.flac: an extra null, Normal level vs Quiet level. Both have a negative gain, so no limiting. A perfect null.
Due to the amount of clipping when normalization is disabled, both "none vs normal" and "none vs quiet" have elevated RMS. When normalization is enabled, there is no clipping (and in this case also no limiting) so we get a perfect null between the levels.

Hans Zimmer / Interstellar (Original Motion Picture Soundtrack) [Expanded Edition] / 01. Dreaming of the Crash
url: open.spotify.com/track/2dDuHXxFxLsdYdBBtgjoEi

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.39 dBFS   -19.96 dBFS   -19.5 LUFS   23.1 LU   -0.39 dBFS   DR12    0.0000 dB   1rec.none.flac
 -4.08 dBFS   -23.65 dBFS   -23.2 LUFS   23.1 LU   -4.08 dBFS   DR12   -3.6893 dB   1rec.albm.normal.flac
 -0.97 dBFS   -14.70 dBFS   -14.5 LUFS   23.7 LU   -0.97 dBFS   DR7    +5.5794 dB   1rec.plst.normal.flac
 -3.82 dBFS   -23.38 dBFS   -23.0 LUFS   23.1 LU   -3.81 dBFS   DR12   -3.4209 dB   1rec.plst.quiet.flac

Sample peak,          RMS
-86.52 dBFS,  -98.92 dBFS - albm.normal.null.flac
 -6.25 dBFS,  -37.63 dBFS - plst.normal.null.flac
-90.34 dBFS,  -98.79 dBFS - plst.quiet.null.flac

albm.normal.null: a negative gain (somewhat surprising, but about that another time), so no limiting. A perfect null.

plst.normal.null: a positive gain, results in limiting:


plst.quiet.null: a negative gain, so no limiting. A perfect null.

Paper Motion / Paper Motion / 05. Gloom
url: open.spotify.com/track/6e2G3jc6uWZHWYXh8lI72D

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.00 dBFS   -20.21 dBFS   -17.7 LUFS   11.6 LU   -0.00 dBFS   DR14    0.0000 dB   5rec.none.flac
 -0.98 dBFS   -18.88 dBFS   -16.3 LUFS   11.4 LU   -0.43 dBFS   DR12   +1.4603 dB   5rec.albm.normal.flac
 -7.50 dBFS   -27.75 dBFS   -25.2 LUFS   11.6 LU   -7.50 dBFS   DR14   -7.5402 dB   5rec.albm.quiet.flac
 -0.97 dBFS   -16.98 dBFS   -14.4 LUFS   10.9 LU   -0.42 dBFS   DR10   +3.6852 dB   5rec.plst.normal.flac

Sample peak,          RMS
-12.20 dBFS,  -46.69 dBFS - albm.normal.null.flac
-53.90 dBFS,  -98.52 dBFS - albm.quiet.null.flac
 -7.62 dBFS,  -38.47 dBFS - plst.normal.null.flac

I wanted a non-classical, non-jazz album, which gets a positive gain in Album mode at Normal level. It wasn't easy to find but here it is. As a bonus, one sample is clipping when normalization is disabled (in a DR14 track).

albm.normal.null: a positive gain, results in limiting:


albm.quiet.null: a negative gain, so no limiting. Almost a perfect null. Big sample peak indicates clipping when normalization is disabled:


plst.normal.null: a positive gain, results in limiting.

Laurence Juber / Guitar Noir / 03. Leaning Post
url: open.spotify.com/track/0cMVmKNw44xHFnnFv7WfdY

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.53 dBFS   -22.95 dBFS   -20.8 LUFS    9.8 LU   +0.27 dBFS   DR15    0.0000 dB   3rec.none.flac
 -0.96 dBFS   -18.38 dBFS   -16.3 LUFS    9.5 LU   +0.26 dBFS   DR11   +4.7076 dB   3rec.albm.normal.flac
 -4.82 dBFS   -27.25 dBFS   -25.1 LUFS    9.8 LU   -4.03 dBFS   DR15   -4.2927 dB   3rec.albm.quiet.flac
 -2.67 dBFS   -25.10 dBFS   -23.0 LUFS    9.8 LU   -1.88 dBFS   DR15   -2.1423 dB   3rec.plst.quiet.flac

Sample peak,          RMS
 -7.51 dBFS,  -47.46 dBFS - albm.normal.null.flac
-87.74 dBFS,  -98.89 dBFS - albm.quiet.null.flac
-88.67 dBFS,  -98.82 dBFS - plst.quiet.null.flac

Another non-classical, non-jazz album, which gets a positive gain in Album mode at Normal level.

albm.normal.null: a positive gain, results in limiting:


albm.quiet.null: a negative gain, so no limiting. A perfect null.

plst.quiet.null: a negative gain, so no limiting. A perfect null.

Hilary Hahn / Mendelssohn & Shostakovich: Violin Concertos / 08. Violin Concerto No. 1 in A Minor, Op. 77: IV. ...
url: open.spotify.com/track/6pFZZ1eryonrUb4Ec6IPv3

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.15 dBFS   -24.60 dBFS   -21.2 LUFS   11.1 LU   -0.15 dBFS   DR14    0.0000 dB   8rec.none.flac
 -0.98 dBFS   -18.54 dBFS   -15.2 LUFS   10.7 LU   -0.78 dBFS   DR11   +6.2615 dB   8rec.albm.normal.flac
 -2.89 dBFS   -27.34 dBFS   -24.0 LUFS   11.2 LU   -2.89 dBFS   DR14   -2.7386 dB   8rec.albm.quiet.flac
 -1.89 dBFS   -26.35 dBFS   -23.0 LUFS   11.2 LU   -1.89 dBFS   DR14   -1.7421 dB   8rec.plst.quiet.flac

Sample peak,          RMS
 -5.21 dBFS,  -45.85 dBFS - albm.normal.null.flac
-85.07 dBFS,  -98.24 dBFS - albm.quiet.null.flac
-88.43 dBFS,  -98.52 dBFS - plst.quiet.null.flac

albm.normal.null: a positive gain, results in limiting:


albm.quiet.null: a negative gain, so no limiting. A perfect null.

plst.quiet.null: a negative gain, so no limiting. A perfect null.

Hilary Hahn / Mendelssohn & Shostakovich: Violin Concertos / 02. Violin Concerto in E Minor, Op. 64, MWV O14: II. ...
url: open.spotify.com/track/2sYGhfLK1Y8uKAywGCKQ7r

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -2.49 dBFS   -29.65 dBFS   -26.1 LUFS   16.7 LU   -2.48 dBFS   DR18    0.0000 dB   2rec.none.flac
 -5.23 dBFS   -32.39 dBFS   -28.8 LUFS   16.7 LU   -5.22 dBFS   DR18   -2.7390 dB   2rec.albm.quiet.flac
 -0.99 dBFS   -26.55 dBFS   -23.0 LUFS   16.7 LU   -0.95 dBFS   DR17   +3.1129 dB   2rec.plst.quiet.flac

Sample peak,          RMS
-90.31 dBFS,  -98.70 dBFS - albm.quiet.null.flac
-17.94 dBFS,  -70.27 dBFS - plst.quiet.null.flac

I wanted a track, which triggers the limiter even at Quiet level. Again, not that easy to find but here it is.

albm.quiet.null: a negative gain, so no limiting. A perfect null.

plst.quiet.null: a positive gain, results in limiting:


Flim & The BB's / Tricycle / 02. Cakewalk
url: open.spotify.com/track/4Ip4FxPoOt8S62pEzOR7A6

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
 -0.43 dBFS   -28.02 dBFS   -25.0 LUFS   13.0 LU   -0.43 dBFS   DR19    0.0000 dB   2rec.none.flac
 -0.98 dBFS   -26.21 dBFS   -23.2 LUFS   13.0 LU   -0.50 dBFS   DR18   +1.8129 dB   2rec.albm.quiet.flac
 -0.98 dBFS   -26.01 dBFS   -23.0 LUFS   13.0 LU   -0.49 dBFS   DR18   +2.0150 dB   2rec.plst.quiet.flac

Sample peak,          RMS
-12.87 dBFS,  -68.64 dBFS - albm.quiet.null.flac
-12.26 dBFS,  -67.60 dBFS - plst.quiet.null.flac

And finally, I wanted a track/album, which triggers the limiter in Album mode at Quiet level.

albm.quiet.null: a positive gain, results in limiting:


plst.quiet.null: a positive gain, results in limiting.


And here we are, 28 attachments later but all together below 300 kB, so I hope Amir won't be angry .
The End

 

[dasdoing]

Dire Straits / Brothers In Arms / 01. So Far Away - Full Version
url: open.spotify.com/track/3QHThjKGMW7y89xIEvB0J4

Sample peak           RMS     Loudness       LRA    True peak     DR   Vol. norm.
-0.00 dBFS   -18.54 dBFS   -15.8 LUFS    3.6 LU   +1.60 dBFS   DR14    0.0000 dB   1rec.none.flac
-1.87 dBFS   -20.42 dBFS   -17.7 LUFS    3.6 LU   -0.28 dBFS   DR14   -1.8808 dB   1rec.albm.normal.flac
-0.98 dBFS   -16.92 dBFS   -14.2 LUFS    3.4 LU   +0.67 dBFS   DR11   +1.7896 dB   1rec.plst.normal.flac
-7.20 dBFS   -25.75 dBFS   -23.0 LUFS    3.6 LU   -5.61 dBFS   DR14   -7.2107 dB   1rec.plst.quiet.flac

Sample peak,          RMS
-59.57 dBFS,  -98.64 dBFS - albm.normal.null.flac
-11.24 dBFS,  -42.55 dBFS - plst.normal.null.flac
-65.05 dBFS,  -97.76 dBFS - plst.quiet.null.flac

that's an intresting example to ABX

take 1rec.plst.normal.flac, bring it to -23.0 LUFS and then ABX with 1rec.plst.normal.flac
my suspition is that the diference, if any, isn't as dramatic as it seams

 

[danadam]

ake 1rec.plst.normal.flac, bring it to -23.0 LUFS and then ABX with 1rec.plst.normal.flac
my suspition is that the diference, if any, isn't as dramatic as it seams

Did you mean "ABX with 1rec.plst.quiet.flac"? If yes, then the difference "plst normal vs quiet" should be essentially the same as "plst normal vs none", only at a different volume level. We know that:

1. plst.normal – none = LD (Limiter Difference)
2. plst.quiet – none = 0
3. from 2 we get: plst.quiet = none
4. we substitute in 1 and get: plst.normal – plst.quiet = LD

And it checks out. After applying -9 dB gain to "plst.normal" and nulling it with "plst.quiet" we get:

Sample peak,          RMS
-11.24 dBFS,  -42.55 dBFS - plst.normal.null.flac              (that's from the post above)
-18.42 dBFS,  -49.76 dBFS - plst.normal__plst.quiet.null.flac  (the new null)

Now we can compare those two nulls . After applying -7.2113 dB gain to the first one and nulling it with the second one we get:

Sample peak,          RMS
-64.79 dBFS,  -98.20 dBFS - plst.normal-none__plst.normal-plst.quiet.null.flac

Almost a perfect null. The big sample peak is again those two pesky samples that are clipped in "none".

To me, a somewhat more interesting example, though not that much different, was "normal vs quiet" in Dua Lipa case. Due to the big clipping in "none", both "none vs normal" and "none vs quiet" have elevated RMS, but "normal vs quiet" should be a perfect null, because there is no clipping. So I captured "albm.quiet" (I updated the post) and indeed, after applying -9 dB gain to "albm.normal" and nulling it with "albm.quiet" we get a perfect null:

Sample peak,          RMS
-90.31 dBFS,  -97.44 dBFS - albm.normal__albm.quiet.null.flac

 

[charleski]

Huh? I don't think that's what's in his notes at all. The encoding does not attempt to reconstruct peaks clipped in the master. But the encoding is lossy, so by definition it changes the waveform. Changing the waveform means that some samples will get smaller and some will get bigger. If those samples that get bigger were already near or at 0 dBFS, now they will be above 0 dBFS. Decoder, working in float, will produce those >0 dBFS samples just fine. Only when outputting them as integer, when the volume normalization is disabled, it will clip them.

So it is not that the encoding or volume normalization tries to reconstruct peaks. It is no volume normalization that deconstructs peaks.

This is what I was saying. You need to think of the encode-decode pipeline as a black box, since inside that box everything is in the frequency domain.

Here's an example of ogg reconstructing peaks, this is a track that was mastered with slight clipping:
True peak: 1.47dB
Sample Peak: -0.01dB
Ave RMS: -13.27dB
B.S. 1770 Loudness: -7.69LUFS


This was encoded with oggenc2 using -b 320 and decoded in 32bits
True Peak: 1.57dB
Sample Peak: 0.45dB
Ave RMS: -13.25dB
B.S. 1770 Loudness: -7.67LUFS


If I encode at a lower bitrate (in this case q=3, around 122kbps) the effect is even more apparent:
True Peak: 2.55dB
Sample Peak: 1.99dB
Ave RMS: -13.33dB
B.S. 1770 Loudness: -7.77LUFS


Ogg will happily assign sample values above 0dB during the decoding process. Yes, clipping those off by simple integer conversion is a bad idea.

 

[dasdoing]

Did you mean "ABX with 1rec.plst.quiet.flac"?

yea, sorry

Almost a perfect null. The big sample peak is again those two pesky samples that are clipped in "none"

So we have a DR difference of 3, but the sonical diference is almost perfect null?

 

[danadam]

So we have a DR difference of 3, but the sonical diference is almost perfect null?

No,:

1. In the big post I compared "plst.normal vs none". The DR difference is 3 and the null is not perfect.
2. In reply to your question I compared "plst.normal vs plst.quiet". The DR difference is again 3 and the null is not perfect.
3. Then I compared those two nulls and their null is perfect.

The perfect null in 3 means that the difference between plst.normal and none is the same as the difference between plst.normal and plst.quiet.

 

[dasdoing]

No,:

1. In the big post I compared "plst.normal vs none". The DR difference is 3 and the null is not perfect.
2. In reply to your question I compared "plst.normal vs plst.quiet". The DR difference is again 3 and the null is not perfect.
3. Then I compared those two nulls and their null is perfect.

The perfect null in 3 means that the difference between plst.normal and none is the same as the difference between plst.normal and plst.quiet.

ok, then I might have expressed badly my intention in my first post.
we should sonicly abx plst.normal vs plst.quiet with both having the same loudness

 

[danadam]

we should sonicly abx plst.normal vs plst.quiet with both having the same loudness

By the same loudness, do you mean matched LUFS value? So in other words, instead of applying -9 dB gain to "plst.normal", apply -8.8 dB? Then we have:

Sample peak           RMS     Loudness       LRA    True peak     DR
 -7.20 dBFS   -25.75 dBFS   -23.0 LUFS    3.6 LU   -5.61 dBFS   DR14   1rec.plst.quiet.flac         (from post #87)
 -9.78 dBFS   -25.72 dBFS   -23.0 LUFS    3.4 LU   -8.13 dBFS   DR11   1rec.plst.normal.-8.8dB.flac (new, LUFS-matched file)

Sample peak           RMS
-18.97 dBFS   -50.11 dBFS   plst.normal.-8.8dB__plst.quiet.null.flac
-18.42 dBFS   -49.76 dBFS   plst.normal__plst.quiet.null.flac          (from post #89, null with -9 dB version)

The null improved a little bit.

As for the changes, now the fragments not affected by the limiter are 0.2 dB louder in "plst.normal.-8.8dB" and the fragments affected by the limiter differ a bit less, peak-wise. Again, after some switching between those tracks in Audacity, I think I could still ABX some of those fragments affected by the limiter and I think now I could ABX some of the fragments not affected by the limiter.

As for the preference, I can't say I have any, which is usually the case for me when I need AB switching to even tell if there is a difference. Of course I can't discard the possibility that if I did dozen(s) of trials with forced choice, then some preference would emerge. And if it did, I suspect that the 0.2 dB increase in parts not affected by the limiter would have more to do with that, than the reduced differences in parts affected by the limiter. Anyway, that level of differences is not something I would ever be bothered by

 

[Music1969]

By the same loudness, do you mean matched LUFS value? So in other words, instead of applying -9 dB gain to "plst.normal", apply -8.8 dB? Then we have:

Sample peak           RMS     Loudness       LRA    True peak     DR
-7.20 dBFS   -25.75 dBFS   -23.0 LUFS    3.6 LU   -5.61 dBFS   DR14   1rec.plst.quiet.flac         (from post #87)
-9.78 dBFS   -25.72 dBFS   -23.0 LUFS    3.4 LU   -8.13 dBFS   DR11   1rec.plst.normal.-8.8dB.flac (new, LUFS-matched file)

Sample peak           RMS
-18.97 dBFS   -50.11 dBFS   plst.normal.-8.8dB__plst.quiet.null.flac
-18.42 dBFS   -49.76 dBFS   plst.normal__plst.quiet.null.flac          (from post #89, null with -9 dB version)

The null improved a little bit.

As for the changes, now the fragments not affected by the limiter are 0.2 dB louder in "plst.normal.-8.8dB" and the fragments affected by the limiter differ a bit less, peak-wise. Again, after some switching between those tracks in Audacity, I think I could still ABX some of those fragments affected by the limiter and I think now I could ABX some of the fragments not affected by the limiter.

As for the preference, I can't say I have any, which is usually the case for me when I need AB switching to even tell if there is a difference. Of course I can't discard the possibility that if I did dozen(s) of trials with forced choice, then some preference would emerge. And if it did, I suspect that the 0.2 dB increase in parts not affected by the limiter would have more to do with that, than the reduced differences in parts affected by the limiter. Anyway, that level of differences is not something I would ever be bothered by

Do you know if the actual mechancism for applying normalization gain is the same as the volume control within the Spotify app itself?

It must be?

 

[danadam]

Do you know if the actual mechancism for applying normalization gain is the same as the volume control within the Spotify app itself?

It must be?

At the lowest level applying gain/changing volume is just multiplying every sample by some constant number, so yes, one could say that the mechanism is the same

But I guess that is not what you meant, so no, they are not the same, though I can only talk about the client on Linux using PulseAudio. With that, and keeping in mind that the following is only AFAIK, the pipeline is like this:

1. app: decode Vorbis to PCM in float
2. app: apply normalization gain if enabled
3. app: cast float to 16 bit integer
4. app: send it to PulseAudio
5. pulseaudio: apply volume gain
6. pulseaudio: send it to DAC

You'll notice that it is not the app that is applying the volume gain. The app delegates that to PulseAudio.

 

[Music1969]

At the lowest level applying gain/changing volume is just multiplying every sample by some constant number, so yes, one could say that the mechanism is the same

But I guess that is not what you meant, so no, they are not the same, though I can only talk about the client on Linux using PulseAudio. With that, and keeping in mind that the following is only AFAIK, the pipeline is like this:

1. app: decode Vorbis to PCM in float
2. app: apply normalization gain if enabled
3. app: cast float to 16 bit integer
4. app: send it to PulseAudio
5. pulseaudio: apply volume gain
6. pulseaudio: send it to DAC

You'll notice that it is not the app that is applying the volume gain. The app delegates that to PulseAudio.

Thanks, I thought I worded my question pretty poorly but you got exactly what I was asking.

Hmm I wonder how it works on macOS using the official Spotify app.

I did some digging but found nothing. I don't think anyone out there really cares lol.

Maybe more will care when Spotify offers "lossless". A new customer base.

 

[danadam]

Also, it’s worth considering how much resolution you lose when setting the normalization to quiet, considering that it’s done in 16-bit. If it turns down the level by 18 dB then Spotify’s output is effectively only 13 bits at best.

Good news, it looks like this changed a few months ago and now the client outputs floats. In previous version 1:1.1.42.622.gbd112320-37:

sink: 0 <alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo>
sample spec: s16le 2ch 44100Hz
        media.name = "Spotify"
        application.name = "Spotify"

In my current version 1:1.1.55.498.gf9a83c60:

sink: 0 <alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo>
sample spec: float32le 2ch 44100Hz
        media.name = "Spotify"
        application.name = "Spotify"

I captured the beginning of "Tick-Tock" from "Interstellar" when playing my CD rip, spotify without normalization and spotify with normalization set to "quiet", and here are their left channels for comparison:

Looks like the dynamic range is preserved.

In my opinion, the way Spotify’s audio pipeline is set up is kind of dumb. The Ogg decoder and normalization should be outputting floating point, so at least any clipping can be avoided by turning down the volume control. It would also prevent the loss of bit resolution that currently occurs from normalization.

Bad news, AFAICT it still clamps the samples' values to 1.0 before sending them to pulseaudio.

 

[hyperplanar]

Good news, it looks like this changed a few months ago and now the client outputs floats. In previous version 1:1.1.42.622.gbd112320-37:

sink: 0 <alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo>
sample spec: s16le 2ch 44100Hz
        media.name = "Spotify"
        application.name = "Spotify"

In my current version 1:1.1.55.498.gf9a83c60:

sink: 0 <alsa_output.usb-RME_ADI-2_Pro__57760455__FC0F29710C736C8-00.analog-stereo>
sample spec: float32le 2ch 44100Hz
        media.name = "Spotify"
        application.name = "Spotify"

I captured the beginning of "Tick-Tock" from "Interstellar" when playing my CD rip, spotify without normalization and spotify with normalization set to "quiet", and here are their left channels for comparison:
View attachment 151758
Looks like the dynamic range is preserved.


Bad news, AFAICT it still clamps the samples' values to 1.0 before sending them to pulseaudio.

That’s certainly encouraging and a huge step in the right direction! I wonder if this change came with their “v2” normalization implementation. They were using ReplayGain before, where the gain change was done inside the decoder. With a switch to the standard LUFS system they probably started doing the gain adjustment after the decoder?

I have some questions… is the decoder still outputting 16-bit integer? Even if the player’s final output is clamped at 0 dBFS, are the >0 dBFS peaks from playing music with normalization off now recoverable with Spotify’s volume control?

 

[danadam]

is the decoder still outputting 16-bit integer?

From the fact that in the capture with normalization disabled I still get samples lower than -96 dBFS, I assume no.

Even if the player’s final output is clamped at 0 dBFS, are the >0 dBFS peaks from playing music with normalization off now recoverable with Spotify’s volume control?

I don't think so. As I wrote a couple of messages back, AFAIK it is not the app that is doing the actual volume change. It just indicates to pulseaudio what the volume should be and it is pulseaudio that is applying the change.

And actually, it might not be the spotify app that is doing the clamping. I just wrote a program that generates a sine with amplitude 2.0 (+6 dBFS) and sends it as float to pulseaudio. Then I set the volume of the app to 64% (-12 dB)) in pavucontrol and captured the output. It is still clipped. Admittedly I used the pulseaudio Simple API, but I doubt that makes a difference.