[MLA] Thomas's concerns. Was More good news: Spotify.....
Bob Katz
bobkatz at digido.com
Thu May 25 21:51:04 CEST 2017
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
>>
>> _______________________________________________
>> MLA mailing list
>> MLA at grimmaudio.nl <mailto: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
--
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/20170525/f28e14a6/attachment-0001.html>
More information about the MLA
mailing list