<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Hi,</div><div><br class=""></div><div>Sorry for my absence, I was a bit busy...</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:CALw1_Q1c4vjyt5Mt8_EqEmAVSfUpxB2umSkhhF8MhWcV9CLfsA@mail.gmail.com" class=""><div dir="ltr" class="">I think it means what it says, normalize PCM audio
to -11 LUFS. From which I assume, stuff that is louder than -11
LUFS gets digitally attenuated. Stuff quieter is untouched
before normalization. Loudness metadata is stored as usual so
that playback target can be adjusted.
</div></blockquote></div></div></blockquote><div><br class=""></div><div>Right. AFAIK all tracks of an album are attenuated with equal amount. But mark that this is not yet implemented by Spotify. It is part of their larger plan which also covers moving to BS1770, using the loudest track of the album as anchor for album normalization etc. They are waiting for td1004 for guidance - if we are fast enough.</div><div><br class=""></div><div><blockquote type="cite" class=""><span style="background-color: rgb(255, 255, 255);" class="">"a reduction on material that's >-11 LUFS" improves encoding quality (subtly) for that material, but there's plenty of lower material whose peak level would overshoot the codec whose LUFS falls between about -11 and -16 and occasionally below -16 so there's not enough forethought going on here. If you're going to attenuate before encoding in order to prevent encoder clipping then do it right. </span></blockquote></div><div><br class=""></div>Sure there is material < -11 LUFS that shows intersample peaks and can overload a codec. But there’s much more material > -11 LUFS that does so. If we can get Spotify to abandon their -11 LUFS option, we may nudge them to attenuating to -14 LUFS before encoding, but I would not put my money on that yet. And attenuating to -11 LUFS is better than nothing imo.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">With Spotify I always need more clarification, since Spotify's
practice has been to upwardly normalize for streaming. </p></div></div></blockquote><div><br class=""></div><div>The ‘attenuate to -11 LUFS’ part just applies to albums with loudest tracks louder than -11 LUFS (these are also the ones that would otherweise clip the codec). Upward normalization is only needed for albums softer than this, so they will be encoded at their original level. </div><div><br class=""></div></div>(Ian wrote):<div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">I thought they would store 3 separate copies, each hard-normalised to Loud, Medium or Soft, and then streamed directly. </div></div></blockquote><div class=""><br class=""></div><div class="">AFAIK not. The way I remember it is:</div><div class="">During encoding:</div><div class="">1. If loudest track of album > -11 LUFS: attenuate album to make it -11 LUFS.</div><div class="">2. Add metadata to all tracks and albums. </div><div class="">3. If loudest track of album < -11 LUFS: make a separate compressed and limited version (do not try to reach -11 LUFS, just add some amount of gain).</div><div class=""><br class=""></div><div class="">And then on playback:</div><div class="">1. Read playback normalization level (-11, -14 or -23 LUFS) from preferences.</div><div class="">2. If -11 LUFS: stream attenuated -11 LUFS music or compressed version of < -11 LUFS music.</div><div class="">3. If -14 LUFS: use metadata and ‘attenuation only’ gain to playback music at -14 LUFS album or track target. </div><div class="">4. If -23 LUFS: use metadata and ‘attenuation only’ gain to playback music at -23 LUFS album or track target. (NB imo -23 LUFS for music is too low, -20 LUFS would be better).</div><div class=""><br class=""></div><div class="">I am not 100% certain that Spotify does not apply positive gain and compression in #3, but what I recall is: compression is only used for ‘Loud’ playback at -11 LUFS, and this compression is not performed in the app, but stored on the server.</div><div class=""><br class=""></div><div class="">Mark that:</div><div class="">a. This is not an official Spotify statement.</div><div class="">b. I am interpreting my discussions with them and may have misunderstood parts of that. For instance it could well be that the app takes care of the compression after all.</div><div class=""><br class=""></div><div class="">Most important for me is that Andreas was at our meetings and likes to contribute and cooperate.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Eelco</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">But actually you’re saying they are just considering a reduction on material > -11 LUFS to improve encoding quality and provide the loudest copy (presumably also with higher quality limiting baked-in for quieter songs ? Or will they stop turning things up ?) but then other reference levels will be achieved in software. </div></div></blockquote><div class=""><br class=""></div></body></html>