[MLA] Loudness example with distortion on Sound Check

Mon Oct 15 11:21:32 CEST 2018

Hi Bob & Kevin,

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.

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 ?

(I believe this is how iTunes works already ?)

Ian

> On 15 Oct 2018, at 04:48, Kevin Gross <kevin.gross at avanw.com> wrote:
> 
> 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.
> 
> Kevin Gross - AVA Networks
> 
> 
> On Sun, Oct 14, 2018 at 9:12 PM Bob Katz <bobkatz at digido.com <mailto:bobkatz at digido.com>> wrote:
> 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?
> 
> 
> Bob
> 
> 
> 
> 
> On 10/14/18 10:09 PM, Kevin Gross wrote:
>> 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.
>> 
>> Kevin Gross - AVA Networks
>> 
>> 
>> On Sun, Oct 14, 2018 at 7:23 PM Bob Katz <bobkatz at digido.com <mailto:bobkatz at digido.com>> wrote:
>> 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. 
>> 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... 
>> 
>> Best wishes,
>> 
>> 
>> 
>> Bob
>> 
>> 
>> On 10/14/18 6:54 PM, Kevin Gross wrote:
>>> 
>>> On Sun, Oct 14, 2018 at 8:32 AM Bob Katz <bobkatz at digido.com <mailto:bobkatz at digido.com>> wrote:
>>> 
>>> 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. 
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Kevin
>> 
>> -- 
>> 
>> If you want good sound on your album, come to
>> Bob Katz 407-831-0233 DIGITAL DOMAIN MASTERING STUDIO
>> Author: Mastering Audio              
>> Digital Domain Website <http://www.digido.com/>
>> 
>> No trees were killed in the sending of this message. However a large number
>> of electrons were terribly inconvenienced.
> 
> -- 
> 
> If you want good sound on your album, come to
> Bob Katz 407-831-0233 DIGITAL DOMAIN MASTERING STUDIO
> Author: Mastering Audio              
> Digital Domain Website <http://www.digido.com/>
> 
> No trees were killed in the sending of this message. However a large number
> of electrons were terribly inconvenienced.
> _______________________________________________
> MLA mailing list
> MLA at grimmaudio.nl
> http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://grimmaudio.nl/pipermail/mla_grimmaudio.nl/attachments/20181015/e638c10d/attachment.html>