<div dir="ltr"><br clear="all"><div><div dir="ltr" class="m_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>