[MLA] ***SPAM*** Thomas's concerns. Was More good news: Spotify.....
Bob Katz
bobkatz at digido.com
Fri May 26 18:18:20 CEST 2017
On Fri, 2017-05-26 at 09:00 +0200, Thomas Lund wrote:
> 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 :-)
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.
I must be missing your point and I fear you are missing mine.
cheers,
Bob
> 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@
> > > > 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
> > > > >
> > > > > http://grimmaudio.nl/mailman/listinfo
> > > > > /mla_grimmaudio.nl
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > >
> > > > MLA mailing list
> > > >
> > > > MLA at grimmaudio.nl
> > > >
> > > > http://grimmaudio.nl/mailman/listinfo/mla_grimmau
> > > > dio.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/20170526/c3184f1f/attachment-0001.html>
More information about the MLA
mailing list