[MLA] Lossy encoder clipping

Sat Oct 13 18:28:24 CEST 2018

Ian, I think you misunderstand what Eelco said about Spotify. They do have
a floating-point decoder, but they apparently hand the audio off to the OS
in integer format. It is in this handoff where there are potential
problems. Modern OS audio can carry floating point through the system.
Apparently Spotify isn't using these capabilities to full advantage. This
is not at all an unusual situation. OS floating point audio support is
fairly recent and if you want your app to work on any legacy platforms, you
need to present integers.

In any case, you do eventually have to convert to integer to feed your DAC
or or digital audio interface and if the OS audio system is set up for
unity gain (which most still consider best practice) there will still be
problems.

I hope/expect you can workaround this shortcoming in Spotify by choosing
their "Quiet" loudness normalization or taking down the gain control in
their desktop application by a few dB.

Kevin Gross - AVA Networks

On Sat, Oct 13, 2018 at 8:11 AM Ian Shepherd <ian at mastering-media.co.uk>
wrote:

>
> Correction - the limiter I mentioned is in use on Android, not iOS.
>
>
>
> On 13 Oct 2018, at 15:04, Ian Shepherd <ian at mastering-media.co.uk> wrote:
>
>
> HI All,
>
> I’ve been talking to Robert more about this, and also I emailed JJ to get
> word from the horses mouth.
>
> It seems I miss-spoke in my blog post - mp3 and AAC encoders (and from the
> Spotify comments, Ogg/Vorbis also) should encode in floating-point, and
> store the data with what JJ refers to as *“scalefactor information (kind
> of like a coarse floating point)” *
>
> In other words, a well-written encoder won’t “bake in” the clipping (my
> bad). But of course, we can’t assume that all encoders are well-written :-/
>
> Robert and JJ both agree that not all decoders operate in floating-point
> and Eelco’s information confirms this to be true for Spotify, sadly - so
> this may be the source of the bad experiences we’ve all had. If a decoder
> resolves to fixed-point without adjusting for headroom and before
> normalising, the clipping may as well be "baked-in”, as far as the final
> result is concerned :-/
>
> (iTunes *does* use floating-point, but also employs a limiter to prevent
> clipping, apparently…! I’m going to try and find out where this limiter is
> placed in the chain - I bet you a cup of really hot tea that it’s right
> after the decoder :-/ )
>
> I’m clarifying a few details with JJ and will then update my post - the
> bottom line is that avoiding high peaks is still good advice, although not
> quite for the reasons I originally posted about.
>
> We learn new stuff every day !
>
> Ian
>
>
>
>
> On 13 Oct 2018, at 12:23, Bob Katz <bobkatz at digido.com> wrote:
>
> 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> 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 listMLA at grimmaudio.nlhttp://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
> 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
> 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/20181013/fbee6f6b/attachment.html>