R128GAIN: An EBU R128 compliant loudness scanner Options

[klonuo]

Can there be some README file on SourceForge or in source archive itself or here on HA as how to build this tool and what it expects to find on system?

CODE

...blah...
src/lib1770/src/example1.c
src/lib1770/src/example2.c
src/lib1770/src/pp/bs1770_version.c
tar cfv rel/0.8.7/r128gain-0.8.7-src-ffmpeg.tar --transform="s,^,r128gain-0.8.7/,g" tools/download/ffmpeg-export-snapshot.tar.lzma
tar: tools/download/ffmpeg-export-snapshot.tar.lzma: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
make: *** [rel] Error 2

[pbelkner]

Can there be some README file on SourceForge or in source archive itself or here on HA as how to build this tool and what it expects to find on system?

CODE

...blah...
src/lib1770/src/example1.c
src/lib1770/src/example2.c
src/lib1770/src/pp/bs1770_version.c
tar cfv rel/0.8.7/r128gain-0.8.7-src-ffmpeg.tar --transform="s,^,r128gain-0.8.7/,g" tools/download/ffmpeg-export-snapshot.tar.lzma
tar: tools/download/ffmpeg-export-snapshot.tar.lzma: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
make: *** [rel] Error 2

I simply don't have the time to provide more documentation as currently available.

For building R128GAIN do the following:

1. Download the source and extract it into a directory.
2. Download "r128gain-0.8.7-src-ffmpeg.tar" and extract into the same directory.
3. CD into "tools" and run "make". It should download all other needed sources.
4. CD into "src" and run make. It should create the binaries.

Please note that "make" in the toplevel directory tries to create the package for distribution. That's possibly not what you want.

[klonuo]

I was talking about simple README as you posted. Thanks

1. done
2. done (provides only download subfolder in tools folder)
3. make: *** No rule to make target `build/a52dec-0.7.4/__installed__', needed by `lib/liba52.a'. Stop.

?

[pbelkner]

I was talking about simple README as you posted. Thanks

1. done
2. done (provides only download subfolder in tools folder)
3. make: *** No rule to make target `build/a52dec-0.7.4/__installed__', needed by `lib/liba52.a'. Stop.

?

Unfortunately the Makefile's download section is lost for whatever reason.

In an hour or two I will upload a new version.

[pbelkner]

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

This should mostly be fixed. I'm not certain whether 1000 and more files are possible, but indeed much more then 20.

To process a directory it should be preferred to enter the directory to the input list rather than the individual files.

Version 0.8.8 released:

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

What's new?

• Implemented some GUI synchronization with respect to the "command" feature.
• Wrapped arguments in the "command" preset with double quotation marks (").
• Extended number of lines in input list.
• Distribute limited versions of "sox.exe" and "ffmpeg.exe" for usage whithin the "command".

[klonuo]

3. make: *** No rule to make target `build/a52dec-0.7.4/__installed__', needed by `lib/liba52.a'. Stop.

CODE

...
touch build/a52dec-0.7.4/__installed__
echo "EXPORTS" > lib/liba52.def
nm lib/liba52.a|sed -n "s/.* \(D\|R\|B\) _\(.*\)/\2 DATA/p" >> lib/liba52.def
nm lib/liba52.a|sed -n "s/.* T _//p" >> lib/liba52.def
mkdir -p bin
gcc -shared -o bin/liba52.dll -Wl,--out-implib,lib/liba52.dll.a lib/liba52.def lib/liba52.a  
/usr/bin/ld: unrecognized option '--out-implib'
/usr/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
make: *** [bin/liba52.dll] Error 1
rm lib/liba52.def

I thought I should ignore this error and go to 'src' but that wasn't good idea
Is this tested on Linux?

[pbelkner]

Is this tested on Linux?

No. The errors you are running in now are coming from trying to build a *Windows* DLL.

[klonuo]

Could you articulate a bit more why your suggestions from #302 does not do what they should?
Is your experimental project reasonably public, in a sense that user does not need to browse through foreign makefiles to figure what author wanted to do?

This post has been edited by klonuo: Oct 9 2011, 03:54

[pbelkner]

Could you articulate a bit more why your suggestions from #302 does not do what they should?

I've written the tool for Windows, hence the build process is Windows specific, DEF files and DLLs are highly Windows specific. The option you had trouble with is a Windows specific GCC option for building DLLs for Windows.

Maybe some day I port the tool to Linux.

Is your experimental project reasonably public, in a sense that user does not need to browse through foreign makefiles to figure what author wanted to do?

The user don't need to browse through the makefiles because I provide the binaries. The makefiles are provided because it's open source.

[klonuo]

I don't understand your replies.

From my first post log #301 it's clear that I'm on Linux. Then you replied with walk-through for building it on Linux (also alluding about building packages). And then you say it's not for Linux and maybe some day you'll port it!?
Examples in your first post #1 in this thread have "/" as folder separator, then couple of subsequent examples showing processing are from Linux terminal (obvious prompt)

I wanted command line RG scanner (not necessarily R128), but now it seems easier to me to wrap a script around available xxxgain scanners than understand with you

This post has been edited by klonuo: Oct 9 2011, 06:59

[pbelkner]

I don't understand your replies.

From my first post log #301 it's clear that I'm on Linux.

Please point me to where you are talking about Linux:

Can there be some README file on SourceForge or in source archive itself or here on HA as how to build this tool and what it expects to find on system?

CODE

...blah...
src/lib1770/src/example1.c
src/lib1770/src/example2.c
src/lib1770/src/pp/bs1770_version.c
tar cfv rel/0.8.7/r128gain-0.8.7-src-ffmpeg.tar --transform="s,^,r128gain-0.8.7/,g" tools/download/ffmpeg-export-snapshot.tar.lzma
tar: tools/download/ffmpeg-export-snapshot.tar.lzma: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
make: *** [rel] Error 2

Then you replied with walk-through for building it on Linux (also alluding about building packages).

Please point me to where I was talking about Linux:

I simply don't have the time to provide more documentation as currently available.

For building R128GAIN do the following:

1. Download the source and extract it into a directory.
2. Download "r128gain-0.8.7-src-ffmpeg.tar" and extract into the same directory.
3. CD into "tools" and run "make". It should download all other needed sources.
4. CD into "src" and run make. It should create the binaries.

Please note that "make" in the toplevel directory tries to create the package for distribution. That's possibly not what you want.

And then you say it's not for Linux and maybe some day you'll port it!?
Examples in your first post #1 in this thread have "/" as folder separator, then couple of subsequent examples showing processing are from Linux terminal (obvious prompt)

Possibly you've never heard about the MSys/MinGW build environment for Windows (http://www.mingw.org/wiki/MSYS). It gives exactly the same appearance as a Unix shell, and that's exactly the build environment used for R128GAIN.

I wanted command line RG scanner (not necessarily R128), but now it seems easier to me to wrap a script around available xxxgain scanners than understand with you

Just do what you like.

PLONK

[klonuo]

Yeah right, that's because I use Cygwin and build Linux packages with it
Just enjoy your champagne, my mistake

[Zao]

From my first post log #301 it's clear that I'm on Linux.

There is nothing linux-specific about your command line session there. It could be anything from AIX to Interix and beyond, especially as you don't even have a prompt showing.

Then you replied with walk-through for building it on Linux (also alluding about building packages).

The words "package" and "distribution" have many fine meanings, the latter being both a noun for "a flavor of OSS OS deployment" and a verb for "deployment to users".
I'd recommend you to stop seeing everything with your Linux goggles and realizing that there's a big world out there. The year of Linux has not come yet, and will not come for a long while.

Examples in your first post #1 in this thread have "/" as folder separator, then couple of subsequent examples showing processing are from Linux terminal (obvious prompt)

Yet again, assuming Linux just because a "/" appears is quite amusing. Not to mention, you don't even have any prompt in your dump.

[klonuo]

OK man I got it, but using strictly FOSS to develop Windows application is something special, without bothering to drop a line about it

All those things I mention and logs itself, allude on *nix and have nothing to do with Windows unless run under emulation. If I'd used some exotic system, I'd mention it in my post as I'd expect to see MinGW mentioned somewhere with even single line including SF or source archive, apart expecting INSTALL for anything non canonical

Doesn't idea of Windows binary and Linux build source seem appropriate while you see freely showing examples from msys prompt?
Then who would want to build this on Windows under *nix emulator and at the same time ask how to build it, when batteries are provided?

I'd recommend you to stop seeing everything with your Linux goggles and realizing that there's a big world out there. The year of Linux has not come yet, and will not come for a long while.

Thanks for your revelation, but I see it as subjective rant if you don't assume some role model
I switched from Windows some months ago and for what I need and use it it's right on time

This post has been edited by klonuo: Oct 9 2011, 16:48

[Zao]

Let's not derail this thread any more, but do note that there's a lot of different UNIXy and BSDy OSes out there, and you GNU and Linux people are quite annoying when you assume the world circles around you.

[klonuo]

Now what's the point of you closing post?
I'm not GNU or Linux person. As I just told you, I switched from Windows some months ago for my reasons, and I don't think OS I'm currently using possesses me under that etiquette

OTOH I see you appear in court anywhere someone mentions Linux and Windows together, which only makes your posts OT and please don't drag me in it with further replies

[Zao]

"Appear in court?" It helps communication if you refrain from using obscure cultural idioms.
In any way, I can post wherever I wish, and in this thread, I tried to clear up the situation and inform of the plethora of environments out there. If there's anyone hostile here, it's you demanding that a product that has always been for a particular platform for the first place should have explicit instructions on what platforms it does not target.

For the sake of the thread and product, I'll leave this alone, but you don't seem to let me.

This post has been edited by Zao: Oct 9 2011, 18:08

[jed]

I'm getting a few errors when processing hundreds of sounds.
ie: sound.wav (293/323) ... sox FAIL gain: parameter 'fixed_gain' must be between -1.#INF and 1.#INF
When listening to the processed sounds, it seems some of them haven't been gained, and those ones are still very loud compared to the others. I also have to mention that most of those sounds are pretty short. Could R128GAIN handle samples shorter than 1sec?
Thanks, jed.

Screenshot:
http://twitpic.com/6yvi2g

[Nick.C]

Don't know if this is totally relevant, but when working on lossyWAV, specifically on processing and creating correction files, the new replaygain context menu in foobar2000 (R128 based) fails to tag some of the correction files with appropriate gain data. My guess is that the signal is too low and no valid gain value is calculated. The correction files are definitely not silence.

[pbelkner]

I'm getting a few errors when processing hundreds of sounds.
ie: sound.wav (293/323) ... sox FAIL gain: parameter 'fixed_gain' must be between -1.#INF and 1.#INF

Most likely this is indeed an R128GAIN error. Could you please upload such a sample somewhere in order that I'm able to reproduce the error?

When listening to the processed sounds, it seems some of them haven't been gained, and those ones are still very loud compared to the others.

As it seems in these cases R128GAIN is unable to calculate a gain and hence doesn't provide a gain to the SoX command line.

I also have to mention that most of those sounds are pretty short. Could R128GAIN handle samples shorter than 1sec?

How short are these sounds? Of how many samples they consist? You should have in mind that there is a minum number of samples required due to the 400ms blocks, and at least one such block has to be processed.

Maybe you can process the failed sounds by hand:

1. Concatenate such a sound a few times to itself.
2. Calculate the gain for the concatenated sound.
3. Apply the gain obtained this way by hand to the original sound.

If it works I may consider to implement this workaround in R128GAIN.

[pbelkner]

Don't know if this is totally relevant, but when working on lossyWAV, specifically on processing and creating correction files, the new replaygain context menu in foobar2000 (R128 based) fails to tag some of the correction files with appropriate gain data. My guess is that the signal is too low and no valid gain value is calculated. The correction files are definitely not silence.

It sounds very similar to the error reported by jed w.r.t. R128GAIN. You should consider raising the question

• at the R128Scan thread, or
• at the libebur128 thread because R128Scan is based on libebur128, i.e. not on R128GAIN.

[pbelkner]

I'm getting a few errors when processing hundreds of sounds.
ie: sound.wav (293/323) ... sox FAIL gain: parameter 'fixed_gain' must be between -1.#INF and 1.#INF

The new version should fix that in defaulting the loudness of sounds having to less samples for being properly processed to -23 LUFS.

Version 0.9 released:

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

What's new?

• Set default gate to -10.0 LUFS and default block overlap to 75% (according to the latest EBU R128 and BS.1770-2 specifications.)
• Avoid division by zero in LIB1770 (by defaulting to e.g. -23 LUFS, implies a slight API change.)
• Further improved GUI synchronization.

[pbelkner]

Version 0.9.1 released:

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

What's new?

• Provided more environment variables for the command option:
  
  • %RATE%: The sample rate.
  • %NCH%: The number of channels.
  • %BITS%: The bit depth.
• Added more presets for the command option:
  
  • Physically apply the track gain using SoX (default):
    

    sox "%TRACK%" "%DN%\%BN%.wav" gain %TGDB%

  • Convert to MP3 and physically apply the track gain using lame (very useful for creating MP3s to be used with your mobile MP3 player, requires "lame.exe" to be copied into the subfolder "r128gain"):
    

    lame --noreplaygain --scale %TG% -V2 "%TRACK%" "%DN%\%BN%.mp3"

  • Decode using SoX and convert to MP3 by physically applying the track gain using lame (very useful for creating MP3s to be used with your mobile MP3 player, requires "lame.exe" to be copied into the subfolder "r128gain"):
    

    sox --no-dither "%TRACK%" -t raw - | lame --noreplaygain --scale %TG% -r --bitwidth %BITS% -s %RATE% -V2 - "%DN%\%BN%.mp3"

• Fixed a glitch regarding switching between the "command" and other output modes.

[pbelkner]

Version 0.9.2 released:

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

What's new?

• LINUX SUPPORT added:
  • The Linux version is build in a VMware Player 4.0.1 running Debian 6.0.3.
  • The VMware Player is set up following the instructions found here using a Debian 6.0.3 small CD image.
  • Currently CLI only.
• Completly restructured build process.

[gb24]

Please forgive me if I missed it, but is there a command line environment variable provided for the actual LUFS value, e.g., %LUFS%?

Thank you.

This post has been edited by gb24: Jan 5 2012, 03:13