Safe listening levels and headphone voltage/power requirements

[Soundescape]

The only not so usable point is that if we connect a software meter with a streaming service it is hard to know the unormalized LUFS for each palying track as we will see the LUFS stats in the meter already normalized.

Playing the track twice is quite annoying (unormalized and then normalized).

 

[Soundescape]

I still don't understand something from the spreadsheet.

E.g. I've attached a software monitor, without loudness normalization, and I have on a track with an integrated at -13 LUFS.

I don't understand why with a target of -14 LUFS (loud normalization on) the the spreadsheet suggest to pull down the the volume knob if we compare on what it suggests with an unormalized track that is at -8 LUFS (in that case it suggests an higher volume knob)

 

[xnor]

V5 adds K-weighting for the target sound pressure. (See #17 for how this weighting filter looks like.)

The K-weighted target is set 3.6 dB higher because the equivalent continuous sound level of pink noise (10Hz-20kHz) is 3.6 dB higher when going from A- to K-weighting with the -0.691 dB offset as per BS-1770 spec. I used pink noise since it's a "good" approximation of environmental noise.

This causes another change: difference in weighted total RMS vs. loudness over different genres more than doubles when moving from A- to K-weighting.
This is because under A-weighting, differences in bass between music genres (or any kind of sound really) are underrated.


Finally, you might ask yourself why the K-weighting does not match the loudness, which uses the same K-weighting: that's because BS-1770 loudness uses an absolute (-70 LUFS) and relative (-10 LU) gate applied to 400ms windows and adds the power of both stereo channels.
In plain English: highly dynamic music (such as my "classical" sample) gets a lower loudness value.


Measuring the K-weighted total RMS value may not be so easy, but you can use the total unweighted RMS amplitude. This will be within +/- 1 dB of the actual value for most music.


edit: fixed the numbers by adding the offset
edit 2: removed the inaccurate hint of how K-weighted RMS could be derived from the A-weighted number

 

[xnor]

I still don't understand something from the spreadsheet.

E.g. I've attached a software monitor, without loudness normalization, and I have on a track with an integrated at -13 LUFS.

I don't understand why with a target of -14 LUFS (loud normalization on) the the spreadsheet suggest to pull down the the volume knob if we compare on what it suggests with an unormalized track that is at -8 LUFS (in that case it suggests an higher volume knob)

That's not the case. The -13 LUFS track will get attenuated by 1 dB. The -8 LUFS track will be attenuated by 6.
Volume knob setting will be the same if the relationship between total RMS and loudness is the same.

Let me describe it differently: music with higher RMS value contains lots of energy. Compared to music with lower RMS value, volume needs to be turned down to arrive at the same total energy.
In your example, the -13 LUFS track probably has a relatively lower RMS value (less energy) which is compensates by a higher volume setting.

 

[Soundescape]

I have in both cases always -15dB total RMS in "Modern Pop/Rock" cell.
So do you mean that this value e.g. -15db is supposed to be at a specific LUFS value filled in same section?

It is why we need to calc the difference between Loudness Target and LUFS of the unormalized track at e.g. -15dB?

 

[xnor]

I have in both cases always -15dB total RMS in "Modern Pop/Rock" cell.
So do you mean that this value e.g. -15db is supposed to be at a specific LUFS value filled in same section?

So you have two different tracks. Both have an RMS value of -15 dBFS, but one has a perceived loudness of -13 and the other one of -8 LUFS. So both tracks have the same "damaging effect" to your hearing, but one is perceived to be a lot louder.
Therefore, both tracks will require the same voltage or power to reach the target, but loudness normalization will attenuate the louder one by an extra 5 dB.
Now the louder track is 5 dB below the SPL target, so the spreadsheet will tell you that you can turn up the volume...


The moral of the story is that if you want to plug in your own numbers then you need to measure both the RMS amplitudes as well as the loudness.

Or just set the Loudness Target to "disabled", then you just need to measure the first number.

 

[Soundescape]

That is the same to measure RMS at a specific LUFS value.
But in the case the LUFS is lower then the target LUFS it will be amplified. So we need care also when the track is lower then the target LUFS value as we will have a gain with the normalization and something to subtract to the attenuation.

 

[xnor]

That is the same to measure RMS at a specific LUFS value.

Yes, if the loudness of both tracks is the same but the RMS value differs then the spreadsheet will allow an increase in volume that matches this difference.

This is the same situation as the previous example after loudness normalization.

But in the case the LUFS is lower then the target LUFS it will be amplified. So we need care also when the track is lower then the target LUFS value as we will have a gain with the normalization and something to subtract to the attenuation.

As mentioned before, the spreadsheet doesn't know anything about track peaks or headroom, so it doesn't do any boosts.
But I can add those.

 

[Soundescape]

As mentioned before, the spreadsheet doesn't know anything about track peaks or headroom, so it doesn't do any boosts.
But I can add those.

Yes this is marginal.. at the end we could also totally ignore all the LUFS and EQ attenuation if we could have a software monitor for the A-weighted RMS as we cannot statically pre-measure tracks/videos on streaming services.
But it is not easy to find one that integrates on long time interval.

 

[xnor]

I added it anyway and grouped the music parameters.
Now you can specify the track peak. If this is below the clipping point (0 dBFS) then loudness normalization can also do boosts up to that point.
There is also an option to specify extra headroom.

Yes this is marginal.. at the end we could also totally ignore all the LUFS and EQ attenuation if we could have a software monitor for A-weighted RMS as we cannot statically per-measure tracks/videos on streaming services.
But it is not easy to find one that integrates on long time interval.

I understand what you mean. I only added all the loudness normalization stuff because I thought it was neat, but it can easily be disabled by setting the loudness target to "disabled".

The music presets in the spreadsheet are only there to give readers an idea of how big the differences can be. It by no means is a comprehensive catalog of all (digital) music that is out there.

Maybe it makes more sense to create a list of specific reference tracks (from different genres, eras) instead?
If streaming services are using the same masters then the difference between services would come to differences in loudness normalization.
Analysis could be done once, offline, for these tracks. Users could then use these tracks as references to compare ot their own music library.

Ideally, no one should have to mess around with monitoring software to be able to use the spreadsheet.

 

[Soundescape]

Maybe it makes more sense to create a list of specific reference tracks (from different genres, eras) instead?
If streaming services are using the same masters then the difference between services would come to differences in loudness normalization.

Something like

Comparison of the RMS Energy and the Amplitude Envelope

We'll visualize and examine the RMS Energy and the Amplitude Envelope of different music genre tracks, using the librosa library.

www.analyticsvidhya.com

 

[xnor]

@Soundescape Hmm, I've added GTZAN data, but I'm seeing several issues with these tracks:

1) wildly varying in quality
2) mono
3) 22050 Hz sampling rate
4) no artist/album/track/release information

But it helped me show one thing: total unweighted RMS and K-weighted RMS are within +/-1 dB of each other for most (90%) music.
So if one can't measure the K-weighted RMS value then it's safer to just use the unweighted RMS value instead of adding something to the A-weighted value as I've suggested before.


Due to these issues, I think I'll remove the data again in the next version.
Here's something that makes more sense to me:
Pick at least one reference album per genre. Analyze that. People can then play the exact same album on their system to calibrate their volume levels.

Different services may use different masters so it could make sense to repeat that for every service. And it could make sense to pick a "loud" (highly dynamic range compressed) and "quiet" album in each genre. (As we saw, with proper loudness normalization differences in volume setting for the same target will be within ~2 dB, so picking the "louder" one would be the safest option.)


In the end, the user experience would be like this:
I listen to metal on Spotify, so I filter for that and copy the values of the reference album into the main sheet.
I configure my target and select a headphone. The spreadsheet tells me I need X volts and Y dB amp gain. Cool, now I know what to buy.
I configure the source and amp. Now the spreadsheet tells me that I need to set the volume to Z dB to be on target. Done.

As long as loudness normalization is engaged, all comparable music I listen to will be at roughly the same target level.

 

[Soundescape]

On a mobile phone could be hard to retrieve specs.
On a desktop setup it could be easier to add a software monitor and measure the *-weigthed RMS of your tracks after eq attenuation, LUFS normalization etc..
So you can just put 0 to the target LUFS and 0 to the attenuation and just use the *-weigthed RMS in your monitor to know your volume knob from the spreadsheet.

 

[Soundescape]

I want to also add a reference to two WHO pdfs:

https://apps.who.int/iris/rest/bitstreams/1176080/retrieve

https://apps.who.int/iris/rest/bitstreams/1176084/retrieve

 

[Soundescape]

The last version of the complete ITU-T H.870 is available at:

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.870-202203-I!!PDF-E&type=items

 

[xnor]

I've cleaned up the music presets and added "jazz" (falls between classical and modern rock/pop) and "hypercompressed metal". Actually, I did that a while ago.

The metal preset is pretty much the worst case. If you use that volume setting then you should be pretty much safe whatever you listen to.
The other extreme (and it really is since it's far away from any of the other presets) is the classical sample, which when normalized to the same loudness would allow the user to turn up the volume by an additional ~3.2 dB.

I think that's a quite helpful insight.

Except if someone has some more extreme examples, I will leave it at that for now and focus on the sensitivity/FR/EQ topic.

 

[Soundescape]

Just to note:
WHO ITU H.870 define for 80 dB(A) SPL (or 1.6 Pa2h) max 40 hours x Week

 

[xnor]

Just to note:
WHO ITU H.870 define for 80 dB(A) SPL (or 1.6 Pa2h) max 40 hours x Week

Thanks. This gave me the idea to calculate the recommended listening time in the spreadsheet.

For example, if a user sets a target of 85 dB(A) it will display:
Listening Time 1: 1h 48min (1.81h) per day
Listening Time 2: 0h 34min (0.57h) per day

Multiply by 7/5 to get numbers for a "work week" ... which might be useful to people that only listen to music at work.

 

[Soundescape]

Listening Time 2: 0h 34min (0.57h)

What is Time 2?

 

[xnor]

What is Time 2?

The recommended time for children and people with sensitive hearing.