R128GAIN: An EBU R128 compliant loudness scanner Options

[rojgreen]

also, (again, newbie question) can I pass the full -sox comand line to the program (through windows .bat file or shortcut)? I tried --command=sox "%TRACK%" "%DN%\%BN%.wav" gain "%TGDB%" but all thouse quotes seem to confuse the .bat file
You should surround it by quotes, i.e. either

'--command=sox "%TRACK%" "%DN%\%BN%.wav" gain "%TGDB%"'

or

"--command=sox '%TRACK%' '%DN%\%BN%.wav' gain '%TGDB%'"

Thanks mate, I'm going to sound like an idiot, but I tried a few variations of quotes swapping in my .bat file but I couldn't get it to pass the variables to the sox command.

My .bat file is:

"C:\Users\Roj\Desktop\r128gain-0.9.6-3\r128gain.exe" "--preamp=-1.0" "--command=sox '%TRACK%' '%DN%\%BN%.wav' gain '%TGDB%'" %1 -o convertedto-24db
pause

but my resulting dos cmd window is:


C:\Users\Roj\Desktop\out>"C:\Users\Roj\Desktop\r128gain-0.9.6-3\r128gain.exe" "
--preamp=-1.0" "--command=sox '' '\.wav' gain ''" C:\Users\Roj\Desktop\out\testf
ile.wav -o convertedto-24db
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
testfile.wav (1/1): -13.9 LUFS, -10.1 LU (peak: 0.923443: -0.7 dBFS, range: 4.
3 LU)
ALBUM: -13.9 LUFS, -10.1 LU (peak: 0.923443: -0.7 dBFS, range: 4.3 LU)
writing ...
testfile.wav (1/1) ... sox FAIL formats: can't open input file `''': No such f
ile or directory
done.

C:\Users\Roj\Desktop\out>pause
Press any key to continue . . .

It creates the convertedto-24 directory and then fails before writing.
I'm sure I am being thick but what did I do wrong?
I can get the command to work in the win32 gui (without the preamp option) but not with the bat file.

Thanks for any insight.

Roj.

This post has been edited by rojgreen: Mar 29 2012, 22:45

[rojgreen]

Managed to get

"C:\Users\Roj\Desktop\r128gain-0.9.6-3\r128gain.exe" --preamp=-1.0 --command="sox %%TRACK%% %%DN%%\%%BN%%-24db.wav gain %%TGDB%%" %1 -o convertedto-24db


working for files with no spaces in their filenames, but bombs when long filenames are used for example "test file - Copy.wav"

Thanks again for any insights - bat files are not my speciality!

[rojgreen]

Managed to get

"C:\Users\Roj\Desktop\r128gain-0.9.6-3\r128gain.exe" --preamp=-1.0 --command="sox %%TRACK%% %%DN%%\%%BN%%-24db.wav gain %%TGDB%%" %1 -o convertedto-24db


working for files with no spaces in their filenames, but bombs when long filenames are used for example "test file - Copy.wav"

Thanks again for any insights - bat files are not my speciality!

SO, after fiddling a bit here is my clumsy first draft at a workaround for windows batch processing multiple files with spaces in them (our scenario)

:loop
set FILENAME="%~n1"
set NEWFILENAME=%FILENAME: =_%
rename %1 %NEWFILENAME%

"C:\Users\Roj\Desktop\r128gain-0.9.6-3\r128gain.exe" --preamp=-1.0 --command="sox %%TRACK%% %%DN%%\%%BN%%-24db.wav gain %%TGDB%%" %NEWFILENAME% -o convertedto-24db
rename %~p1%NEWFILENAME% %FILENAME%.wav

shift /1

if not "%~1"=="" goto loop
pause


Any other suggestions, let me know.

[pbelkner]

Any other suggestions, let me know.

I'd like to resort to your first approach figuring out how to escape DOS special symbols from the command option if used from inside a BAT script:

• As you've already noticed, each occurrence of "%" has to be substituted by "%%".
• Secondly, double quotes (") have to be preceded by a backslash (\). Substituting them by single quotes (') does not work, as you've already figured out.

The following script "r.bat" seems to do the job:

CODE

@echo off
r128gain --preamp=-1.0 "--command=sox \"%%TRACK%%\" \"%%DN%%\%%BN%%-24db.wav\" gain %%TGDB%%" %1 -o "H:\tmp\Folder with Space in Name\Output Subfolder with Space in Name"

Following is a test session (please note that the argument to the script is surrounded by double quotes):

CODE

H:\>r "H:\tmp\Folder with Space in Name\Input Subfolder with Space in Name\*"
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
  01 Track 1 with Space in Name.flac (1/8): -12.7 LUFS, -11.3 LU (peak: 0.956400: -0.4 dBFS, range: 2.6 LU)
  02 Track 2 with Space in Name.flac (2/8): -12.7 LUFS, -11.3 LU (peak: 0.867426: -1.2 dBFS, range: 2.9 LU)
  03 Track 3 with Space in Name.flac (3/8): -13.4 LUFS, -10.6 LU (peak: 0.987564: -0.1 dBFS, range: 6.5 LU)
  04 Track 4 with Space in Name.flac (4/8): -12.7 LUFS, -11.3 LU (peak: 0.987406: -0.1 dBFS, range: 2.3 LU)
  05 Track 5 with Space in Name.flac (5/8): -12.7 LUFS, -11.3 LU (peak: 0.919231: -0.7 dBFS, range: 2.3 LU)
  06 Track 6 with Space in Name.flac (6/8): -12.5 LUFS, -11.5 LU (peak: 0.829128: -1.6 dBFS, range: 3.6 LU)
  07 Track 7 with Space in Name.flac (7/8): -13.0 LUFS, -11.0 LU (peak: 0.976282: -0.2 dBFS, range: 4.2 LU)
  08 Track 8 with Space in Name.flac (8/8): -14.5 LUFS, -9.5 LU (peak: 0.899243: -0.9 dBFS, range: 3.1 LU)
  ALBUM: -12.9 LUFS, -11.1 LU (peak: 0.987564: -0.1 dBFS, range: 3.8 LU)
writing ...
  01 Track 1 with Space in Name.flac (1/8) ... done.
  02 Track 2 with Space in Name.flac (2/8) ... done.
  03 Track 3 with Space in Name.flac (3/8) ... done.
  04 Track 4 with Space in Name.flac (4/8) ... done.
  05 Track 5 with Space in Name.flac (5/8) ... done.
  06 Track 6 with Space in Name.flac (6/8) ... done.
  07 Track 7 with Space in Name.flac (7/8) ... done.
  08 Track 8 with Space in Name.flac (8/8) ... done.

H:\>dir "H:\tmp\Folder with Space in Name\Output Subfolder with Space in Name"
Datenträger in Laufwerk H: ist DATA
Volumeseriennummer: B4EC-4972

Verzeichnis von H:\tmp\Folder with Space in Name\Output Subfolder with Space in Name

31.03.2012  08:52    <DIR>          .
31.03.2012  08:52    <DIR>          ..
31.03.2012  08:51        38.984.444 01 Track 1 with Space in Name-24db.wav
31.03.2012  08:51        40.007.564 02 Track 2 with Space in Name-24db.wav
31.03.2012  08:51        47.204.684 03 Track 3 with Space in Name-24db.wav
31.03.2012  08:51        74.810.108 04 Track 4 with Space in Name-24db.wav
31.03.2012  08:51        47.282.300 05 Track 5 with Space in Name-24db.wav
31.03.2012  08:51        44.563.388 06 Track 6 with Space in Name-24db.wav
31.03.2012  08:52        53.362.220 07 Track 7 with Space in Name-24db.wav
31.03.2012  08:52        33.897.068 08 Track 8 with Space in Name-24db.wav
               8 Datei(en),    380.111.776 Bytes
               2 Verzeichnis(se), 206.937.473.024 Bytes frei

H:\>_

Edit: If you throw away true peak and loudness range anyway, you should consider using the "--fast" option.

This post has been edited by pbelkner: Mar 31 2012, 08:22

[rojgreen]

r128gain --preamp=-1.0 "--command=sox \"%%TRACK%%\" \"%%DN%%\%%BN%%-24db.wav\" gain %%TGDB%%" %1 -o "H:\tmp\Folder with Space in Name\Output Subfolder with Space in Name"[/code]

Edit: If you throw away true peak and loudness range anyway, you should consider using the "--fast" option.
[/quote]


Brilliant - Thanks for all your effort. It seems to work, I will test at work soon.

[audioworld]

Hello to this active community,
and millions of thanks to Mr. Belkner for his efforts with this project, most appreciated.

I understand r128gain is using RG parameters as the Output, and I was wondering if it would be possible to use BWF (Broadcast Wave Format) Tags alternatively. I know there is a BWF "Loudness" Chunk standardisation underway currently, and all the broadcasters are using BWF anyway (and not mp3 or FLAC). We use BWF (and RF64 for multichannel files >2GB) for all our mpeg1LayerII and linear files, and this tool could be a tremendous help for many applications across a broadcast workflow (analysis/corrected on playout/corrected in the file directly)

Thank you for your consideration,
karl.

[pbelkner]

millions of thanks to Mr. Belkner for his efforts with this project, most appreciated.

Thank you

would be possible to use BWF (Broadcast Wave Format) Tags alternatively.

Could you please link me to a respective standard?

[audioworld]

Sure, and I just see that TR 3285-2 is already published an not a draft any more:
BWF Metadata Specifications
please see pages 10-12ff.

And I also found something quite exciting while googling around right now:
BWF Metadata Editor
BWF Meta Edit Sourcforge Page
This command line or even GUI interface allows one to read out and/or edit BWF Broadcast Chunk Data!

best regards, karl.

This post has been edited by audioworld: Apr 4 2012, 23:19

[pbelkner]

I was wondering if it would be possible to use BWF (Broadcast Wave Format) Tags alternatively.

Version 0.9.7 released:

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

What's new?

• Added an option to the command line (--tags=[rg|bwf]) and the GUI (drop down box) for letting R128GAIN write BWF tags instead of ReplayGain tags. The following BWF tags are currently supported (depending on the format they may appear converted to upper case):
  
  • LoudnessValue
  • LoudnessRange
  • MaxTruePeakLevel

We use BWF (and RF64 for multichannel files >2GB) for all our mpeg1LayerII and linear files, and this tool could be a tremendous help for many applications across a broadcast workflow (analysis/corrected on playout/corrected in the file directly)

Please note that whether the BWF format itself is supported or not depends on whether FFmpeg or SoX, respectively, is supporting it.

[audioworld]

OMG Mr. Belkner you are incredible!!!

I do not want to think about how long it would have taken a commercial software company to implement BWF loudness Tags, and you are able to pull this off within 24 hours as a "side project"!!! Congratulations and thank you so much!

As the chairman from the EBU R128 working group is a good friend and colleague of mine, I will communicate your efforts to this EBU group and additionally to all the public broadcasters in germany which are currently searching for tools to implement R128. I know that you are doing this in your free time and really hope there are some broadcasters placing commercial orders for further adaptions and integrations with you, to give you some kind of compensation for everything you are doing for the R128 loudness standard.

Thanks and respect, karl.

PS: a small observation in the dropdown-box for the output metadata format: It should read "BWF" and not "BFW"

This post has been edited by audioworld: Apr 6 2012, 21:42

[pbelkner]

PS: a small observation in the dropdown-box for the output metadata format: It should read "BWF" and not "BFW"

I've uploaded a corrected version: http://sourceforge.net/projects/r128gain/files/.

[jangk]

OMG Mr. Belkner you are incredible!!!

I do not want to think about how long it would have taken a commercial software company to implement BWF loudness Tags, and you are able to pull this off within 24 hours as a "side project"!!! Congratulations and thank you so much!

As the chairman from the EBU R128 working group is a good friend and colleague of mine, I will communicate your efforts to this EBU group and additionally to all the public broadcasters in germany which are currently searching for tools to implement R128. I know that you are doing this in your free time and really hope there are some broadcasters placing commercial orders for further adaptions and integrations with you, to give you some kind of compensation for everything you are doing for the R128 loudness standard.

Thanks and respect, karl.

Nothing more to add, except: thumbs up for pbelkner

Best regards
Jean

[TZOTZIOY]

I'm interested in trying R128 volume for my lossless collection (ripped CDs, stereo @ 44100 Hz). However, I want to discover the reported "gain" and "range" values for each track, not a copy of the file with some tags applied. So I need some help here. This post is mostly directed to pbelkner and since it was written in a hurry, it's dense and probably incomprehensible; I'll gladly explain everything if asked to.

LIBRARY BUILDING RELATED
I work on an Ubuntu 11.10 64-bit environment. I downloaded lib1770-0.6-src.tar.gz . Trying to compile it (the source has a little bit unusual structure for me), I got errors on linking because the source files were not compiled with PIC (position independent code). I edited src/lib1770/common.mk and right below `CFLAGS+=-mfpmath=sse` I added a line `CFLAGS+=-fPIC`. `make clean; make` produced a static and a dynamic version of the library. `make install` was unhelpful (copied to some directories relative to my current directory), so I copied the .so and the .h files to the relevant /usr/local/@(lib|include) directories.

USING THE LIBRARY
Now, I would like to verify/have documentation for the correct calls to the following functions:

1. I need to create a context. A (possibly obsolete) post in this thread suggests that bs1770_ctx_open has no arguments, but bs1770_ctx.h suggests I need to provide int mode(what's that?), double gate (in what units?), double ms (I assume I'll provide 400), int partition (=4 for 75%?), double def (what's that?).

2. for every (left, right) sample of a track, bs1770_ctx_add_sample gets called with: ctx (the context created), double fs (=44100.0?), int channels (=2), bs1770_sample_t sample (basically, an array of max 5 doubles; typically I will fill the first two doubles since channels == 2; however, do I have to divide the short int sample by 32768.0 so my sample values become [-1.0,1.0) ? )

3. to get the track LRA, I call bs1770_ctx_track_lra with: ctx (context), double lower (?), double upper (?), double fs (44100.0? why use it again?), int channels

4. to get the track lufs (and implicitly prepare the context for the next track), I call bs1770_ctx_track_lufs with: ctx (context), double fs (44100.0? again?), int channels

THE GIST OF IT
So, given that I easily can get the raw samples (stereo, 44100 Hz, 16-bit samples) from my collection, what are the steps to take to calculate R128-compatible (including the gating of silence or near-silence) suggested track gain and loudness range?

NOTE
I have a mechanism already in place that prepares audio for car-listening; based on the pre-calculated RG gain values, a crude way to calculate loudness range (basically, the standard deviation of RMS values of the audio sectors/frames (1/75 sec) ) and some manually-inserted adjustments (as tags), I create .ogg files (with per-track varying dynamic compression applied) for my car-listening pleasure. RG over-attenuates tracks with too much dynamic compression, and over-amplifies mostly silent tracks. Reading about R128, I got my hopes up that my manual intervention can be reduced.

This post has been edited by TZOTZIOY: May 2 2012, 13:41

[pbelkner]

I'm interested in trying R128 volume for my lossless collection (ripped CDs, stereo @ 44100 Hz). However, I want to discover the reported "gain" and "range" values for each track, not a copy of the file with some tags applied. So I need some help here. This post is mostly directed to pbelkner and since it was written in a hurry, it's dense and probably incomprehensible; I'll gladly explain everything if asked to.

...

• The build process is not compliant with "autotools" because I'm struggling on several fronts and simply didn't found the time so far to look at "autotools".
• Currently I'm rewriting the whole program. The main goals for the rewrite are to provide UNICODE support for Windows, a GTK GUI for Linux, remove each static buffers from the program and base everything on consolidated grounds. The current state of the rewrite is that the programm itself is stable but the build process is not in a fashion I'd like to have it.
• The new build process should follow the "./configure; make && make install" pattern, at least in a restricted way. The restriction mainly is that the "configure" scripts will be "home grown", i.e. not generated by "autotools". These "configure" scripts will allow for providing "CFLAGS", "LDFLGS" and "LIBS" and will allow for "out of tree" builds. Having this done will take some more weeks.
• I should add as a goal for the new version to provide 64 bit builds (implying that the build process is tested on 64 bit.)
• If you are able to build the current version at 64 bit, there should be no problem to run just an analysis by omitting the "-o" option. The result of the analysis is written to "stdout" and can be parsed from there using e.g. "sed".
• If you like to embed "lib1770" into a program you should have a look at "example1.c" provided with the source of "lib1770".

[TZOTZIOY]

• If you like to embed "lib1770" into a program you should have a look at "example1.c" provided with the source of "lib1770".

Thank you. I did that and had success (I changed RATE to 44100, made buf into static short array multiplying each sample by 1.0/32768.0). However, I obviously get only the suggested gain, not the loudness range. I perused the source of r128gain and found the commented-out BWF_AR defines, but no other mentions. Can I assume that the loudness range functionality is not yet implemented? I'm not pressuring; I'm asking to stop looking for it if it isn't there.
Again, thank you very much for both spending time to develop r128gain/lib1770 and answering here to all of us.

[pbelkner]

• If you like to embed "lib1770" into a program you should have a look at "example1.c" provided with the source of "lib1770".

Thank you. I did that and had success (I changed RATE to 44100, made buf into static short array multiplying each sample by 1.0/32768.0). However, I obviously get only the suggested gain, not the loudness range. I perused the source of r128gain and found the commented-out BWF_AR defines, but no other mentions. Can I assume that the loudness range functionality is not yet implemented? I'm not pressuring; I'm asking to stop looking for it if it isn't there.
Again, thank you very much for both spending time to develop r128gain/lib1770 and answering here to all of us.

If you look at "exampel1.c" you'll find a symbol "LRU" defined:

• If the symbol is defined, the example program calculates the loudness range in LU.
• If the symbol is undefined, the example program calculates the (absolute) loudness in LUFS (not a gain).

[TZOTZIOY]

If you look at "exampel1.c" you'll find a symbol "LRU" defined:

• If the symbol is defined, the example program calculates the loudness range in LU.
• If the symbol is undefined, the example program calculates the (absolute) loudness in LUFS (not a gain).

That's great. So, for my very specific case, I create two contexts, one for the loudness range and one for the absolute loudness (each with the suggested values for gate, block and partition) and at the end I report both. Thank you.

[pbelkner]

I create two contexts, one for the loudness range and one for the absolute loudness (each with the suggested values for gate, block and partition) and at the end I report both.

That's exactly how it is meant.

[pbelkner]

Version 1.0-alpha-1 released:

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

What's new?

• Unicode/UTF16 support for Win32.
• GTK2 and GTK3 GUIs for Linux.
• GTK2 GUI for Win32.
• No static buffers any longer.
• 75% rewrite (BS.1770 algorithm unchanged).

Native Win32

GTK3 under Ubuntu 11.10 Linux

GTK2 under Debian 6.03 Linux

This post has been edited by pbelkner: May 18 2012, 20:11

[v0n]

Version 1.0-alpha-1 released:

First of all, thanks for doing this, and suport, I use r128gain mainly as a command line utility - and it's a great help. I use normalize to adjust volumes and r128gain to monitor the outcome and necessary adjustment.

I don't want you to misinterpret the few notes and opinions that I wrote below, I think the program is great and it's a fantastic effort, and I'm not bashing, just trying to highlight few larger problems.

I think we are jumping slightly too far ahead with new releases focusing on GUI for linux, because as is, the GUI bit would be relatively niche requirement, and meanwhile none of releases actually compile correctly under linux even as a command line utility, so introducing additional elements will just create bigger mess. As it is, r128gain fails to compile "out of the box" on just about every distro I've tried - I usually try each release on centos, gentoo and debian.

All previous versions were nearly impossible to compile on most 64 bit linux distros which most of us use these days, because source is not using -fPIC anywhere in the code. I used to bypass this by manually fixing every Makefile and common.mk and adding it to CFLAGS where ever possible, but the new version doesn't seem to use common flags anymore so even after changing CFLAGS in Makefile it still fails while linking files in lib1770. I don't know enough about compiling to fix it this time.

In new alpha 'make' won't even start if the GUI:= value is ommited in config.mak, so those of us who use server linux distros without full desktops, can't even use it.

Compilation of r128 on 32bit linuxes was usually slightly easier in general but there is still a lot to fix, bits failing all over the place with several config files failing to execute because they don't have +x permissions. The undocumented manual download of ffmpeg-export-snapshot.tar.lzma inside another randomly named tar with full paths stored plus the fact that many linuxes in "stable" tree don't have the latest tar with lzma, so extractions fail with "tar: unrecognized option `--lzma'" (as example Fedora has it, because it's "cutting edge", Centos and Redhat don't have it, because "stable" branch use old 1.5x. And so on, so forth.

Realistically, static build would probably be the best answer, but I understand it might not be possible with current resources and time you have for this development.

This post has been edited by v0n: May 24 2012, 19:14

[longnvl]

When I pass a file path with spaces and without "enclosing quotes", or a file which doesn't exist, it prints an assert and crashes.

Other than that, it seems to analyze as expected, but I have some questions after looking at the source code.

For the loudness analysis, all input files are resampled to 48 kHz, right?
For the peak finder, the files are additionally resampled to 192 kHz, right?
The way I understand R128 is:
Pass 1: analyze entire file/album, compute loudness taking into account the absolute gate of -70 LUFS.
Pass 2: analyze entire file/album again, this time also taking into account the relative loudness gate derived from the result of pass 1. Is that how you implemented it?

[pbelkner]

For the peak finder, the files are additionally resampled to 192 kHz, right?

This is true only for "true peak" mode, which is the default (cf. "r128gain_s_r128.c".) You may choose "peak off" mode or "sample peak" mode instead.

For the loudness analysis, all input files are resampled to 48 kHz, right?

That's wrong. If they where up-sampled because of "true peak" mode, they will be down-sampled to the original rate before the loudness analysis, in "peak off" and "sample peak" modes the original sample rate is used anyway (cf. "r128gain_s_r128.c".)

The way I understand R128 is:
Pass 1: analyze entire file/album, compute loudness taking into account the absolute gate of -70 LUFS.
Pass 2: analyze entire file/album again, this time also taking into account the relative loudness gate derived from the result of pass 1. Is that how you implemented it?

No. There's only one pass using a histogram (cf. "bs1170_stats_h.c", the slow two-pass implementation "bs1170_stats_s.c" is maintained only for historical reasons.) The gate of -70 LUFS is set in "bs1170_stats.c".

[dr.schanker]

Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:

'r128gain.exe hat ein Problem festgestellt und muss beendet werden.' (encountered a problem and has to be closed.)
AppName: r128gain.exe AppVer: 0.0.0.0 ModName: msvcrt.dll
ModVer: 7.0.2600.5512 Offset: 0000ee96

Example commandline:
r128gain.exe --help
r128gain.exe "C:\tmp\02.wav"

Simply running 'r128gain.exe' will start the GUI, subsequent processing works fine then. I'm using WindowsXP SP3 32bit.

Is it possible to pipe audio data to r128gain? I checked the commandline switches but couldn't find any hints.

[pbelkner]

Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:

'r128gain.exe hat ein Problem festgestellt und muss beendet werden.' (encountered a problem and has to be closed.)
AppName: r128gain.exe AppVer: 0.0.0.0 ModName: msvcrt.dll
ModVer: 7.0.2600.5512 Offset: 0000ee96

Thank you for reporting this error. I can reproduce it on my XP SP3.

The reason is that the new UNICODE enabled version uses __wgetmainargs() to convert the command line from OEM to UNICODE. Unfortunately __wgetmainargs() seems not to be available on systems with older Windows versions, as it is on my Vista.

The alternative is using CommandLineToArgvW() in conjunction with GetCommandLineW(). Unfortunately CommandLineToArgvW() doesn't expand wildcards, where R128GAIN relies on. This puts me into a dilemma ...

Is it possible to pipe audio data to r128gain? I checked the commandline switches but couldn't find any hints.

Currently not.

[pbelkner]

When I pass a file path with spaces and without "enclosing quotes", or a file which doesn't exist, it prints an assert and crashes.

Unfortunately I'm not able to reproduce this error. Could you please provide some more details, e.g. example command line, program response / error message, Windows version ...