[MLA] Lossy encoder clipping

[Bob Katz]

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".

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.


Best wishes,




Bob


On 10/12/18 12:41 PM, Thomas Lund wrote:
> Companeros,
>
> 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.
>
> Better to stay below 0 dBTP, and to keep checking M/S.
>
> cheers,
> Thomas
>
>
>
>> On 12 Oct 2018, at 18.34, Bob Katz <bobkatz at digido.com 
>> <mailto:bobkatz at digido.com>> wrote:
>>
>> Thanks, Eelco, for that confidential information. You have a good 
>> contact at Spotify. Keep on pushing them to stop that egregious peak 
>> limiting!
>>
>> 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.
>>
>> 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.
>>
>> So I would not change my practices because of this discovery. 
>> Prevention is the best way to a cure.
>>
>>
>> Bob
>>
>>
>>
>> On 10/12/18 12:10 PM, Grimm | Eelco wrote:
>>> Hi Kevin and Bob,
>>>
>>>> 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.
>>>>
>>>
>>> I got a reply from my Spotify contact. Please treat this as 
>>> confidential information!
>>>
>>> "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."
>>>
>>> So at the moment there’s not much they can do. But at least they are 
>>> aware of the problem and the opportunities now.
>>>
>>> All the best,
>>> Eelco
>>>
>>>
>>>
>>> _______________________________________________
>>> MLA mailing list
>>> MLA at grimmaudio.nl
>>> http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl
>>
>> -- 
>> 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 <mailto:MLA at grimmaudio.nl>
>> http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl
>

-- 

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.

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