[MLA] Lossy encoder clipping

[Kevin Gross]

OK, thanks. Now I understand what "baked in" means. I think we're on the
same page. With good encoder and decoder implementation, this can become a
post-decode problem. Spotify and R128 suggest it be solved pre-encode which
is a reasonable and holistic approach, just not a wholly robust one given
current mastering practices.

-kg


On Thu, Oct 11, 2018 at 6:25 PM Bob Katz <bobkatz at digido.com> wrote:

> 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> 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> 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 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
>>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://grimmaudio.nl/pipermail/mla_grimmaudio.nl/attachments/20181012/5b086080/attachment.html>