Hello,
I am thankful for the new feature in 6.2 - R 128 normalisation. However I think it is not working correctly for mono files. They are normalised to the same (e.g. -23 dB) level as the stereo files, but when I mixdown the playlist, the parts, which are created form the mono files are +3dB louder than parts created from the stereo ones. So AFAIK the mono files should be R128 normalised to -3dB below the value for stereo files - please see http://www.producenewmedia.com/podcast-loudness-mono-vs-stereo-perception/.
I can confirm this.
In this example you see a test playlist 2* music stereo, followed by news (mono) and again 2* music stereo.
All are normalised to -23 LUFS at -1 dBTP.
All music files are normalised correctly, the news (mono) file isn’t.
You can see it in the Container Waveform:
… and the result in the Analysis of the Orban Loudness Meter:
1 Like
Hi radio7,
you are totally right: When it comes to the summing of two stereo channels, mono signals (the expert says coherent signals) will become 3 LU louder than incoherent (stereo-) signals. This is a well-known incompatibility between mono and stereo.
From the mAirList point-of-view, a solution is some tough task to fulfil – it were necessary to analyze the content of the two channels and compare them in respect of identity. (If identical --> mono.) Another way were the analysis of the degree of correlation over the audio’s length – essentially the same effort.
So what could be established relatively easy were an evaluation of a flag which says that the audio is mono and therefore shoud be normalized 3 LU lower. Fixed.
This, however, means that you had to mark every single mono file yourself before. And, not to be forgotten, @Torben incorporated this feature into both the normalisation procedure and the database.
Coherent regards
TSD
Well, for me it would be enough just to evaluate the audio file itself, if it contains one or two channels of audio, no extra flags neccessary.
It sure would be, as it is the easiest way for you to get decent results. What I wanted to figure out is that this would lead to a huge computing effort which would slow down the import speed by a factor of, say, 10 to 20 (maybe more?), with a continuous CPU load of 100%.
No word about the programming expense to be provided.
Doubtful regards
TSD
Addendum: What about audios which are partially mono …?
Not the best idea.
I know some people preparing spoken audio files as two channel files (which is still mono, as left = right) although they don’t need it. So this is not a good criterion.
What about the “false stereo” recordings like some 7" Beatles releases (some instruments recorded on the left channel, some on the right channesl, but no “real” stereo)?
I am not sure if I understand. I think to determine if an audio file is mono (1 channel) or stereo (2) is an elementary task, because this information is in its header. For my case would be enough to treat every 2 channel file as stereo (without further analyzing its audio content) and R128 normalize it to the preset (e.g. -23 dB) level, and every 1 channel file as mono, and R128 normalize it to the preset level minus 3 dB.
Unfortunately, it isn’t.
Stereo is defined as a [ger] “Laufzeitdifferenz” where one (!) signal arrives at two ore more different times at your ears (think about the car driving away).
When I speak the daily news on my DAW and use two channels, it’s still mono.
@Tondose will explain it in particular.
Yes, sure, thats clear. But in my environment this basic detection would be sufficient. At least it would help, if I could see easily in mAirList (Item Properties), if the item is 1 or 2 channel (maybe I am missing it?)
So far correct, but we are dealing with 2-channel files essentially. If you were to download The Beatles In Mono via Amazon or iTunes, you will not receive 1-channel files but 2-channel containing the same audio each – the same process as @UliNobbe pointed out. Rip a CD like, say, 20 Oldie Flops, all the monaural takes will be coded as 2-channel files likewise.
So mAirList would have to figure out again which of all these 2-channel files are containing monophonic signals.
Elaborate regards
TSD
ymmd
Well, ok, I understand your inputs, guys. I would like to discuss it further, but I am quite busy right now, perhaps I will get back to it later. (What I am dealing with on my radiostation are either “normal” stereo files (songs) or speech recordings (1 channel)).
But, anyway, what would help me at the moment: Is it possible somehow to display in mAirList the number of channels, the audiofile has? I am not able to figure it out, so when I need this information, I have to go outside mAirList, which is unpractical.
Thank you.
Here’s a discussion on the Github page of the library we’re using (ebur128) that might be interesting:
This, however, is confusing me, as I thought the 3-dB-issue is occurring with double-mono files either – see @UliNobbe’s news example. And what is this addressed EBUR128_DUAL_MONO thing?
Attenuated regards
TSD
Okay, here is the news. 
We have done a few tests and found the following:
-
A mono file based on only one track in the DAW is calculated +3 dB compared to a “normal” file.
-
A mono file on two tracks (but with the same content - track 1 doubled and panned 1=L and 2=R), which means a stereo file that is actually dual mono, is calculated correctly.
mAirList handles it as a simple stereo file.
From my understanding, this means:
mAirList has to check wether an audio file has one or two tracks. The one-track-files must be handled with -3dB.
So what type was your News example of?
Anticipating regards
TSD
The news example I used here:
…was a one-track file. It was something with the news container.
It was a download of the Deutschlandfunk Nachrichten
https://ondemand-mp3.dradio.de/file/dradio/nachrichten/nachrichten.mp3
They come as download on two tracks (@Tondose mentioned it before) and I manipulated it for the news container on one track.
We tried it as follows:
- Download original file -19,3 LUFS.
- Separated the tracks and delete one: -22,3 LUFS.
Aha!
- Double the one-track to a panned two-track: -19,3 LUFS.
So @radio7 was right:
… and I was wrong (not really, but technically):
We hear mono, but the two channels let the algorithm handle it as stereo.
There is a difference between the tech and the real acoustics.
Ahaa! 
This is the crucial Information I’ve been detained from. So my conclusions were based on this erroneous assumption.
Then the solution is simple. As you are saying, check the number of tracks and apply the 3 dB/LU corrective value.
It is rather simple arithmetics.
Solved regards
TSD
Edit: And thank you @radio7 for pointing this out.
2 Likes
Actually the library we use - GitHub - jiixyj/libebur128: A library implementing the EBU R128 loudness standard. - already has a flag for that, EBUR128_DUAL_MONO. And actually that flag was, supposedly, activated in mAirList already, but I used the wrong function to do that. So in the end this is actually just a bug in mAirList 
Already fixed it, will do some more testing, then upload as b4117 (and possible v6.2.1).
Just a summary of what this flag does, for anyone who might read this in the future:
R128 standard assumes that mono files are played on mono speakers (e.g. a single speaker). Obviously a stereo file with two identical tracks, playing on two speakers, has double the loudness (twice the number of speakers!). This is why there is a 3 LUFS (= double loudness) difference in the calculated loudness between a mono file and the expanded “stereo” version.
In our context, radio broadcast, we can safely assume that any audio material will be processed and played through stereo equipment, also files that happen to be mono. So we must handle single-channel files as if they were dual-channel (with the same samples on both channgels). This is exactly what the EBUR128_DUAL_MONO flag does; or as ebur128.h puts it:
EBUR128_DUAL_MONO, /**< a channel that is counted twice */
3 Likes
