<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body class=""><div>On Fri, 2017-05-26 at 09:00 +0200, Thomas Lund wrote:</div><blockquote type="cite">Hi Bob,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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 :-)</div></blockquote><div><br></div><div><br></div><div>I must admit I'm still confused as to what you exactly were trying to say, Thomas. I'm beginning to see that you are focusing on the causality issue. But causality is messed up with any kind of normalization and so the user has to learn to adjust... so I don't understand your point about blurring. I tried to make the point that album normalization would improve the situation and furthermore not go into effect anyway when testing encodes since there would be no metadata.</div><div><br></div><div>I must be missing your point and I fear you are missing mine.</div><div><br></div><div>cheers,</div><div><br></div><div><br></div><div>Bob</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div class=""><br class=""></div><div class="">cheers,</div><div class="">Thomas</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 25/05/2017, at 21.51, Bob Katz <<a href="mailto:bobkatz@digido.com" class="">bobkatz@digido.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">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. <br class="">
</p><p class="">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. <br class="">
</p><p class="">2) Thomas brings up several other interesting issues:</p><p class="">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. <br class="">
</p>
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 <b class="">perceived quality </b>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. <br class="">
<br class="">
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. <br class="">
<br class="">
Messy, isn't it!<br class="">
<br class="">
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? <br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
What other implications are there of an offset between album and
single normalization targets? We should discuss. <br class="">
<br class="">
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." <br class="">
<br class="">
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 <b class="">better.</b>
It's not unfortunate they'd get different gains, it's a benefit.
I'll explain: <br class="">
<br class="">
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. <br class="">
<br class="">
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. <br class="">
<br class="">
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 <b class="">benefit,</b>
not an unfortunate side effect! That's what loudness normalization
is supposed to do anyway :-). <br class="">
<br class="">
Put that in your pipe and smoke it :-).<br class="">
<br class="">
<br class="">
BK<br class="">
<br class="">
<br class="">
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.<br class="">
<br class="">
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. <br class="">
<br class="">
<br class="">
Best wishes,<br class="">
<br class="">
<br class="">
Bob<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 5/25/17 4:33 AM, Thomas Lund wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:AAB71995-BFA9-4824-970B-DECB034088A8@lund.one" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Hi Bob L,
<div class=""><br class="">
</div>
<div class="">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 <i class="">production
aspects</i> 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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">cheers,</div>
<div class="">Thomas</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 23/05/2017, at 21.02, Robert Ludwig <<a href="mailto:gatewaybob@mac.com" class="" moz-do-not-send="true">gatewaybob@mac.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">Hi
Eelco and Ian,
<div class=""><br class="">
</div>
<div class="">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!</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">I had two questions:</div>
<div class=""><br class="">
</div>
<div class="">1. I agree that all services should use
the same algorithm for normalization.</div>
<div class=""><br class="">
</div>
<div class="">Eelco, I’m not clear about this:</div>
<div class="">VERY often we do a single that is being
released <u class="">before</u> the album is
finished. </div>
<div class="">How will the average album level be
determined if there is no album with which to measure
when the single is released?</div>
<div class=""><br class="">
</div>
<div class="">2. Does Sound Check measure highly
compressed music any better than BS1770 (I assume -4)?
I’d be surprised if it did.</div>
<div class=""><br class="">
</div>
<div class="">That is mind-blowing that someone would
put 20kHz tones into the music in order to make it
louder. </div>
<div class=""><br class="">
</div>
<div class="">I’m very encouraged by all of this!</div>
<div class=""><br class="">
</div>
<div class="">All my best,</div>
<div class="">Bob L.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">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:<br class="">
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.<br class="">
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).<br class="">
<br class="">
We promised to stay in regular contact the next
few months and all in all this feels _very_
encouraging. <br class="">
<br class="">
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...<br class="">
<br class="">
Cheers,<br class="">
Eelco<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
MLA mailing list<br class="">
<a href="mailto:MLA@grimmaudio.nl" class="" moz-do-not-send="true">MLA@grimmaudio.nl</a><br class="">
<a href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl" class="" moz-do-not-send="true">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
MLA mailing list<br class="">
<a href="mailto:MLA@grimmaudio.nl" class="" moz-do-not-send="true">MLA@grimmaudio.nl</a><br class="">
<a class="moz-txt-link-freetext" href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
MLA mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MLA@grimmaudio.nl">MLA@grimmaudio.nl</a>
<a class="moz-txt-link-freetext" href="http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl</a>
</pre>
</blockquote>
<br class="">
<div class="moz-signature">-- <br class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">
<title class=""></title>
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">MLA mailing list<br class=""><a href="mailto:MLA@grimmaudio.nl" class="">MLA@grimmaudio.nl</a><br class="">http://grimmaudio.nl/mailman/listinfo/mla_grimmaudio.nl<br class=""></div></blockquote></div><br class=""></div></blockquote></body></html>