[MLA] Lossy encoder clipping

[Bob Katz]

Dear Kevin:

Fraunhofer hasn't solved any problem. 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.

Subject to reverification as it's been so long I can't grab my 
documentation on previous research I did on this issue.


Bob



On 10/11/18 5:59 PM, Kevin Gross wrote:
> The floating point decoder of course has ample headroom naturally. You 
> can also design a fixed point decoder with ample headroom (possibly 
> sacrificing some resolution). In either case, it doesn't help to have 
> headroom if you don't do something to avoid clipping (attenuation, 
> limiting...) before you send the digital signal to the DAC.
>
> I want to know more about how Fraunhofer believe they have solved 
> this problem.
>
> Kevin
>
> On Mon, Oct 8, 2018, 10:09 AM Grimm | Eelco <eelco at grimmaudio.com 
> <mailto:eelco at grimmaudio.com>> wrote:
>
>     Hi Kevin,
>
>     Interesting point. The question then becomes how many fixed point
>     based subband decoders are still around (in percentage of the
>     total). Another question is whether the path from the decoder to
>     the volume block (that likely will perform the normalization) is
>     floating point.
>
>     All the best,
>     Eelco
>
>>     I'm pretty sure integer decoders are still in use. Not on PCs or
>>     even smartphones but in smaller audio appliances (e.g. Bluetooth
>>     speakers). In any case, you've got to get back to integer at some
>>     point to feed the DAC. So you either give the encoder the extra
>>     headroom as Spotify is suggesting (see Ian's blog) or you
>>     attenuate after the decoder as you've suggested. Maybe you end up
>>     doing both conservatively in which case you've lost perhaps 6 dB
>>     compared to 0 dBFS PCM which is obviously not a small discrepancy.
>>
>>     Kevin Gross - AVA Networks
>>
>>
>>     On Mon, Oct 8, 2018 at 7:45 AM Bob Katz <bobkatz at digido.com
>>     <mailto:bobkatz at digido.com>> wrote:
>>
>>         Ian, it's been a while since I performed this test. I would
>>         have to retest to be sure, but to the best of my
>>         recollection, *the clipping is ONLY on the repro side and
>>         only when converted to fixed point.* Remember that all the
>>         codecs (both encode and decode side) are 32 bit floating point.
>>
>>         If you run an attenuator in the floating point domain after
>>         the decoder, you can fix any over issues which would manifest
>>         as clipping when converted to fixed. Test it yourself. Run
>>         Apple's AU lab with the round trip codec and Bitter placed in
>>         critical places.
>>
>>         Then put a 24 bit dithering plugin and run a distortion test
>>         on a sine wave to make sure it's not an illusion. If you guys
>>         don't perform this test before the weekend, I'll try to do it
>>         myself again.
>>
>>
>>         Best wishes,
>>
>>
>>         Bob
>>
>>
>>         On 10/7/18 7:39 PM, Ian Shepherd wrote:
>>>         Hi All !
>>>
>>>         My recent blog post about lossy encode clipping has had quiet a bit of attention:
>>>
>>>         http://productionadvice.co.uk/spotify-upload-true-peak/
>>>
>>>         Including an email from Robert Bleidt @ Fraunhofer. He’s asking if I have specific examples of encodes that have “baked in” the clipping, because his position is that it shouldn’t happen, these days.
>>>
>>>         I’d like to give him a helpful reply and I’ve experienced problems myself in the past with encoding from Logic and Audacity, for example, but the truth is I don’t have a collection of examples on hand to offer him.
>>>
>>>         Do any of you have recent examples that I can point him at, or know for sure of current encoders that consistently have issues with extremely loud content ?
>>>
>>>         Thanks for any suggestions,
>>>
>>>         Ian
>>>         _______________________________________________
>>>         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.
>>
>>         _______________________________________________
>>         MLA mailing list
>>         MLA at grimmaudio.nl <mailto:MLA at grimmaudio.nl>
>>         http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl
>>
>>     _______________________________________________
>>     MLA mailing list
>>     MLA at grimmaudio.nl <mailto:MLA at grimmaudio.nl>
>>     http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl
>
>     _______________________________________________
>     MLA mailing list
>     MLA at grimmaudio.nl <mailto: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

-- 

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/20181011/2c5ef6ea/attachment-0001.html>