<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 class="">Companeros,</div><div class=""><br class=""></div><div class="">With lossy encoders, clipping can happen in the M/S domain, even if e.g. the S signal is nowhere near clipping, but the M component is. I’ve played several listening examples of that on panels with you, Bob and Bob. Sample rate converters is another place where you can’t take pre-attenuation let alone headroom for granted.</div><div class=""><br class=""></div><div class="">Better to stay below 0 dBTP, and to keep checking M/S.</div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Thomas</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Oct 2018, at 18.34, Bob Katz <<a href="mailto:bobkatz@digido.com" class="">bobkatz@digido.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Thanks, Eelco, for that confidential information. You have a good
contact at Spotify. Keep on pushing them to stop that egregious
peak limiting!</p>
Even though with a floating point codec, the clipping is NOT
officially "baked in", I would always advise engineers to protect
the path ahead of the encoder. It's the safest and probably the best
place to deal with future clipping down the line. Apple performs the
encodes and adds metadata. Engineers and producers do NOT send AAC
files to Apple. And you won't find Apple changing data, even if it
would prevent clipping down the line. Apple would NOT attenuate a
master in front of the encode. This is a mastering engineer's
prerogative. <br class=""><p class="">And the chances of expecting a playback device to inspect ahead
of time for overshoot during a streaming session are slim and
none. Think about it, the real time decoder would have to have
foreknowledge that the codec was going to overshoot, and know
ahead of time to attenuate the whole song before it had started.
It's just not practical. And I don't believe in adding peak
limiting to already-mastered and approved material. At the least
it changes the producer's intent, at worst it distorts and just
goes one step closer to sucky broadcast-style processing.<br class="">
</p><p class="">So I would not change my practices because of this discovery.
Prevention is the best way to a cure.</p><p class=""><br class="">
</p><p class="">Bob</p><p class=""><br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 10/12/18 12:10 PM, Grimm | Eelco
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:A49C70CA-88AF-4176-9090-6D06748E1509@grimmaudio.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div class="">Hi Kevin and Bob,</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Robert from Fraunhofer was just complaining
because Ian claimed that the clipping was "baked in" to
the encoder. Which is untrue to the best of my
knowledge. The encoder/decoder are in a closed floating
point relationship and so if you intercept the decode in
the floating point domain, attenuate it and dither it to
24 bits and then send it on to the DAC or file or
whatever, there will be no clipping. </p>
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">I got a reply from my Spotify contact. Please treat this as
confidential information!</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">"I've also found out the float/int situation, and
unfortunately it was as I feared, we're using int:s throughout
the pipeline. The decoder(s) is/are float, but we clamp them
to int right after the decode step. This is also, for sure, on
our roadmap to change, but no promises on timeline there
either, I'm afraid."</div>
</div>
<br class="">
<div class="">So at the moment there’s not much they can do. But
at least they are aware of the problem and the opportunities
now.</div>
<div class=""><br class="">
</div>
<div class="">All the best,</div>
<div class="">Eelco</div>
<div class=""><br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
MLA mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MLA@grimmaudio.nl">MLA@grimmaudio.nl</a>
<a class="moz-txt-link-freetext" href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a>
</pre>
</blockquote>
<br class="">
<div class="moz-signature">-- <br class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">
<title class=""></title>
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">
<pre class="moz-signature" cols="80"><font face="Courier" class="">
If you want good sound on your album, come to
Bob Katz 407-831-0233 </font><font face="Courier" class="">DIGITAL DOMAIN MASTERING STUDIO
Author: <b class="">Mastering Audio </b></font><font face="Courier" class="">
<a href="http://www.digido.com/" class="">Digital Domain Website</a>
No trees were killed in the sending of this message. However a large number
of electrons were terribly inconvenienced.<font color="#ff0000" class="">
</font></font></pre>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">MLA mailing list<br class=""><a href="mailto:MLA@grimmaudio.nl" class="">MLA@grimmaudio.nl</a><br class="">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl<br class=""></div></blockquote></div><br class=""></body></html>