[MLA] ***SPAM*** Thomas's concerns. Was More good news: Spotify.....

Thomas Lund thomas at lund.one
Fri May 26 09:00:49 CEST 2017


Hi Bob,

You misunderstood my concern about causality in production getting weakened with album norm. I get weekly mail from engineers that have understood and appreciated my compare-at-equal-loudness mantra.

With album norm, that’s one of the transparent causalities we stand to loose, or at least blur. Behavioral studies in a variety of areas typically find that a direct and predictable effect is the main motivation for action/change. It’s a human thing :-)

cheers,
Thomas




> On 25/05/2017, at 21.51, Bob Katz <bobkatz at digido.com> wrote:
> 
> 1) I think the clipping on the soft Victoria Mullova track can be traced to Sound Check's unpleasant (and discouraged by us) practice of upward normalization, yes? Apple have to stop that practice. In fact, I've proved that album normalization as we've proposed, using the loudest track as the reference, will minimize the kind of damage that occured with the soft Mullova song. It's all due to upward norm, anyway. 
> I don't see any harm in the right algorithm if Thomas wants to raise the target to -14 for album norm, since the right algorithm will prohibit upward normalization if the track would clip. At least for the duration of the Cenelec issue. 
> 2) Thomas brings up several other interesting issues:
> 
> a) The production issue is only relevant when playing files in a playlist, so it won't apply to streaming. Frankly, the issue of comparing tracks encoded at different levels or qualities and hearing how they sound encoded is so fraught with psychoacoustic issues that I think applying normalization is a red herring. With or without normalization you're in a psychoacoustic pickle. 
> Personally I'd turn off normalization to begin with for an encode-quality test. Here's why: The quality of the encode is dependent on the RMS and the peak level of the material. Too high of either and the codec starts to suffer. The perceived quality of that encode is dependent not just on the encode but exactly on how loud you play it back. But since different level encodes result in different level decodes, without normalization they will sound different just because of the level. 
> 
> But even with normalization, especially Sound Check, the algorithm will interpret these different encodes differently and often unpredictably. Resulting in perceived quality differences that are simply due to the differences in output level. Sound Check especially since it includes peaks in its complex calculation. So you'll easily fall into the "louder is better" camp even if you didn't wish to. 0.2 dB level difference between two otherwise IDENTICAL files can produce an obvious difference in depth and separation. So if Sound Check makes one of the two louder, even if it's not the better of the two, your preference will be to the one it makes louder. Regardless of its objective quality. 
>  
> Messy, isn't it!
> 
> Yes, you'd think that album normalization adds yet another complication to that comparison, but I don't think so, Thomas. Here's why: These test encodes will not have any metadata. So Sound Check will revert to track normalization. So what's the worry? 
> 
> b) Currently Sound Check is not running our recommended "normalize to the loudest track", but let's assume that it's the magical day in the future when it does (thanking Buddy Judge if it happens!). In that case, I would test the encode with the loudest track in the album and see how it's affected, and assume that lower level encodes will sound even better. Usually it seems to me that we're looking for the highest level encode that won't deteriorate the quality too much. So we pick the loudest song for that listening test. Done and done.
> 
> c) Yes, the issue of what target offset (if any) to use between track and album normalization becomes very relevant. But we have to conquer that. Since the single is usually the loudest track on a pop album. If you set up an offset so that track normalization would be at, say -16 LUFS but album norm is at -14 LUFS, then the single will play 2 dB lower than it would play when it's part of the album. So I'm not so sure that target-offset-between-album-and-track-norm is the world's greatest idea.
> 
> What other implications are there of an offset between album and single normalization targets? We should discuss. 
> 
> d) Thomas wrote: "It’s also unfortunate that the same track will get a different gain depending on whether it’s from an original album, a “best of”, or a compilation."  
> 
> Different gain would occur even with track normalization, if the three albums are mastered to different levels as is often the case, the greatest hits album is often mastered louder than the original album. It shouldn't be that way, but it is the case. Album normalization would make this situation subjectively better. It's not unfortunate they'd get different gains, it's a benefit. I'll explain: 
> 
> First of all, the same track on each of those may get a different gain anyway when mastered! For example, on the compilation it might be turned down or up compared to the original album. 
> 
> We know that the greatest hits album will have different metadata than the original album and so the album normalizer will adjust to the loudest track on each album. What I've seen in my own research is a remarkable convergence between styles and music when FORTE is used as the target instead of MEZZO FORTE. Album normalization takes the loudest song on the album and normalizes it to a target. When that happens, a playlist mixing Beatles and Frank Sinatra will be remarkably consistent, as soon as you apply album normalization all of the time. Every song, even from different genres, is more compatible with each other. Eelco's test demonstrated this very very well.  Once the forte songs on both albums are made to be the same loudness, the rest fall into place. 
> 
> The logical conclusion is that if the original album, the best of, and the compilation were mastered properly, then album normalization will make everything sound more right, even if you mix songs from all three albums into a playlist. It won't fix the horrendous compression on the poorly-mastered greatest hits album, but it will make everything more compatible. In fact, the soft songs will play in the same proportion that they do on each album. So if the mastering engineer for the greatest hits turned up the ballads, then sadly, those ballads from the greatest hits will play more like track-normalized anyway. And they will sound louder than the ballad from the original album. But if the mastering engineer for the greatest hits album mastered each song by what sounds right, even if his center of gravity for the whole album is turned up, then the ballads from the greatest hits and original albums will sound the same when album normalization is applied. And will be turned up way too far if track norm is applied. So the different gain is a benefit, not an unfortunate side effect! That's what loudness normalization is supposed to do anyway :-). 
> 
> Put that in your pipe and smoke it  :-).
> 
> 
> BK
> 
> 
> P.S. Yes, we are all collaborating here! I've always got the collaboration spirit. But the originator of an idea should not be forgotten. Eelco gave Norm-L to the world and we owe him a big debt of gratitude. I always credit  anyone who originates an idea, Thomas gets a lot of credit in all my seminars. Florian, our hard-working mentor, gets amazing credit for corralling and making collaborations work. But regardless, if you originate an idea you should be credited for it, along with the collaborators who help make that idea work! No one works in a vacuum.
> 
> That said, for the record I'd like to mention that I was the first to propose album normalization be done to the loudest track. 
> 
> 
> Best wishes,
> 
> 
> Bob
> 
> 
> 
> 
> On 5/25/17 4:33 AM, Thomas Lund wrote:
>> Hi Bob L,
>> 
>> Even if the user has selected Album Norm, the system should revert to Track Norm (and Track Target Level) for a case like you describe. That’s related to some production aspects I don’t like about potential Album Norm: The loop becomes less predictable. Now, during mastering, you can compare several versions of a track loudness normalized, and decide which one is the best. With Album Norm, this gets blurred. It’s also unfortunate that the same track will get a different gain depending on whether it’s from an original album, a “best of”, or a compilation. More ambiguity.
>> 
>> To your second question: Most certainly not. Where it’s difficult to make BS.1770 return an unreasonable result, examples with Sound Check may readily be found. Maybe you recall our general BS.1770 vs SC comparisons from a while back. Ian commented wrt soft often getting too loud - to which I agree - you found the Victoria Mullova track with obvious clipping, and recently we’ve seen a host of insanely loud tracks that probably saturates the SC measurement; result being that they end up way too loud. Like 12 dB or more.
>> 
>> Playing around with HF tones can sometimes buy one or two dB extra with BS.1770, but at the risk of angry customers, burned tweeters and defunct lossy codecs. Another technicality we shouldn’t take too seriously for all the confusion and ripple effects it would cause. Should it ever become a problem, filter or reject at ingest.
>> 
>> cheers,
>> Thomas
>> 
>> 
>>> On 23/05/2017, at 21.02, Robert Ludwig <gatewaybob at mac.com <mailto:gatewaybob at mac.com>> wrote:
>>> 
>>> Hi Eelco and Ian,
>>> 
>>> This is all amazing.  Using Album normalization for everything is something that just never occurred to me, thanks for out-of-the-box thinking, Eelco!
>>> 
>>> Yes, I've know Buddy Judge pretty well for over 5 years now, we worked together during the “pre-release” stage of MFiT.  I met him in person in California and he has always been very straight forward with me.  I’m so glad to finally read SOME rationale for why Apple has not turned on Sound Check. 
>>> 
>>> I had two questions:
>>> 
>>> 1.  I agree that all services should use the same algorithm for normalization.
>>> 
>>> Eelco, I’m not clear about this:
>>> VERY often we do a single that is being released before the album is finished.  
>>> How will the average album level be determined if there is no album with which to measure when the single is released?
>>> 
>>> 2. Does Sound Check measure highly compressed music any better than BS1770 (I assume -4)?  I’d be surprised if it did.
>>> 
>>> That is mind-blowing that someone would put 20kHz tones into the music in order to make it louder.  
>>> 
>>> I’m very encouraged by all of this!
>>> 
>>> All my best,
>>> Bob L.
>>> 
>>> 
>>>> Yesterday Buddy Judge, senior product manager at Apple and responsible for iTunes, came to me after my presentation. We had a beer and then we even went for dinner together ("all on Tim" :-). Buddy is a cool guy and a musician (I guess Bob Ludwig knows him well since he is also the guy behind "Mastered for iTunes"). Buddy told me a few interesting things that may help us understand why normalization was not turned on by default yet:
>>>> 1. The artistic integrity is very important for Apple. Just like Tidal they do not like that with track normalization the loudness integrity of an album is disturbed. Buddy told me it had never come to his mind to advocate using album normalization even in shuffle mode, but he found it an interesting concept that he would love to test.
>>>> 2. Buddy said that if normalization would be turned on by default, all streaming services should use the same type of normalization so mastering engineers can anticipate to it and would not have to make seperate masters for every different platform (because many will likely still aim for being the loudest). ITU BS1770 seemed to make most sense to him, although he knew that compressed music is measured a little too loud by BS1770. Album normalization with the loudest track aligned to target level also made most sense (in my presentation I showed that when normalizing the _average_ album level (like currently in iTunes), the loudness of the loud hit tracks would only be known when the full album is finished - this is a clear no-go for a mastering engineer).
>>>> 
>>>> We promised to stay in regular contact the next few months and all in all this feels _very_ encouraging. 
>>>> 
>>>> But this brings me to an important note. Pop music mastering engineers might even be worse than Italian commercial mix engineers. So if the latter ingest 20 kHz tones just above the relative gate threshold, to gain 1 or 2 dB of level, this will probably happen to pop masters too. Florian, it will become even more important to convince ITU to add the HF low pass filter to K weighting, so we better make sure that this development is not delayed too much...
>>>> 
>>>> Cheers,
>>>> Eelco
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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>
>> 
>> 
>> 
>> _______________________________________________
>> 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.
> _______________________________________________
> 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/20170526/f0463470/attachment-0001.html>


More information about the MLA mailing list