[MLA] Lossy encoder clipping

[Bob Katz]

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.

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