[MLA] Normalizing on Tidal

[Kevin Gross]

The MLA hasn't issued any information or recommendations for streaming. AES
TD1004.1.15-10 with contributions from MLA members Bob Katz and Thomas Lund
has recommended -16 LUFS. -16 LUFS is in conflict with the EBU's -24 LUFS
recommendation (the AES document says -24 LUFS can't work on mobile
devices). I beleive even -16 LUFS is too low for some player hardware and
listening environments. Because it is not possible to make everyone happy
with a single target and because the tendency is to standardize on the
loudest option when multiple targets are in play, I have always advocated
against fixed target normalization.

I agree with what I think Eelco is suggesting; Streaming services should
transmit unnormalized audio but include loudness metadata so that it can be
normalized by the player.

On Sat, Feb 27, 2016 at 4:06 AM, Grimm | Eelco <eelco at grimmaudio.com> wrote:

> Hi Kevin,
>
> > Things do get complicated when multiple loudness targets are in play.
> The easiest thing to do is to produce to the highest target. Our whitepaper
> recommends improving players. We should stay on that message and resist
> efforts to put even more targets in play.
>
> Yes, so -16 (to -20) LUFS is our target. The fact that Tidal offers the
> metadata to 3rd party integrators is however something different. In all
> media players it is standard that the replaygain level is merged with the
> volume control level and forwarded to for instance ALSA sound control in a
> Linux system. The fact that Tidal now offers the replaygain values
> alongside their audio means that streaming audio can be treated exactly the
> same like locally stored audio. How logical can it be?
>
> Cheers,
> Eelco
>
> > On Feb 26, 2016 9:16 AM, "Thomas Lund" <thomas at lund.one> wrote:
> > Hi Eelco,
> >
> > The catch is to get metadata safely out of the system alongside audio.
> It’s not as attractive to use an upstream NormL gain control and then
> (analog) interfacing to the amp and speaker.
> >
> > I agree with your 2+3. In case streamers use a fixed target, we have to
> convince them that one-size-fits-all doesn’t cut it. There needs to be a
> target setting at -16 LUFS or lower. To me, that’s more important than if
> we get the whole NormL enchilada from day one.
> >
> > cheers,
> > Thomas
> >
> >
> > > On 26/02/2016, at 09.34, Grimm | Eelco <eelco at grimmaudio.com> wrote:
> > >
> > > Hi Thomas,
> > >
> > >> BTW, I’m promoting the NormL principle everywhere, but the ideal is
> of course to have access to a late gain control in a *system*, especially
> if interfacing from the streaming device is analog. Hopefully Apple has
> listened...
> > >
> > > Well, Tidal did so for sure. If a company like Roon Labs has the
> replaygain data, any Tidal integrator has and they are free to implement
> Norm-l.
> > >
> > > In the end that is perhaps the largest step that Tidal set: offering
> the raw loudness data to app builders that integrate Tidal support, in
> stead of rendering the loudness data directly in their API (at their own
> default target level).
> > >
> > > I will check with someone who is deep into this streamer code stuff
> how the loudness metadata rendering in Spotify, Deezer, Qobuz etc is done.
> > >
> > > So it all boils down to three questions for streamers:
> > > 1. Do you offer the raw loudness metadata + raw audio data to
> downstream services via your API?
> > > 2. In your own apps: what is the internal target level?
> > > 3. If the loudness level of a track is lower than that target level,
> what happens?
> > >
> > > I will try to find the answer to question 1. Questions 2 and 3 will be
> answered soon when we finished our research project for the TV show. I will
> keep you updated.
> > >
> > > All the best,
> > > Eelco
> > >
> > > PS Florian: will there be a loudness panel again at AES Paris? I would
> be happy to present the results of the research project...
> > > _______________________________________________
> > > 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/20160301/eb6cd7e0/attachment.html>