[MLA] Not either or

Bob Katz bobkatz at digido.com
Thu Dec 14 16:34:52 CET 2017


Track normalization is a big start towards consumers who do background 
listening or non-attentive listening in their homes. As opposed to album 
norm. Track normalization is a meaningful form of manual compression, no 
doubt about it.

DRC is a big and important procedure that we can discuss in a white 
paper, but please don't use it to derail any other discussion.


BK



On 12/12/17 11:40 AM, Kevin Gross 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 
> <mailto: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
>>     <mailto: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 <mailto:MLA at grimmaudio.nl>
>>         http://grimmaudio.nl/mailman/listinfo/mla_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
>>     <http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl>
>
>     -- 
>
>     If you want good sound on your album, come to Bob Katz
>     407-831-0233 <tel:%28407%29%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 <mailto:MLA at grimmaudio.nl>
>     http://grimmaudio.nl/mailman/listinfo/mla_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/20171214/225e109f/attachment.html>


More information about the MLA mailing list