<div dir="ltr">The outline for improving ReplayGain is here - <a href="http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification">http://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification</a><div><br></div><div>I would actually like to see this adopted as a loudness normalization AES standard for file-based playback. I could make this happen if I could find a few more hours in the week for a year or so.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 3, 2017 at 1:35 PM, Ian Shepherd <span dir="ltr"><<a href="mailto:ian@mastering-media.co.uk" target="_blank">ian@mastering-media.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Spotify uses the ReplayGain algorithm for loudness measurement. It might help to finish the work to update ReplayGain to use BS.1770<br>
<br>
</span>If you can influence that in any way it would be fantastic, Kevin !<br>
<span class=""><br>
> I think Spotify actually uses a lower target level than YouTube. Lower target should help improve normalization.<br>
<br>
</span>Measurements show that YouTube’s overall level is approx. -13 LUFS, whereas Spotify’s is roughly -11 LUFS<br>
<span class=""><br>
> If limiting is in play, that complicates things. I don't think we advocate limiting as part of normalization<br>
<br>
</span>Limiting is certainly being used, a Spotify software engineer told me that years ago.<br>
<span class="HOEnZb"><font color="#888888"><br>
Ian<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
MLA mailing list<br>
<a href="mailto:MLA@grimmaudio.nl">MLA@grimmaudio.nl</a><br>
<a href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" rel="noreferrer" target="_blank">http://grimmaudio.nl/mailman/<wbr>listinfo/mla_grimmaudio.nl</a><br>
</div></div></blockquote></div><br></div>