<div dir="ltr">Fixed attenuation is a valid and quick fix for fixed-point audio systems. <div><br></div><div>Floating-point systems push this problem to the final output and any clipping can be resolved by pulling down the device's master volume control.<div><br></div><div>The NORM-L proposal in the MLA whitepaper also pushes this problem out to the master volume control.<br><div><br></div><div>Intersample clipping is rarely audible as clipping but it is distortion and it manifests differently in different playback systems. Are you basing your "intersample safe" claim on your ears or on a dBTP meter?<br><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kevin Gross - AVA Networks</div></div></div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 15, 2018 at 3:22 AM Ian Shepherd <<a href="mailto:ian@mastering-media.co.uk">ian@mastering-media.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>
</div><div>Hi Bob & Kevin,</div><div><br class="m_-5251024066397857243webkit-block-placeholder"></div><div>I wonder if fixed attenuation is actually necessary in a system where floating-point normalization takes place ? At reasonable data rates, at least. Most material around -14 LUFS is likely to be “intersample safe” in my experience. As material is pushed higher the peaks become more “dangerous” from an encoding standpoint, but the normalization should deal with this cleanly.</div><div><br></div><div>I guess there would be no harm in a global attenuation if we could persuade people to do it, but since we now know of several popular systems where the music is currently reduced to fixed-point immediately after decoding, applying normalization (and ideally user volume settings) before this happens could potentially kill two birds with one stone ?</div><div><br></div><div>(I believe this is how iTunes works already ?)</div><div><br></div><div>Ian</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>
<br><div><blockquote type="cite"><div>On 15 Oct 2018, at 04:48, Kevin Gross <<a href="mailto:kevin.gross@avanw.com" target="_blank">kevin.gross@avanw.com</a>> wrote:</div><br class="m_-5251024066397857243Apple-interchange-newline"><div><div dir="ltr">It could be up to 3 dB for the difference between dBFS and dBTP and then a couple more on top of that for codec behavior.<div><br></div><div><div><div><div dir="ltr" class="m_-5251024066397857243gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kevin Gross - AVA Networks</div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 14, 2018 at 9:12 PM Bob Katz <<a href="mailto:bobkatz@digido.com" target="_blank">bobkatz@digido.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><p>In that case you are advocating a fixed attenuation (1 dB, 2 dB?)
across the board. I would certainly accept that. I wonder if
Spotify will?</p><p><br>
</p><p>Bob</p><p><br>
</p><p><br>
</p>
<br>
<div class="m_-5251024066397857243m_-6600787828700072727moz-cite-prefix">On 10/14/18 10:09 PM, Kevin Gross
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">To fix this all you need to do is attenuate the
floating-point output of the decoder by a couple or few dB
before you convert to fixed. The playback will be a little
quieter but the listener can compensate by adjusting the volume
up. The same attenuation is applied to all material at all times
so there's no anticipation or other monkey business. For
efficiency, this adjustment can be combined with the loudness
normalization adjustment.
<div><br clear="all">
<div>
<div dir="ltr" class="m_-5251024066397857243m_-6600787828700072727gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Kevin Gross - AVA Networks</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sun, Oct 14, 2018 at 7:23 PM Bob Katz <<a href="mailto:bobkatz@digido.com" target="_blank">bobkatz@digido.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><p>Dear Kevin: Admittedly, there is no one size fits all
encoding level. But if content producers (mastering
engineers) shoot for iTunes' MFIT (high bit rate) codec,
the vast majority of clipping in all streaming will be
handled fairly well in my opinion. I personally don't shiv
a git if it's occasionally too hot for Spotify if we cover
MFIT in our coding of a master. Spotify deserves what they
get with such a low bit rate codec they use, and that will
improve in due time. As a mastering engineer I do not want
to shoot for lowest common denominator. And most of my
sensibly-mastered material will play fine on Spotify with
possibly only occasional one hit clips. As I've said
before, it's impractical to make and control too many
masters. We're currently lobbying for all distributors to
send the 2444 MFIT master and send it to all the streaming
customers. We'd like to see the 1644 originally intended
to send to CD die a quick death. That's often a dB hotter
than the MFIT master. <br>
</p><p>As for attacking both ends and dealing with clipping on
the decode side I'd like to hear an explanation as to how
a streaming service's player can deal with (anticipate) a
clipping situation and attenuate post decoder.... from a
moving bitstream. Please start by telling us how you would
deal with a song that has a clip two minutes after the
song has already begun... <br>
</p>
<br>
Best wishes,<br>
<br>
<br>
<br>
Bob<br>
<br>
<br>
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-cite-prefix">On
10/14/18 6:54 PM, Kevin Gross wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br clear="all">
<div>
<div dir="ltr" class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807m_2960190518890253103gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">On Sun, Oct 14, 2018 at 8:32 AM Bob
Katz <<a href="mailto:bobkatz@digido.com" target="_blank">bobkatz@digido.com</a>>
wrote:<br>
</div>
</div>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
In our recent conversations, I pointed out that
it's totally impractical to expect or even talk
about any streaming player applying attenuation to
avoid overs just post the decode stage. Therefore
even though the clipping is not baked into a
well-made encoder, it has to be the responsibility
of the mastering engineer to prevent decoder
clipping by reducing the level that will be
applied to the encoder if necessary. Mastering
engineers have to bake that level into the fixed
point file that we supply to the distributors. <br>
</div>
</blockquote>
<div><br>
</div>
<div>If you want to fix this pre-encoder, you're going
to get content producers to comply with something
like Spotify's -2 dBTP suggestion. That means
bringing peaks down 4-6 dB compared to where they
currently stand at 0 dBFS. I don't see mastering
engineers getting behind this. I don't know if we
even want to recommend it either because it will
result in more squashing.</div>
<div><br>
</div>
<div>We should also be raising awareness of the
potential for clipping post-encoder and advocating
for more robustness in players in this regard.
You're right, we're not going to be able to get all
decoders fixed. We're also not going to be able to
get all masters fixed. If we work both ends, we'll
make the most meaningful progress.</div>
<div><br>
</div>
<div>Kevin</div>
</div>
</div>
</blockquote>
<br>
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">-- <br>
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature">
<pre class="m_-5251024066397857243m_-6600787828700072727m_-2823499860786167807moz-signature" cols="80"><font face="Courier">
If you want good sound on your album, come to
Bob Katz 407-831-0233 </font><font face="Courier">DIGITAL DOMAIN MASTERING STUDIO
Author: <b>Mastering Audio </b></font><font face="Courier">
<a href="http://www.digido.com/" target="_blank">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">
</font></font></pre>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">-- <br>
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<div class="m_-5251024066397857243m_-6600787828700072727moz-signature">
<pre class="m_-5251024066397857243m_-6600787828700072727moz-signature" cols="80"><font face="Courier">
If you want good sound on your album, come to
Bob Katz 407-831-0233 </font><font face="Courier">DIGITAL DOMAIN MASTERING STUDIO
Author: <b>Mastering Audio </b></font><font face="Courier">
<a href="http://www.digido.com/" target="_blank">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">
</font></font></pre>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div>
_______________________________________________<br>MLA mailing list<br><a href="mailto:MLA@grimmaudio.nl" target="_blank">MLA@grimmaudio.nl</a><br><a href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" target="_blank">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br></div></blockquote></div><br></div>_______________________________________________<br>
MLA mailing list<br>
<a href="mailto:MLA@grimmaudio.nl" target="_blank">MLA@grimmaudio.nl</a><br>
<a href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" rel="noreferrer" target="_blank">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br>
</blockquote></div>