Scanning mono MP3 files does not yield correct results.

[DrZAjV]

First, I want to thank the developer for creating this tool, it's very useful. I noticed during use that the results obtained for mono MP3 files differ from those produced by other tools. The scan results with fb2k_with true-peak scan plugin:

The scan results with EZ CD Audio Converter:

The scan results with rsgain:

As you can see, the results from fb2k and EZ CD Audio Converter are the same, with a loudness of -26.21 LUFS. However, the result from rsgain differs by about -3 LUFS compared to the other two.

1ch.zip

[ben-nason]

I came here to say the same thing. Great tool!

I think this is due to how the algorithm measures mono signals. There is a 3 LU difference between mono measurements and stereo measurements. Since typically mono signals are played back as stereo (dual mono) signals a -3 LU offset needs to be applied to mono files.

See the "Multi-channel reproduction of single-channel content" section of this AES doc on loudness: https://www.aes.org/technical/documentDownloads.cfm?docID=731

I think the solution is to subtract 3.01 dB for mono files, per Figure 3 in the doc. Or convert the mono audio to stereo before scanning, since playback will be in stereo, and scan the stereo version which will produce the correct offset measurement.

[complexlogic]

That is an interesting case. Thanks for sharing.

Out of curiosity, I modified the code so that it force remixes all audio to 2 channels before sending to the loudness meter. Here is the existing code (v3.5.2, no remixing), using the file that @DrZAjV provided:

Track: 1ch.mp3
  Loudness:   -29.22 LUFS
  Peak:     0.253967 (-11.90 dB)
  Gain:        11.22 dB 

And here is the experimental code which remixes files to 2 channels:

Track: 1ch.mp3
  Loudness:   -29.22 LUFS
  Peak:     0.359161 (-8.89 dB)
  Gain:        11.22 dB 

So, we see the 3 LU shift in the peak value, but not loudness. I will have to do some more research later to see what should be the correct behavior in this particular case.

[ben-nason]

So here are some additional data points. It's strange that in your testing the True Peak measurement is changing by 3 dB instead of the Integrated Loudness. I measured the original mono sample file in three apps that do loudness measurement and support true peak measurement: Ocen Audio, Youlean Loudness Meter, and iZotope RX 9. And they all measure the True Peak to be -8.89 dB, same as your experimental code, but not the same as the existing code.

Converting the original mono MP3 into a stereo AIFF file and measuring it again with the three tools, the true peak measurement is unchanged, but the integrated loudness is 3 dB higher for the stereo version, which is what the AES and EBU docs say to expect.

Screenshots and sample files: 1ch_measurements.zip

[DrZAjV]

Thank you to @ben-nason and @complexlogic for sharing the information. I've gained some related knowledge, but as an end user, I feel somewhat confused. Which one is actually correct? Or could both be correct, just applicable to different use cases?

Below is some information I've recently come across, which I hope will be useful for the professionals here: This is the scan result from Adobe Audition CC 2018.

The result is similar to rsgain, as shown in the image below: ITU-R BS.1770-3 Loudness: -29.25 LUFS.

It is said that： When fb2k scans a mono file, it treats it as stereo.

Default mode of operation in fb2k is to play audio with the exact channel mapping it contains. Nothing is upmixed unless the user asks for it. fb2k plays mono as mono on center channel. You can enable "Convert mono to stereo" DSP to play it on two front speakers instead.

[DrZAjV]

Based on the previous content, If a mono file is intended for playback on a stereo system, its EBU R128 measurement will be perceptually incorrect. It is known that the famous FFmpeg tool's loudnorm filter has a dual_mono option, providing users with a choice. The official documentation describes it as follows.

dual_mono

Treat mono input files as "dual-mono". If a mono file is intended for playback on a stereo system, its EBU R128 measurement will be perceptually incorrect. If set to true, this option will compensate for this effect. Multi-channel input files are not affected by this option. Options are true or false. Default is false.

https://ffmpeg.org/ffmpeg-filters.html#loudnorm

@complexlogic Could the author consider adding this dual_mono option to implement the corresponding functionality? Thanks.

[complexlogic]

Thanks for the information.

I looked at the source code for FFmpeg's loudnorm filter. They don't actually upmix the mono file to 2 channels as I did above. They just set a flag for the loudness meter to treat the single channel as "dual mono".

The same option exists in rsgain's loudness meter (libebur128). So I just added an option in a new feature branch that can be invoked with -d or --dual-mono to enable. The results are the same as for Foobar2000 in the first post above:

rsgain custom -d 1ch.mp3

Track: 1ch.mp3
  Loudness:   -26.21 LUFS
  Peak:     0.359161 (-8.89 dB)
  Gain:         8.21 dB 

You can download a Windows development build here. Please give it a test.

[DrZAjV]

I tested some files right away, and rsgain worked very well. The problem was resolved effectively. Once again, thank you to the developer for their hard work.

[DrZAjV]

Summary of usage scenarios based on the above theory:

To achieve a perceived loudness of -18 LUFS:

1. If the dual-mono feature is not used, for mono audio content, the loudness target should be -21.01 LUFS, rather than -18 LUFS.

2. If the dual-mono feature is enabled, regardless of whether it is stereo or mono, the loudness target should be -18 LUFS.

(Please correct me if there are any errors.)

[complexlogic]

@DrZAjV That seems right. I'm going to merge the feature into master now.