[MLA] Loudness example with distortion on Sound Check

Mon Oct 15 17:57:11 CEST 2018

Fixed attenuation is a valid and quick fix for fixed-point audio systems.

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.

The NORM-L proposal in the MLA whitepaper also pushes this problem out to
the master volume control.

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?

Kevin Gross - AVA Networks

On Mon, Oct 15, 2018 at 3:22 AM Ian Shepherd <ian at mastering-media.co.uk>
wrote:

>
> 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> 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> 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> 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
>
>
> _______________________________________________
> 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/6fd0fefa/attachment-0001.html>