[MLA] AES71 comments

Mon Jul 2 16:23:14 CEST 2018

-20 LUFS was one of the three targets they tested. The others tested were
-16 and -23 LUFS.  -20 LUFS is not mentioned in any of the normative
tables. -16 LUFS is specified as an absolute maximum loudness presumably
when metadata is available. I assume a player would see the metadata and
attenuate something like this 7 dB.

Kevin Gross - AVA Networks

On Sun, Jul 1, 2018 at 2:16 PM, Grimm | Eelco <eelco at grimmaudio.com> wrote:

> Hi Kevin,
>
> I thought AES71 recommended -20 to -16 LUFS?
>
> Cheers,
> Eelco
>
> Even for systems with metadata, the standard is not very specific on what
> the metadata is and how to use it to control playback.
>
> I think we have identified important use cases where portable devices do
> not get metadata. The blanket AES71 recommendation in this case is for -23
> LUFS target level. We know that does not square with current practice and
> recommendations. The recommendation is based on preliminary and incomplete
> testing that surfaced problems with this level. I don't think it will work.
>
> I think deficiencies in this work has the potential to cause implementers
> to lose confidence in loudness standards. I am considering putting in an
> official comment against AES71 to this effect.
>
> Kevin Gross - AVA Networks
>
> On Fri, Jun 29, 2018 at 5:08 PM, Grimm | Eelco <eelco at grimmaudio.com>
> wrote:
>
>> Hi Kevin,
>>
>> When you say all OTT formats require metadata, can you give some examples
>> and do you know details about the metadata formats and systems used?
>>
>>
>> What I meant is that most streaming services offer their own apps and
>> have a communication channel within their own ecosystem. For streaming to a
>> browser you are right: in that case the metadata needs to be integrated
>> with the audio stream and so it is dependent on the format. But I’m afraid
>> we cannot guarantee that this will never be abused (like feeding it with
>> wrong metadata). So my recommendation would be that the OS will only offer
>> additional gain to approved apps, not to browsers. I agree it is not a
>> complete solution, but a large majority of users (and content providers)
>> will profit from it.
>>
>> It should work like this: in the browser, -16 LUFS will be the target
>> level. Programs that are softer will sound softer. In the app -23 LUFS can
>> be the target level and all content (soft and loud) will be normalized.
>>
>> Cheers,
>> Eelco
>>
>> If we have good support for metadata, AES71 can work. I am concerned
>> about its default behavior when no metadata is available. AES71 is not
>> helping its own adoption by not at least referencing any existing metadata
>> formats or systems.
>>
>> Kevin Gross - AVA Networks
>>
>> On Sat, Jun 16, 2018 at 2:11 AM, Grimm | Eelco <eelco at grimmaudio.com>
>> wrote:
>>
>>> Dear friends,
>>>
>>> I’m sorry I did not check my MLA mailbox the past week and did not
>>> respond more early.
>>>
>>> Kevin, can you please tell me under what circumstances there will be no
>>> metadata and/or guaranteed normalization level? All OTT formats I know
>>> cannot be used without metadata. Did they specify these circumstances in
>>> AES71 more precisely?
>>>
>>> Also, what does it mean ‘-23 LUFS when there is no metadata’? If the
>>> audio is measured, metadata can be added. If the audio is not measured, it
>>> could be -6 LUFS and it is dangerous to treat it as if it is -23 LUFS.
>>>
>>> But perhaps we are dealing with a completely different problem. The
>>> loudness of the program at the OTT service is known, with or without
>>> metadata: -23 LUFS. The question then is: how to do playback on a portable
>>> device? The solutions is to solve it in either the app (with 7 dB extra
>>> gain and a limiter) or in the OS. I will reach out to the OTT contacts at
>>> Google and Apple that Matthieu Parmentier gave me to pitch a simple
>>> solution I came up with: let the app signal to the OS that it has turned
>>> normalization on at a certain level (let’s say -23 LUFS), and then the OS
>>> offers 7 dB (in this case) extra headroom. Buddy Judge has already checked
>>> this idea within Apple and apparently the engineers have been thinking
>>> along simiar lines. You can’t fool the OS since the app needs to comply to
>>> AppStore rules and will be tested prior to release. I want to pitch this
>>> idea to as many developers within Apple as possible so chances are higher
>>> it will be adopted.
>>>
>>> Cheers,
>>> Eelco
>>>
>>>
>>> On 8 jun. 2018, at 16:41, Kevin Gross <kevin.gross at avanw.com> wrote:
>>>
>>> I have done some work with Dolby on this but not specific to loudness.
>>> There is a standards initiative they've started to define a network format
>>> for metadata to go along with our network formats for audio and video.
>>> There are already means to carry metadata in video and AES3 and in many of
>>> the coded audio and video formats.
>>>
>>> I think what is mostly missing is a metadata definition for loudness.
>>> What metadata would be in a loudness dataset? I know LUFS and dBTP would be
>>> central but the devil is in the details. Are these short-term, long-term or
>>> for the entire program. If for the program, how do we know where the
>>> program starts and ends. What is needed to specify the "DRC Profile" that
>>> AES71 introduces? How does a player use all of this stuff?
>>>
>>> Kevin Gross - AVA Networks
>>>
>>> On Thu, Jun 7, 2018 at 12:10 AM, Ian Shepherd <ian at mastering-media.co.uk
>>> > wrote:
>>>
>>>>
>>>> Same. I suspect it was left vague in AES71 because it’s a massive can
>>>> of worms, and they want to allow flexibility in actually implementing it.
>>>>
>>>> Either way I don’t personally have the bandwidth, either as part of
>>>> this group or for the AES directly.
>>>>
>>>> Having said that, I think including a recognition that mobile devices
>>>> may need to use a higher level as an interim measure would be a good idea.
>>>>
>>>> Ian
>>>>
>>>>
>>>>
>>>> On 7 Jun 2018, at 01:31, Bob Katz <bobkatz at digido.com> wrote:
>>>>
>>>> I think we'd have to bring in Dolby and other experts at least as
>>>> consultants. I only understand the basics of Metadata so I'd be shooting in
>>>> the dark.
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>> On 6/6/18 5:01 PM, Kevin Gross wrote:
>>>>
>>>> We need to get this metadata thing sorted out. AES71 tells you when to
>>>> use metadata but it doesn't say exactly what it is, how to transport it or
>>>> what you should do with it. Is this something that we help could flesh out?
>>>>
>>>> Kevin Gross - AVA Networks
>>>>
>>>> On Wed, Jun 6, 2018 at 1:22 PM, Bob Katz <bobkatz at digido.com> wrote:
>>>>
>>>>> I'm in favor of any solution that lowers the recommended target! But
>>>>> it's always interim.
>>>>>
>>>>>
>>>>> -18 LUFS is 5 dB away from -23. It ought to be safe for the majority
>>>>> of program with an emergency protection limiter, at least for portable
>>>>> devices. But I would NOT recommend -18 LUFS target for set top devices
>>>>> playing wide range program material on loudspeakers. There's the rub and
>>>>> the need for metadata.
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>>
>>>>> On 6/5/18 8:49 PM, Ian Shepherd wrote:
>>>>>
>>>>>
>>>>>
>>>>> Maybe the solution for fallback in the absence of metadata on portable
>>>>> devices we recommend a gain boost of 7 dB with a protection limiter. Since
>>>>> it's music it's likely to have a PLR of less than 16 dB so if it was
>>>>> normalized to -23 it would hardly trigger the limiter. But without metadata
>>>>> how do you know it's music? And if they normalize regular program to -23 it
>>>>> will be too low for many portable devices, also.
>>>>>
>>>>> Shit (excuse my French)
>>>>>
>>>>> We’ve settled on around -18 LUFS for my podcast, which is plenty loud
>>>>> on my (European) iPod with stock earbuds. Anecdotally the BBC seems to be
>>>>> similar, and also works works fine, for the most part.
>>>>>
>>>>> We should look back through our notes for the meeting where the
>>>>> podcast providers joined in, Bob - from memory most of them had also
>>>>> settled on -16 or -18, I think.
>>>>>
>>>>> I assume your concern is that raising normal program to -16 would
>>>>> trigger excessive limiting, Bob. Perhaps suggesting -18 (which is the
>>>>> median of the AES recommended range) for everything would be a workable
>>>>> compromise, when there’s no meta-data ?
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://grimmaudio.nl/pipermail/mla_grimmaudio.nl/attachments/20180702/370becf2/attachment-0001.html>