[MLA] ***SPAM*** Re: Not either or
Kevin Gross
kevin.gross at avanw.com
Wed Dec 13 17:03:45 CET 2017
OK, we can and should recommend that per track loudness metadata be
retained. You will need this to compute album loudness anyway.
I appreciate that when album normalization is used, it is more difficult
to, during production, to audition how loudly a track will play when
streamed. Perhaps a solution to this is something we can work on and I'm
interested in helping because I beleive it is important. But I do not think
accurate loudness audition for in-progress production is as important as
optimizing final listener experience. The only purpose of this audition is
to determine whether loudness of the production is "competitive" which, in
the long run, is not a question we want producers focusing on. I'm
convinced by Eelco's recent work and years of using ReplayGain that album
normalization is best aesthetically for listeners.
You haven't given any reason why or situations where a listener would want
to hear things track normalized. You haven't given a suggestion for how to
explain track vs album normalization if this is given as a user option in
player settings. I think we need to have both of these before we would
advocate for implementing a track normalization mode for music.
Kevin Gross - AVA Networks
On Wed, Dec 13, 2017 at 6:03 AM, Thomas Lund <thomas at lund.one> wrote:
> Hi Ian,
>
> Examples can always be found where one norm strategy or the other works
> best. In five year’s time, we will likely have an idea if one is better for
> normalisation in general.
>
> In the meantime, giving the advice “Album norm only” comes with at least
> two serious downsides: a) streaming providers might carry only the Album
> number forward, and b) Album reduces production transparency, a hard-fought
> feature of BS.1770. As a third minor downside, Tidal won’t be able to offer
> search criteria such as “only suggest tracks with PLR >12 dB” or “tracks
> with higher PLR at top of list”.
>
> Ad a), if the Track value became vital, e.g. because of new regulatory
> requirements, extensive metadata work would be needed. Ad b), the
> wonderfully simple production concept - whatever you add, listen loudness
> normalised - is void.
>
> cheers,
> Thomas
>
>
> On 13 Dec 2017, at 00.54, Ian Shepherd <ian at mastering-media.co.uk> wrote:
>
> Having been one of Eelco’s test subjects, I have to say that for me, even
> at low levels & background listening, I preferred the album-normalised
> stream. Both provided sufficient normalisation, but the track-normalised
> version simply had certain songs that caught my attention as being “wrong”,
> whereas the album-normalised version didn’t.
>
> Also I agree with Bob - there is so much that’s positive about this result
> (enabled by default, for starters) and it can be refined in future if
> necessary.
>
> Having said all that, I greatly respect your opinion Thomas, and am
> curious about the problems you see with not providing a track-normalised
> mode, if you’d like to comment ?
>
> Ian
>
>
>
>
> On 12 Dec 2017, at 16:40, Kevin Gross <kevin.p.gross at gmail.com> wrote:
>
> For listening at low levels or in noisy environments, we do need to talk
> about DRC. Maybe track normalization is part of that discussion but it will
> definitely not solve the problem on its own. Telling listeners track
> normalization is for these situations is not very satisfying advice.
>
> Unless/until we can justify and explain how to use a track normalization
> mode, we should not be advocating that it be included in player
> implementations.
>
> If you want to do your own listening tests, no Tidal subscription is
> required; Most players with ReplayGain allow you to choose album vs track
> normalization. I use MediaMonkey.
>
> Kevin
>
> On Dec 12, 2017 8:02 AM, "Bob Katz" <bobkatz at digido.com> wrote:
>
>> I think that background listeners playing background music at low level
>> would prefer track normalization. I would in that case as the softer tracks
>> become non-viable.
>>
>> Given that I believe that Tidal listeners are more critical doing
>> foreground listening, that track normalization is not as urgent a
>> requirement as it would be with Spotify, Apple, etc.
>>
>> I have no idea how to tell listeners how to specify mode, but if I were
>> trying to make life easier like Apple attempts to do I would not give them
>> that advice, I would try to estimate what kind of a listener they are based
>> on the SPL they are listening at. So some form of a smart player would be
>> necessary. It's probably impractical to implement, but I can dream, if the
>> computer uses its internal microphone to judge the loudness of the music
>> being played versus the noise of the room, it could judge whether to use
>> track or album normalization.
>>
>> Since that's currently science fiction, I have not easy idea on how to
>> present the options to the user. No matter how you do it, it will be
>> confusing. Beta test. Beta test Beta test. Refine. Refine Refine.
>>
>> Bob
>>
>>
>>
>> On 12/12/17 10:34 AM, Kevin Gross wrote:
>>
>> You've read Eelco's paper right? Aside from the fact that album worked
>> best subjectively for normal and corner cases, one practical issue is that
>> if you include an album/track option for users you should explain what it
>> is for. I'm curious what advice you would give to users on selecting mode.
>> You say track normalization is better in some cases. What cases are those
>> exactly?
>>
>> Kevin Gross - AVA Networks
>>
>> On Tue, Dec 12, 2017 at 1:56 AM, Thomas Lund <thomas at lund.one> wrote:
>>
>>> Hi,
>>>
>>> We have had some discussions after it became clear Tidal's system didn’t
>>> support Loudness-normalization based both on Track and Album; so they are
>>> stuck with the latter for now. If we jump to conclusions, more companies
>>> this group is used to advise, may find themselves taking one step forward
>>> and two backwards.
>>>
>>> For some applications, Track norm is better, for other applications
>>> Album norm should be preferred. It’s bad advice to impose an either/or
>>> decision, and in this case it might have ramifications for Tidal’s
>>> capability to comply with certain requirements or new track search criteria.
>>>
>>> Careful and unbiased guidance in these matters will better stand the
>>> test of time.
>>>
>>> Best regards,
>>> Thomas
>>> _______________________________________________
>>> 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 <(407)%20831-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://grimmaudio.nl/pipermail/mla_grimmaudio.nl/attachments/20171213/2b652849/attachment-0001.html>
More information about the MLA
mailing list