I’m sure that the answers to my two questions have already been given but I can’t find them, so please bear with me!
Roon’s volume levelling knowledge base entry states that the target volume level is -23 LUFS. I gather that, at some stage, the option to change this was introduced. Why is the default set at -14 LUFS?
Should I set my target volume level so as to ensure that volume levelling never gives a positive adjustment? I’m currently using the default -14 (set to album) but, very occasionally, this does give a positive adjustment. Should I set it to -16 LUFS?
In addition to using volume levelling, I also use my DAC remote as a hardware volume control when listening on headphones (I’m too lazy to get up and use the amp pot). The DAC tends to sit at around -4 to -6 dB
LUFS came from the broadcast industry - where -23 dB LUFS was set as the standard.
So the measurement is done to that standard.
The norm for music has been -14 dB LUFS - which is what some streaming services used.
The latest AES recommendations are to use -16 dB LUFS - and album normalisation. In trials they found that people preferred album normalisation (even when not listening to albums). I think it keeps the mastering engineer’s / composer’s dynamics between tracks.
I’m currently using -16 dB LUFS with album normalisation and I’m finding it works pretty well.
If you want (a lot) more detail the latest AES paper is here: https://www.aes.org/technical/documentDownloads.cfm?docID=731
I’m surprised you’re seeing much in the way of upward adjustments - I’d guess that will mostly be in classical music or perhaps in some rare high res masters where they have left the full dynamics. I’m just listening to a very quiet Vaughn Williams song - and I see it’s normalising to -0.4 dB to -16 dB LUFS - so that would have been an upward adjustment at -14 dB LUFS. Interesting there is a 4 dB difference between this track and the album normalisation - so track normalisation would have badly messed up this track!
You don’t need to worry about upward adjustments causing clipping because roon checks the true peak figure before it adjusts, and so won’t clip. More detail here:https://help.roonlabs.com/portal/en/kb/articles/volume-leveling#Enabling_Volume_Leveling
However positive adjustments / the need to avoid clipping might slightly mess up the smoothness of the volume levelling.
I’d say give the AES recommendations a try and see what you think.
With 24 bit and 32 bit DACs - and such great dynamic range in modern DACs - I’ve also started being lazy and using roon DSP for volume adjustment - I don’t think I can hear any problems!
Thank you for the detailed answer.
The upward adjustment when using -14 LUFS is rare and small! I think that the most I’ve ever had is +1.3 dB. On the basis of this I think I’ll follow your suggestion of setting target volume level at -16 LUPS.
I’ve observed some clipping when playing DSD tracks with volume leveling enabled, even at -16LUFS and when the signal path shows 0 dB or less in adjustments. Not sure why this is…perhaps the Delta-Sigma modulator requires a few dB of headroom to do its work…
Great answers, @GregD . Thanks for sharing.
Interesting about DSD. I think volume adjustments need a DSD to pcm conversion and back again.
Don’t know how roon does this, esp as the true peak calculation needs to be done after the whole file is converted. I don’t have any DSD files to test (only DXD).
It looks like they didn’t used to do Volume levelling on DSD files, but this may be old. DSD to PCM and Volume Leveling - #2 by brian
Yeah, that’s a little old. Here’s an update on how Roon handles DSP with DSD content: Native DSD processing - #2 by brian
Edit: I’ve read this six times, but don’t ask me to explain it. LOL.
Loudness is calculated per file/per album. I cannot offhand remember the algorithm, but basically it is continuous over the file and aggregated for an album I think. This is what is done at the import/scanning stage I expect, or provide from the streaming service in metadata.
True peak is (I believe) calculated through a relatively simple continuous process roughly as follows: make some calculation headroom (12dB reduction, or sample value /4), oversample (4x I think), apply band limiting low pass filter and use the resulting absolute sample value as your true peaks with the initial attenuation value multiplied (x4 sample value, or added to the dB value). It is the output of the band limiting filter that can yield high intermediate sample values and thus trigger the clip light despite that original samples may have been limited well below 0dBFS.
If using floating point as will be likely (64 bit double), then the initial headroom adjustment could be skipped along with the post correction as there is effectively near infinite headroom in the floating point calculations.
(My memory of this is ancient and maybe IBU-R 128.2 has updated/replaced this method as it may be from the old K-System metering days.)
Yes - even when you know how 1 bit DS works, then I think this explanation glosses over the complexity which if provided might actually help it all to make more sense. To be fair, the bit that seem glossed over are where I expect the real inventiveness was applied that enable the rest of it to work and thus are not something that is ever likely to be discussed beyond need to know within the dev team… (I think I can guess exactly what they are doing and what assumptions they are making about the limits of their DSP to enable it to work in this manner, but I have not mathematically verified the plausibility of my guess if that makes sense)
Thanks guys. This is really interesting - thanks
Gven my lack of knowledge of DSD processing I’d going to go away and study more!
Yeah. All I know is that I’m able to use Roon’s convolution engine to run my 65k tap room correction filter with DSD64 files. My little 7th gen i5 NUC just barely manages to keep up since Roon has to upsample the filters to 4,205k taps to apply them. But, sound and measurements are both great.
No apparent conversion to PCM, though I could force that if I wished.
Regardless of whether the target is -14 LUFS or -16 LUFS or -24 LUFS, the leveling corrections that roon applies are wrong so I wouldn’t fret about this too much until roonlabs fixes this bug.
I reported it 1.5 years ago and sent them the sample tracks that they requested. In our followup PMs, @noris in technical support said he reproduced the bug and filed a ticket, but I’m not aware that it’s been fixed yet.