Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mark_h]

There are a number of threads questioning whether volume normalisation is working correctly.  I've been having my own issues, and started looking for files that trip things up to build a case for the dev team to take a look, but then I figured that, as the EBU specifies the requirements for R128 it might also provide test files.

Current R128 Documentation:

http://tech.ebu.ch/docs/tech/tech3341.pdf
https://tech.ebu.ch/docs/tech/tech3342.pdf

Current Test files:

https://tech.ebu.ch/publications/ebu_loudness_test_set

The test files, and expected results, are described in these documents.  The current MC R128 implementation fails most of the tests...  which perhaps explains the observations being talked about on the forum?

My guess is simply that the R128 implementation in MC hasn't kept up to date with the standards and that issues fixed by standards updates are being seen in MC...

Devs?

[mwillems]

Excellent sleuthing, I'll be curious to see what the issues are.

[Hendrik]

I analyzed all the samples and compared to the documented value ranges of both those standards, and MC seems to be perfectly accurate here (within the allowed derivation) in all categories, LU/LUFS (3341 1-8), TruePeak (3341 15-23), and LRA (3342)
Note that 3341 tests 9-14 don't apply since we don't use M/S anywhere, only I.

For the record, the values we display:
Volume Level (R128) = -I (ie. the negative of I, since we store the volume level to apply during leveling, while I is the difference to the reference point)
Dynamic Range (R128) = LRA
Peak Level (R128) = Max. true peak level

Which tests seem to disagree for you?

[mark_h]

All of them fail... eg for test Seq-3341-7 Seq-3342-5-24bit, where the documents state that the expected respones is -23 LUFS I see -27 LUFS...  None of the sine waves hit -23 LUFs.  The only tests that DO work are for LU Range, so even though -23 LUFS is missed, the LU Range on the samples is correct.

If I disable volume levelling in DSP then the files do hit the targets, but with volume levelling DSP active they fail. 

And I'm talking about PLAYBACK here, not analysis restults?  The expectation being, of course, that playback with Volume Levelling active will always result in a -23 Integrated LUFS playback level. 

[Hendrik]

We don't display LUFS, only LU, which is I=Volume Level (R128).

But LUFS is just an offset of -23 on top of LU - don't confuse it with Peak Level.

And of course analysis is the important part, thats what those documents reference, since they are about validating the algorithm.
If you apply volume leveling once and then analyze afterwards, clearly its going to not match the documented values anymore.

During playback, volume leveling is just a static one-time offset afterall (per track), which is the value retrieved during analysis.
If those test files analyze with volume level 0.0 then playback is not going to change it, unless you're running in adaptive or some other fancy mode. Audio Path shows you which offsets are being applied.

[mark_h]

Playback...

EBU VST plugins display the LUFS targets and show MC missing the target...

OK, I think I've found the problem:

If Seq-3341-7 Seq-3342-5-24bit is in a playlist on it's own, it hits the correct -23 Integrated LUFS playback, but if there are other tracks in the playlist it fails.

So MC is adjusting the target volume based on the full playlist... which means this problem goes back to the album volume vs track volume discussions that were made in the past...

Are there still options to control volume on an album or track basis?  I'm looking but cannot see them... target volume for EVERY track should be -23 LUFS

When people are transferring to iPods, that's one MASSIVE playlist, which is clearly the root of the volume inconsistency issue.

[Hendrik]

Its not about playlists, its about albums. All tracks in playing now in the same album = album mode. All those test samples are probably considered in the same album.
If you transfer a load of files to an iPod, they should use track mode, unless they are all from the same album. I'm not even sure if file conversion can ever use album mode, to be honest, it has strict checks to avoid using it wrongly last I checked.

But in any case, the R128 analysis implementation works just fine.

[mark_h]

Analysis works, I agree.  Let's move on from that.

The problem is playback.  So MC works in "album mode": all tracks from SAME album are "album adjusted" and giving a consistent volume between tracks, but then when we play with random playlists we are seeing random, and sometimes quite large jumps, in volume between tracks as MC transitions from each "album" grouping in that playlist, which might be just one track.

I wonder whether it would work better if entire playlists are considered ONE album so that all tracks are then normalised against that collection?  [EDIT: I have this backwards - a random playlist should NEVER be considered an album, but always be treated as a random playlist for volume levelling]

Either way, something isn't working well - hence my own experience, and that of others posting on the forums.

[Hendrik]

when we play with random playlists we are seeing random, and sometimes quite large jumps, in volume between tracks as MC transitions from each "album" grouping in that playlist, which might be just one track.

It should not do that, it looks at the entire playlist and only acts like that if you play nothing else but a single album, if I remember the code right.

I wonder whether it would work better if entire playlists are considered ONE album so that all tracks are then normalised against that collection?

I believe thats basically how "Adaptive" mode works, going from the top of my head.

[mark_h]

I stuck Seq-3341-7 Seq-3342-5-24bit in a small playlist (5 tracks), and it works correctly to -23 LUFS.

So, OK, back to trying to find tracks that break things for you...

I know that when I generate my iPod playlists for my car I am forever having to jump on volume to deal with significant changes in volume between some tracks, when the expectation is they are "Volume Normalised" by DSP.  But that is many thousands of tracks, so who knows whether there's just ONE in there causing problems.  Could take a while to find...

[Hendrik]

If I remember correctly, in the past we had a few cases where there was one track with totally wild analysis results that threw it all off. Could look for something with extremely huge Volume Level or Peak values.

[mark_h]

Had a sleepless night dreaming up test sets.  Will report any useful results

[mark_h]

OK, I think I've found the/a problem.

I created a whole bunch of test playlists, working through as many permutations as I could think up that would soak test the volume levelling engine.  The results summary:

Using volume R128 normalisation, the target for playback volume is -23 LUFS.

1. Single tracks: -23 LUFS [good]
2. Random track playlists from different albums: -23 LUFS [good]
3. Random track playlists that might contain tracks from same albums, but never consecutively: -23 LUFS [good]

OK, so all the above are good.  A consistent volume playback, as expected.  No sudden volume surprises.

Albums:

When MC plays an album, it volume normalises in "album mode" to preserve the dynamics between album tracks, as it should. [good]

The problem, though, is when we (humans) think we are in random playlist mode, ie a party mix, an ipod car mix, an exercise mix etc, and there are, by chance or design, consecutive tracks from a same album in the playlist.  Then MC gets it wrong.  It plays all the random tracks consistently at -23 LUFS [good], but for the consecutive album tracks it suddenly switches into album mode and there is a volume change. [bad]

These two charts show the same three tracks (two from the same album), first in non-consecutive album order, and then in consecutive album order:

1. Three tracks, two from same album but separated from each other by the third, non-album, track: [-23 LUFS, GOOD]



2. Same three tracks, this time with two tracks from same album next to each other: [Not -23 LUFS, BAD]



You can clearly see that MC treats both "random" playlists differently, with the second showing a swing in volume of 5-6dB.   And I think this is the root cause of the problems people are hearing with mixes: every time consecutive album tracks appear, MC switches into "album mode" and there are sudden, sometimes very large, volume changes. 

The solution seems obvious:

IF a playlist contains only tracks from one album - only use "album mode"
IF a playlist contains tracks from multiple albums - only use "playlist mode".

And NEVER switch between the two modes once play has started.  Conversion processes should also respect these rules.

It seems to me that the way MC volume levelling logic currently works is causing the issues being reported with random playlist volume swings and is actually potentially dangerous: imagine wearing headphones where you've set them to a comfortably loud -23LUFS setting and then it suddenly jumps into dangerously loud "album mode"...

Thoughts?

[AndrewFG]

You will probably have to figure out what to do with tracks from a single album but played in random play order.

[mark_h]

The main argument I'd make against my own proposal would be when playing multiple albums in one playlist: each album should be treated independently for volume levelling, and not normalised as part of the bigger playlist.  I sense that's why MC behaves the way it does currently...

I'd counter myself by saying that you'd then have a playlist containing large volume jumps as each album transitions, which will require user intervention.  Especially if playing through hi-fi kit: don't want to blow up my speakers!  Especially if playing through headphones: don't want to blow up my ears!

So, how to "fix"?

The problem is how do you determine whether a playlist is a genuine random mix, or whether it's an album mix? 

How difficult would it be to check that tracks in the playlist are always partnered with tracks off the same album?  If not all tracks are partnered, then it's treated as a random mix; if all tracks are partnered, it's an album mix?

If it's a random mix, all tracks are normalised to -23 LUFS.

If it's an album mix, all albums are normalised however albums are normalised right now, unless there's a better way?

[mwillems]

IF a playlist contains only tracks from one album - only use "album mode"
IF a playlist contains tracks from multiple albums - only use "playlist mode".

And NEVER switch between the two modes once play has started.  Conversion processes should also respect these rules.

I think what you're suggesting might make sense for playback, but for conversion there are some real problems with your approach.  For example, one common use case for "baking in" volume leveling is syncing to a handheld.  Obviously the baked in leveling has to choose one mode or the other, but there's no easy way to assess which is the desired behavior as all syncs involve creating a playlist first.  And one may consume the tracks both ways on the receiving device (as part of playlists and as part of albums).

FWIW, album leveling by default during conversion would be my preferred behavior, but I'm mostly an album listener and never ever want track leveling on a mobile device.

[mark_h]

Yes, I can see that being an issue.

At the moment I cannot see a solution that solves every possibility to everybody's satisfaction.

Maybe there should be a conversion option that dictates the type of levelling to use.  That way there is no guessing...?  [EDIT] Actually that's not going to work where multiple playlists (random and album) are pulled together for device syncing.

[mark_h]

FWIW, album leveling by default during conversion would be my preferred behavior, but I'm mostly an album listener and never ever want track leveling on a mobile device.

I use both random track playlists and album playlists and would like both types of normalisation.  Perhaps my TEST above might work; if all the tracks in the playlist are partnered up with other tracks from the same album, use album mode; otherwise, use random mode. 

That way I could sync out a bunch of playlists, some random based, some album based, and the conversion process could choose how to hardbake.

[EDIT] Again, I can see that only works if MC is aware of each smartlist/playlist type during syncing.

[mark_h]

Maybe MC only uses album mode for full albums present in the playlist, not partials?  That would solve random playlists that just happen to clump a few album tracks together by chance.

[mark_h]

Or maybe a modifier can be added to smartlists that specify the type of normalisation to use?

[mark_h]

How about an (DSP?) option somewhere to specify R128 works in album mode or random mode, which could be used in zones, ie we could create an ALBUM ZONE which uses the album logic and a RANDOM ZONE which uses random logic.  DEFAULT R128 mode would remain as now - an "intelligent" mix of random/album mode.

That would also enable finer control of device transfers?

[KingSparta]

I am trying out another program, MP3 Batch Processor - Sound Normalizer (It does more than mp3's)

going to see how it does.

[mark_h]

OK, I think I've identified *THE* problem.

With R128 normalisation, the overall sound is generally lower, requiring speakers to be turned up to compensate.  A normal side effect of normalisation.  And we've seen that (ignoring the Album vs Random debate) MC R128 processing works correctly.

For my ipod transfers though, to compensate for the overall volume loss, what I do, during conversion, is I add a parametric adjustment of +6 dB to Left/Right channel.  And THIS is what seems to be breaking things...

OK, so this first chart is four tracks played off my iPod, converted through DSP using ONLY Volume Normalisation.  You see that the conversion is correct and that the target -23 LUFS is hit and playback volume is consistent.



The second chart adds a 10dB lift (to highlight the problem) AFTER(?) volume normalisation, via the Parametric EQ DSP, during conversion.  You would expect to see the same flat normalised output as above, just lifted by ~10dB, but instead you get wild volume swings... 



Note that the ParaEQ only seems to "break" during device conversions.  If playing direct from the library it seems to work as expected, with a consistently normalised, but boosted, volume.

And, just for laughs, I tried converting to WAV (DSP: Volume Levelling/+10dB ParaEQ1) on the iPod instead of MP3 as above, and the same four songs generate this, completely different, output (no +10dB boost whatsoever).



Finally, here are the four tracks played direct from the library with volume levelling and a 10dB boost.  And this is how it should look from the external device.



This looks like something the devs could and *should* fix... Please

[mark_h]

BUMP (now that the holidays are over...)

[mark_h]

BUMP. 

Even if the album vs random thing isn't going to be addressed, the parametric equaliser problem with volume levelling really should be...

[Hendrik]

I was on vacation in January, hence the silence, in case you were wondering.

Just to clarify, volume leveling is still being applied during conversion, but the PEQ DSP is not being applied reliably? Or does volume leveling also stop functioning in that case?
I should probably find a batch of files with varying volume levels where this is easy to spot.

[mark_h]

Welcome back

Yeah, it's the PEQ DSP that is broken DURING CONVERSIONS, as per my examples above.  Volume levelling seems to work just fine.

So what I, and others, are trying to do is first volume level (works) to normalise the overall volume (-23 LUFS) and then apply a fixed PEQ boost to bring the overall volume back up again, but as you can see in the examples above, the PEQ layer results in swinging volume levels.

The PEQ works correctly for normal playback, but breaks during conversion operations, eg transferring files to external devices.

[Hendrik]

Do you specifically use the handheld  tool to convert, or the ordinary Convert Format tool?
I just tried the latter with Volume Leveling and a PEQ Boost, and subsequent analysis of the output files yields perfect +10dB gain in all of them from my short playlist. I'll try the handheld tool to check that soon.

You aren't hitting the conversion cache or copying some files in original (which wouldn't apply DSP) and some converted that might cause this?

[mark_h]

Do you specifically use the handheld  tool to convert, or the ordinary Convert Format tool?

The examples above were from the handheld conversion tool.  There are many other reporting the same, which is another reason I've been pushing a bit harder to get this looked at/fixed.

I just tried the latter with Volume Leveling and a PEQ Boost, and subsequent analysis of the output files yields perfect +10dB gain in all of them from my short playlist. I'll try the handheld tool to check that soon.

Yeah, plenty work, but plenty seem not to.  Maybe you got "lucky"

You aren't hitting the conversion cache or copying some files in original (which wouldn't apply DSP) and some converted that might cause this?

I emptied my cache prior to testing...

[Hendrik]

Does that appear to depend on the files if they work or not? Or in other words, do the same files fail predictably, and others pass all the time?

[mark_h]

Does that appear to depend on the files if they work or not? Or in other words, do the same files fail predictably, and others pass all the time?

Couldn't say for certain. 

Here are the four files I was testing with to show the problem above:

https://dl.dropboxusercontent.com/u/7082504/Media%20Center/R128%20problem%20files/Black%20-%20Wonderful%20Life%20-%2001%20-%20Wonderful%20Life.mp3
https://dl.dropboxusercontent.com/u/7082504/Media%20Center/R128%20problem%20files/Radiohead%20-%20Pablo%20Honey%20-%2008%20-%20Vegetable.flac
https://dl.dropboxusercontent.com/u/7082504/Media%20Center/R128%20problem%20files/The%20Beatles%20-%201%20-%2006%20-%20A%20Hard%20Day%27s%20Night.flac
https://dl.dropboxusercontent.com/u/7082504/Media%20Center/R128%20problem%20files/The%20Beatles%20-%201%20-%2011%20-%20Yesterday.flac

Maybe they will help?

[mark_h]

Just a quick test today on those four tracks.

Via Convert Format all works as expected.
Via Handheld Sync is breaks as described above.

The "handheld" in this instance was simply a folder on my drive.

[Hendrik]

Unfortunately its still not happening for me.
I must be missing some particular settings. I'm just applying Volume Leveling and a +10 PEQ boost, nothing else.

On a hunch, you don't use varying DSP presets stored in the "DSP" tag, do you?

Edit:
Actually on repeated tries one file suddenly changed. How odd for it to be so inconsistent.

[Hendrik]

Actually interesting development - despite being set to "Always Convert", the mp3 file in the set gets synced without conversion, so the DSP is never applied. Of course this results in wrong volume levels.
I suppose it detects that the original is MP3 and the target is equal or higher bitrate, and figures, why convert. Of course that DSP is on might be an important factor it should consider here.

[mark_h]

The DSP tag for each of the files is empty, so shouldn't be a factor.

Just in case it's a factor, my track ordering in my conversion playlist is:

A Hard Day's Night
Wonderful Life
Vegetable
Yesterday

All I'm doing is Volume Levelling and adding +10dB in PEQ

After conversion, I drag them into playing now and reanalyse to find out how they end up.

Through the Convert Format tool they all reanalyse wth -10 LU, meaning they've all been correctly volume level converted.

If I send those 4 files through the Handheld Sync tool with the same DSP settings, I get

A Hard Day's Night: -13.9 LU
Yesterday: -9.1 LU
Pablo Honey: -11.1 LU
Wonderful Life: -10 LU

So, *something* in the handheld transfer is messing with things...

EDIT:  OK, they are around the right way now.

[Hendrik]

Whats your setting for simultaneous conversions?
I still get consistent -10LU now, as it should be. I'm not sure whats going on.

In your info, the 3 FLAC files retain their original loudness without any modification, so they are not being changed at all, neither leveled or boosted.
Are they really being transcoded?

My Handheld settings:
Conversion -> Audio
Mode: Specified Output format
Encoder: MP3
Encoder Settings -> VBR
Cover Art: No Change
Apply DSP: Checked
DSP -> Volume Level checked, PEQ Checked with +10db Boost

And the result is always perfect.

[mark_h]

Mode: Specified output
Encoder: FLAC
Cover Art: Add to Tags
DSP: Volume Level checked, PEQ checked +10dB Left/Right

[mark_h]

If I switch my encoding to mp3, all the FLAC are converted to -10 LU, but the Wonderful Life mp3 ends up -7.3 LU (not converted?)

[mark_h]

Interestingly, when I switch to ALAC, which is what I use on my car iPod, they all end up -10 LU, however I am aware of wild swings on the car iPod, which is why I've been looking into this, suggesting that while these tracks may be ok under ALAC, others aren't.

[Hendrik]

suggesting that while these tracks may be ok under ALAC, others aren't.

Following this pattern, ALAC tracks wouldn't be, if you have any of those.
It seems to not convert files that match the specified output format, which may have made sense before we had the option to apply DSP. Guess I should make it convert all the time if DSP is on.

[mark_h]

Guess I should make it convert all the time if DSP is on.

Yeah.  Some DSP (Output Format) might make no difference, but in general DSP is likely to change the output file, making conversion mandatory.

[Hendrik]

The next version will have a change to always convert audio files, even to the same type, if DSP is active. Note that the conversion cache is still used if enabled, so if DSP settings are changed, it would need to be cleared.
Also, it only works fully when in "Convert: Specified output format" mode, not in any of the "only when necessary" modes, as it can then still copy the original files untouched.

[mark_h]

Super.  Many thanks, Hendrik.  Look forward to trying this out!

[KingSparta]

Good News...

Thanks For Figuring it out...

[mark_h]

Also, it only works fully when in "Convert: Specified output format" mode, not in any of the "only when necessary" modes, as it can then still copy the original files untouched.

So far, so good!  Converted a few hundred files and all looks good.   Got to drive for an hour this morning so will take the iPod out and see out things work.

Question re: "Only When Necessary"...  If Volume Levelling check is set, or DSP is active then surely that qualifies as "necessary" because the files ARE going to change.  Just wondering whether not converting in these instances might cause some user confusion down the line?

[mark_h]

Conversion cache is still acting strange.

I converted 1285 files.  I analysed them all and they are all correct.  Yay!

But only 565 files ended up in the cache...?

Every song is unique, no duplicates in the smartlist I use...

[Hendrik]

You didn't run out of space, did you?
I don't actually know if it has like a max cache limit or something and then starts clearing out older files or something, but on a quick glance I didn't find anything of that sort.

[mark_h]

11TB free space...

Will mess about some more when I get home. 

[mark_h]

Doing a large conversion now while watching the temp and conversion cache.

All the files appear in the temp folder, during conversion, but many of them never make it to the conversion cache afterwards...

Temp is on an SSD
Cache is on my NAS

Conversion is: Specified Output Format: MP3
DSP: Output Format (highres downsampled to redbook for iPod compatibility), Volume Level, DSP

[mark_h]

3199 files of 7556 ended up cached...

No biggie really, as the main problem is solved, but it might be something to look at some time.

Anyway, huge thanks for working through the conversion problem - it's a "life changer" for handheld users