<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 apple-content-edited="true" class=""><br class="">
</div><div class="">Correction - the limiter I mentioned is in use on Android, not iOS.</div><div class=""><br class=""></div><div class=""><br class=""></div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 13 Oct 2018, at 15:04, Ian Shepherd <<a href="mailto:ian@mastering-media.co.uk" class="">ian@mastering-media.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div apple-content-edited="true" class=""><br class="">
</div><div class="">HI All,</div><div class=""><br class="webkit-block-placeholder"></div><div class="">I’ve been talking to Robert more about this, and also I emailed JJ to get word from the horses mouth.</div><div class=""><br class=""></div><div class="">It seems I miss-spoke in my blog post - mp3 and AAC encoders (and from the Spotify comments, Ogg/Vorbis also) should encode in floating-point, and store the data with what JJ refers to as <i class="">“scalefactor information (kind of like a coarse floating point)” </i></div><div class=""><br class=""></div><div class="">In other words, a well-written encoder won’t “bake in” the clipping (my bad). But of course, we can’t assume that all encoders are well-written :-/</div><div class=""><br class=""></div><div class="">Robert and JJ both agree that not all decoders operate in floating-point and Eelco’s information confirms this to be true for Spotify, sadly - so this may be the source of the bad experiences we’ve all had. If a decoder resolves to fixed-point without adjusting for headroom and before normalising, the clipping may as well be "baked-in”, as far as the final result is concerned :-/</div><div class=""><br class=""></div><div class="">(iTunes <b class="">does</b> use floating-point, but also employs a limiter to prevent clipping, apparently…! I’m going to try and find out where this limiter is placed in the chain - I bet you a cup of really hot tea that it’s right after the decoder :-/ ) </div><div class=""><br class=""></div><div class="">I’m clarifying a few details with JJ and will then update my post - the bottom line is that avoiding high peaks is still good advice, although not quite for the reasons I originally posted about.</div><div class=""><br class=""></div><div class="">We learn new stuff every day !</div><div class=""><br class=""></div><div class="">Ian</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On 13 Oct 2018, at 12:23, 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="">Yes, Thomas, you have shown this many times and this is true. But
it seems the clipping does not happen in the encoder if the
encoder and decoder are floating point (as most are). The clipping
actually occurs not in the decoder either, but when the output
material of the decoder is converted to fixed point. Which is why
Robert from Fraunhofer protested when Ian Shepherd made the
contention that the clipping is "baked in". <br class="">
</p><p class="">It would not take much effort to prove this. I've got clients in
all day. I'm not sure if I'll have time to demonstrate (or
disprove) this contention before AES NY. Regardless, I agree with
you, I would not recommend encoding material that would clip. So
for me this is a purely academic exercise. <br class="">
</p><p class=""><br class="">
</p><p class="">Best wishes,</p><p class=""><br class="">
</p><p class=""><br class="">
</p><p class=""><br class="">
</p><p class="">Bob<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 10/12/18 12:41 PM, Thomas Lund
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:45FEAFFB-A5C3-4A46-9850-1DA3537214A4@lund.one" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" 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 class="">
<blockquote type="cite" class="">
<div class="">On 12 Oct 2018, at 18.34, Bob Katz <<a href="mailto:bobkatz@digido.com" class="" moz-do-not-send="true">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 class="" wrap="">_______________________________________________
MLA mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MLA@grimmaudio.nl" moz-do-not-send="true">MLA@grimmaudio.nl</a>
<a class="moz-txt-link-freetext" href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" moz-do-not-send="true">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 class="" face="Courier">
If you want good sound on your album, come to
Bob Katz 407-831-0233 </font><font class="" face="Courier">DIGITAL DOMAIN MASTERING STUDIO
Author: <b class="">Mastering Audio </b></font><font class="" face="Courier">
<a href="http://www.digido.com/" class="" moz-do-not-send="true">Digital Domain Website</a>
No trees were killed in the sending of this message. However a large number
of electrons were terribly inconvenienced.<font class="" color="#ff0000">
</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="" moz-do-not-send="true">MLA@grimmaudio.nl</a><br class="">
<a class="moz-txt-link-freetext" href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</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=""><a href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" class="">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>