R128GAIN: An EBU R128 compliant loudness scanner Options

[Northpack]

Researchers have compared A-weighting vs. ReplayGain vs. K-weighting for loudness estimation using a variety of source material and listeners. K-weighting may not be perfect, but it is the overall winner.

Is there a paper documenting this kind of research?

[Notat]

• Recent HA thread
• Bibliography

[pbelkner]

@pbelkner, I appreciate your posting of the lib1770 code, and have a question about the gating constants. From my reading of bs1770_stats.c, the gating overlap is set to 50% of the of the 400 ms window. However, BS.1770-2 (03/2011) specifies a gating overlap of 75%. Shouldn't the overlap be 300 msec instead of 200 msec?

Version 0.8.5 released:

Home: http://r128gain.sourceforge.net/
Download: http://sourceforge.net/projects/r128gain/files/

What's new?

• Allow choosing the BS.1770 block overlap by the parameter partition (1, 2, 3, ...). The corresponding overlap in % is (1 - 1/partition) * 100%.
• LIB1770 is updated accordingly.

Example command line with block overlap 75% (partition 4) and gate -10.0:

CODE

$ r128gain --partition=4 --gate=-10.0 ../sounds/ebu-loudness-test-setv01/
SoX successfully loaded.
FFmpeg successfully loaded.
../sounds/ebu-loudness-test-setv01
  analyzing ...
    1kHz Sine -20 LUFS-16bit.wav (1/16): -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)
    1kHz Sine -26 LUFS-16bit.wav (2/16): -26.0 LUFS, 3.0 LU (peak: 0.050508: -25.9 dBFS)
    1kHz Sine -40 LUFS-16bit.wav (3/16): -40.0 LUFS, 17.0 LU (peak: 0.010260: -39.8 dBFS)
    seq-3341-1-16bit.wav (4/16): -23.0 LUFS, -0.0 LU (peak: 0.071316: -22.9 dBFS)
    seq-3341-2-16bit.wav (5/16): -33.0 LUFS, 10.0 LU (peak: 0.023049: -32.7 dBFS)
    seq-3341-3-16bit.wav (6/16): -23.0 LUFS, 0.0 LU (peak: 0.071468: -22.9 dBFS)
    seq-3341-4-16bit.wav (7/16): -23.1 LUFS, 0.1 LU (peak: 0.070849: -23.0 dBFS)
    seq-3341-5-16bit.wav (8/16): -22.9 LUFS, -0.1 LU (peak: 0.100845: -19.9 dBFS)
    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -24.0 dBFS)
    seq-3341-7_seq-3342-5-24bit.wav (11/16): -23.0 LUFS, -0.0 LU (peak: 0.358340: -8.9 dBFS)
    seq-3341-8_seq-3342-6-24bit.wav (12/16): -23.2 LUFS, 0.2 LU (peak: 0.718297: -2.9 dBFS)
    seq-3342-1-16bit.wav (13/16): -22.6 LUFS, -0.4 LU (peak: 0.100088: -20.0 dBFS)
    seq-3342-2-16bit.wav (14/16): -16.8 LUFS, -6.2 LU (peak: 0.177971: -15.0 dBFS)
    seq-3342-3-16bit.wav (15/16): -20.0 LUFS, -3.0 LU (peak: 0.100088: -20.0 dBFS)
    seq-3342-4-16bit.wav (16/16): -24.5 LUFS, 1.5 LU (peak: 0.100073: -20.0 dBFS)
    ALBUM: -21.9 LUFS, -1.1 LU (peak: 0.718297: -2.9 dBFS)

[punkrockdude]

Is modern albums supposed to be attenuated by 20 dB using R128 compared to Replaygain (using Foobar2000 or Winamp to scan) which most often are 10-12 dB attenuation? Regards.

This post has been edited by punkrockdude: Jul 11 2011, 23:58

[pbelkner]

Is modern albums supposed to be attenuated by 20 dB using R128 compared to Replaygain (using Foobar2000 or Winamp to scan) which most often are 10-12 dB attenuation? Regards.

In practice most of them attenuated by about 15-16 dB (at least by my observation.)

[Notat]

ReplayGain uses a -14 dBFS reference level. R128 calls for a -23 dBFS reference level. All else being equal, ReplayGain playback will be 9 dB louder than playback on an R128-compliant system.

[jangk]

ReplayGain uses a -14 dBFS reference level.

Which I do not understand

Considering this file: official pink noise reference file,
and analyzing this file, I read:
Integrated EBU R128 Loudness = -23.4 LUFS
MaxTP = -22.9dBTP
Loudness RMS average = -20.0 dBFS
Max Peak = -10.87 dBFS (on a sample-peak meter)

so nothing pointing to -14 dBFS !!!???

Jean

[Notat]

You are apparently studying the original ReplayGain proposal. The file you link to is a -20 dB reference. Here's the current specification. Specifically read this. Have a look at note 9. All RG implementations are using the -14 dB reference.

Please let us know where this old information still exists. We'd like to get it corrected if possible.

[pbelkner]

You are apparently studying the original ReplayGain proposal. The file you link to is a -20 dB reference. Here's the current specification. Specifically read this. Have a look at note 9. All RG implementations are using the -14 dB reference.

Please let us know where this old information still exists. We'd like to get it corrected if possible.

BTW: The link to Replaygain on the toplevel page at http://www.hydrogenaudio.org/forums/ (left, under "Hosted Sites") should be corrected. Currently it points to http://replaygain.org/ which gives an "domain has expired" message.

[jangk]

@ Notat:

I took the information from here: http://www.hydrogenaudio.org/forums/index....aded&start=

and downloaded the wav file http://replaygain.hydrogenaudio.org/proposal/ref_pink.wav

I hope this helps to bring some light

[jangk]

I was wondering how R128GAIN calculates the album tags for gain and peak:

if there is a batch of files, does R128GAIN refer on meta-tags (reads the "album" tag) or does it refer on the folder structure?

Thank you for more information!

Jean

[pbelkner]

I was wondering how R128GAIN calculates the album tags for gain and peak:

if there is a batch of files, does R128GAIN refer on meta-tags (reads the "album" tag) or does it refer on the folder structure?

Thank you for more information!

Jean

It refers to the folder structure. All media files (tracks) found in a folder (belonging directly to the folder, i.e. not to a sub-folder) are considered to form an album.

[jangk]

Ok, thank you!

Jean

[smok3]

is there a r128gain (or replaygain) ported back/implemented in ffmpeg as well?

This post has been edited by smok3: Sep 26 2011, 00:02

[pbelkner]

is there a r128gain (or replaygain) ported back/implemented in ffmpeg as well?

As far as I understand FFmpeg it converts a set of audio and video streams (taken from one ore more input files) into one otput file. AFAIK there is no notion of processing a set of input files (an album) in parallel.

[pbelkner]

Version 0.8.7 released:

Home: http://r128gain.sourceforge.net/
Download: http://sourceforge.net/projects/r128gain/files/

What's new?

• Implemented an alternate BS.1770 statistics using a histogram as proposed in "http://lac.linuxaudio.org/2011/download/lm-pres.pdf". The histogram based statistics avoids memory overflow and appears to improve performance. The new histogram based statistics is default.
• The public API of lib1770 is changed slightly in order to allow for choosing the statistcs algorithm, either histogram or sequence.
• Provided an option to execute a command in addition to the build-in actions to be enabled via the "Format" drop down box. Via a command it is possible to alter an audio stream physically (instead of just writing tags.)
• The command's environment provides the following variables:
  
  • %PATH%: The systems's path extended by the sub-directory "r128gain".
  • %TRACK%: The complete path to the source track.
  • %NAME%: The name of the source track including the extension.
  • %BN%: The base name of the source track, i.e. excluding the extension.
  • %EXT%: The extension of the source track.
  • %DN%: The output directory.
  • %TG%: The track gain.
  • %TGDB%: The track gain in dB.
  • %TP%: The track peak.
  • %TPDB%: The track peak in dB.
  • %AG%: The album gain.
  • %AGDB%: The album gain in dB.
  • %AP%: The album peak.
  • %APDB%: The album peak in dB.

[jangk]

Hello,

getting the following error message:

1kHz Sine -20 LUFS-16bit.wav (1/1) ... 'sox' is not recognized as an internal or external command,
operable program or batch file.

what have I to consider further?

Thank you for your help!

Jean

[pbelkner]

getting the following error message:

1kHz Sine -20 LUFS-16bit.wav (1/1) ... 'sox' is not recognized as an internal or external command,
operable program or batch file.

Unfortunately I made an error in packaging the release and forgot to provide "sox.exe".

You should be able to work around this by

1. downloading "sox.exe" from "http://sourceforge.net/projects/sox/files/sox/14.3.2/sox-14.3.2-win32.exe/download", and
2. copying "sox.exe" into the "r128gain" sub-folder.

Another solution should be having "sox.exe" in your systems's PATH.

Sorry for any inconvenience.

[jangk]

Adding the path to sox.exe in my System's path was helpful.

But here is another issue:

SetDlgItemURL successfully loaded.
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
1kHz Sine -20 LUFS-16bit.wav (1/1): -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)
ALBUM: -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)
writing ...
1kHz Sine -20 LUFS-16bit.wav (1/1) ... sox FAIL formats: can't open input file `E:\EBU': No such file or directory
done.
Done. Hit enter to continue ...

or

SetDlgItemURL successfully loaded.
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
aaa.wav (1/1): -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)
ALBUM: -20.0 LUFS, -3.0 LU (peak: 0.100733: -19.9 dBFS)
writing ...
aaa.wav (1/1) ... sox FAIL formats: can't open output file `%DN%\aaa.wav': No such file or directory
done.
Done. Hit enter to continue ...

The path to the file to analyze is: E:\EBU Loudness\EBU Loudness Test Set v03 (wav) respectively E:\
and the audiofiles exist.

Thank you

Jean

[Nick.C]

I suggest that you enclose the path in double quotation marks (") as Windows doesn't deal with spaces in path names very well.

[Zao]

Nothing overly specific to Windows, of course. In my experience the UNIX world tends to be worse when it comes to not escaping spaces in command lines, as paths there typically do not contain them.

[pbelkner]

But here is another issue:

1. As already noted, you should wrap the arguments in double quotation marks ("). I will fix this in for the preset with the next release: sox "%TRACK%" "%DN%\%BN%.wav" gain %TGDB%
2. To give the variable %DN% a value you have to choose an output directory with the help of the dialog. I will introduce a respective test with the next release.

[jangk]

Thank you all for the quick replies!

Jean

[jed]

I've been talking to Peter for a while via emails and figured out it would contribute more to the community and the project if I shared my feedback here. Since the normalization standard got released to public a couple of months ago, I've been thinking about applying it to any kind of audio content including sound libraries. I'm a sound editor for Film/video games and I kept a close eye on the EBU R128 standard as a fast way to deliver sounds based on the same loudness content. From my little different tests with Peter, I noticed that R128GAIN doesn't allow more than 20 sounds in the input field. My goal is to normalize thousands of files using the command and I would love to see the application importing the content of an entire folder (including the sub-folders) or at least to select an unlimited amount of sound files from one folder.

The sound files I'm trying to normalize also contain metadata embedded withing the broadcast wav files that I entered with Soundminer ("Description", "Microphones used", "Recorder used", "Location", "Category", "Sub Category", "Comments" fields etc). I noticed that when using the command ( and batch processing the wav files), the new files created lost their metadata. This is a detail as you can back up the metadata from your original source files and re-apply it to the new ones but if this can be achieved, it would make a significant improvement for sound designers and sound editors who are not aware of that issue as I see a lot of potential in this application.

Cheers,
Jean-Edouard.

[pbelkner]

I noticed that R128GAIN doesn't allow more than 20 sounds in the input field. My goal is to normalize thousands of files

I'm able to reproduce the error and hopefully will be able to fix it.

Instead of entering all the files individually into the input field you may try just to enter the directory where all the files are located in.

BTW: For this kind of processing you should switch off "True Peak" because it is not needed and switching off "True Peak" will increase performance dramatically.