HydrogenAudio

Hydrogenaudio Forum => General Audio => Topic started by: pbelkner on 2011-01-05 18:38:35

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-05 18:38:35
I've just uploaded on sourceforge a first version of r128gain, an EBU R128 (http://tech.ebu.ch/loudness (http://tech.ebu.ch/loudness)) compliant loudness scanner:
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]Tagging is currently supported only for FLAC:
These tags should be honored by each Replay Gain compliant media player.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-05 19:13:35
Didn't try the tool, yet, but had a look at the source. Great work!

It would be nice, if you could also include your test suite.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-05 20:32:58
Didn't try the tool, yet,

You really should do that. After all that's the only thing that counts. Currently I'm in the process to convert my whole audio collection in order to get an impression. The first results are very promising.

but had a look at the source. Great work!

Thanks 

It would be nice, if you could also include your test suite.

Here we go:

Code: [Select]
$ r128gain ../sounds/ebu-loudness-test-setv01
../sounds/ebu-loudness-test-setv01
formats: no handler for file extension `txt'
  analyzing ...
    1kHz Sine -20 LUFS-16bit.wav (1/16): -19.2 LUFS, -3.8 LU (peak: 0.100734: -10.0 dBFS)
    1kHz Sine -26 LUFS-16bit.wav (2/16): -25.2 LUFS, 2.2 LU (peak: 0.050508: -13.0 dBFS)
    1kHz Sine -40 LUFS-16bit.wav (3/16): -39.2 LUFS, 16.2 LU (peak: 0.010260: -19.9 dBFS)
formats: no handler for file extension `txt'
    seq-3341-1-16bit.wav (4/16): -22.2 LUFS, -0.8 LU (peak: 0.071316: -11.5 dBFS)
    seq-3341-2-16bit.wav (5/16): -32.2 LUFS, 9.2 LU (peak: 0.023049: -16.4 dBFS)
    seq-3341-3-16bit.wav (6/16): -26.7 LUFS, 3.7 LU (peak: 0.071468: -11.5 dBFS)
    seq-3341-4-16bit.wav (7/16): -26.8 LUFS, 3.8 LU (peak: 0.070850: -11.5 dBFS)
    seq-3341-5-16bit.wav (8/16): -22.2 LUFS, -0.8 LU (peak: 0.100845: -10.0 dBFS)
    seq-3341-6-5channels-16bit.wav (9/16): -22.3 LUFS, -0.7 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -22.9 LUFS, -0.1 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-7_seq-3342-5-24bit.wav (11/16): -21.5 LUFS, -1.5 LU (peak: 0.358341: -4.5 dBFS)
    seq-3341-8_seq-3342-6-24bit.wav (12/16): -22.8 LUFS, -0.2 LU (peak: 0.718299: -1.4 dBFS)
    seq-3342-1-16bit.wav (13/16): -21.8 LUFS, -1.2 LU (peak: 0.100089: -10.0 dBFS)
    seq-3342-2-16bit.wav (14/16): -16.0 LUFS, -7.0 LU (peak: 0.177974: -7.5 dBFS)
    seq-3342-3-16bit.wav (15/16): -22.2 LUFS, -0.8 LU (peak: 0.100089: -10.0 dBFS)
    seq-3342-4-16bit.wav (16/16): -25.9 LUFS, 2.9 LU (peak: 0.100075: -10.0 dBFS)
    ALBUM: -22.7 LUFS, -0.3 LU (peak: 0.718299: -1.4 dBFS)

Please note: Unfortunately version 0.1 had a minor glitch in interpreting the wildcard. I've just uploaded 0.2.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-05 22:23:34
Wow, thank you so much for this tool! I was already mentally preparing myself to have to write my own R128 scanner, but here it is! And in version 0.2, it already does all I need.

Having said that...

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.



Thanks again for your work!

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-05 23:46:07
Wow, thank you so much for this tool! I was already mentally preparing myself to have to write my own R128 scanner, but here it is! And in version 0.2, it already does all I need.

Thanks 

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.

The scanner is heavily based on SoX (http://sox.sourceforge.net/ (http://sox.sourceforge.net/)). This is SoX philosophy: use assert() (http://www.cplusplus.com/reference/clibrary/cassert/assert/) in production code, i.e. if a pre-condition isn't fulfilled just die.

  • 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?

48 kHz is due to BS 1770 because they define filter coefficients for that sample rate only. R-REC-BS.1770-1-200709-I!!PDF-E.pdf (http://webs.uvigo.es/servicios/biblioteca/uit/rec/BS/R-REC-BS.1770-1-200709-I!!PDF-E.pdf)states:

Quote
These filter coefficients are for a sampling rate of 48 kHz. Implementations at other sampling rates will require different coefficient values, which should be chosen to provide the same frequency response that the specified filter provides at 48 kHz. The values of these coefficients may need to be quantized due to the internal precision of the available hardware. Tests have shown that the performance of the algorithm is not sensitive to small variations in these coefficients.

It is not obvious for me how to quantize the given coefficients with respect to other sample frequencies, hence I decided to re-sample to 48 kHz

On the other hand R-REC-BS.1770-1-200709-I!!PDF-E.pdf (http://webs.uvigo.es/servicios/biblioteca/uit/rec/BS/R-REC-BS.1770-1-200709-I!!PDF-E.pdf) states regarding true peak determination:

Quote
  • Attenuate: 12.04 dB attenuation
  • 4 × over-sampling
  • Emphasis: Pre-emphasis shelving filter, zero at 14.1 kHz, pole at 20 kHz (optional)
  • DC block (optional)
  • Absolute: Absolute value
  • Max: Highest value detection (optional, included if DC block is included).

The current version of R128GAIN combines all this in order to avoid multiple passes:
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?

tech3341.pdf (http://tech.ebu.ch/webdav/site/tech/shared/tech/tech3341.pdf) states:

Quote
  • using an absolute 'silence' gating threshold at -70 LUFS for the computation of the absolute-gated loudness level, and
  • using a relative gating threshold, 8 LU below the absolute-gated loudness level, and
  • the measurement input to which the gating threshold is applied is the loudness of the400 ms gating blocks measured using an ITU-R BS.1770 method without gating, that is, summed across channels;
  • a constant overlap between consecutive gating blocks of at least 50% is required (for increased precision especially when measuring programs of short duration).

R128GAIN interprets this as follows:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Fandango on 2011-01-06 00:53:08
On a completely other note... What about patents? Is it safe to use your tool in other projects?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-06 01:37:56
Congratulations on this!

I know that BS.1770 may be used royalty free. I assume the same is true for R128 but I'll find out.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-06 02:42:42
What is the license for the tool?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: A_Man_Eating_Duck on 2011-01-06 07:14:42
i can't for the life of me get this app to just analyse and then tag, it always encodes the FLAC's again.

Code: [Select]
D:\New Downloads\r128gain-0.2.exe>r128gain.exe "d:\New Downloads\r128gain-0.2.exe\2009 - This Is War
" "d:\New Downloads\r128gain-0.2.exe\2009 - This Is War"
d:\New Downloads\r128gain-0.2.exe\2009 - This Is War
  analyzing ...
    01. Escape.flac (1/12): -13.4 LUFS, -9.6 LU (peak: 1.001484: 0.0 dBFS)
    02. Night Of The Hunter.flac (2/12): biquad: biquad clipped 4 samples; decrease volume?
-5.7 LUFS, -17.3 LU (peak: 1.138934: 0.6 dBFS)
    03. Kings And Queens.flac (3/12): biquad: biquad clipped 1 samples; decrease volume?
-6.4 LUFS, -16.6 LU (peak: 1.136147: 0.6 dBFS)
    04. This Is War.flac (4/12): biquad: biquad clipped 4 samples; decrease volume?
-7.0 LUFS, -16.0 LU (peak: 1.135694: 0.6 dBFS)
    05. 100 Suns.flac (5/12): -18.2 LUFS, -4.8 LU (peak: 0.602695: -2.2 dBFS)
    06. Hurricane.flac (6/12): -7.4 LUFS, -15.6 LU (peak: 1.061867: 0.3 dBFS)
    07. Closer To The Edge.flac (7/12): -5.3 LUFS, -17.7 LU (peak: 1.309490: 1.2 dBFS)
    08. Vox Populi.flac (8/12): -6.0 LUFS, -17.0 LU (peak: 1.083542: 0.3 dBFS)
    09. Search And Destroy.flac (9/12): -7.1 LUFS, -15.9 LU (peak: 1.085039: 0.4 dBFS)
    10. Alibi.flac (10/12): -8.9 LUFS, -14.1 LU (peak: 1.017255: 0.1 dBFS)
    11. Stranger In A Strange Land.flac (11/12): -7.2 LUFS, -15.8 LU (peak: 1.082148: 0.3 dBFS)
    12. L490.flac (12/12): -9.3 LUFS, -13.7 LU (peak: 1.010430: 0.0 dBFS)
    ALBUM: -7.2 LUFS, -15.8 LU (peak: 1.309490: 1.2 dBFS)
  encoding ...
    01. Escape.flac (1/12) ... done.
    02. Night Of The Hunter.flac (2/12) ... done.
    03. Kings And Queens.flac (3/12) ... done.
    04. This Is War.flac (4/12) ... done.
    05. 100 Suns.flac (5/12) ... done.
    06. Hurricane.flac (6/12) ... done.
    07. Closer To The Edge.flac (7/12) ... done.
    08. Vox Populi.flac (8/12) ... done.
    09. Search And Destroy.flac (9/12) ... done.
    10. Alibi.flac (10/12) ... done.
    11. Stranger In A Strange Land.flac (11/12) ... done.
    12. L490.flac (12/12) ... done.
Is there any possibility of getting proper switches implemented?
e.g.
Code: [Select]
r128gain <switch> <directory> <directory>
switch:
--a --analyse
--at --analyse-tag
--ate --analyse-tag-encode

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 08:19:16
On a completely other note... What about patents?

I'm no lawyer, but the least I can say is the following: At the time of this writing the implementation of R128GAIN is exclusively based on information publicly available from the following documents:
None of them contain any reference to a patent, especially not in their list of references.

What is the license for the tool?

Is it safe to use your tool in other projects?

It's GPLv3 (http://www.gnu.org/licenses/gpl.html (http://www.gnu.org/licenses/gpl.html))
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 08:34:23
i can't for the life of me get this app to just analyse and then tag, it always encodes the FLAC's again.

That's a restriction of this (early) version. But even if you only tag you have to overwrite the existing file. Overwriting your files is the last thing I wanna do!

Currently I'm thinking about how to preserve the encoded streams. That's especially important for lossy codecs as e.g. MP3. Hopefully FFmpeg (http://ffmpeg.org/) will offer a solution.

Is there any possibility of getting proper switches implemented?
e.g.
Code: [Select]
r128gain <switch> <directory> <directory>
switch:
--a --analyse
--at --analyse-tag
--ate --analyse-tag-encode

The command line syntax will most likely change in the future. But as already stated, overwriting your files is the last thing I consider.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-06 12:20:43
It's GPLv3 (http://www.gnu.org/licenses/gpl.html (http://www.gnu.org/licenses/gpl.html))



Any reason why? To suit "Free" software uses only? Doing so restricts other players like FB2K from using that code, even if a different implementation is made....>_>
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-06 12:22:33
On a completely other note... What about patents? Is it safe to use your tool in other projects?


No. Its not safe for non "open source" projects.

The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 12:29:55
Note that "use" in mudlord's post is about reusing code from it, not launching it as a standalone tool.

If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 12:44:57
The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.


Huh, it is a stand alone program and not a library that you link to. As long as the closed sourced players invokes it as an external helper program, there is no problem. The closed source players can even distribute it as long as the license is intact and the source code, or a link to the source, is provided.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-06 12:46:41
The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.


Huh, it is a stand alone program and not a library that you link to. As long as the closed sourced players invokes it as an external helper program, there is no problem. The closed source players can even distribute it as long as the license is intact and the source code, or a link to the source, is provided.


I'd rather a implementation of it in the host audio player rather than a outside application.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 12:47:07
Even if the end artifact is a program, this prevents anyone from lifting source code from it (with proper attribution), or preventing anyone from forking it into a library with a sane license. So the license matters, even for a standalone application.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 12:48:08
If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.


Yes, and let other people leech off your work without contributing back.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 12:52:41
Even if the end artifact is a program, this prevents anyone from lifting source code from it (with proper attribution), or preventing anyone from forking it into a library with a sane license.


What is sane to you is not sane for others..

So the license matters, even for a standalone application.


True. For me it is the GPL.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 12:52:53
If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.


Yes, and let other people leech off your work without contributing back.


Eh? Using non-copyleft licenses and being a douche are orthogonal concepts. If you want to steal code, you can just ignore licenses like Miriam and steal anything you want.
What I'm saying is that the choice of license (uninformed or informed) prevents use of part of the software in other software.
If more kinds of applications can use the code, the quality of the code improves. More software exercising the code in different ways makes it more robust. An interface that only has one client tends to be very brittle and idiosyncratic.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 12:54:34
What is sane to you is not sane for others..


Replace "sane" with "non-copyleft open source" then, as "sane" is an subjective choice of words.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 12:59:05
If more kinds of applications can use the code, the quality of the code improves. More software exercising the code in different ways makes it more robust. An interface that only has one client tends to be very brittle and idiosyncratic.


Huh, how can the quality of the code improve since the changes in the closed source program is by definition "closed"? No one outside can see them.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 13:02:25
If a developer uses a library with one of the usual non-copyleft open source licenses, he's bound by the license to make any alterations to the library available.
As such, if the library needs alterations to work in the software (may it be open source or not), the changes the developer makes will be made available (and probably contributed back in the form of patches) to the original author.
If the library works perfectly fine, all is good, both for the original author and for the developer.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-06 13:10:25
Please remember that
The scanner is heavily based on SoX
and SoX is covered by LGPL.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 13:14:56
If a developer uses a library with one of the usual non-copyleft open source licenses, he's bound by the license to make any alterations to the library available.


Really, how about BSD or MIT?

Back on topic. For a library, I will actually choose LGPL. This allows any program (open or closed) to be linked against it. However, if the library is modified (and distributed), the changed source code must be made available.


Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-01-06 13:16:49
You cannot always dynamically link to a library, and in any way the LGPL is extremely vague when it comes to class templates, function templates and data in import libraries.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 13:33:33
You cannot always dynamically link to a library,


Please give me an example where you really have to link statically.

and in any way the LGPL is extremely vague when it comes to class templates, function templates and data in import libraries.


Don't know, I don't do C++. However, if is easy enough to ask at gnu.org, if you are interested. However, the program we are discussing is pure C

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-06 14:23:08
It is not obvious for me how to quantize the given coefficients with respect to other sample frequencies, hence I decided to re-sample to 48 kHz

For 44.1 kHz, I resampled the 48-kHz filter impulse responses and tried to find new coefficients which match the given transfer function. Here is what I got:

RLB: numerator = [1 -2 1], denominator = [1 -1.9891 0.98913], accurate to ~0.02 dB above 50 Hz
Pre:  numerator = [1.535 -2.633 1.151], denominator = [1 -1.647 0.701], accurate to ~0.05 dB, will tune it a bit more soon

Quote
R128GAIN interprets this as follows:
  • the -70 LUFS is absolute, hence no second path is needed.
  • the 8 LU is relative to the 400ms gating block. R128GAIN uses a running 400ms gating block, hence 50% overlap is guarantied and no second pass is needed.

Sorry, but I don't think that's correct. Look at Tech doc 3341, Annex 1. I think the 8 LU is relative to the entire file/album (summation in equation 7, the Jg are the set of 400-ms gating blocks).

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 14:26:46
It's GPLv3 (http://www.gnu.org/licenses/gpl.html (http://www.gnu.org/licenses/gpl.html))



Any reason why? To suit "Free" software uses only?

R128GAIN is heavily based on SoX (http://sox.sourceforge.net/) (uses SoX IO, re-sampler, filters, chain architecture etc.)

IO will probably be re-implemented in order to support most of the existing codecs using FFmpeg (http://ffmpeg.org/).

Both, SoX (http://sox.sourceforge.net/) and FFmpeg (http://ffmpeg.org/), are GPLed, hence R128GAIN is "GPL infected".

Doing so restricts other players like FB2K from using that code, even if a different implementation is made....>_>

Yep.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Soap on 2011-01-06 14:53:13
Both, SoX (http://sox.sourceforge.net/) and FFmpeg (http://ffmpeg.org/), are GPLed, hence R128GAIN is "GPL infected".

ffmepg is v2.1 or later.  Is there a reason you went to v3?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 15:03:23
Quote
R128GAIN interprets this as follows:
  • the -70 LUFS is absolute, hence no second path is needed.
  • the 8 LU is relative to the 400ms gating block. R128GAIN uses a running 400ms gating block, hence 50% overlap is guarantied and no second pass is needed.

Sorry, but I don't think that's correct. Look at Tech doc 3341, Annex 1. I think the 8 LU is relative to the entire file/album (summation in equation 7).

What R128GAIN does is the following (in principle):
That's my understanding of Tech doc 3341, Annex 1, at least in principle.

Hopefully
[blockquote]EBU Tech Doc 3343 ‘Practical Guidelines for Production and Implementation in accordance with EBU R 128’[/blockquote]will clarify this, if published some day.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-06 15:09:55
ffmepg is v2.1 or later.  Is there a reason you went to v3?


Not totally true, there are some code that is under GPL v3 (or later). However, I believe, they will only be enabled if you run configure with " --enable-version3".


Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 15:13:05
Both, SoX (http://sox.sourceforge.net/) and FFmpeg (http://ffmpeg.org/), are GPLed, hence R128GAIN is "GPL infected".

ffmepg is v2.1 or later.  Is there a reason you went to v3?

Not really.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Soap on 2011-01-06 15:21:40

ffmepg is v2.1 or later.  Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-06 15:49:12

ffmepg is v2.1 or later.  Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.

I've heard about some discussions regarding v3 but I'm not aware of the details. Maybe it's a good idea to relax to v2 later on.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: saratoga on 2011-01-06 17:37:55

ffmepg is v2.1 or later.  Is there a reason you went to v3?

Not really.

Your call, not mine, but unless you're worried about Tivoation (however you spell it) or one of the other corner cases covered in new by v3, removing v2 becomes a (significant?) restriction on uptake.

I've heard about some discussions regarding v3 but I'm not aware of the details. Maybe it's a good idea to relax to v2 later on.


I strongly recommend using a "v2 or later" type GPL license, rather then explicitly going v3.  It makes it MUCH easier for other people to use your code, and the added protections in the v3 aren't particularly relevant here anyway.

That said, for this kind of code using a GPL front end and an LGPL backend for the actual DSP library makes a lot of sense since it keeps your tool GPL but still allows a wider range of people to use your code without having to re-implement it.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: cpchan on 2011-01-07 00:39:02
That said, for this kind of code using a GPL front end and an LGPL backend for the actual DSP library makes a lot of sense since it keeps your tool GPL but still allows a wider range of people to use your code without having to re-implement it.


I totally agree with this.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: GHammer on 2011-01-07 03:39:07
Seven of 38 posts on software licensing.
Geesh!

Could we move the non-pertinent holy-war debate to a different thread?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-07 06:14:29
Seven of 38 posts on software licensing.
Geesh!

Could we move the non-pertinent holy-war debate to a different thread?


Why, its relevant to the software release, so no >_>.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-07 06:19:30
You cannot always dynamically link to a library,


Please give me an example where you really have to link statically.



To avoid dependancy hell. I am sure FB2K users would appreciate one singular DLL to install rather then the library, SoX, etc, just to tag some files. >_> Sure, with "GNU/Linux" thats not a problem, but with Windows, it sorta is. >_>

Funny how people EXPECT Linux development philosphies to carry over to the Windows world. Well, sorry, we don't have package managers to install all dependancies. Sorry to jerk you around so much.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-07 09:46:36
Quote from: mudlord link=msg=0 date=
To avoid dependancy hell. I am sure FB2K users would appreciate one singular DLL to install rather then the library, SoX, etc, just to tag some files. >_> Sure, with "GNU/Linux" thats not a problem, but with Windows, it sorta is. >_>

Funny how people EXPECT Linux development philosphies to carry over to the Windows world. Well, sorry, we don't have package managers to install all dependancies. Sorry to jerk you around so much.


Not even funny but rather irritating how people feel entitled to a demanding tone about something they have neither contributed to nor paid for. No one on this forum has any intention or purpose to fulfill your christmas wish list.

I think you have made your position clear several times. How about you program your own lib or shut up about this now?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: romor on 2011-01-07 14:57:53
Bad talk. You are free to see his posts if you want to see his contribution to "community"
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Soap on 2011-01-07 15:43:12
forget it.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-07 16:02:37
Forget this, too. Else the joke doesn't work out.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: staale on 2011-01-07 16:08:58
Hi,

Just wanted to add that we've released our first try at an open-source implementation EBU R.128 library (http://labs.radionova.no/2011/01/07/ebu-r128-library/). It's GPL, does filter coefficients calculation for samplerates other than 48kHz and can measure EBU m, s and i mode. There's also some example programs (including one using ffmpeg/avcodec for decoding).

There's probably lot of bugs and errors, but it seem to function quite well.

Feel free to download and have fun with it.

Regards

Staale @ Radio Nova
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-07 16:27:02
Hello,

back to audio issues again.
Thank you pbelkner for working on this EBU R128 subject.
I am convinced that this will bring RG a big step forward.

I tried r128gain and compared it's results with NUGEN Audio VisLM-H (EBU compliant Loudness Meter) using a test track (dynamic music)
Unfortunately the results were not the same.

Further on, the results emanating from the EBU R128 Test Signals (see post#3) do not correspond to the "Expected response and accepted tolerances" as one can see in EBU-TECH 3341.

Am I missing something???

Thank you for your information

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-07 16:45:21
No one on this forum has any intention or purpose to fulfill your christmas wish list.
At a time when I had no idea about any of this, I said that ReplayGain implementations should be GPL. People wanting to use it suggested that LGPL would be better, so I said that instead. Though having published the algorithm without IP protection, I had no legal right to demand either.

There's always...
http://sam.zoy.org/wtfpl/ (http://sam.zoy.org/wtfpl/)
http://en.wikipedia.org/wiki/WTFPL (http://en.wikipedia.org/wiki/WTFPL)
The lawyer's fees for making people comply with that one are far less than for the other options

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-07 17:13:13
Am I missing something???

Of course not:

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: mudlord on 2011-01-07 17:57:00
Quote
How about you program your own lib or shut up about this now?


Since staale posted crystal clear docs, that is a possibility. >_>

I'll STFU and let you GNU/Linux zealots get on with work.

.....this is the last time I will discuss ANYTHING dealing with GPL here. Obviously people's feelings get hurt if Richard Stallman's poster boy is criticised!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-07 18:13:26
Am I missing something???

Of course not:
  • I'm aware of EBU R128 only for a few days (cf. discussion with C.R.Helmrich).
  • Hacked this in much fewer days (two or three).
  • Immediately published v01.
  • Consider the tolerance acceptable for practical purposes (cf. test cases 7 and 8).
  • Hopefully future releases based on more inside into the standard will further improve the tool.



Ok, thank you, now I understand.

Anyhow, great work in progress     
I am excited to see further developement and how it coud work with RG.

Best regards

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-07 18:56:38
Anyhow, great work in progress 

Thanks 

I am excited to see further developement and how it coud work with RG.

R128GAIN writes the RG tags (currently only for FLAC). I've re-tagged all my FLACs and listen (shuffling) to them all the time with RG enabled. That's my most important test case
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-07 20:34:49
What R128GAIN does is the following (in principle):
  • Create an empty gating block capable of holding samples up to 400ms using a ring buffer.
  • For each input sample:
    • If the gating block is full remove the first sample from it.
    • Add the current sample to the end of the gating block.
    • If the gating block is full:
      • Pick the sample cached in the middle of the gating block.
      • Depending on the (un-gated) loudness measure of the gating block decide, whether to add the picked sample to the overall statistics.
That's my understanding of Tech doc 3341, Annex 1, at least in principle.


I agree with C.R.H. that this interpretation doesn't seem to follow Tech 3341, Annex 1.


I think it would be simpler to work with block indices (a list, array, or bitmap) than a ring buffer.* Read the input stream two times block by block and skip the calculated indices. Usually, with the buffering left to the OS, you should be reading the second pass from memory automatically.

PS The wording in Annex 1 could be better. Especially the "gated loudness" LKG in (6) and (8) should use different symbols. But mathematically it is not ambiguous. It took me over an hour to crunch the whole thing, though.

* Of course, you can still use something as a ring buffer for I/O. But I would put a block-wise abstraction layer on top of it to make the overall design simpler.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-07 21:17:27
I agree with C.R.H. that this interpretation doesn't seem to follow Tech 3341, Annex 1.

Probably you're both are right, I have to think about it.

What I have in mind (probably not correct) is the following:
The block relative to each sample is what I call the running gate because it's easy to update it's sum of squares at each step.

  • The "ungated" total loudness of the resulting set of blocks is your result.

What do you mean by "loudness of a set of blocks"? Doesn't it imply to count samples more than once?

It seems to me that what I've implemented is the limit of what you get if you let go the overlap to 100%. If this is true than it would be fully compliant because they require 50% at a minimum.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-07 21:35:46
It seems to me that what I've implemented is the limit of what you get if you let go the overlap to 100%.


No. Because, for true overlap, the answer to this

Doesn't it imply to count samples more than once?


is "Yes!". Within the overlapping area the same sample can be part of both, zero or more eliminated blocks and zero or more non-eliminated blocks. All non-eliminated blocks are part of the final calculation.

What do you mean by "loudness of a set of blocks"?


Conceptually: Concatenate all non-eliminated blocks and calculate the "ungated" loudness for the whole interval. In practice you basically average the pre-calculated loudness values of all non-eliminated blocks, see step (8).

PS My comments are not supposed to curtain the fact that you have done a great job so far!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-07 22:21:23
PS My comments are not supposed to curtain the fact that you have done a great job so far!

Many thanks to C.R.Helmrich and you for the great comments! Meanwhile I've taken another look at the papers and I think the point is clear now.

Probably the next version will offer the two pass approach (and may leave the current one pass as a very good approximation).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-07 23:28:10
Please pardon the noob here; hopefully I'm keeping up with the discussion even though most of this is far outside my normal domain. I'm sure you'll all set me straight if I'm on the wrong track!

Is a two-pass approach over the input really required? While I'm sure it's a reasonable approach; from a library perspective a single pass interface seems convenient (like the common ReplayGainAnalysis C code). In googlebot's steps 1 through 6; the loudness per block is calculated implicitly during step #2 and if I'm understanding correctly only that per-block loudness is needed for all of the remaining steps.

Now in a "maximum overlap" approach as suggested by pbelkner each input sample results in a block so the block count per second is of course very high (equal to the sample rate). In this case buffering the per-block loundness in a single-pass approach sounds ridiculous compared to a two-pass algorithm.

But in the minimum 50% overlap standard laid out by Tech 3341, Annex 1; the block count per second is fixed at 5 independent of the sample rate. If I'm understanding this correctly it means that buffering the per-block loudness would "only" require 18K samples per hour (versus 172 million for near 100% overlap). If the loudness samples are stored in 64-bits that's only a little over 700 KiB an hour of buffering. While it isn't bounded; it sounds reasonable for in memory buffering this application on modern hardware (considering tyipcal PC applications at this point, not embedded devices, etc).

I looks to me like there is a good reason to stay near the 50% minimum overlap.

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-08 00:51:41
Completely agree! One doesn't really have to pass two times over the whole input. Only the loudness values of non-eliminated blocks need to be saved during the first pass. The second "pass" can then just further decimate those (in the same loop as the final averaging).

I often do not start to look for speed optimization potential before I have a simple to understand and correctly working first sketch. In my experience this leads to better code in the long run. But you are right: 2 passes over the whole input are overkill, probably even for a first sketch...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-08 08:32:13
But in the minimum 50% overlap standard laid out by Tech 3341, Annex 1; the block count per second is fixed at 5 independent of the sample rate. If I'm understanding this correctly it means that buffering the per-block loudness would "only" require 18K samples per hour (versus 172 million for near 100% overlap). If the loudness samples are stored in 64-bits that's only a little over 700 KiB an hour of buffering. While it isn't bounded; it sounds reasonable for in memory buffering this application on modern hardware (considering tyipcal PC applications at this point, not embedded devices, etc).

I looks to me like there is a good reason to stay near the 50% minimum overlap.

Thanks a lot for this estimation. For album gain calculation we have to buffer "loudness samples" in this order of magnitude.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-08 13:29:51
Many thanks to C.R.Helmrich and you for the great comments!

Gern geschehen. Thank you for taking the implementation initiative!

I also agree with Jeff and googlebot and suggest to do it exactly like they proposed: compute a new block loudness measure every 9600 samples (at 48 kHz) and store all blocks with loudness > -70 LUFS in a linked list (or array if you know the track/album length ahead of time... which you do in our scenario, I guess). Then you can apply the relative gate on this list.

Actually, I think to avoid calculating the logarithm and division by T every 200 ms you can simply store the block energies in your list, because the comparison

[blockquote]block loudness > -70 LUFS[/blockquote]
is, assuming your block energy = left energy + right energy + center energy + 1.41* ..., equivalent to

[blockquote]block energy > 0.4 * sample rate * 10^((-70+0.691)/10),[/blockquote]
with the right-hand term being a constant (0.00225113 for 48 kHz, 0.00206823 for 44.1 kHz). Then you can work analogously for the relative gating: simply sum up all the block energies in your 70-gated list, divide by the number of energies in the list to get the average 70-gated energy, and apply the relative gating threshold by

[blockquote]block energy > 0.1584893 * average 70-gated energy[/blockquote]
Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-08 17:42:20
I have it on good authority that the calculation can be done in a single pass. This was a design requirement as R128 was designed to be workable for live broadcast applications. I will make inquiries and try and scare up the technical details. If anyone happens to be in Switzerland in February (http://tech.ebu.ch/loudness11) all will be revealed.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-08 18:40:16
A fully standard compliant single-pass outline is on the table since at least post #54 (bottom). For I-scale measurements, some state has to be accumulated, though, because the loudness of a programme's last block can in principle decide whether its first block gets gated or not. Hardware with limited memory will have to be subject to limits for the maximum integrable time span (which can be huge at moderate cost if you look at Jeff's post). The S- and M- scales, on the other hand, are suited for measurements of infinite length.

I'm looking forward, however, to what you can dig up at the workshop and share here!

Great optimization by C.R.Helmrich, btw, this should save several orders of magnitude CPU time!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-09 17:47:37
v0.3 released

I've just uploaded the new version and it's available at[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-10 08:58:54
Works perfectly, great job! Even for multichannel and high resolution files.

I'm wondering why the EBU provided test sample don't match their own descriptions in tech 3341. That should be fixed.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-10 16:38:38
Actually, I think to avoid calculating the logarithm and division by T every 200 ms you can simply store the block energies in your list, because the comparison

[blockquote]block loudness > -70 LUFS[/blockquote]
is, assuming your block energy = left energy + right energy + center energy + 1.41* ..., equivalent to

[blockquote]block energy > 0.4 * sample rate * 10^((-70+0.691)/10),[/blockquote]
with the right-hand term being a constant (0.00225113 for 48 kHz, 0.00206823 for 44.1 kHz). Then you can work analogously for the relative gating: simply sum up all the block energies in your 70-gated list, divide by the number of energies in the list to get the average 70-gated energy, and apply the relative gating threshold by

[blockquote]block energy > 0.1584893 * average 70-gated energy[/blockquote]

Let me, please, summarize how I understand this:It turns out that it is possible to avoid any logartithm during intermediate calculations. Intermediate results, i.e. weighted mean squares, are optained simply by add and multiply operations. Only the one time calculaton of the two thresholds for phase 1 and phase 2 needs exponentation.

Pass 1 of the EBU R128 algorithm only has to cache the weighted mean squares wmsq_i of the EBU R128 segmentation. From that all the rest can easily be derived.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-10 17:01:33
The BS.1770 loudness measure is defined as[blockquote]-0.691 + 10*lg(wmsq),[/blockquote]where[blockquote]wmsq = sum_i_j G_i*x_i_j*x_i_j/n,
i running over all channels,
G_i the weighting coefficient for the i-th channel,
j running from 0 to n-1 over all sampling intervals,
x_i_j the j-1 channel's voltage of the i-1 sample[/blockquote]is the (per channel) weightet mean square of the intervall under consideration.

should read

Quote
The BS.1770 loudness measure is defined as[blockquote]-0.691 + 10*lg(wmsq),[/blockquote]where[blockquote]wmsq = sum_i_j G_i*x_i_j*x_i_j/n,
i running over all channels,
G_i the weighting coefficient for the i-th channel,
j running from 0 to n-1 over all sampling intervals,
x_i_j the j-th channel's voltage of the i-th sample[/blockquote]is the (per channel) weightet mean square of the intervall under consideration.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-10 17:20:09
Exactly, and if you pull out the "/n" in wmsq = sum_i_j G_i*x_i_j*x_i_j/n, which you can do since n is the same in all blocks and channels, you get what I wrote because n = 0.4 * sample rate and

[blockquote]wmsq = block energy / n[/blockquote]

and save many divisions. Of course you still need the division when computing the final R128 loudness measure.

I think you mean "x_i_j the i-th channel's voltage of the j-th sample" though, right?

Chris

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-10 17:35:10
Just out of curiosity, where does that 0.4 come from?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-10 18:27:26
Just out of curiosity, where does that 0.4 come from?


I assume that's due to the 400 ms block size = .4 seconds.

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-10 20:40:40
Duh. My bad!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Fandango on 2011-01-11 22:14:15
I have a proposal.

New standard tag fields:
EBU_R128_REFERENCE_LOUDNESS
EBU_R128_TRACK_GAIN
EBU_R128_TRACK_PEAK
EBU_R128_ALBUM_GAIN
EBU_R128_ALBUM_PEAK
or R128GAIN_*, EBUR128_*, ...

Replay Gain tag fields should become optional, only activated by a command line option. So no loss there if people want to test your implementation without having an EBU R128 DSP plugin.

Without independent tag fields the authors of such plugins cannot start supporting EBU R128 gain control in their Replay Gain plugins.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Fandango on 2011-01-12 01:02:20
PS: I'd say that using GAIN in your prefix is a bad idea like I had suggested (unfortunately I can't edit the post anymore). The GAIN in REPLAYGAIN_* is part of the proper name of that loudness measurement system. Choose wisely, AFAIK you're the first with such an implementation that uses tag field names or even the first with a PC implementation of EBU R128. The tag fields will probably become the standard (in the PC sound community).

EBUR128_* would be consistent with Replay Gain's omission of the whitespace between the two words, but it is confusing so that people might think the standard's name is Ebur 128 or EBUR 128. Hence I would vote for EBU_R128_*
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-12 03:11:34
Without independent tag fields the authors of such plugins cannot start supporting EBU R128 gain control in their Replay Gain plugins.

Why not? There is a simple and reasonably accurate mapping (http://www.aes.org/e-lib/browse.cfm?elib=15341) between R128 and Replay Gain metrics.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-12 05:40:57
I had been hoping that the written tags were being converted into REPLAYGAIN compatible units (although I wondered). How are the flacs being tested being tested; a modified playback program as well? In that case is the correction algorithm applied at playback the same just different units / base?

New tags seems very unfortunate (given hardware device support, etc). New tags for the peak data wouldn't mean anything more than sample peak (ReplayGain) versus true signal peak (EBU R128); right? Would a playback program care about the distinction (would seem unlikely unless a fancy client had some way of estimating the worst-case error in sample-peak based on sampling frequency, etc ... sounds far fetched). In terms of the gain; I had been assuming that it was just a matter of converting units / reference levels. I guess the paper probably answers that. It sound interesting; too bad it's $20.

Also note that storing REFERENCE_LOUDNESS for ReplayGain is not a standard and probably doesn't make any more sense here than it does for ReplayGain (current non-standard metaflac behavior notwithstanding).

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-12 09:18:45
Just compared r128gain output versus ReplayGain for ref_pink.wav. ReplayGain defines ref_pink.wav as +6.00 dB. This was originally 0 when compared to 83 dB SPL but shifted up when 6 dB was added to make typical music "loud enough" on non-calibrated systems.

Code: [Select]
C:\development\replaygain>r128gain.exe ref_pink.wav
args
  analyzing ...
    ref_pink.wav (1/1): -23.4 LUFS, 0.4 LU (peak: 0.292569: -5.3 dBFS)
    ALBUM: -23.4 LUFS, 0.4 LU (peak: 0.292569: -5.3 dBFS)


Since the whole point is to come up with a scaling ratio and relative LU are scaled in dB it looks to me like this algorithm will generate ReplayGain compatible values simply by adding 5.6 to the reported LU to compensate for the different base loudness of ref_pink.wav (-.4 difference due to fundamental differences in algorithms and +6 difference due to the ReplayGain reference point shift). However; this whole comparison is based on my assumption that the goal is to use the new algorithm for computing the loudness and adjustment but calibrating to the original reference sound. I don't know if this is a valid comparison or if for example the new algorithm would specifically not be expected to behave ideally on ref_pink.wav.

Anyway, for the few real music files I compared the results were similar enough to the ReplayGain calculated values that this seems plausible but different enough that I don't know if this is a valid conversion method or not.

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-12 09:21:18
I had been hoping that the written tags were being converted into REPLAYGAIN compatible units (although I wondered). How are the flacs being tested being tested; a modified playback program as well? In that case is the correction algorithm applied at playback the same just different units / base?

EBU R128 and ReplayGain are two different approaches to reach the same goal: uniform loudness at replay time.

Common to both approaches is to define an algorithm in order to determine at scan timeEven if this is common to both approaches there are huge differencesMetadata is not part of EBU R128. What R128GAIN does is writing the same tags as METAFLAC (http://flac.sourceforge.net/documentation_tools_metaflac.html#metaflac_shorthand_add_replay_gain) . Each playback software providing ReplayGain and honoring the METAFLAG tags should work with FLACs tagged by R128GAIN, e.g. Winamp (http://www.winamp.com/). The loudness level than will be -23 LUFS as requiered by EBU R128 (completely different measure than RG's 83 dB).

Tests where performed using Winamp (http://www.winamp.com/) in conjunction with my own SoX and FFmpeg based input plugin (http://in-ffsox.sourceforge.net/). Native WA should do as well.

New tags seems very unfortunate (given hardware device support, etc). New tags for the peak data wouldn't mean anything more than sample peak (ReplayGain) versus true signal peak (EBU R128); right? Would a playback program care about the distinction (would seem unlikely unless a fancy client had some way of estimating the worst-case error in sample-peak based on sampling frequency, etc ... sounds far fetched). In terms of the gain; I had been assuming that it was just a matter of converting units / reference levels. I guess the paper probably answers that. It sound interesting; too bad it's $20.

Plaback software (as e.g. Winamp) makes use of the peak values (e.g. providing a clipping prevention mode). Whether it is amplitude peak or true peak will become intersting in case there is some up-sampling in the playback chain, and propably it is, because each contemporary DAC does it. Hence you should always store true peaks.

Also note that storing REFERENCE_LOUDNESS for ReplayGain is not a standard and probably doesn't make any more sense here than it does for ReplayGain (current non-standard metaflac behavior notwithstanding).

Maybe it could become part of the RG standard:on the unit dB vs. LU, provided someone figures out the mean relative loudness between the two approaches.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-12 11:58:30
I think you both have a valid point.

I also think that it is not very probable, that just because there is a tool now and some forum people decide to agree on a R128 tagging format, that there will be only a fraction of RG's device and player support anytime soon. It was different, when David started, because it filled a gap at its time, for which there were no solutions.

Until RG evolves into something allowing versioning, it can take ages. It might even never happen, since ID3 is such a mess. (The world of tagging could be such a better place without mp3.)

=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefits of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

PS An additional tag could indicate, that the values are R128 based. A user could then choose to rescan all tracks, which do not have that, yet.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-12 12:14:00
=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefit of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

That's exactly what I've tried to say. With R128GAIN you can do this just out of the box.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-12 16:07:05
PS An additional tag could indicate, that the values are R128 based. A user could then choose to rescan all tracks, which do not have that, yet.

R128GAIN solves this by design:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-12 17:27:51
=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefit of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

That's exactly what I've tried to say. With R128GAIN you can do this just out of the box.

I agree. Just use the RG fields. The only difference would be how the RG values were calculated. The key point here is the calibration of the R128-calculated RG data to match the RG-calculated RG data. Which means...

Quote
Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.

I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS. Taking the difference between the RG-average gain and the R128-average gain gives you the offset by which RG and R128 differ. Based on that offset we could "correct" the R128 gain values when writing them as RG-style metadata to files. Doing it that way, we wouldn't really need the additional tag that googlebot mentioned, since on average the new R128-calculated RG values are in the exact same range as the "old" RG values.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-12 17:46:28
How large are the expected differences? Is there already any data? How much would the allocation of genres affect the outcome of that test?

Gating is an advantage of R128. Depending on the amount of silent passages in that huge collection, which are part of the ReplayGain but not the R128 calculation, the average result my become skewed. The calculated offset might appear larger than practically justified. Since it is a feature, that R128 rates tracks with a lot of silence differently from ReplayGain, this feature shouldn't be reduced by averaging. Maybe the collection could be gated before the comparison? But then, how much difference would remain? We could well end up close to +5.6 in the end again.  But that's speculation.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-12 18:00:29
True. I guess for the averaging we should leave out {not quiet but} high-loudness-range tracks (which I guess includes most classical music) and tracks with lots of silence (last track of a CD with hidden track or stuff like that). One or two seconds of silence around tracks ripped from CD shouldn't matter. You're right, the result will probably be near the pink-noise gain difference, but I just want to make sure.

Once Peter releases v0.4 which includes my optimizations, and it is confirmed that that release gives identical results to the current version, I'll start running some albums through RG and R128gain.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-12 19:26:31
Code: [Select]
    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.7 LUFS, 0.7 LU (peak: 0.063133: -12.0 dBFS)


IMHO they should both be the same. But you probably already know that.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-12 20:24:01
Also note that storing REFERENCE_LOUDNESS for ReplayGain is not a standard and probably doesn't make any more sense here than it does for ReplayGain (current non-standard metaflac behavior notwithstanding).

Maybe it could become part of the RG standard:
  • It would help to resolve the 83 dB vs. 89 dB debate.
  • It would help to integrate playback of ReplayGain tagged and EBU R128 tagged tracks depending
on the unit dB vs. LU, provided someone figures out the mean relative loudness between the two approaches.


In various past threads (including this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=71154&st=25&p=721226&#entry721226) by David) strong cases have been made against storing the reference level. I don't think it's needed for the original ReplayGain nor for an EU R128 based solution. In both cases the reference points are now well understood and essentially part of the standard (89 dB and -23 LU).

For existing player compatibility; I think it's a bad idea to change the meaning of the existing tags. Existing players can't be expected to do anything meaningful with REFERENCE_LOUDNESS. Further although it sounds like the one's you've tested are happily ignoring the units (dB verus LU) in the VorbisComment tags; assuming that is not a good idea for standardization. An existing player could quite reasonably ignore the tags altogether since it doesn't understand the LU unit.

Points on a homogenously processed library are good; but I don't think a player or the standard should presume that situation when reusing existing tags. A legacy player encountering a heterogeneously processed set of music might (a) ignore the new RG128 tags due to the LU units or (B) apply the value as is likely resulting in a significant loudness discrepency between true ReplayGain tags and RG128-overloaded ReplayGain tags. An update player might handle the situation better based on noticing the LU units or perhaps the REFERENCE_LEVEL. But I think there is a better way in terms of compatibility.

Assuming that some REPLAYGAIN_RG128_CONVERSION_FACTOR can be defined (for the momemt I'll allow for the situation where it is not fixed; allowing for alternative approaches such as ref_pink.wav calibaration versus averaging over a large sample set); it seems ideal to store that in a new tag and while storing ReplayGain-compatible values in the original tags. A legacy player would be able to handle heterogenous libraries reasonably (within the inherent limitations of defining a conversion factor and mixing algorithms); while an updated player could optionally use the conversion factor to convert the ReplayGain back to true EBU R128 compliant values. For a homogeneous EBU R128 library nothing is lost. The conversion factor may not provide perfect handling of heterogenous cases; but as a constant factor it can't make the situation any worse for homogenous libraries (beyond having to adjust the initial volume knob once compared to the quieter values provided by the current true EBU R128 compliant solution).

If we want a "pure" EBU R128 approach; I believe that should be stored in separate tags (as suggested earlier) either specific to this case or perhaps some generalized ReplayGain 2.0 spec that allows for explicitly indicating algorithms, etc but that doesn't overload the meaning of existing tags.

I think the current solution of overloading ReplayGain tags should be reserved for special use-cases (and thus not be a default or recommend behavior). It is only reasonable for homogenously processed libraries and is really a hack as a new RG128 compliant player doesn't need to overload ReplayGain tags in a non-standard way while compatibility with existing players can only be determined empirically since the overloading is not based on any flexibility in the existing ReplayGain/VorbisComment specs.

In terms of peak; I suspect that substituting the more accurate wave peak should be an acceptable backward-compatible replacement for the sample-peaks currently specified by ReplayGain. Updated players could assume true-peaks when the conversion factor tag is present. Legacy players won't know the difference; but it's unlikely that they were doing anything fancy about the discrepency anyway. The true-peaks should just allow improved clipping prevention.

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-13 01:57:25
I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS...

There is now a public link (http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/AES128-Loudness-Normalization-Portable-Media-Players.pdf) for this paper. Recommended reading. But if you can't manage to find the time, the answer can be found on page 11: RG=-18dB - LKFS
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-13 05:21:46
I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS...

There is now a public link (http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/AES128-Loudness-Normalization-Portable-Media-Players.pdf) for this paper. Recommended reading. But if you can't manage to find the time, the answer can be found on page 11: RG=-18dB - LKFS


Thanks for providing the public link; good read and very on-topic here. RG=-18dB - LKFS means an adjustment factor of +5 considering the -23 LKFS reference point for EBU R128. This compares to the aforementioned adjustment factor of 5.6 based on a simplistic ref_pink.wav comparison alone.

I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-13 09:25:41
I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

Please, let's re-analyze it! Otherwise we can't be sure.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-13 09:26:26
Code: [Select]
    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.7 LUFS, 0.7 LU (peak: 0.063133: -12.0 dBFS)


IMHO they should both be the same. But you probably already know that.

Yep. I suspect that's possible for "libebur128.a" because it is based on "libsndfile.a" providing information regarding the channel map. R128GAIN instead uses a fixed (hard coded) channel map, because I coudn't figure out how to get the channel map from SoX or even more important from FFmpeg.

The goal is to have R128GAIN's IO based on FFmpeg in the near future. This will enable R128GAIN to process virtually any existing format or codec without re-encoding (as it is currently done for FLAC).

Please note that the tool is designed from a complete practical/pragmatic point of view: I want to be able to EBU R128 compliant tag my complete audio collection, including FLAC, WV, MP3, and AC3. All of them are plain 2.0 stereo anyway or multichannel downmixed to 2.0 by FFmpeg at playback time. That's the main reason for using the same tool chain for R128 analysis.

I would greatly appreciate if someone is aware on how to get the channel map from FFmpeg.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-13 09:37:17
I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

Please, let's re-analyze it! Otherwise we can't be sure.

Chris

My ad-hoc "measured" difference between RG and R128 is about 4dB. For RG I have the playback preamp at -2 dB, for R128 at +2dB to (subjectively) perceive about the same loudness shuffeling to two respective tagged huge audio collections. This pretty much matches the (theoretical) difference of about 5dB.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-13 10:01:27
I think the current solution of overloading ReplayGain tags should be reserved for special use-cases (and thus not be a default or recommend behavior). It is only reasonable for homogenously processed libraries and is really a hack as a new RG128 compliant player doesn't need to overload ReplayGain tags in a non-standard way while compatibility with existing players can only be determined empirically since the overloading is not based on any flexibility in the existing ReplayGain/VorbisComment specs.

If you think in terms of defining a standard, I agree. Otherwise I strongly disagree: I want to listen to R128 compliant tagged audio now.

In terms of peak; I suspect that substituting the more accurate wave peak should be an acceptable backward-compatible replacement for the sample-peaks currently specified by ReplayGain. Updated players could assume true-peaks when the conversion factor tag is present. Legacy players won't know the difference; but it's unlikely that they were doing anything fancy about the discrepency anyway. The true-peaks should just allow improved clipping prevention.

I completely agree.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-13 10:23:09
Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.
I agree.
That is exactly how it's supposed to work.

You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

If you're comparing two loudness measurements, neither of which have a reference level, then you're stuck with comparing results from a large sample set. But if one or both have properly defined reference levels, then that should be unnecessary - and will only reveal inaccuracies in one or other algorithm with the chosen sample set. Presumably you want to remove such inaccuracies. Hard coding them into the conversion factor doesn't seem right.


But like I said - you could argue it either way. I think unless there's strong evidence to the contrary, the simple approach, "just use ref_pink", is the one to stick with.


I think (I've always thought!) that a version tag might be useful.
I think existing tags must keep their existing meanings.
Using a new calculation method with the same reference level is absolutely fine.
I think inter-sample peaks might be better in a separate tag, not in the existing peak tags. Some processing (e.g. typically that within software players) cares about the values of the actual sample data, and doesn't care at all about inter-sample overs. The player may do things differently if the real samples go above 0dB FS (e.g. introduce soft or hard limiting, or soft clipping) which may decrease quality if applied when it's only inter-sample values that go above 0dB FS. (In practice it's rare for ReplayGained audio to have significant inter-sample overs but no on-sample overs - "loud/squashed" audio like that tends to get turned down by ReplayGain to a level where there's no chance of any values above 0dB FS either on or between samples)

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Raiden on 2011-01-13 10:44:36
What is so special about pink noise? How does pink noise better appromixate the set of all possible audio inputs than a large set of audio inputs?

FWIW, analysing my library (a week of FLAC) resulted in a difference of 5.11 dB, similar to the ~5 dB other people got.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-13 11:02:38
Pink noise has equal energy over all octaves. It's just the reference against which all current ReplayGain values are calibrated. So it can make sense to use the same calibration for new loudness estimators instead of endless debates over which reference collection to choose, the allowed loudness range within that, etc. Even if you take the whole catalog from all major music publishers, averaging might not deliver optimal results. See the discussion above, why collection averaging might dilute the wanted differences between gating and non-gating loudness estimators.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-13 12:57:47
Thank you Notat for the link to AES "Loudness Normalization in Portable Players".

Very interesting on page 9 is Figure 3 showing the different frequency weighting curves for ReplayGain and for ITU-R BS1770.

Best regards

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-13 14:41:49
You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

The statistical processing in RG and the gate in R128 introduce non-linear behaviors that are difficult or impossible to compare mathematically or by using a single reference. This motivates the empirical/statistical approach.

Here's (http://www.speech.kth.se/prod/publications/files/3319.pdf) another (longer) study that takes a statistical approach. Loudness measurement implementation variations are considered including one with gating.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Fandango on 2011-01-13 15:21:16
Without independent tag fields the authors of such plugins cannot start supporting EBU R128 gain control in their Replay Gain plugins.

Why not? There is a simple and reasonably accurate mapping (http://www.aes.org/e-lib/browse.cfm?elib=15341) between R128 and Replay Gain metrics.

As I've seen it now whether it is accurate enough is subject to debate.

Independent tag fields make such discussions superflous at least for people who want to have both and are willing to rescan their music once. Most importantly switching between EBU R128 and Replay Gain would not require rescanning the audio when both values are stored alongside. The implementing mapping itself is also probably an obstacle for some plugin developers (especially commerical ones where time is money) although I believe most people here would embrace it as a task.

And as I said storing EBU R128 information in a Replay Gain compatible format and tag fields should still be made available as an option. But if r128gain will never adopt its own tag fields with a relevant format then there's no appeal for loudness equalization plugin developers to adopt this method, since there's nothing to work with. EBU R128 will be too compatible to be distinct, and it will never stand a chance against Replay Gain.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-13 16:01:10
But if r128gain will never adopt its own tag fields with a relevant format then there's no appeal for loudness equalization plugin developers to adopt this method, since there's nothing to work with.

From where you know? R128GAIN exists just for one week. Of course, currently there is no sense in storing gain information in some new tags not a singel player out there is recognising. This early version of R128GAIN is aimed to allow you to get an practical idea of what EBU R128 is.

BTW: I'm myself a plug-in developer, and for sure one of the plug-in's next releases will support EBU R128 compliant tagging.

EBU R128 will be too compatible to be distinct, and it will never stand a chance against Replay Gain.

From where you know? EBU is not a nobody, it is the European Broadcasting Union (http://www.ebu.ch/). EBU R128 is aimed that all European broadcasters will transmit there programs at -23 LUFS according to this standard. Why would you like to have your music coming from the PC at another loudness?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-13 16:20:13
Most importantly switching between EBU R128 and Replay Gain would not require rescanning the audio when both values are stored alongside.
I'm not sure why you'd want to do that. The whole point of anchoring ReplayGain to a known reference was so that an improved calculation could be introduced at any point without breaking anything (as could user defined values). Once an improved calculation is available, there's no reason to use the old (original) one, so no reason to have two sets of tags.

If the EBU defines a new set of tags and pushes for their adoption, then I can see that this could happen. But failing this, the existing RG tags, populated with values from another calculation (e.g. EBU R128), provide a perfectly good solution.

Don't underestimate industry inertia. Don't overestimate the EBU's interest in portable media players etc.

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-13 16:24:06
EBU R128 is aimed that all European broadcasters will transmit there programs at -23 LUFS according to this standard.
That is the intent, and is no doubt a "good thing". The EBU also told all EU broadcasters to use 720p. Most use 1080i. So, we'll see.

In terms of forcing a market to stick to a reference loudness, Dolby is the most successful by far. The vast majority of DVDs have dialnorm set correctly, and all AC-3 decoders use it to deliver -30dB Leq (with a fixed boost for RF / midnight mode).

Quote
Why would you like to have your music coming from the PC at another loudness?
If the world moved to such a low loudness standard it would be a wonderful thing, but I'm sure people will continue to use the pre-amp to make their music as loud as they think it should be (typically, louder!).

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-13 16:27:01
I'm with David.

I think we should verify the gain offset (5dB difference) and just write the new values to the old tags.  In theory, EBU R128 could just be a more accurate ReplayGain.

It might also be interesting to add some of the recommendations from EBU R128, particularly the silence gating and 66% window overlap, to ReplayGain and see if it provides a noticeable improvement.  ReplayGain could also be improved with a more up-to-date human hearing curve as well as a better filter design model (isn't Yule-Walker meant to be used for auto-regression analysis in Economics?).  10th order IIR filters aren't exactly ideal (stability issues with precision) for limited-precision digital applications.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Fandango on 2011-01-13 17:22:57
So if the old tags are used, how do I know whether audio files have been processed with r128gain or another EBU R128 implementation? The REPLAYGAIN_REFERENCE_LOUDNESS tag field? What if a Replay Gain scanner does not remove this tag field when I change from EBU R128 to Replay Gain?

Personally I'd like to be able to switch between both in an instant in order to compare their capabilities even more so because their coexistence in the PC audio domain has just started with this project, I thought that's obvious. Currently I would have to prepare two sets of audio files in order to compare them adequately, not very practical if you don't really know what music you actually need to test, as I don't remember every album where I found something odd.

@pbelkner:
Quote
Why would you like to have your music coming from the PC at another loudness?
Personally I have noticed quite some loudness differences of already replaygained music titles, as I understood it, EBU R128 does not simply has a lower base loudness, but may be better at bringing those albums to an adjusted level. But without proper testing preconditions this is not possible to proof for me. Easy instant switching between both would help a lot.

Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-13 17:43:50
Easy instant switching between both would help a lot.


This would be first and foremost a player feature. Are you planning to implement it?

Of course, we could continue the discussion on a purely conditional level: IF we had both types as separate tags AND the millions of playback devices and software players would adopt to the new format soon... then you could sit comfortably in your chair, switch back and forth over your collection and decide if you like R128 better than the venerable ReplayGain estimator.

For pure playback the existing tag infrastructure is totally sufficient. Testing and comparison can be accomplished with the already with the recently developed tools. We don't need separate tags for that. As a device manufacturer I wouldn't invest a penny just to let people switch back and forth between legacy and R128 measured gain values. I don't even think that the additional possibilities would outweigh the added confusion for consumers. If R128 turns out to be better, write the result properly offset into the existing tags. Add true peaks for any players which care. That's it.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-13 18:04:02
Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.

Have a look at the reference in post #94; further evidence that BS.1770 does a slightly better job than ReplayGain. R128 is based on and a further improvement to BS.1770.

In addition to strong acceptance in Europe, BS.1770 is specifically called out in the CALM act here in the US. The FCC is required to evaluate and, in 1 years time, require broadcasters to deploy it. It is possible the technology will be further improved in this process.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-13 18:52:56
I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-13 19:18:42
Sorry for the detailed technicality, but:

Why not use the first bit (MSB) of the originator code field for precisely that? Meaning: 0 = original RG algorithm, 1 = EBU R128 algorithm. Quote from the current revision of the ReplayGain HA Wiki (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification):

Quote
Originator code
[blockquote]000 = Replay Gain unspecified
001 = Replay Gain pre-set by artist/producer/mastering engineer
010 = Replay Gain set by user
011 = Replay Gain determined automatically, as described in Calculating (above)
other = reserved for future use[/blockquote]
For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is 000 (Replay Gain unspecified), then the player should ignore that Replay Gain adjustment field.

For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is unknown, then the player should still use the information within that Replay Gain Adjustment field. This is because, even if we are unsure as to how the adjustment was determined, any valid Replay Gain adjustment is more useful than none at all.


This question especially goes to David and audio player developers. Any potential disadvantages of doing it that way?

Edit: Bit pattern 100 could still be reserved for future use.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: greynol on 2011-01-13 19:26:02
Perhaps because we haven't identified many applications that use such a cryptic system.

Why not implement benski's suggestion?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-13 19:53:20
Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.

Have a look at the reference in post #94; further evidence that BS.1770 does a slightly better job than ReplayGain. R128 is based on and a further improvement to BS.1770.

In addition to strong acceptance in Europe, BS.1770 is specifically called out in the CALM act here in the US. The FCC is required to evaluate and, in 1 years time, require broadcasters to deploy it. It is possible the technology will be further improved in this process.


I have some concerns about this paper.  I need to read it again, and maybe I'll ask for the raw data and recalculate.  The fact that Replay Gain using 85th percentile scored better than the default 95th percentile implies to me that there might be a calibration issue.  Ideally, the calibration adjustment (a constant gain value) should be made so that it minimizes the RMS error, and I'm not sure that they did this (again - I need to re-read the paper and verify this).

Also, speech samples seemed to be overly represented in the data set.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-13 19:54:32
Quote
Why not implement benski's suggestion?


For example because we don't want to waste bits in the file. Wait... so which player / file format actually implements David's original gain data format proposal (16-bit field per gain value)?

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-13 19:56:24
Quote
Why not implement benski's suggestion?


For example because we don't want to waste bits in the file. Wait... so which player / file format actually implements David's original gain data format proposal (16-bit field per gain value)?

Chris


I believe the only implementation of the original gain data format is in the LAME extended Xing header, which hardly anything uses for ReplayGain information, mostly because it's typically missing album gain.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-13 20:14:36
I believe the originator code is written in a different format (ASCII) in some of the other tagging schemes. This all will be clearer to me and everyone else once I've worked this part of the document. At this point, what C.R. quoted from the new specification is just a copy of the original proposal (http://replaygain.hydrogenaudio.org).

There is some history regarding addition of a revision field. David has always been in favor, Garf did not feel necessity and proposed usage had been adequately demonstrated.

Once the two systems have been calibrated to one another, indications are that the difference in measurements on most material is typically just a few dB. Errors in playback with a mixture of ReplayGain and R128 scanned material will probably be no worse than the inherent variability experienced with a single system.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-13 20:17:06
I see. So what's the de-facto standard (most widely used) bit stream format? The one that foobar uses, i.e. clear-text? i.e. around 70 characters = 560 bits to store two gains and a peak value? I'm speechless.

Guys and girls, feel free to define whatever format you want. I'll pass on this one.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-13 20:27:17
I certainly hope an extension at this point adds support for versioning or algorithm identification beyond a single bit distinction. The great part here is that with the exception of true versus sample peak; playback devices don't care about any of this (based on original intent of the ReplayGain proposal of course). I expect the inertia and compatibility issues at playback time are a lot bigger deal than on the tagging application side.

In terms of the adjustment factor; the upside there is that the values being discussed (5 versus 5.6 versus a new statistically derived value using EBU R128 on the referenced sample set) seem close enough that when playing mixed-algorithm content the cross-track results are still generally an improvement over the recommended behavior when encountering untagged tracks (e.g. use a running average as the ReplayGain spec suggests or a fixed value as the paper mentions). The ideal recommendation is of course to tag everything with one algorithm; but if it's mixed the sky shouldn't fall.

In terms of keeping separate tags for comparison, etc... I think that should remain in the realm of experimental features for an expert audience. That kind of support doesn't need any standardization and shouldn't be considered in a spec optimized for broad uptake. Considering the VorbisComment system for FLAC; it would be trivial to adjust the existing open-source tagging tools here to allow for user-specified tag names. I assume something similar could be done on an opensource player such that the tag names to read could be configured as an expert option. I don't know that it's worth doing; but I think there are a lot of contributors here could if they felt it added real testing value.

On the other hand; exposing end-users to the differences in these algorithms at playback time is probably the last thing general-consumption player want to even think about.

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: greynol on 2011-01-13 20:27:57
If you're getting up in arms over 560 bits, I'd hate to see how you feel about tagging with software like dBpoweramp, iTunes or MusicBrainz Picard.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-13 20:37:52
Some tagging formats (particularly Vorbis comments for ogg and FLAC) don't support binary data, so plaintext is used in these cases.  For ID3v2 tags, TXXX is used for consistency.  Most id3v2 tags are padded anyway (to allow modification w/o re-writing the file) so it often ends up being a non-issue anyway, size-wise
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-13 21:23:15
I see. So what's the de-facto standard (most widely used) bit stream format? The one that foobar uses, i.e. clear-text? i.e. around 70 characters = 560 bits to store two gains and a peak value? I'm speechless.


Yes, a whooping 10 MB of total overhead for a 10,000 album collection. Imagine you have 4 TB worth of FLAC files and need another disk just for those 10 MB!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nowings69 on 2011-01-13 23:38:51
This is wonderful idea.
Replay Gain is so cool too but usage is limited for audio
I looked for this since I gave up read a tag from a container for movie(wihout vorbis gain in ffdshow and musepack DS filter)
Its means shows other new standards for normalize
Please keep it up!thank you so much

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-14 06:55:52
Easy instant switching between both would help a lot.


This would be first and foremost a player feature. Are you planning to implement it?

I'm considering this for my WA input plug-in (http://in-ffsox.sourceforge.net/).

Certainly I'm in favor with benski's proposal:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

In the meantime a player may try to make a guess based on units dB vs. LU.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jdoering on 2011-01-14 08:02:37
Certainly I'm in favor with benski's proposal:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

In the meantime a player may try to make a guess based on units dB vs. LU.


That's completely wrong! The existing tags should never have any units except dB. That overloads the meaning of the tags in a way that is not backward compatible. Even if a REPLAYGAIN_ALGORITHM tag is added; the units for the existing tags must be dB and should be normalized to original ReplayGain reference level.

Obviously it doesn't matter what you do to your personal library for algorithm testing purposes; but now you're talking about potential player implementations. Encouraging players to support incompatible deviations from the existing ReplayGain standard just weakens the standard - look at the ID3 tagging mess (not that it's limited to ReplayGain).

-Jeff
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-14 08:17:47
That's completely wrong!

It can't be wrong because it's a matter of convention.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-14 12:29:12
So if the old tags are used, how do I know whether audio files have been processed with r128gain or another EBU R128 implementation? The REPLAYGAIN_REFERENCE_LOUDNESS tag field? What if a Replay Gain scanner does not remove this tag field when I change from EBU R128 to Replay Gain?
My proposal is (and has been for a LONG time! (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=15445&view=findpost&p=154583)) that there should be a tag which states the ReplayGain calculation method.

Quote
Personally I'd like to be able to switch between both in an instant in order to compare their capabilities even more so because their coexistence in the PC audio domain has just started with this project, I thought that's obvious. Currently I would have to prepare two sets of audio files in order to compare them adequately, not very practical if you don't really know what music you actually need to test, as I don't remember every album where I found something odd.
Actually, while you're developing something, you have to do such things! Also, I think it's unreasonable to expect generally released software to include functionality that's only useful for testing and development - it would confuse normal users.

The process should work like this:
1. figure out the best available method of loudness matching in 2011.
2. define and document how this should work with ReplayGain tags (offset, versioning tag e.g. ReplayGain_calculation=2 or whatever, inter-sample peaks tags, etc).
3. add a pointer from all current RG documentation to this new document
4. encourage your favourite ReplayGain scanning software to switch to the new method

Quote
Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.
I think it needs to be tested properly first. The evidence is that it's better, and as it's a standard I think it makes sense to go with it even if there's something else non-standard that's fractionally better still. What needs checking is that it works well with a full variety of CDs.

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-15 11:25:08
v0.4 released[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)
http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
[/blockquote]What's new?
As an example consider MP3 with fully upgraded FFmpeg:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-15 11:36:04
Wow, you are quite productive!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-15 16:16:41
That's completely wrong!

It can't be wrong because it's a matter of convention.

It is wrong because it causes existing RG players to malfunction. Exiting players do not know about REPLAYGAIN_ALGORITHM and they assume that existing REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags are in dB units releaive to a -14 dBFS reference. Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-15 18:55:14
Thanks a lot for version 0.4! Regarding

What is so special about pink noise? How does pink noise better appromixate the set of all possible audio inputs than a large set of audio inputs?

FWIW, analysing my library (a week of FLAC) resulted in a difference of 5.11 dB, similar to the ~5 dB other people got.

and
Quote from: Notat link=msg=0 date=
Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.

For a mixed selection of pre-loudness-war material (Kuschelrock Vols. 1 and 2, 4 CDs total), I get an average track-gain difference between the RG and R128 algorithms of exactly 4.6 dB (or LU). Since Raiden got 5.11 dB, I think the 5 dB proposed in Dolby's AES paper are well chosen. Hence, R128gain should write

[blockquote]-18 - R128 LUFS loudness[/blockquote]
instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-15 19:09:19
I agree with Christian, you should write a 'calibrated' gain value, and use dB instead of LUFS. 

As for calibration, I would think that finding a zero-order adjustment that minimized RMS difference rather than simply the average would be better.  I'll test my library as well (huge mix of genres)


Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-15 20:55:13
Easy instant switching between both would help a lot.

Sometimes dreams come true. For convenience a full quote follows:

v0.4.6 released[blockquote]http://sourceforge.net/projects/in-ffsox/files/ (http://sourceforge.net/projects/in-ffsox/files/)[/blockquote]What's new?
  • Support for mixed ReplayGain (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification) and EBU R128 (http://tech.ebu.ch/loudness) playback added:

    (http://home.snafu.de/pbelkner/upload/110115/01/preferences-r128.png)

    (http://home.snafu.de/pbelkner/upload/110115/01/preferences-rg.png)
    • The configuration allows for defining a relative gain between the two standards, typically about 5 dB. The relative gain can be adjusted according to the user's preferences.
    • It is possible to switch between the normative loudness of both approaches, -23 LUFS and 83 dB, respectively. The respective gains are adapted automatically.
    • If the "Write Comment" is checked RG respective information is written into the File Info's comment field

    (http://home.snafu.de/pbelkner/upload/110115/01/file_info.jpg)
  • Depending on whether the effective gain resulting from RG and pre-amp is an amplification or an attenuation up-sampling is done first or last in the processing chain, respectively, in order to avoid clipping.

That's my vision on how to deal with the different RG approaches: the player should handle it. In order to do this the player should have as much information as possible, e.g. a REPLAYGAIN_ALGORITHM tag, a REPLAYGAIN_REFERENCE_LOUDNESS tag, different units (dB, LUSF), etc.

Some recent posts point in the opposite direction, i.e. they are in favor for washing out this information:

It is wrong because it causes existing RG players to malfunction. Exiting players do not know about REPLAYGAIN_ALGORITHM and they assume that existing REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags are in dB units releaive to a -14 dBFS reference. Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.

For a mixed selection of pre-loudness-war material (Kuschelrock Vols. 1 and 2, 4 CDs total), I get an average track-gain difference between the RG and R128 algorithms of exactly 4.6 dB (or LU). Since Raiden got 5.11 dB, I think the 5 dB proposed in Dolby's AES paper are well chosen. Hence, R128gain should write

[blockquote]-18 - R128 LUFS loudness[/blockquote]
instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.

I agree with Christian, you should write a 'calibrated' gain value, and use dB instead of LUFS. 

As for calibration, I would think that finding a zero-order adjustment that minimized RMS difference rather than simply the average would be better.  I'll test my library as well (huge mix of genres)

Fortunately there is a simple solution: With the next version R128GAIN will offer a "wash out" switch.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Surfi on 2011-01-15 21:18:08
::

Seems r128gain doesn't like 32-bit PCM .wav.

Code: [Select]
  analyzing ...
    [01] The Honeymoon - Passive Aggressive.wav (1/1): -2.9 LUFS, -20.1 LU (peak: 1.447794: 1.6 dBFS)
    ALBUM: -2.9 LUFS, -20.1 LU (peak: 1.447794: 1.6 dBFS)
  writing ...
    [01] The Honeymoon - Passive Aggressive.wav (1/1) ... re-encoding via SoX
... wav: wave header missing FmtExt chunk
done.



Greetings ...

::
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-15 21:52:41
Seems r128gain doesn't like 32-bit PCM .wav.

Probably ...

For a moment I thought about dropping the transcoding option to FLAC, and I think it would be best. R128GAIN is an EBU R128 compliant tagger and not the one in all solution. Instead you should
BTW: Is FLAC able to transcode 32 bit WAVs? I'm not certain about it ...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Surfi on 2011-01-15 21:57:31
BTW: Is FLAC able to transcode 32 bit WAVs? I'm not certain about it ...
::

Yes, it is.

::
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-15 22:25:51
BTW: Is FLAC able to transcode 32 bit WAVs? I'm not certain about it ...
::

Yes, it is.

::

What happens if you process the resulting FLAC with R128GAIN?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Surfi on 2011-01-15 22:45:35
BTW: Is FLAC able to transcode 32 bit WAVs? I'm not certain about it ...
::

Yes, it is.

::

What happens if you process the resulting FLAC with R128GAIN?
::

You have my apologies. FLAC isn't able to transform too! (throwing an "unsupported format type")
Thanks for the scanner, keep up the good work.

Best regards ...

::
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-16 13:26:20
v0.5 released[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)
http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
[/blockquote]What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Rescator on 2011-01-16 14:58:16
Interesting. I did some tests with my own RMS tool (nicknamed K20RMS currently as it uses the K-System and K-20 headroom but with a Z weighting "flat filter" aka plain RMS).

Using the same test suit as R128 http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
I get the following:
Code: [Select]
K20RMS v1.0
E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\1kHz Sine -20 LUFS-16bit.wav
Within 1dB (+/- 0.5dB) and peak is 0.0 dBFS or less.
Gain adjustment is not advised in this case.
Title RMS: -19.93 dBFS (0.1008560, 83.07 dBSPL)
Title Peak: -19.94 dBFS (0.1007385)
Title Dynamic Range: 0.03 dB (max RMS -19.91 dBFS, min RMS -19.94 dBFS)
Title Dynamic Headroom: -0.01 dB (0.9988354)
Title Dynamic Energy: 0.02 dB (1.0019993)
Title Gain ref -20dBFS/83dBSPL: -0.07 dB (0.9915128)
Title Modifier: -0.07 dB (0.9915128)
Title Final Peak: -20.01 dBFS (0.0998835)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\1kHz Sine -26 LUFS-16bit.wav
Title RMS: -25.90 dBFS (0.0506862, 77.10 dBSPL)
Title Peak: -25.93 dBFS (0.0505066)
Title Dynamic Range: 0.04 dB (max RMS -25.88 dBFS, min RMS -25.93 dBFS)
Title Dynamic Headroom: -0.03 dB (0.9964557)
Title Dynamic Energy: 0.02 dB (1.0024331)
Title Gain ref -20dBFS/83dBSPL: 5.90 dB (1.9729222)
Title Modifier: 5.90 dB (1.9729222)
Title Final Peak: -20.03 dBFS (0.0996456)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\1kHz Sine -40 LUFS-16bit.wav
Title RMS: -39.96 dBFS (0.0100410, 63.04 dBSPL)
Title Peak: -39.78 dBFS (0.0102539)
Title Dynamic Range: 0.03 dB (max RMS -39.95 dBFS, min RMS -39.98 dBFS)
Title Dynamic Headroom: 0.18 dB (1.0212016)
Title Dynamic Energy: 0.02 dB (1.0020251)
Title Gain ref -20dBFS/83dBSPL: 19.96 dB (9.9591475)
Title Modifier: 19.96 dB (9.9591475)
Title Final Peak: -19.82 dBFS (0.1021202)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-1-16bit.wav
Title RMS: -22.91 dBFS (0.0714933, 80.09 dBSPL)
Title Peak: -22.94 dBFS (0.0713196)
Title Dynamic Range: 0.03 dB (max RMS -22.90 dBFS, min RMS -22.93 dBFS)
Title Dynamic Headroom: -0.02 dB (0.9975703)
Title Dynamic Energy: 0.01 dB (1.0016830)
Title Gain ref -20dBFS/83dBSPL: 2.91 dB (1.3987327)
Title Modifier: 2.91 dB (1.3987327)
Title Final Peak: -20.02 dBFS (0.0997570)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-2-16bit.wav
Title RMS: -32.94 dBFS (0.0225409, 70.06 dBSPL)
Title Peak: -32.75 dBFS (0.0230408)
Title Dynamic Range: 0.03 dB (max RMS -32.93 dBFS, min RMS -32.95 dBFS)
Title Dynamic Headroom: 0.19 dB (1.0221772)
Title Dynamic Energy: 0.01 dB (1.0015823)
Title Gain ref -20dBFS/83dBSPL: 12.94 dB (4.4363842)
Title Modifier: 12.94 dB (4.4363842)
Title Final Peak: -19.81 dBFS (0.1022177)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-3-16bit.wav
Title RMS: -27.53 dBFS (0.0420017, 75.47 dBSPL)
Title Peak: -22.92 dBFS (0.0714722)
Title Dynamic Range: 17.08 dB (max RMS -22.91 dBFS, min RMS -39.99 dBFS)
Title Dynamic Headroom: 4.62 dB (1.7016501)
Title Dynamic Energy: 4.62 dB (1.7021379)
Title Gain ref -20dBFS/83dBSPL: 7.53 dB (2.3808570)
Title Modifier: 7.53 dB (2.3808570)
Title Final Peak: -15.38 dBFS (0.1701650)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-4-16bit.wav
Title RMS: -29.63 dBFS (0.0329802, 73.37 dBSPL)
Title Peak: -23.00 dBFS (0.0708008)
Title Dynamic Range: 51.77 dB (max RMS -22.82 dBFS, min RMS -74.58 dBFS)
Title Dynamic Headroom: 6.64 dB (2.1467686)
Title Dynamic Energy: 6.82 dB (2.1926796)
Title Gain ref -20dBFS/83dBSPL: 9.63 dB (3.0321255)
Title Modifier: 9.63 dB (3.0321255)
Title Final Peak: -13.36 dBFS (0.2146769)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-5-16bit.wav
Title RMS: -22.94 dBFS (0.0713034, 80.06 dBSPL)
Title Peak: -19.93 dBFS (0.1008301)
Title Dynamic Range: 6.03 dB (max RMS -19.92 dBFS, min RMS -25.95 dBFS)
Title Dynamic Headroom: 3.01 dB (1.4140999)
Title Dynamic Energy: 3.02 dB (1.4154997)
Title Gain ref -20dBFS/83dBSPL: 2.94 dB (1.4024584)
Title Modifier: 2.94 dB (1.4024584)
Title Final Peak: -16.99 dBFS (0.1414100)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-6-5channels-16bit.wav
Title RMS: -27.19 dBFS (0.0436962, 75.81 dBSPL)
Title Peak: -24.00 dBFS (0.0630798)
Title Dynamic Range: 0.00 dB (max RMS -27.19 dBFS, min RMS -27.19 dBFS)
Title Dynamic Headroom: 3.19 dB (1.4435992)
Title Dynamic Energy: 0.00 dB (1.0000000)
Title Gain ref -20dBFS/83dBSPL: 7.19 dB (2.2885273)
Title Modifier: 7.19 dB (2.2885273)
Title Final Peak: -16.81 dBFS (0.1443599)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-6-6channels-WAVEEX-16bit.wav
Title RMS: -27.19 dBFS (0.0436962, 75.81 dBSPL)
Title Peak: -24.00 dBFS (0.0630798)
Title Dynamic Range: 0.00 dB (max RMS -27.19 dBFS, min RMS -27.19 dBFS)
Title Dynamic Headroom: 3.19 dB (1.4435992)
Title Dynamic Energy: 0.00 dB (1.0000000)
Title Gain ref -20dBFS/83dBSPL: 7.19 dB (2.2885273)
Title Modifier: 7.19 dB (2.2885273)
Title Final Peak: -16.81 dBFS (0.1443599)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-7_seq-3342-5-24bit.wav
Title RMS: -22.59 dBFS (0.0742564, 80.41 dBSPL)
Title Peak: -8.91 dBFS (0.3583316)
Title Dynamic Range: 13.72 dB (max RMS -16.88 dBFS, min RMS -30.60 dBFS)
Title Dynamic Headroom: 13.67 dB (4.8255968)
Title Dynamic Energy: 5.70 dB (1.9282742)
Title Gain ref -20dBFS/83dBSPL: 2.59 dB (1.3466849)
Title Modifier: 2.59 dB (1.3466849)
Title Final Peak: -6.33 dBFS (0.4825597)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3341-8_seq-3342-6-24bit.wav
Clipping caused by the gain, modifier was adjusted to protect peaks,
volume will be lower than expected.
Title RMS: -23.90 dBFS (0.0638479, 79.10 dBSPL)
Title Peak: -2.87 dBFS (0.7182941)
Title Dynamic Range: 31.36 dB (max RMS -11.96 dBFS, min RMS -43.31 dBFS)
Title Dynamic Headroom: 21.02 dB (11.2500906)
Title Dynamic Energy: 11.94 dB (3.9531405)
Title Gain ref -20dBFS/83dBSPL: 3.90 dB (1.5662234)
Title Modifier: 2.87 dB (1.3921874)
Title Final Peak: 0.00 dBFS (1.0000000)
Title Final RMS: -21.02 dBFS (0.0888882, 81.98 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3342-1-16bit.wav
Title RMS: -22.41 dBFS (0.0757570, 80.59 dBSPL)
Title Peak: -20.00 dBFS (0.1000061)
Title Dynamic Range: 10.00 dB (max RMS -19.82 dBFS, min RMS -29.82 dBFS)
Title Dynamic Headroom: 2.41 dB (1.3200905)
Title Dynamic Energy: 2.60 dB (1.3484154)
Title Gain ref -20dBFS/83dBSPL: 2.41 dB (1.3200099)
Title Modifier: 2.41 dB (1.3200099)
Title Final Peak: -17.59 dBFS (0.1320090)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3342-2-16bit.wav
Title RMS: -16.63 dBFS (0.1473578, 86.37 dBSPL)
Title Peak: -15.00 dBFS (0.1778259)
Title Dynamic Range: 5.00 dB (max RMS -14.82 dBFS, min RMS -19.82 dBFS)
Title Dynamic Headroom: 1.63 dB (1.2067628)
Title Dynamic Energy: 1.82 dB (1.2326562)
Title Gain ref -20dBFS/83dBSPL: -3.37 dB (0.6786202)
Title Modifier: -3.37 dB (0.6786202)
Title Final Peak: -18.37 dBFS (0.1206763)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3342-3-16bit.wav
Title RMS: -22.78 dBFS (0.0725930, 80.22 dBSPL)
Title Peak: -20.00 dBFS (0.1000061)
Title Dynamic Range: 20.00 dB (max RMS -19.82 dBFS, min RMS -39.81 dBFS)
Title Dynamic Headroom: 2.78 dB (1.3776278)
Title Dynamic Energy: 2.97 dB (1.4071872)
Title Gain ref -20dBFS/83dBSPL: 2.78 dB (1.3775438)
Title Modifier: 2.78 dB (1.3775438)
Title Final Peak: -17.22 dBFS (0.1377628)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

E:\Downloads\Audio\audio tests\ebu-loudness-test-setv01\seq-3342-4-16bit.wav
Title RMS: -26.53 dBFS (0.0471508, 76.47 dBSPL)
Title Peak: -20.00 dBFS (0.1000061)
Title Dynamic Range: 29.99 dB (max RMS -19.82 dBFS, min RMS -49.80 dBFS)
Title Dynamic Headroom: 6.53 dB (2.1209822)
Title Dynamic Energy: 6.72 dB (2.1664915)
Title Gain ref -20dBFS/83dBSPL: 6.53 dB (2.1208527)
Title Modifier: 6.53 dB (2.1208527)
Title Final Peak: -13.47 dBFS (0.2120982)
Title Final RMS: -20.00 dBFS (0.1000000, 83.00 dBSPL)

Clipping caused by gain, modifier adjusted to protect peaks.
Album RMS: -23.69 dBFS (0.0654086, 79.31 dBSPL)
Album Peak: -2.87 dBFS (0.7182941)
Album Dynamic Range: 62.62 dB (max -11.96 dBFS, min -74.58 dBFS)
Album Dynamic Headroom: 20.81 dB (10.9816437)
Album Dynamic Energy: 11.73 dB (3.8588116)
Album Gain ref -20dBFS: 3.69 dB (1.5288506)
Album Modifier: 2.87 dB (1.3921874)
Album Final Peak: 0.00 dBFS (1.0000000)
Album Final RMS: -20.81 dBFS (0.0910610, 82.19 dBSPL)
As you can see R128 is much closer to RMS, and if you run the test suit through ReplayGain (foobar2000) you can see that RG89 is a tad more inconsistent, so R128 is looking pretty good so far.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bryant on 2011-01-16 15:46:15
I have been following this with interest, but I would like to echo what the others are saying and suggest that changing the meaning of the existing ReplayGain tags would be a huge mistake. It breaks the (admittedly undocumented) ReplayGain specs and would instantly break all existing players and cause a lot of long-term confusion and frustration with users of ReplayGain (which is probably not what anyone  wants).

If you want to have a different meaning to the tags that’s fine, but I think you should use different names in that case, like REPLAYGAIN_TRACK_GAIN_EBU, or something. What is the advantage of keeping the same tag names when the meaning has changed and the players will have to be modified to use them anyway? Players that want to take advantage of the new method can query the different names.

You could still have the --transitional option to write out compatible tags, but having the default behavior be to break existing players makes no sense to me. It would be sad if this new and better scanner/tagger got a bad reputation because of this oversight.

David

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-16 17:18:17
You could still have the --transitional option to write out compatible tags, but having the default behavior be to break existing players makes no sense to me. It would be sad if this new and better scanner/tagger got a bad reputation because of this oversight.

Just to give you another reason: The example above, Jethro Tull's "Budapest", taken from the original CD "Crest Of A Knafe" (no remaster), was not chosen by accident. The amplification and peak values are with respect to a pre-amp of 2 dB relative to -23 dBFS (EBU R128). If you consider a build-in "pre-amp" of 5 dB the play-back would be hopefully clipped by as much as 3 dB.

EBU R128 is completely different than traditional ReplayGain. The people should know what they are doing.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-16 18:08:21
Quote
EBU R128 is completely different than traditional ReplayGain.


From player's (h/w or s/w) point of view, no. They both calculate value of gain that player should apply to a track.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-17 11:18:43
  • Without "--transitional" you get EBU R128 compliant tags:
Please be very careful what you write. EBU R128 doesn't define a tagging standard, so it's hard to see how any tags you write could be "compliant" with EBU R128.

I think I know what you mean, but it's not exactly what you said.

And I agree with bryant entirely.

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-17 12:09:16
  • Without "--transitional" you get EBU R128 compliant tags:
Please be very careful what you write. EBU R128 doesn't define a tagging standard, so it's hard to see how any tags you write could be "compliant" with EBU R128.

I think I know what you mean, but it's not exactly what you said.

To make it clear: You get instantan EBU R128 conformant playback by each player supporting RG tags. Nothing is broken.

And I agree with bryant entirely.

I will think about it till the next release.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-17 12:48:49
I think the "--transitional" mode is fine. You get exactly the same as what original ReplayGain delivers, just computed by a better loudness estimator.

But using the name "REPLAYGAIN_*" for new, incompatible R128 tags is really bad and would lead to a lot of confusion. This mode should not be the default! If at all, give it a "--babylon" switch, which is IMHO the most adequate description.

I'd vote for writing "--transitional" (or traditional) tags as default and add an additional set of "R128_TRACK_GAIN" etc. tags for players, which want to follow R128 to the last word (I don't really see any practical benefit in comparison to traditional RG).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-23 16:30:46
v0.6 released
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-23 19:02:57
Suuuuper !!!

Thank you very much !

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-24 08:45:08
BTW, working with the GUI, how can I convert to FLAC now?

Thank you

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-24 15:06:53
BTW, working with the GUI, how can I convert to FLAC now?

Unfortunately transcoding to FLAC doesn't made it into the first GUI version (due to lack of time). Hopefully this will change with the next version.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-24 15:18:14
ok thank you !
Thought I missed something (again) ;-)

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Surfi on 2011-01-24 21:06:08
::

First: Many thanks for this tool. I'm very happy with it.
Now my question: Is it possible to implement an option for tagging (FLAC) files without copying them?

[EDIT] Oh, and I get exactly the same results for --fast and --true-peak=off. Where's the difference of these two switches? [/EDIT]


Greetings ...

::
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-25 06:56:42
Now my question: Is it possible to implement an option for tagging (FLAC) files without copying them?

Technically tagging only is the following anyway:
The disadvatages of such an approach are:
Propably the tool will offer such an option with the next release. But please don't blame me if something's going wrong and your original files are lost.

Oh, and I get exactly the same results for --fast and --true-peak=off. Where's the difference of these two switches?

If you try this on contemporary over-compressed (hard limited) CDs you will observe inter-sample peaks up to 0.8 dBFS (which is impossible for sample peaks with a technical maximum of 0.0 dBFS).

Currently there is no difference between these two options. They're just synonyms.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kode54 on 2011-01-26 07:16:35
[a href='index.php?showtopic=86404']Blammo.[/a]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-26 15:32:48
FYI - I did a comparison of ReplayGain and R128 (based on the libebur128 code in the other thread) and found -17.25 LU to be a good reference loudness level for R128 to match the 89dB reference level of ReplayGain.

More specifically, regression analysis indicated that the gain adjustment should actually be -17.5 - 1.05*R128  (e.g. an R128 value of -10LU would correspond to -8.55dB gain adjustment), but I don't like the idea of having the beta coefficient not be 1.0.

This was done on a 45,000 track test library.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-26 16:20:06
My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

http://img816.imageshack.us/img816/5396/rgr128.png (http://img816.imageshack.us/img816/5396/rgr128.png)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-26 16:37:52
My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

http://img816.imageshack.us/img816/5396/rgr128.png (http://img816.imageshack.us/img816/5396/rgr128.png)


foo_r128scan is using -18.0 - 1.0 * R128, so your finding of a 0.62dB difference corresponds fairly well with my proposal of -17.25 - 1.0 * R128    (your data would suggest -17.38 - 1.0 * R128).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: spies on 2011-01-26 17:14:23
This was done on a 45,000 track test library.

My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

I assume you both did the comparison in track mode and I am curious if the results are the same in album mode.

Duh, I see now looking at lvqcl graphic is that it contains both track and album mode so I assume the result is the averaging of the two.  I am still curious what the results are when just comparing track or album mode.

Obviously I am not quite awake yet but now I see that lvqcl's result is based on track information.  How does it compare to album and the averaging of the two?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-26 17:30:58
This was done on a 45,000 track test library.

My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

I assume you both did the comparison in track mode and I am curious if the results are the same in album mode.

Duh, I see now looking at lvqcl graphic is that it contains both track and album mode so I assume the result is the averaging of the two.  I am still curious what the results are when just comparing track or album mode.


I compared only track mode.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-26 18:21:20
Track mode (2124 tracks): foo_R128 = foo_RG - 0.62
Album mode (175 albums): foo_R128 = 0.93*foo_RG - 1.01
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-26 23:15:41
My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

http://img816.imageshack.us/img816/5396/rgr128.png (http://img816.imageshack.us/img816/5396/rgr128.png)

Nice plot! My first question would be: could you give us the names of the songs on which the two algorithms strongly diverge, esp. the ones at [R128=-2, RG=6], [R128=-6ish, RG=1ish], [R128=1.5, RG=-2.5]?

The same question of course also goes to benski, if he has such data!

Edit: Guess I should have read this (http://www.hydrogenaudio.org/forums/index.php?showtopic=86424) first.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-26 23:25:53
Yes, that thread.

I also uploaded 3 short (~20 sec) samples here: http://www.hydrogenaudio.org/forums/index....showtopic=86429 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86429)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-26 23:39:02
I got snowed in today and don't have access to the data at the lab at the office.  I'll find some outlier tracks tomorrow (there were some major ones!) and post details.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-28 19:20:08
This might be of interest:

Grimm Audio (http://www.grimmaudio.com/index.html) has published an EBU R128 compliant Loudness scanner and Loudness Normalizer called "Level One".

There is a Demo ready for download in the web shop.
Here is the link to the manual: Manual Download (http://www.grimmaudio.com/product_info/Manual%20LevelOne.pdf)

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: spies on 2011-01-28 20:19:46
url="http://www.grimmaudio.com/index.html"]Grimm Audio[/url] has published an EBU R128 compliant Loudness scanner and Loudness Normalizer called "Level One".

Looks nice and perhaps I will download the demo but € 450.00 excl. VAT! 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: punkrockdude on 2011-01-28 20:32:07
Hi guys. Is it the oversampling which makes the scanning procedur really slow and is the volume supposed to be quite alot quieter than replay gain? Regards.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-28 21:34:24
Is it the oversampling which makes the scanning procedur really slow

Yes. You may switch it off by disabling "True Peak".

The next version will have a bit faster "True Peak" mode.

is the volume supposed to be quite alot quieter than replay gain? Regards.

It is about 5 dB quieter compared to ReplayGain. You may switch on ReplayGain compatible mode, it makes it about 5 dB louder.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bryant on 2011-01-28 21:58:26
is the volume supposed to be quite alot quieter than replay gain? Regards.

It is about 5 dB quieter compared to ReplayGain. You may switch on ReplayGain compatible mode, it makes it about 5 dB louder.

This is the confusion I was referring to earlier.

Have you considered the suggestion of using different tag names when writing incompatible gain information?

Regards,
David
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-28 22:30:22
This is the confusion I was referring to earlier.

As it seems there is a lot of confusion out there:
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.

This tool is about EBU R128 in it's entirety, not only about BS.1770.

EDIT: The following are some out of the reasons why I don't like to have any ad-hoc assumptions regarding the correlation between R128 and RG in the tool:

More specifically, regression analysis indicated that the gain adjustment should actually be -17.5 - 1.05*R128  (e.g. an R128 value of -10LU would correspond to -8.55dB gain adjustment)

Especially this one:

but I don't like the idea of having the beta coefficient not be 1.0.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: punkrockdude on 2011-01-28 23:12:45
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-28 23:18:08
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Yep. That's the whole reason for "true" peak. Exactly the same you can expect to happen during playback, i.e. even if the record itself technically doesn't clip, during playback it may happen. I observed clipping according to "true peak" up to 1 dB for brickwall limited records (not restricted to them).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-29 09:41:51
Quote
Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled?


Yes exactly, please google for "Intersample Peaks".

Recommended comprehensive reading: 0dBFS+ Levels in Digital Mastering (http://www.tcelectronic.com/media/Level_paper_AES109.pdf)

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-29 17:07:17
As it seems there is a lot of confusion out there:
  • If I go to the EBU R128 (http://tech.ebu.ch/loudness) page the first thing I see is -23 LUFS. Written in boldface and highlighted by blue color. If you like to blame someone go there.
  • If I see something labeled EBU R128 conformant than that's exactly what I expect.
  • What seems to be completely mixed-up in this forum is the difference between BS.1770 and EBU R128. EBU R128 is essentially -23 LUFS, about 5 dB below RG.
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.

If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags. You should not be reusing ReplayGain tags. You will do as you will, I suppose; there is no tag police to enforce this and documentation for ReplayGain tags is just now coming into existence.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-29 17:15:52
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: [JAZ] on 2011-01-29 17:15:59
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.


If i get a file with ReplayGain information, as in the file has the tags used by a Replaygain-compatible scanner to indicate gain i would expect that tool to conform to the replaygain standard meaning for those tags. It is not important what is used to calculate the tags, or the amount of difference from the reference implementation. What is important is that the tags mean exactly what Replaygain says it means.


If you write replaygain tags, you ought to write them with the meaning that Replaygain applies.
If you want to conform to R128, the tags need to be different, and those can be in conformance with what R128 says.

So you got the option wrong. Specifying replaygain in your tool should specify "write the scanning data as replaygain-compatible tags", while r128 should mean "write the scanning data as a new tag format which is not the replaygain tags".


Else, you're just making a double standard, and this is what you are being warned about repetitively in this thread.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 17:50:23
If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags. You should not be reusing ReplayGain tags. You will do as you will, I suppose; there is no tag police to enforce this and documentation for ReplayGain tags is just now coming into existence.

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.

The tool makes it obvious to any user when it is in accordance with RG and when not. If you don't like the idea to have "True Peak" for RG I change the tool accordingly.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 17:52:34

If you write replaygain tags, you ought to write them with the meaning that Replaygain applies.
If you want to conform to R128, the tags need to be different, and those can be in conformance with what R128 says.

It's not me writing the tags. It's possibly you by hitting the button. If you don't like it just leave it.


this is what you are being warned about repetitively in this thread.

WTF?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 18:14:31
If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags.

If i get a file with ReplayGain information, as in the file has the tags used by a Replaygain-compatible scanner to indicate gain i would expect that tool to conform to the replaygain standard meaning for those tags. It is not important what is used to calculate the tags, or the amount of difference from the reference implementation. What is important is that the tags mean exactly what Replaygain says it means.

Just to make it clear for another time: the tool follows benski's proposal to indicate the difference:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 18:23:10
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.

Done.

The next release will flag  checked "True Peak" as non RG compliant.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nick.C on 2011-01-29 19:10:54
.... but surely if you are using existing ReplayGain tag names then a legacy program will not be able to differentiate using the new REPLAYGAIN_ALROGITHM tag as it will ignore it. Is there therefore a risk that the program will apply the wrong gain?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 19:44:53
.... but surely if you are using existing ReplayGain tag names then a legacy program will not be able to differentiate using the new REPLAYGAIN_ALROGITHM tag as it will ignore it. Is there therefore a risk that the program will apply the wrong gain?

The algorithm is applied during scan time, not at playback time. Both, RG and R128, scan the files, determine a gain, and write it to a tag. At playback time the player reads the tag and applies the gain accordingly. That's all.

The discussion is only about the loudness against which the gain is measured. RG says (about) -18.0 LUFS, R128 says -23 LUFS, hence R128 appears quieter during playback (by about 5 dB).

Hi guys. Is it the oversampling which makes the scanning procedur really slow and is the volume supposed to be quite alot quieter than replay gain? Regards.

That's the only consequence. It's just like discussing Fahrenheit vs. Celsius. If you don't like the one, chose the other. It's just one click on the GUI. The player will apply exactly the gain value according to the standard you've chosen.

It's your choice. Nothing is hard coded. The tools does nothing behind your back. It does exactly what you tell it. It's all visible on the GUI.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: [JAZ] on 2011-01-29 21:26:13
Just to make it clear for another time: the tool follows benski's proposal to indicate the difference:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0
or
REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done



That tells which algorithm was used to calculate the tags, not to which reference level the gains are based on. Replaygain expects it to be compared to -89dB (K-14 if you preffer). You can make the calculation with R128 at -23LUs, but when saving a replaygain tag, the gain needs to be relative to -89dB.


So no, this is not "A click on the GUI" neither about the unit used in the value. LUs vs dBs would be like Fahrenheit vs Celsius. A different base for the gain information is not.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-29 21:34:20
You can make the calculation with R128 at -23LUs, but when saving a replaygain tag, the gain needs to be relative to -89dB.

Are you really know what you are talking about? Sure?

Ever heard about the difference between absolute and relative values? What of the two you guess is a gain?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: [JAZ] on 2011-01-29 21:48:11
The gain that is written in a replaygain tag is relative. And by definition, a relative "something" needs an absolute value to be compared to.

Replaygain strictly defines (or at least now that the documentation is being rewritten) that the absolute value to which the relative gains are calculated, be -89dB.


What is it that I am missing?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-29 22:55:22
Has anyone read the paper from Dolby at AES128 comparing ITU-R BS.1770 to Replay Gain.  They suggest a -18 LU reference loudness for comparison with Replay Gain.  I'm in contact with Martin Wolters (one of the authors of the paper) to try to see if we can pinpoint the reference level exactly.

Also, I strongly object to writing REPLAYGAIN_ALBUM_GAIN and REPLAYGAIN_TRACK_GAIN values that are referenced to something other than 89dB ReplayGain (which corresponds somewhere between -17 LU and -18 LU).  ReplayGain is meant as a standard for playback and the exact means of how the volume adjustment was determined do not matter as long as the reference loudness is the same.  It might have been done manually, RMS average, or using the filter recommended in the original proposal.  The spec even allows for such differences in algorithms to exist!

If pbelkner is unwilling to do that, that's his decision as it's also his tool.  But it's not the only tool - Raiden has released libebur128 which kode54 has already integrated into a Foobar2000 scanner, and which I'm also using as a basis for a Winamp scanner.  I just want to sort out the reference level / calibration issue before releasing anything official.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 00:39:38
If pbelkner is unwilling to do that

Did you ever had a closer look at R128GAIN?

Version 0.7 released:
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]How do you come to say that I'm unwilling to write the tags compatible with RG? With this tool you are the one deciding how the tags are written.

Other news:

EDIT: Command line options:

Code: [Select]
$ r128gain --help
An EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.
For details refer to "http://r128gain.sourceforge.net/".

Usage: r128gain [options] (file|directory)+ [-o <directory> [flac]]
Options:
  --r128             Run in EBU R128 compliant mode (default).
  --rg               Run in ReplayGain compliant mode.
  --r128-compatible  Calibrate output according to EBU R128.
  --rg-compatible    Calibrate output according to ReplayGain.
  --rg-calibration=<float>  Aequivalent to use for ReplayGain
                     loudness (default: -18.0).
  --true-peak=on,--true-peak  Up-sample for peak determination.
  --true-peak=off,--fast  Switch off up-sampling.
  --in-place         Allow overwriting of files in place.
  --regression       Calculate linear regression between EBU R128
                     and ReplayGain.
  --duration         Print out duration.
  --version          Display version information.
  --help             Display this information.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 01:19:22
LIB1770 v0.1 released

I've started to factor out some code from R128GAIN and to put it into a library called LIB1770:
[blockquote]http://sourceforge.net/projects/r128gain/files/lib1770/ (http://sourceforge.net/projects/r128gain/files/lib1770/)[/blockquote]The library is under LGPL 2.1 (or any later).

The public API resembles the one known from the wide spread RG implementation "gain_analysis.c":

Code: [Select]
ctx=bs1770_ctx_open()

for each album {
  for each track {
    while there are samples
      bs1770_ctx_add_sample(ctx, rate, channels, sample)

    bs1770_ctx_track_lufs(ctx, rate, channels)
  }

  bs1770_ctx_album_lufs(ctx)
}

bs1770_ctx_close(ctx)

Following is an example program which reproduces the EBU R128 test vector:

Code: [Select]
#include <stdio.h>
#include "bs1770_ctx.h"

// assume 2 channel interleaved/48 kHz/64 bit float raw pcm.
#define CHANNELS  2
#define RATE      48000

#define BUF_SIZE  (CHANNELS*4096)

int main(int argc, char **argv)
{
  static double buf[BUF_SIZE];

  bs1770_ctx_t *ctx;
  int i,j;
  FILE *f;
  size_t n;
  bs1770_sample_t sample;

  // print out library version.
  fprintf(stderr, "lib1770 v%s\n", bs1770_version);

  // open a 1770 context.
  if (NULL==(ctx=bs1770_ctx_open()))
    goto cleanup;

  // for each track ...
  for (i=1;i<argc;++i) {
    int channel=0;  // offset in sample vector.

    // open the raw pcm stream.
    if (NULL==(f=fopen(argv[i],"rb")))
      continue;

    // display the name of the current track.
    fprintf(stderr, "%s: ", argv[i]);
    fflush(stderr);

    // while there are samples ...
    while (0<(n=fread(buf, sizeof buf[0], BUF_SIZE, f))) {
      // consume the samples read.
      for (j=0;j<n;++j) {
        // build up a sample vector accross the channels.
        // NOTE: client code may apply a "channel map" right here.
        //   lib1770 assumes the order "left", "right", "centre",
        //   "left sorround", "right sorround".
        if (channel<BS1770_MAX_CHANNELS)
          sample[channel]=buf[j];

          // if the sample vector is done add it to the 1770 statistics.
          if (++channel==CHANNELS) {
            bs1770_ctx_add_sample(ctx, RATE, CHANNELS, sample);
            channel=0;
          }
      }
    }

    // print out track statistics (implicitely clears).
    fprintf(stderr, "%.1f LUFS.\n", bs1770_ctx_track_lufs(ctx,
        RATE, CHANNELS));

    // close the raw stream.
    fclose(f);
  }

  // print out album statistics (implicitely clears).
  fprintf(stderr, "ALBUM: %.1f LUFS.\n", bs1770_ctx_album_lufs(ctx));
cleanup:
  // close the 1770 context.
  if (NULL!=ctx)
    bs1770_ctx_close(ctx);

  return 0;
}

In order to run the test vector you first have to convert it into 2 channel interleaved/48 kHz/64 bit float raw pcm. This can be achieved using SoX in the following way:

Code: [Select]
sox a.wav -c 2 -b 64 -e float b.raw

The above example program produces the following output:

Code: [Select]
$ example ../sounds/ebu-loudness-test-setv01/*.raw
lib1770 v0.1
../sounds/ebu-loudness-test-setv01/1kHz Sine -20 LUFS-16bit.raw: -20.0 LUFS.
../sounds/ebu-loudness-test-setv01/1kHz Sine -26 LUFS-16bit.raw: -26.0 LUFS.
../sounds/ebu-loudness-test-setv01/1kHz Sine -40 LUFS-16bit.raw: -40.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-1-16bit.raw: -23.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-2-16bit.raw: -33.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-3-16bit.raw: -23.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-4-16bit.raw: -23.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-5-16bit.raw: -22.9 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-6-5channels-16bit.raw: -27.8 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-6-6channels-WAVEEX-16bit.raw: -28.9 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-7_seq-3342-5-24bit.raw: -23.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3341-8_seq-3342-6-24bit.raw: -23.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3342-1-16bit.raw: -22.6 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3342-2-16bit.raw: -16.8 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3342-3-16bit.raw: -20.0 LUFS.
../sounds/ebu-loudness-test-setv01/seq-3342-4-16bit.raw: -20.0 LUFS.
ALBUM: -21.9 LUFS.

Please note the deviation for multichannel. This is because these samples where down-mixed beforehand by SoX into two channels.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-30 03:09:23
Correct me if I'm wrong but it is my understanding that in R128 mode, R128Gain writes "REPLAYGAIN_*" tags with R128 values. I'd find no fault if it instead wrote "EBUR128_*" tags or somesuch in this mode.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-30 03:58:12
Quote
Replaygain strictly defines (or at least now that the documentation is being rewritten) that the absolute value to which the relative gains are calculated, be -89dB.


There is no absolute value such as -89dB.

Absolute values are dBu, dBm, dBV, dBW, dBµV, dB (A), dBFS etc.

R128gain (and R128) uses unambiguously Full Scale FS as a reference, so the target is -23 LUFS (which in fact corresponds to -23 dBFS).


Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: GHammer on 2011-01-30 04:28:06
Correct me if I'm wrong but it is my understanding that in R128 mode, R128Gain writes "REPLAYGAIN_*" tags with R128 values. I'd find no fault if it instead wrote "EBUR128_*" tags or somesuch in this mode.

I'd think this is for compatibility with RG capable players.
Kind of useless to have a tool that works, appears to be better than an existing tool, but have no way to hear the results.

So, if I wish to use this tool, how do you propose that I listen with the calculated gain if not by using existing tags?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-30 10:24:47
So, if I wish to use this tool, how do you propose that I listen with the calculated gain if not by using existing tags?


By using R128 based loudness estimation AND writing REPLAY_GAIN_* based values calibrated to the same loudness as what ReplayGain compatible players expect (so that all tracks can be played back at about the same volume).

The mode, that pbelkner calls "R128 compliant" hijacks the REPLAY_GAIN tag format an writes incompatible values into it. Incompatible since those tracks will play back only about half as loud as traditional RG tracks (~5 dB). This is totally unnecessary and only due to pbelkner's somewhat odd interpretation of what R128 'compliance' should be inside a ReplayGain compliant tag.

Of course, one could have the benefit of both worlds, the better loudness estimation of R128 and playback compatibility to existing ReplayGain tagged collections - with REPLAY_GAIN_* tags but without the 5 dB difference! I do not really see the benefit of more than two options, the latter plus one plain R128 with R128_* tags.

Instead pbelkner now just drowns the user in options. I do not see the benefit of that either. Lets not forget, why one chooses to use RG, to get consistent loudness over a music collection. The current presets will introduce a lot of ~5dB inconsistencies. Up to know I associate ReplayGain with simplicity. Why change that without necessity? More choice is not always better.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 10:47:53
Instead pbelkner now just drowns the user in options.

This tool is not and was never aimed for the mass market. It's aimed to the curious who want to learn something along the way.

BTW: That's the only reason why I'm bothering myself.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-30 11:02:49
There is no absolute value such as -89dB.

Absolute values are dBu, dBm, dBV, dBW, dBµV, dB (A), dBFS etc.

And ReplayGain uses dB SPL.

( http://replaygain.hydrogenaudio.org/calibration.html (http://replaygain.hydrogenaudio.org/calibration.html) , http://en.wikipedia.org/wiki/Sound_pressur..._pressure_level (http://en.wikipedia.org/wiki/Sound_pressure#Sound_pressure_level) )
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 13:10:29
Version 0.7.1 released:
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]It's a bug-fix. There where reportedly noticeable gaps introduced at the end of re-written MP3s. In order to fix that changed av_write_frame() (http://wiki.aasimon.org/doku.php?id=ffmpeg:av_write_frame) into av_interleaved_write_frame() (http://wiki.aasimon.org/doku.php?id=ffmpeg:av_interleaved_write_frame). Hope this helps.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-01-30 14:21:54
Has anyone read the paper from Dolby at AES128 comparing ITU-R BS.1770 to Replay Gain.  They suggest a -18 LU reference loudness for comparison with Replay Gain.  I'm in contact with Martin Wolters (one of the authors of the paper) to try to see if we can pinpoint the reference level exactly.

I read the paper. They only compare BS.1770, not R128 (= gated BS.1770), to ReplayGain. In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=740984), the best-fit conversion involves a slope different from 1:

Quote
The optimum slope of -0.81 indicates a dependency on loudness. This can be explained by the loudness dependent level difference between the near maximum frame power (Replay Gain) and the long term power average (ITU-R BS.1770). Due to dynamic range processing and limiting this difference tends to get smaller for louder music. This observation is supported by an experiment where in the Replay Gain procedure the near maximum frame power analysis was replaced by a long term power average. Then the least squares fit between this modified Replay Gain and the ITU-based loudness has indeed a slope of -1.

That's probably still the case when converting from R128 to RG. So what you measured yourself was probably quite appropriate (it tended to emphasize contemporary loud music, right?).

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: M on 2011-01-30 17:42:31
Version 0.7.1 released:
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]It's a bug-fix. There where reportedly noticeable gaps introduced at the end of re-written MP3s. In order to fix that changed av_write_frame() (http://wiki.aasimon.org/doku.php?id=ffmpeg:av_write_frame) into av_interleaved_write_frame() (http://wiki.aasimon.org/doku.php?id=ffmpeg:av_interleaved_write_frame). Hope this helps.


Looks interesting, to say the least! There may be a bug in the bug-fix version (although I haven't tested any previous versions, yet; I just became aware of your project this morning).

Although I can add files via the "Choose" button, they are listed without any file extension... so when I add "C:\test\mytestaudio.flac" and then press the "OK" button, the dialogue gives me this message:

Code: [Select]
SetDlgItemURL successfully loaded.
SoX successfully loaded.
FFmpeg successfully loaded.
Couldn't stat "C:\test\mytestaudio"
Done. Hit any key to continue ...


(Also, for what it's worth, hitting any key won't close the dialogue. Hitting the "Enter" key will, but all the others type their respective characters.)

    - M.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 18:12:04
There may be a bug in the bug-fix version

Sounds very strange. Unfortunately I'm not able to reproduce it. Tried also spaces and special characters in directory and file names. On my XP 32 and Vista 64 systems everything looks fine.

What Windows version are you on?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 18:25:25
they are listed without any file extension...

May be this is because you've possibly disabled file extensions in Windows Explorer. Hopefully the next version will fix this.

Probably you can work around this by just enabling file extensions in Windows Explorer.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: M on 2011-01-30 18:32:20
There may be a bug in the bug-fix version

Sounds very strange. Unfortunately I'm not able to reproduce it. Tried also spaces and special characters in directory and file names. On my XP 32 and Vista 64 systems everything looks fine.

What Windows version are you on?


Vista Home Premium (32-bit), but that isn't the issue. Fortunately, this should be an easy thing to fix, for future versions!

In my system, I keep "Hide extensions for known file types" checked by default. Your selector dialogue sees the extension, but when it drops the filename into the processing queue, it strips the extension away... thus the "Couldn't stat" message. When I un-hid the extensions system-wide, the R128GAIN suddenly worked. 

The "Hit any key to continue" option still ignores anything but "Enter," though.

    - M.

Edit: I see I took too long to think about/type my response... you came to the same conclusion, as I was composing.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: benski on 2011-01-30 19:10:18
Has anyone read the paper from Dolby at AES128 comparing ITU-R BS.1770 to Replay Gain.  They suggest a -18 LU reference loudness for comparison with Replay Gain.  I'm in contact with Martin Wolters (one of the authors of the paper) to try to see if we can pinpoint the reference level exactly.

I read the paper. They only compare BS.1770, not R128 (= gated BS.1770), to ReplayGain. In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=740984), the best-fit conversion involves a slope different from 1:

Quote
The optimum slope of -0.81 indicates a dependency on loudness. This can be explained by the loudness dependent level difference between the near maximum frame power (Replay Gain) and the long term power average (ITU-R BS.1770). Due to dynamic range processing and limiting this difference tends to get smaller for louder music. This observation is supported by an experiment where in the Replay Gain procedure the near maximum frame power analysis was replaced by a long term power average. Then the least squares fit between this modified Replay Gain and the ITU-based loudness has indeed a slope of -1.

That's probably still the case when converting from R128 to RG. So what you measured yourself was probably quite appropriate (it tended to emphasize contemporary loud music, right?).

Chris


Yes you are correct.  Re-reading the paper it is clear that they only used BS.1770 and used the loudness of the entire track, so it's not quite an appropriate comparison to ReplayGain (95th percentile) or R128 (gated loudness).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-30 19:37:28
In my system, I keep "Hide extensions for known file types" checked by default. the same conclusion, as I was composing.

This is harder as it seems. Fortunately I've already found example code how to resolve it (http://gnuplot.sourcearchive.com/documentation/4.2.6-1/wmenu_8c-source.html). There you find the following comment:

Code: [Select]
/* The normal code to retrieve the item's text is 
   not very useful since user may select "hide common
   extensions" */

The "normal code" is exactly the one you currently find in R128GAIN. Changing this will take some time.

The "Hit any key to continue" option still ignores anything but "Enter," though.

Fortunately there is a very simple and obvious solution: the next version will write "Hit enter to continue" 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: [JAZ] on 2011-01-30 22:01:35
Maybe you should try using common controls instead. Something in line with this:
Code: [Select]
			OPENFILENAME ofn; // common dialog box structure
char szFile[_MAX_PATH]; // buffer for file name

szFile[0]='\0';
// Initialize OPENFILENAME
ZeroMemory(&ofn, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = GetParent()->m_hWnd;  //You have to supply an HWND here.
ofn.lpstrFile = szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = "Example 1 (*.ex1)\0*.ex1\0Example 2 (*.ex2)\0*.ex2\0All (*.*)\0*.*\0";
ofn.nFilterIndex = 1; //Which of the filters above to select by default. Index starts at 1.
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
//ofn.lpstrInitialDir = // Use this if you want to set a default directory to show.
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;

// Display the Open dialog box.
if(::GetOpenFileName(&ofn)==TRUE)
{
///szFile contains the filename (full path including extension) and ofn.nFilterIndex contains the filter selected in the filter combobox
}
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gjgriffith on 2011-01-31 01:26:13
Congratulations for developing a great tool.

Is it considered correct for mono flac files to be tagged for 3dB more gain than their stereo (dual mono) equivalent? This is not intuitive to me, as practically all playback devices will send the same mono signal to the two speakers (effectively making it 3 dB louder already).

Am I missing something?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kode54 on 2011-01-31 01:47:56
I have moved foo_r128scan related posts to [a href='index.php?showtopic=86404']the relevant topic[/a].
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-01-31 03:38:41
Yes you are correct.  Re-reading the paper it is clear that they only used BS.1770 and used the loudness of the entire track, so it's not quite an appropriate comparison to ReplayGain (95th percentile) or R128 (gated loudness).

This work (http://www.speech.kth.se/prod/publications/files/3319.pdf) compares 19 different loudness measurement algorithms. R128 did not yet exist when this study was done but several gated versions of BS.1770 were tested. No conversion factors are computed but the raw test data is included so perhaps it could be calculated.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-31 10:17:16
Maybe you should try using common controls instead.

Thanks for the hint. But that's exactly what I'm doing (cf. "r128gui_args.c").

The problem with the pure GetOpenFileName() approach is that it doesn't allow users to pick directories. Fortunately I came across this (http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.ui/2005-10/msg00211.html) and learned about hook procedures and sub-classing. I was happy having found a solution ... but it appears to work only in the most trival cases.

Letting users pick directories from a common controls dialog appears to me more advanced then implementing EBU R128/BS.1770.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-31 10:21:15
Am I missing something?

Propably not. Maybe the solution is having a "treat mono as stereo" switch in the next version.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-31 11:22:52
The mode, that pbelkner calls "R128 compliant" hijacks the REPLAY_GAIN tag format an writes incompatible values into it. Incompatible since those tracks will play back only about half as loud as traditional RG tracks (~5 dB). This is totally unnecessary and only due to pbelkner's somewhat odd interpretation of what R128 'compliance' should be inside a ReplayGain compliant tag.

Of course, one could have the benefit of both worlds, the better loudness estimation of R128 and playback compatibility to existing ReplayGain tagged collections - with REPLAY_GAIN_* tags but without the 5 dB difference! I do not really see the benefit of more than two options, the latter plus one plain R128 with R128_* tags.
I agree. If you're writing REPLAY_GAIN tags they should be 100% compatible with ReplayGain!

If you want to add an extra tag which stores the actual conversion factor used (so someone can convert back to the correct EBU R128 value if they want), by all means do so.

If users really want their audio to be 5dB quieter (or whatever reference level they choose), they can set the ReplayGain pre-amp to -5dB (or whatever).

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-31 11:28:40
In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=740984), the best-fit conversion involves a slope different from 1:

Quote
The optimum slope of -0.81 indicates a dependency on loudness. This can be explained by the loudness dependent level difference between the near maximum frame power (Replay Gain) and the long term power average (ITU-R BS.1770). Due to dynamic range processing and limiting this difference tends to get smaller for louder music. This observation is supported by an experiment where in the Replay Gain procedure the near maximum frame power analysis was replaced by a long term power average. Then the least squares fit between this modified Replay Gain and the ITU-based loudness has indeed a slope of -1.
While a loudness dependent coefficient makes the two data sets match more closely, that's not what should be used here.

One algorithm or the other is a closer match to human perception. Assuming that R128 is closer to human perception, then using a loudness dependent conversion factor will give a poorer result!

Cheers,
David.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-31 11:42:35
If you're writing REPLAY_GAIN tags they should be 100% compatible with ReplayGain!

Could you please define what 100% compatible with ReplayGain is? Provided the following:

In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=740984), the best-fit conversion involves a slope different from 1:

One algorithm or the other is a closer match to human perception. Assuming that R128 is closer to human perception, then using a loudness dependent conversion factor will give a poorer result!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: 2Bdecided on 2011-01-31 14:16:14
Could you please define what 100% compatible with ReplayGain is?
Not in a precise manner in a few words. Maybe the wiki version of the RG spec will do the job eventually.

However, in the meantime, I'm sure that using an intentionally different reference level to write ReplayGain tags isn't 100% compatible with ReplayGain.

It's really simple - pick a suitable conversion factor from R128 to ReplayGain, use it to convert the R128 values to ReplayGain values, store these converted values in ReplayGain tags, and store the conversion factor in an extra tag in case someone wants to get the real R128 value back later.

Or use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.

You can't mix both. Well, obviously you can - you can write software to do anything you want - but it's not very helpful.


For a suitable default conversion factor, just run ref_pink through it...
http://www.hydrogenaudio.org/forums/index....st&p=739094 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=739094)
...or pick the best guess from the literature, or the various suggestions from this thread. They are all remarkably close.

Cheers,
David.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-31 15:49:52
I'm sure that using an intentionally different reference level to write ReplayGain tags isn't 100% compatible with ReplayGain.

I'm not using an intentionally different reference level. In order to do so I had to know the right reference level. As you and others meanwhile confirm such reference level can never exist because the measured loudness difference beteween the two algorithms depend on style, genere, production etc.

Given that such a reference level doesn't exist (in the sense of science not bureaucracy, i.e. ad-hoc definition) your statement is trivial.

use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.

Do you have plans to hold a trade mark on an everyday word? It's very common these days ...

For a suitable default conversion factor, just run ref_pink through it...

That's just one way out of a zillion to come to a more or less meaningful definition. Simply asking Dolby (proof by authority as proposed by benski) is another.

Such a definition will by no means be any gurantee that audio tagged by the two methods will sound equally loud (see above).

Another such a definition (equally good or bad, but from my perspective a more natural choice) is to calibrate EBU R128 according to EBU R128.

From my perspective it simply makes no sense even trying to mix RG and R128.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-31 16:28:10
Such a definition will by no means be any gurantee that audio tagged by the two methods will sound equally loud (see above).


That's black and white thinking applied to a domain of shades. The range of possible conversion factors discussed so far spans a range of about 0.6 dB. Many of the values discussed can give you average differences to a traditionally scanned collection of 0.1 dB or less, with few singular exceptions (with good cause), where gated scanning beats traditional RG.

Because you haven't been served with a single value, that gives a "100%" guarantee, but just something that will be much better than 1 dB on average, you choose to go for a >5 dB average error. That might satisfy black and white thinking but else it doesn't make too much sense to me.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-01-31 16:47:15
That's black and white thinking applied to a domain of shades.

Oviously you've completely missed the point.

What is the advantage of having a mean deviation of 0.5 dB in the linear term? What about the non-linearity, i.e. the dependency of the "factor" from the loudness itself?

The bottom line was that I can't hardly see any reason for mixing the two worlds. From that any definition appears to me as good or as bad as any other. However, one out of all the possible definitions seems to me as to be the natural choice.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Case on 2011-01-31 17:31:49
I'm thankful that you introduced us the new loudness evaluation algorithm but what you are doing with the tool doesn't do good to anyone. Smarter people than I have already given you valid arguments why the target level should match the official ReplayGain level so I won't bother you with that. I'll just mention that ReplayGain standard defines how it is calibrated so the only proper way to calibrate R128 is to use the same method. It really is that simple.
If you do not wish to comply please use another set of tags. I'll just remind that it may be difficult to get the same amount of software and hardware support as ReplayGain has for your new set of tags.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bryant on 2011-01-31 17:44:01
Instead pbelkner now just drowns the user in options.

This tool is not and was never aimed for the mass market. It's aimed to the curious who want to learn something along the way.

BTW: That's the only reason why I'm bothering myself.

If this tool is just for experimentation, then I don’t see any problem with writing out the standard ReplayGain tags with a different reference level. As Ghammer points out, it’s obviously impossible to experiment with a scanner that writes newly defined tags if there’s no player that recognizes them!

But if it turns out to be impractical in the long-term to simply convert EBU scan results to standard ReplayGain values, then the goal would be to define a new set of tags for the EBU method and a recommended procedure (and perhaps set of options) for players to implement if they want to be compatible. The intent would be that this would be done in a backwards-compatible way (i.e., files scanned and tagged with the new procedure would play at an acceptable level in legacy players). Once that is in place, then the option to write the non-compliant ReplayGain tags would go away (or at least no longer be the default behavior).

The ReplayGain spec that lives here on HA should make it clear (if it doesn’t already) that the currently defined tags have a reference level that is fixed by historical usage and that using a different level (for those tags) is a violation of the spec. I would recommend that any program that writes something different pop up a dialog first that says something like FOR EXPERIMENTATION ONLY!! - the operation you are about to do will result in files that will not play at the correct level on existing players - use yada-yada option to write compliant ReplayGain tags. That would reduce the possibility of confusion, although it’s obviously up to the respective authors to decide how much frustration they would like to source.

note: I wrote this response yesterday and ended up not posting it because it seemed the discussion had moved on, but this morning [here] I see that it hasn't. Even though it's a little outdated, I think it hints at a direction.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-31 18:41:40
Back to basics:

I am afraid, but the calculation of True Peak Level in r128gain gives wrong results:

e.g. seq-3341-1-16bit.wav reads peak = -11.5 dBFS, should be -23.0 dBFS.

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gjgriffith on 2011-01-31 18:44:22
Maybe the solution is having a "treat mono as stereo" switch in the next version.

If you could, I for one would appreciate that option. I don't have that many mono flacs, but I still don't cherish the prospect of hunting them all down and treating them differently from stereo flacs.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-01-31 20:21:41
For a suitable default conversion factor, just run ref_pink through it...
http://www.hydrogenaudio.org/forums/index....st&p=739094 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=739094)
...or pick the best guess from the literature, or the various suggestions from this thread. They are all remarkably close.

I disagree. I tested foo_rgscan and foo_r128scan on real music tracks, and they gave really close result: foo_r128 gain = foo_rg gain - 0.63  (see posts 147 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=740984)-149)

ref_pink (original mono track): foo_r128 gain = foo_rg gain - 0.63;
ref_pink converted to stereo: foo_r128 gain = foo_rg gain - 3.64.

So in reality, ref_pink is not very good for comparison of RG and R128.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-01-31 20:26:38
Quote
I am afraid, but the calculation of True Peak Level in r128gain gives wrong results


Sorry, I forgot to mention that it happens in the DOS window.

The tags in the converted FLAC files seem to be correct.

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nick.C on 2011-01-31 22:17:00
use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.
Do you have plans to hold a trade mark on an everyday word? It's very common these days ...
.... but equally, why should you come along and make the information contained in REPLAY_GAIN tags ambiguous by writing information into them which has been calculated using a different algorithm. This smacks of opportunism, i.e. use the fact that a fairly large number of applications recognise the REPLAY_GAIN tags to enhance the usability of the information created using the EBU R128 algorithm.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: googlebot on 2011-01-31 22:27:40
...but equally, why should you come along and make the information contained in REPLAY_GAIN tags ambiguous by writing information into them which has been calculated using a different algorithm.


David has suggested exactly that, replacing the algorithm with something better if available, over half a decade ago. Why should that be problematic?

ReplayGain hasn't been perfect for all songs and I'm enthusiastic about R128, that it could improve results in some areas. But it should be calibrated to the same target level.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nick.C on 2011-01-31 22:39:30
The lack of matching calibration is exactly the ambiguity that I am referring to.

[edit] Well, maybe ambiguity is not the correct word in this context - but a 5dB difference is quite a difference indeed if you are shuffling tracks.... [/edit]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bilbo on 2011-02-01 01:17:30
@pbelkner
I applaud you you for your hard work and your willingness to on the leading edge of bringing this into existence. Early on you received much support on your project, But all seems to have broken down on your insistence on putting R128 values into the RG tags without factoring. I believe that this has hurt what was otherwise  an excellent project. Since players use RG Tags, these tags should have RG comparable data! You should use new tags for the unmodified R128 values. I would urge you to accept this for now and proceed with your valuable project before you lose your audience for the program to a new upstart.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-02-01 03:11:31
I'm personally critical AND supportive (and often misunderstood for it). There are clearly marked settings where R128GAIN does the right thing. Things are at an experimental stage. I'm confident it will all get sorted out.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: GHammer on 2011-02-01 03:22:32
The lack of matching calibration is exactly the ambiguity that I am referring to.

[edit] Well, maybe ambiguity is not the correct word in this context - but a 5dB difference is quite a difference indeed if you are shuffling tracks.... [/edit]


Perhaps I'm a bit silly, but if I were to find a new tool that was much better (or just better. or I just wanted to use the new tool), I'd likely re-scan all my audio files using the New! Improved! tool. (I'm a sucker for new things...)

I'd not hear any difference.

But, that's me. I understand on one level the points being forcefully put out for consideration. One the other hand, I don't really have an axe to grind here because of the way I operate.

As I said, I do things a wee bit differently than others. In this case, it works out well.

To me, the main idea is whether this is a "Good Thing', and if it is, why not use it to the exclusion of the original RG?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: carpman on 2011-02-01 04:11:52
Something I don't understand is this. If pbelkner's tool is for "experimental purposes", can't it be made a little like WavGain, but output a wav file that is a copy of the input with the gain applied. Thus it wouldn't require tags at all for files to be played at the correct volume.

So depending on the options selected, for an input named SONG.WAV, the tool would output:

SONG_R128_TRUEPEAK_TRACKGAIN.WAV, or
SONG_R128_NOTRUEPEAK_TRACKGAIN.WAV, or
SONG_REPLAYGAIN_TRACKGAIN.WAV (for traditional replay gain) etc ..

Possibly creating directories with similar suffixes for entire albums (album gained).
ALBUM_R128_TRUEPEAK_ALBUMGAIN\SONG_R128_TRUEPEAK_ALBUMGAIN.WAV etc ..

Then people could run a whole load of stuff through it and see how each fared. This way the tags issue would be void, and we could all get on with "experimenting".

Later down the line, I agree R128 should have it's own tags. What bryant, 2Bdecided and many others are saying makes complete sense to me.

C.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-01 04:28:44
Quote
but output a wav file that is a copy of the input with the gain applied


This is not the objective, and it doubles the storage needs.
The aim is to tag, for to have an non-destructive system (I know, you have the copy ... )

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: carpman on 2011-02-01 08:28:17
If pbelkner's tool is for "experimental purposes"...

C.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-01 10:07:06
I'm confident it will all get sorted out.

I couldn't have said it any better.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-01 10:12:52
I don't have that many mono flacs

A lot of Youtube videos seem to be mono. (Video processing is not possible yet, but should be in the future).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-01 10:18:56
I am afraid, but the calculation of True Peak Level in r128gain gives wrong results:

e.g. seq-3341-1-16bit.wav reads peak = -11.5 dBFS, should be -23.0 dBFS.

Could it be that you've mixed up the loudness (first value -23.0 LUFS) and the peak (second value -11.5 dBFS)?

Code: [Select]
$ r128gain.exe ../sounds/ebu-loudness-test-setv01/seq-3341-1-16bit.wav
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
  seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)
  ALBUM: -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-01 12:02:41
can't it be made a little like WavGain, but output a wav file that is a copy of the input with the gain applied.

I'm thinking about this myself. It appears to be very useful if your mobile MP3 player doesn't support RG.

Please note that one important constraint to this project is to let FFmpeg handle all I/O and not trying to re-invent it.

There is some very good documentation available for reading via FFmpeg, but unfortunately literally nothing for writing, except "ffmpeg.c" itself. Figuring out how to write via FFmpeg will take same time. A first step towards this direction is copying audio streams only as already avilable with R128GAIN. The next step propably is to extend this to copying video streams. Re-encoding streams, as this request implies, will propably require much deeper insight into FFmpeg.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-01 14:08:35
@ pbelkner:

Quote
seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)


Peak: 0.071316 is -22.9363 dBFS, not -11.5 dBFS.

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-01 14:39:53
Quote
seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)


Peak: 0.071316 is -22.9363 dBFS, not -11.5 dBFS.

Please correct me where I'm wrong:
I suspect you are talking about 10.0*log(A1^2/A0^2) (http://en.wikipedia.org/wiki/Decibel#Field_quantities).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: ExUser on 2011-02-01 14:52:31
You guys are overcomplicating it.

(http://img816.imageshack.us/img816/5396/rgr128.png)

There we go. That correlation is good enough for anyone. Would there be any complaint when using that correlation as the provisional mapping for now? I know that the semantic meaning may not be identical, but when the correlation is that strong...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: M on 2011-02-01 15:10:31
You guys are overcomplicating it.

(http://img816.imageshack.us/img816/5396/rgr128.png)

There we go. That correlation is good enough for anyone. Would there be any complaint when using that correlation as the provisional mapping for now? I know that the semantic meaning may not be identical, but when the correlation is that strong...

Canar, do you have an example of that graph with the reference values used? If it compares ReplayGain @ 89dB to R128 @ -18.0 LUFS, that is different from comparing it to R128 @ -23.0 LUFS, isn't it?

My understanding of the argument (as much as I've followed of it, at least!) is that folks object to "ReplayGain" tags being used to store values calculated for R128 @ -23.0 LUFS, since they are inherently ~5dB lower than the majority of ReplayGain values. I didn't pick up on much objection to using them for this purpose if the calculation is based on R128 @ -18.0 LUFS, and there certainly hasn't been any such objection in the foo_r128scan (http://www.hydrogenaudio.org/forums/index.php?showtopic=86404) thread, despite the fact that ReplayGain tags are similarly used by that component.

    - M.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: ExUser on 2011-02-01 15:27:26
That graph, if I recall correctly, comes from lvgcl and is from foo_r128scan's -18 reference level, you are correct. The point that I'm making is that using that mapping to calculate values stored in ReplayGain tags is quite valid. At this point, any further comment on my part would be simply recapitulating Case and/or Notat.

We are dealing with software that is in early development and we will see where things go from here. I don't think there's uncovered ground left in the discussion about the various tagging formats.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-01 18:38:36
Quote
Please correct me where I'm wrong:

  1. We are talking about a voltage/power.
  2. According to Wikipedia we calculate as follows: 10.0*log10(P1/P0).
  3. In our case P1/P0 is 0.071316.
  4. Using http://www.calcoolate.com/ (http://www.calcoolate.com/) and typing 10.0*log10(0.071316) we get -11.468130236941654.

I suspect you are talking about 10.0*log(A1^2/A0^2).


We are talking about peak voltage, in that case level calculation applies 20*log ...

Here are measured values of seq-3341-1-16bit.wav, see True Peak at aprox. -23 dBFS

(http://img268.imageshack.us/img268/6364/pict1.gif)

As a reminder, the text from EBU Tech 3341:
Stereo sine wave, 1000 Hz, -23.0 dBFS (per-channel peak level); signal applied in phase to both channels simultaneous; 20 s duration
M, S, I = -23.0 ±0.1 LUFS M, S, I = 0.0 ±0.1 LU

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: eevan on 2011-02-01 21:04:31
Jean is correct, the proper formula for voltages is 20*log(V/Vref). That's because power is proportional to the square of the amplitude (voltage), so one gets 10*log(V2/V2ref)=20*log(V/Vref).

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-02 07:18:34
We are talking about peak voltage, in that case level calculation applies 20*log ...

Jean is correct, the proper formula for voltages is 20*log(V/Vref). That's because power is proportional to the square of the amplitude (voltage), so one gets 10*log(V2/V2ref)=20*log(V/Vref).

Thank's a lot for clarifying. The next version will, of course, correct this.

If I thought to measure up to 1 dBFS clipping for hard (brickwall) limited audio this means that it is about 2 dBFS instead. This underlines what an important tool true peak measurement is.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-02 07:26:35
Quote
Thank's a lot for clarifying. The next version will, of course, correct this.

Great 

Quote
This underlines what an important tool true peak measurement is.

Quite true, don't underestimate intersample peaks!

Best regards
Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-05 15:26:58
R128GAIN v0.8 released
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]What's new?
GUI:

(http://home.snafu.de/pbelkner/upload/110205/r128gain.jpg)
Command line options:

Code: [Select]
$ r128gain.exe --help
An EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.
For details refer to "http://r128gain.sourceforge.net/".

Usage: r128gain [options] (file|directory)+ [-o <directory> [flac|mkv]]
Options:
  --r128             Run in EBU R128 compliant mode (default).
  --rg               Run in ReplayGain compliant mode.
  --r128-compatible  Calibrate output according to EBU R128.
  --rg-compatible    Calibrate output according to ReplayGain.
  --rg-calibration=<float>  Aequivalent to use for ReplayGain
                     loudness (default: -18.0).
  --true-peak=on,--true-peak  Up-sample for peak determination (default).
  --true-peak=off,--fast  Switch off up-sampling.
  --mono=off         Treat mono as stereo (default).
  --mono=on,--mono   Don't treat mono as stereo.
  --in-place         Allow overwriting of files in place.
  --loglevel=<integer>  Set FFmpeg loglevel.
  --regression       Calculate linear regression between EBU R128
                     and ReplayGain.
  --duration         Print out duration.
  --version          Display version information.
  --help             Display this information.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gjgriffith on 2011-02-05 17:53:35
R128GAIN v0.8 released
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]


The new mono mode works just as I had hoped - thank you. Unfortunately, the new version appears to null out the values of all of my standard flac tags (ARTIST, ALBUM, etc.). In other words, the tags are present but have blank values.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-05 19:18:22
R128GAIN v0.8.1
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
Unfortunately, the new version appears to null out the values of all of my standard flac tags (ARTIST, ALBUM, etc.). In other words, the tags are present but have blank values.

Many thanks for the report. Fortunately it was not that hard to fix. Sorry for any inconvenience.

Version 0.8.1 adds the option to increase the FFmpeg loglevel to the GUI:

(http://home.snafu.de/pbelkner/upload/110205/r128gain-02.jpg)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bbrabant on 2011-02-10 13:03:17
I have been testing the latest version (0.8.1). After scanning a number of mp3 files I noticed the track duration of the generated files were wrong.
When the r128 scanner writes the mp3 files, vbr mp3 get written as cbr mp3.  They play alright but the track duration is totally messed up.
Mp3 were encode with lame 3.98.4 (-v2).
Used ffmpeg-r26397-swscale-r32676-mingw32-shared.
R128Gain 0.8.1 setting algorithm to BS 1770 and compatible Replaygain.

Could this time issue be fixed?

Greetings,

Ben
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-10 15:04:59
Thanks for the report. In order to reproduce it I did the following (using v0.8.2, should make no difference):

As it is obvious both, FFmpeg and R128GAIN, seem to loose header information present in the original MP3 (e.g. duration).

By loading the three MP3s into Winamp it can be seen that the VBR information is also lost during FFmpeg and R128GAIN processing. On the other hand WA is able to recover the duration (propably similar to FFmpeg's "Estimating duration from bitrate ...").

As far as I can see, R128GAIN reproduces FFmpeg. That's the expected behaviour.

Please note that (at least currently) FFmpeg's capabilities are a constraint to R128GAIN's capabilities.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-13 16:24:41
R128GAIN v0.8.3 released
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bbrabant on 2011-02-13 18:09:15
Quote
It seems to be caused by the FFmpeg MP3 de-muxer eating the VBR header.
Because it is an FFmpeg issue and I'm avoiding to re-distribute MPEG related software in binary form you have to compile and install it yourself:


Thank you for your effort to fix the vbr header issue. Compiling FFmpeg myself is a bit to technical for me.
I have a different solution. I use foobar with the 128gainscan plugin. This way only the gain tags are written without messing with the vbr header.

Thanks again,

Ben

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-13 18:46:09
Compiling FFmpeg myself is a bit to technical for me.

Please check your private mail.

BTW: Does somebody know about the patent/license issues with respect to MPEG audio frame headers (http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx) (maybe starting a respective thread)?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bbrabant on 2011-02-13 23:26:27
After a quick test with R128GAIN v0.8.3 and the new mp3_demuxer_alternate.dll (thanks peter) the mp3 vbr header is written correctly.
The track duration is now the same as the source mp3.

I also noticed that some id3 tags are not the same as the source mp3.

The "Year" tag is changed to "RELEASETIME" tag.
The "comment" tag is removed
The album art (cover.jpg) stored in the mp3 is also removed.

Thank you for the r128gain scanning, almost time to replace replaygain scanning.

greetings,

ben
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-25 19:54:30
Hi,

today EBU Tech 3343 was finally published:

EBU Tech 3343 (http://tech.ebu.ch/docs/tech/tech3343.pdf)

Best regards

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-02-26 12:05:09
Thanks for the link, Jean! I skimmed through the 43 pages. Quotes of the most important passages with regard to file metadata such as ReplayGain:

page 10:
Quote
The Low Frequency Effects channel (the “.1”-channel in “5.1”) of a multichannel audio signal is currently not taken into account for the loudness measurement according to ITU-R BS.1770. [...] Ongoing investigations try  to evaluate the subjective effect the LFE has on the perception of loudness as well as the appropriate way to include it in the objective loudness measurement.

Page 12:
Quote
Recently (September 2010), the EBU has submitted the suggestion to the ITU to include the relative gating method into BS.1770. At the subsequent ITU meeting this suggestion was accepted, albeit with a slightly lower threshold level of -10 LU below the ungated loudness level. According to the tests of PLOUD, the results with a relative gate of -10 LU are only marginally different from -8 LU. Therefore, once the -10 LU gate is published in the next revision of ITU-R BS.1770, it will also be incorporated into EBU R 128 and the accompanying documents, particularly EBU Tech Doc 3341.

Page 34:
Quote
Metadata generally can be active (potentially changing the audio signal) or descriptive (providing information about the signal, such as format, copyright etc.). As a natural consequence of the work within PLOUD and the publication of EBU R 128 and its supporting documents, the three main parameters Programme Loudness, Loudness Range and Maximum True Peak Level shall form the core of loudness Metadata in audio files. Work is underway to include those parameters in the header (Broadcast Extension (BEXT) chunk) of the Broadcast Wave File (BWF) format (for a detailed description of BWF, see [10], [11] and [12]).

Page 35:
Quote
Exceptions where a different value than -23 [LUFS] may be used are: [...] A fully functional system of providing and using Metadata over the whole signal chain is already in place. This implies faithful transportation of loudness Metadata to the consumer’s home equipment.


Since ReplayGain can be considered a "fully functional system", I think we're on the right track with the R128 gain taggers here on HA, especially for stereo (only the change from -8 to -10 LU will be needed one day). Regarding a Programme Loudness tag, I have no opinion on whether/how we should transmit that.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Raiden on 2011-02-26 18:46:07
Also interesting:
Quote
Informal tests conducted by
members of the EBU PLOUD group have shown that the difference in the loudness measurement
with and without the -8 LU relative gate of programmes with a small to medium loudness range are
around 0 – 1 LU.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-02-26 20:38:54
Since ReplayGain can be considered a "fully functional system", I think we're on the right track with the R128 gain taggers here on HA, especially for stereo (only the change from -8 to -10 LU will be needed one day).


Yes, I fully agree!

Jean

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-27 10:52:13
R128GAIN v0.8.4 released:
[blockquote]http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]What's new?

Page 12:
Quote
Recently (September 2010), the EBU has submitted the suggestion to the ITU to include the relative gating method into BS.1770. At the subsequent ITU meeting this suggestion was accepted, albeit with a slightly lower threshold level of -10 LU below the ungated loudness level. According to the tests of PLOUD, the results with a relative gate of -10 LU are only marginally different from -8 LU. Therefore, once the -10 LU gate is published in the next revision of ITU-R BS.1770, it will also be incorporated into EBU R 128 and the accompanying documents, particularly EBU Tech Doc 3341.


With R128GAIN v0.8.4 it's possible to parametrize the BS.1770 gate:

(http://home.snafu.de/pbelkner/upload/110227/r128gain.jpg)
The range from -10.0 LU to -8.0 LU is considered EBU R128 compliant.

The command line version offers an respective "--gate" option:

Code: [Select]
$ r128gain --help
An EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.
For details refer to "http://r128gain.sourceforge.net/".

Usage: r128gain [options] (file|directory)+ [-o <directory> [flac|mkv]]
Options:
  --r128             Run in EBU R128 compliant mode (default).
  --rg               Run in ReplayGain compliant mode.
  --r128-compatible  Calibrate output according to EBU R128.
  --rg-compatible    Calibrate output according to ReplayGain.
  --gate=<float>     R128 gate (-10.0 .. -8.0, default: -8.0).
  --rg-calibration=<float>  Aequivalent to use for ReplayGain
                     loudness (default: -18.0).
  --true-peak=on,--true-peak  Up-sample for peak determination (default).
  --true-peak=off,--fast  Switch off up-sampling.
  --mono=off         Treat mono as stereo (default).
  --mono=on,--mono   Don't treat mono as stereo.
  --in-place         Allow overwriting of files in place.
  --loglevel=<integer>  Set FFmpeg loglevel.
  --regression       Calculate linear regression between EBU R128
                     and ReplayGain.
  --duration         Print out duration.
  --version          Display version information.
  --help             Display this information.

Also interesting:
Quote
Informal tests conducted by
members of the EBU PLOUD group have shown that the difference in the loudness measurement
with and without the -8 LU relative gate of programmes with a small to medium loudness range are
around 0 – 1 LU.

It appears that this is true for almost all test cases except the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" (the last one):

Code: [Select]
$ r128gain --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.0 LUFS, 0.0 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)

For the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" there is a huge difference of about 4.5 LU.

This mirrors exactly what I've expected: The compromise towards the original un-gated BS.1770 becomes noticeable in case of high dynamics where the gate is thought for.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-02-27 11:00:36
With R128GAIN v0.8.4 it's possible to parametrize the BS.1770 gate:

(http://home.snafu.de/pbelkner/upload/110227/r128gain.jpg)
The range from -10.0 LU to -8.0 LU is considered EBU R128 compliant.

The command line version offers an respective "--gate" option:

That's nice. We could use that functionality to check the validity of the statement "the results with a relative gate of -10 LU are only marginally different from -8 LU" and could actually report to the P/LOUD group songs where it makes a difference of e.g. more than 1 LU.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-27 11:20:09
That's nice. We could use that functionality to check the validity of the statement "the results with a relative gate of -10 LU are only marginally different from -8 LU" and could actually report to the P/LOUD group songs where it makes a difference of e.g. more than 1 LU.

As already stated:

For the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" there is a huge difference of about 4.5 LU.

This mirrors exactly what I've expected: The compromise towards the original un-gated BS.1770 becomes noticeable in case of high dynamics where the gate is thought for.

Provided I've made no mistake ...

Maybe Raiden can incorporate this feature in his tool as well? This would enable us to have a second independent test.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-02-27 11:33:32
That's a different issue, namely "gating vs. no gating". What I meant was comparing "-8 LU gating vs. -10 LU gating (and maybe vs. -9 LU gating)".

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-27 12:05:13
That's a different issue, namely "gating vs. no gating". What I meant was comparing "-8 LU gating vs. -10 LU gating (and maybe vs. -9 LU gating)".

It's exactly this:
Plus the comment that lowering the gate is a step (compromise) towards the un-gated algorithm.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-02-27 12:41:26
For the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama" there is a huge difference of about 4.5 LU.

I have to correct myself: This is not the "Authentic programme 2, stereo, wide Loudness Range (WLR) programme segment; similar in genre to a movie/drama". It's one of the artificial test cases:

(http://home.snafu.de/pbelkner/upload/110227/seq-3342-4-16bit.png)
The largest deviation between results from -8.0 LU and -10.0 LU gates I've found so far from my audio collection is about 0.4 LUFS.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: SamDeRe81 on 2011-03-02 22:28:14
Hey, is this thing lossless if I use it on mp3 files?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-03-03 06:50:12
Hey, is this thing lossless if I use it on mp3 files?

Yes, except that FFmpeg is "eating" the VBR header. There is a workaround available (cf. http://www.hydrogenaudio.org/forums/index....st&p=743480 (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978&view=findpost&p=743480)).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-03-10 12:31:53
I found some very interesting reading on our loudness subject here at the Qualis Audio homepage:

TechNote #1 Loudness Measurements and the CALM Act (http://www.qualisaudio.com/documents/TechNote-1.pdf) and especially
TechNote #2 Understanding & Verifying Loudness Meters (http://www.qualisaudio.com/documents/TechNote-2.pdf).

There is also a free download for a Loudness Meter Test Suite (http://www.qualisaudio.com/documents/LM_Waveforms.zip)


Best regards

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: oortoen on 2011-04-24 12:43:41
Hello.

Small question.

I tried this app for analysis only and I am a bit puzzled about how the numbers are presented.
In my opinion the presentation of LU has the wrong sign.

-23 LUFS is the reference hence this is presented as 0 LU.
All is fine.

R128gain measures my testfile and says: -21.6 LUFS which is 1.4 LU louder than the reference -23 LUFS.

However R128gain presents this as being -1.4 LU which I would interpret as 1.4 LU below the reference. I would equal -1.4 LU with -24.4 LUFS.

Why does R128gain present the numbers in this way?


Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2011-04-24 12:53:11
That's how replaygain was defined several years ago: http://replaygain.hydrogenaudio.org/calibration.html (http://replaygain.hydrogenaudio.org/calibration.html)
gain = reference - loudness.

I think that's the main reason: to be compatible with existing software...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: C.R.Helmrich on 2011-04-24 13:33:41
However R128gain presents this as being -1.4 LU which I would interpret as 1.4 LU below the reference. I would equal -1.4 LU with -24.4 LUFS.

Why does R128gain present the numbers in this way?

Because in your case the loudness of the test file needs to be lowered by 1.4 dB (or LU) to achieve the reference loudness of -23 LUFS, since, as you say, the file is louder than the reference loudness. The idea was not to save a relative loudness but a gain to achieve a certain constant loudness.

Chris
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: oortoen on 2011-04-24 16:09:56
OK I see what you mean.
The "LU" value that R128gain presents is the desired replay gain, which by definition is the relative LU value multiplied by -1.

The reason I assumed the "LU" value from R128 was the relative loudness is the following passage in EBU Tech 3343:
"In an "EBU Mode" loudness meter, 0 LU equals -23 LUFS."
EBU tech 3343, page 23 (http://tech.ebu.ch/docs/tech/tech3343.pdf)

I believe we have a potential source of misunderstanding here. Precisely as the relative unit "dB" can represent various things "LU" can also represent various things. In this case it was obviously replay gain and I missed that.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-04-24 19:22:31
That's how replaygain was defined several years ago: http://replaygain.hydrogenaudio.org/calibration.html (http://replaygain.hydrogenaudio.org/calibration.html)

The reference level was raised 6 dB after the proposal was published. This (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Reference_level) is the up-to-date version of that description.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: stereotype on 2011-04-26 23:35:46
Sorry for the dumb question, but even after googling I'm still at a loss... What does this tool do?
Is it like mp3gain with different mathematics?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-04-27 09:02:18
Sorry for the dumb question, but even after googling I'm still at a loss... What does this tool do?
Is it like mp3gain with different mathematics?

There are at least two differences:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: drosen on 2011-05-08 12:24:58
@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?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-05-08 17:00:43
@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?

Your right. Future versions will support this, most probably using some kind of parametrization.

The last days the focus was on fixing the "lost VBR header" problem from FFmpeg (http://ffmpeg.org/) (see above). Luckily yesterday a respective patch (http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d62bf5d4e73250295c0a652e151498c5b19cbd63) was accepted.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-05-15 15:34:34
I have been testing the latest version (0.8.1). After scanning a number of mp3 files I noticed the track duration of the generated files were wrong.
When the r128 scanner writes the mp3 files, vbr mp3 get written as cbr mp3.  They play alright but the track duration is totally messed up.
Mp3 were encode with lame 3.98.4 (-v2).
Used ffmpeg-r26397-swscale-r32676-mingw32-shared.
R128Gain 0.8.1 setting algorithm to BS 1770 and compatible Replaygain.

Could this time issue be fixed?

Greetings,

Ben

Finally got this sorted out by providing a respective patch to FFmpeg (http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d62bf5d4e73250295c0a652e151498c5b19cbd63). Meanwhile FFmpeg has "bumped" their DLLs:
Version 0.8.5 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
For upgrading to full FFmpeg (needed for MP3 processing) get the FFmpeg DLLs from the latest shared builds
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: smok3 on 2011-05-24 11:13:57
questions:
a. can i make the tool to work without tags, like wav in -> modified wav out?
b. can i say to the tool to do a file by file (now by default, if it crashes in between, the entire sample-set is not written)
(cmd used was: r128gain --r128 --r128-compatible --gate=-10.0 --true-peak=on --regression e:\!tmp -o e:\!tmp2)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-05-24 11:54:05
a. can i make the tool to work without tags, like wav in -> modified wav out?

This was alredy requested by somebody else and I need it for my own purposes.

Unfortunately it is not implemented yet. Hope to fix this next time.

b. can i say to the tool to do a file by file (now by default, if it crashes in between, the entire sample-set is not written)
(cmd used was: r128gain --r128 --r128-compatible --gate=-10.0 --true-peak=on --regression e:\!tmp -o e:\!tmp2)

From your command line I'm not certain on your intention.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: smok3 on 2011-05-26 19:22:14
thanks for explanation(s).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: AstralStorm on 2011-06-22 21:55:51
I've an important comment on both ReplayGain and R128Gain: both use A-weighting or a similar curve.
A-weighting is known to overestimate the loudness of high frequencies, esp. > 4kHz.
Good loudness adjustment would use a real set of psychoacoustic curves, for example ISO 226:2003.
Not doing that is bound to fail somewhere - currently most noticeable with metal which is very rich in high end.

A real curve for mixed tone+noise should be measured... or if you're lazy, you can steal LAME's GPsycho or NSPsyTune - these psychoacoustic models are very well regarded.
Use their energy estimator.

Pity I don't have the time to code this myself.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: ExUser on 2011-06-22 22:32:49
ReplayGain does not use A-weighting, it uses an ATH-derived curve with specific points chosen for an IIR filter, cascaded with a Butterworth filter for low-end compliance.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: AstralStorm on 2011-06-22 22:46:55
Correct. However, EBU 128 uses A-weighting for its LUFS, which of course is incorrect.
ISO 226:2003 might also be incorrect for mixed sound and noise though, but is likely more accurate.

Perhaps an empirically tuned mix of D-weighting (for noise) and ISO 226:2003 (for tones) should be used?
Or maybe tone vs noise content could be estimated... (hello nspsytune again)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-06-23 01:35:58
R128 uses a weighting filter defined by BS.1770 it is also known as K-weighting. It was specifically designed correct the  deficiencies of A-weighting for perceived loudness measurement. Though derived separately, K-weighting turns out to be quite similar to ReplayGain's weighting filter.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Northpack on 2011-06-23 10:08:02
A-weighting is known to overestimate the loudness of high frequencies, esp. > 4kHz.

If the A-weighting curce overestimates hf, the K-weighting curve is even worse. It doesn't decline at all in the hf range:

(http://broadcastengineering.com/tests-and-measurements/102bew07_Fig2.jpg)

Consequently RG128 tends to rate metal albums a bit louder than ReplayGain, which uses an equal loudness contour with hf decline.

The difference isn't as dramatical as you'd expect by looking at the graphs however. Actually it seems to match my subjective impression better than ReplayGain, even for those albums. Maybe this is because I can hear very well up to 20kHz. Maybe it is because those frequencies doesn't matter anyway and other things implemented in R128 are much more important for accurate loudness estimation.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-06-24 01:58:35
The main problem with A-weighting for loudness estimation is that it ignores a lot of the low frequency range. 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.

K's weighting of a 20 kHz tone at +4 dB is only accurate for certain children. What do you propose to do to fix this? Different people have dramatically different sensitivity to ultra-high frequencies. K-weighting does not try to solve this problem. Sometimes the best solution is no solution.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Northpack on 2011-06-24 08:30:44
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?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-06-24 14:07:52
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-07-10 15:20:43
@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:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
(http://home.snafu.de/pbelkner/upload/110710/r128gain.jpg)
Example command line with block overlap 75% (partition 4) and gate -10.0:

Code: [Select]
$ 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)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: punkrockdude on 2011-07-11 23:55:15
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-07-12 06:47:24
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.)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-07-12 18:02:11
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-07-21 20:53:59
Quote
ReplayGain uses a -14 dBFS reference level.


Which I do not understand 

Considering this file: official pink noise reference file (http://replaygain.hydrogenaudio.org/proposal/ref_pink.wav),
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Notat on 2011-07-22 04:53:46
You are apparently studying the original ReplayGain proposal (http://replaygain.hydrogenaudio.org/proposal/). The file you link to is a -20 dB reference. Here's the current specification (http://replaygain.hydrogenaudio.org). Specifically read this (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Reference_level). Have a look at note 9 (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#cite_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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-07-22 06:47:59
You are apparently studying the original ReplayGain proposal (http://replaygain.hydrogenaudio.org/proposal/). The file you link to is a -20 dB reference. Here's the current specification (http://replaygain.hydrogenaudio.org). Specifically read this (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Reference_level). Have a look at note 9 (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#cite_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/ (http://www.hydrogenaudio.org/forums/) (left, under "Hosted Sites") should be corrected. Currently it points to http://replaygain.org/ (http://replaygain.org/) which gives an "domain has expired" message.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-07-22 08:00:33
@ Notat:

I took the information from here: http://www.hydrogenaudio.org/forums/index....aded&start= (http://www.hydrogenaudio.org/forums/index.php?showtopic=89353&pid=760962&mode=threaded&start=)

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

I hope this helps to bring some light 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-08-02 20:37:49
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-08-03 07:31:10
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-08-03 18:22:59
Ok, thank you!

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: smok3 on 2011-09-25 20:07:12
is there a r128gain (or replaygain) ported back/implemented in ffmpeg as well?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-09-29 07:23:47
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-03 17:39:16
Version 0.8.7 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-10-05 09:47:43
Hello,

getting the following error message:

Quote
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-05 10:30:45
getting the following error message:

Quote
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 Another solution should be having "sox.exe" in your systems's PATH.

Sorry for any inconvenience.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-10-05 12:18:25
Adding the path to sox.exe in my System's path was helpful.

But here is another issue:
Quote
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

Quote
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nick.C on 2011-10-05 12:36:12
I suggest that you enclose the path in double quotation marks (") as Windows doesn't deal with spaces in path names very well.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-10-05 12:38:49
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-05 13:01:31
But here is another issue:

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2011-10-05 13:36:39
Thank you all for the quick replies!

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jed on 2011-10-06 17:44:43
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-08 13:42:23
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-08 20:23:58
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: [Select]
...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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-08 20:39:34
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: [Select]
...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:
Please note that "make" in the toplevel directory tries to create the package for distribution. That's possibly not what you want.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-08 20:50:06
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.

?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-08 21:12:12
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-08 22:13:21
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:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-08 23:07:47
3. make: *** No rule to make target `build/a52dec-0.7.4/__installed__', needed by `lib/liba52.a'.  Stop.


Code: [Select]
...
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?


Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-09 02:43:06
Is this tested on Linux?

No. The errors you are running in now are coming from trying to build a *Windows* DLL.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-09 03:54:00
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?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-09 06:34:13
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-09 06:57:05
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-09 07:25:00
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: [Select]
...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:
  • Download the source and extract it into a directory.
  • Download "r128gain-0.8.7-src-ffmpeg.tar" and extract into the same directory.
  • CD into "tools" and run "make". It should download all other needed sources.
  • 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 (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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-09 07:32:40
Yeah right, that's because I use Cygwin and build Linux packages with it
Just enjoy your champagne, my mistake
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-10-09 10:16:59
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-09 16:48:11
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?

Quote
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-10-09 17:33:48
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: klonuo on 2011-10-09 17:54:12
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2011-10-09 18:08:32
"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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jed on 2011-10-11 18:51:23
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 (http://twitpic.com/6yvi2g)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nick.C on 2011-10-11 19:25:30
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-12 07:02:56
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:
If it works I may consider to implement this workaround in R128GAIN.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-10-12 07:12:52
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-11-20 14:07:37
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:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-12-09 12:56:30
Version 0.9.1 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2011-12-18 20:15:01
Version 0.9.2 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-01-05 02:12:14
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-01-06 16:23:05
Please forgive me if I missed it, but is there a command line environment variable provided for the actual LUFS value, e.g., %LUFS%?


Version 0.9.3 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-01-06 19:41:34
  • Provided four more environment variables for the command option:
    • %TL%: The track loudness relative to full scale.
    • %TLDB%: The track loudness relative to full scale in dB/LUFS.
    • %AL%: The album loudness relative to full scale.
    • %ALDB%: The album loudness relative to full scale in dB/LUFS.

Excellent! Thank you for making this great tool available to the community.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2012-01-06 22:50:20
You couldn't have chosen something slightly more unique for the environment variables?
At least put a prefix on them or something to avoid collisions.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-01-09 01:32:09
You couldn't have chosen something slightly more unique for the environment variables?
At least put a prefix on them or something to avoid collisions.

Is this causing a specific problem which you cannot work around? Is there a reason for your focus on this small detail given all the functionality of this free program?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-01-23 17:19:47
One more I may have missed: is there a command line environment variable provided for the Loudness Range (LRA) in LU? 

With this additional data, the scanner would provide all three measures in R128.  For example, for a given track would the following be correct?

Thank you.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-01-24 08:23:12
One more I may have missed: is there a command line environment variable provided for the Loudness Range (LRA) in LU?

There's no range computing in R128GAIN yet, that's not only a matter of an environment variable.

With this additional data, the scanner would provide all three measures in R128.  For example, for a given track would the following be correct?
    • "Programme Loudness" in LUFS (%TLDB%)
    • "Loudness Range" in LU ( ? )
    • "True Peak Level" in dBTP (%TPDB%)
    [/li]

Thank you.[/quote]
On the other hand there's a LU measure: %TGDB% holds the gain (in dB / LU) you have to apply in order to correct the loundess to -23 LUFS.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-01-25 15:22:53
Please consider adding Loudness Range (LRA).  The scanner would then provide all three R128 descriptors, for example:

- Programme Loudness (%TLDB%)
- Loudness Range ( ? )
- True Peak Level (is this %TPDB%?)

Thank you.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-01-25 17:16:58
Please consider adding Loudness Range (LRA).  The scanner would then provide all three R128 descriptors

Yep.

But next in the pipeline is a GTK+ (http://www.gtk.org/) GUI for Linux. Here's some preview:

(http://www.cidee.de/upload/120110/R128GAIN.png)
- True Peak Level (is this %TPDB%?)

Yes.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gepebril on 2012-02-01 12:46:14
Hi there,

I'm not realy an audio guru, but for a project we have to make audio EBU-R128 compliant.
As I favour Open source solutions I would like to use R128GAIN, what I don't understand from the documentation is:
1) Can R128GAIN process audio so the result is EBU-R128 compliant
2) If so. We have the following specifications, and can they be achieved with R128GAIN
Code: [Select]
Parameter                      Meterindication  Value
Integrated Loudness            I                 -23 LUFS
Maximum True Peak Level        dBTP              -1 dBTP
Maximum Momentary Loudness     M                 +8 LU
Maximum Short Term Loudness    S                 No limitation
Loudness Range                 LRA               No limitation

3) Can one file be made EBU-R128 complaint, or can it only be as range of files in e.g. a play-out list
4) What file formats can be used as input (format, bitrate, samplerate) and what can be output formats (format, bitrate, samplerate)
Thanks in advance.

Yours sincerely,

Albert
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-01 14:35:25
1) Can R128GAIN process audio so the result is EBU-R128 compliant

In principle yes, but currently not with respect to all measures (cf. answers to the following questions.)

2) If so. We have the following specifications, and can they be achieved with R128GAIN
Code: [Select]
Parameter                      Meterindication  Value
Integrated Loudness            I                 -23 LUFS
Maximum True Peak Level        dBTP              -1 dBTP
Maximum Momentary Loudness     M                 +8 LU
Maximum Short Term Loudness    S                 No limitation
Loudness Range                 LRA               No limitation

Integrated loudness: Yes, via the command feature and using the default sox-command.
Maximum True Peak: R128GAIN is able to measure true peak but has no build in way to correct it. But most likely in almost all cases you will see that after having normalized to -23 LUFS your true peak requirement is fulfilled.
Maximum Momentary Loudness is not measured yet.
Maximum Short Term Loudness is not measured yet.
Loudness Range is not measured yet but should be available sometimes soon (cf. request by gb24 above.)

3) Can one file be made EBU-R128 complaint, or can it only be as range of files in e.g. a play-out list

You can use it on a file by file basis as well as on a range of files.

4) What file formats can be used as input (format, bitrate, samplerate) and what can be output formats (format, bitrate, samplerate)

After having upgraded to full versions of SoX (http://sox.sourceforge.net/ (http://sox.sourceforge.net/)) and FFmpeg (http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/)) there should be no practical restriction.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-04 17:54:43
Please consider adding Loudness Range (LRA).  The scanner would then provide all three R128 descriptors

Version 0.9.4 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Test cases for Loudness Range (tech3342.pdf (http://tech.ebu.ch/docs/tech/tech3342.pdf)):

Code: [Select]
$ r128gain ~/ebu-loudness-test-setv03/*3342*.wav
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
  seq-3341-2011-8_seq-3342-6-24bit-v02.wav (1/6): -23.0 LUFS, 0.0 LU (peak: 0.737823: -2.6 dBFS, range: 15.3 LU)
  seq-3341-7_seq-3342-5-24bit.wav (2/6): -23.0 LUFS, 0.0 LU (peak: 0.358340: -8.9 dBFS, range: 6.3 LU)
  seq-3342-1-16bit.wav (3/6): -23.0 LUFS, 0.0 LU (peak: 0.100088: -20.0 dBFS, range: 10.0 LU)
  seq-3342-2-16bit.wav (4/6): -23.0 LUFS, 0.0 LU (peak: 0.177971: -15.0 dBFS, range: 5.0 LU)
  seq-3342-3-16bit.wav (5/6): -23.0 LUFS, 0.0 LU (peak: 0.100088: -20.0 dBFS, range: 20.0 LU)
  seq-3342-4-16bit.wav (6/6): -23.0 LUFS, 0.0 LU (peak: 0.100073: -20.0 dBFS, range: 15.0 LU)
  ALBUM: -23.0 LUFS, 0.0 LU (peak: 0.737823: -2.6 dBFS, range: 17.1 LU)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: gb24 on 2012-02-06 18:29:15
Thank you for incorporating LRA, Peter.  I think you now have a great tool for batch processing of audio files per EBU R128.

I am not aware of any other free or open source software which provides all this functionality.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-07 18:46:06
Version 0.9.5 (source / win32 binary) released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
The Linux binary will follow in a few days.

Test cases for Loudness Range (tech3342.pdf (http://tech.ebu.ch/docs/tech/tech3342.pdf)):

Code: [Select]
$ r128gain ~/ebu-loudness-test-setv03/*3342*.wav
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
  seq-3341-2011-8_seq-3342-6-24bit-v02.wav (1/6): -23.0 LUFS, 0.0 LU (peak: 0.737823: -2.6 dBFS, range: 15.3 LU)
  seq-3341-7_seq-3342-5-24bit.wav (2/6): -23.0 LUFS, 0.0 LU (peak: 0.358340: -8.9 dBFS, range: 6.3 LU)
  seq-3342-1-16bit.wav (3/6): -22.6 LUFS, -0.4 LU (peak: 0.100088: -20.0 dBFS, range: 10.0 LU)
  seq-3342-2-16bit.wav (4/6): -16.8 LUFS, -6.2 LU (peak: 0.177971: -15.0 dBFS, range: 5.0 LU)
  seq-3342-3-16bit.wav (5/6): -20.0 LUFS, -3.0 LU (peak: 0.100088: -20.0 dBFS, range: 20.0 LU)
  seq-3342-4-16bit.wav (6/6): -24.5 LUFS, 1.5 LU (peak: 0.100073: -20.0 dBFS, range: 15.0 LU)
  ALBUM: -21.2 LUFS, -1.8 LU (peak: 0.737823: -2.6 dBFS, range: 17.1 LU)

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-10 22:20:15
The Linux binary will follow in a few days.

The 0.9.5 Linux binary has been published.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-11 18:10:24
Version 0.9.6 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bacondither on 2012-02-13 21:38:08
With every ogg vorbis file i try to process i get "Application provided invalid, non monotonically increasing dts
to muxer in stream"
An example of a test ogg vorbis file encoded with aotuv 6.03:
Code: [Select]
SetDlgItemURL successfully loaded.
SoX successfully loaded.
FFmpeg successfully loaded.
[ogg @ 02197FE0] Format ogg probed with size=2048 and score=100
[ogg @ 02197FE0] Page at 58 is missing granule
[ogg @ 02197FE0] ti bytes of comment header remain
[ogg @ 02197FE0] All info found
[ogg @ 02197FE0] Format ogg probed with size=2048 and score=100
[ogg @ 02197FE0] Page at 58 is missing granule
[ogg @ 02197FE0] ti bytes of comment header remain
[ogg @ 02197FE0] All info found
analyzing ...
  test.ogg (1/1): -10.3 LUFS,
 -12.7 LU (peak: 1.097097: 0.8 dBFS, range: 7.6 LU)
  ALBUM: -10.3 LUFS, -12.7 LU (peak: 1.097097: 0.8 dBFS, range: 7.6 LU)
writing ...
  test.ogg (1/1) ... [ogg @ 0
220F9A0] Format ogg probed with size=2048 and score=100
[ogg @ 0220F9A0] Page at 58 is missing granule
[ogg @ 0220F9A0] ti bytes of comment header remain
[ogg @ 0220F9A0] All info found
[ogg @ 0220FE80] Application provided invalid, non monotonically increasing dts
to muxer in stream 0: 13760 >= 13760
error.
Done. Hit enter to continue ...
The resulting outputted file from the operation above is a 58 byte .ogg file with this content:
Code: [Select]
OggS         íôûÄ    çѱvorbis    D¬       ô     ¸

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: romor on 2012-02-13 22:19:57
Interestingly, I got same errors earlier today while doing DVD (M2V+LPCM) to MKV (x264+OGG) with Avidemux, which was handy at the moment. Result was fine thou, audio seemed fine after I checked, as I was surprised by misleading DTS errors
Seems like some ffmpeg issue
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-14 07:24:15
With every ogg vorbis file i try to process i get "Application provided invalid, non monotonically increasing dts
to muxer in stream"
An example of a test ogg vorbis file encoded with aotuv 6.03:
Code: [Select]
SetDlgItemURL successfully loaded.
SoX successfully loaded.
FFmpeg successfully loaded.
[ogg @ 02197FE0] Format ogg probed with size=2048 and score=100
[ogg @ 02197FE0] Page at 58 is missing granule
[ogg @ 02197FE0] ti bytes of comment header remain
[ogg @ 02197FE0] All info found
[ogg @ 02197FE0] Format ogg probed with size=2048 and score=100
[ogg @ 02197FE0] Page at 58 is missing granule
[ogg @ 02197FE0] ti bytes of comment header remain
[ogg @ 02197FE0] All info found
analyzing ...
  test.ogg (1/1): -10.3 LUFS,
 -12.7 LU (peak: 1.097097: 0.8 dBFS, range: 7.6 LU)
  ALBUM: -10.3 LUFS, -12.7 LU (peak: 1.097097: 0.8 dBFS, range: 7.6 LU)
writing ...
  test.ogg (1/1) ... [ogg @ 0
220F9A0] Format ogg probed with size=2048 and score=100
[ogg @ 0220F9A0] Page at 58 is missing granule
[ogg @ 0220F9A0] ti bytes of comment header remain
[ogg @ 0220F9A0] All info found
[ogg @ 0220FE80] Application provided invalid, non monotonically increasing dts
to muxer in stream 0: 13760 >= 13760
error.
This seems to be an FFmpeg error. FFmpeg is currently under heavy development.

A workaround is making FFmpeg unusable by e.g. renaming "avcodec.dll" from the "r128gain-tools" directory to "avcodec.dll.X". In this case R128GAIN will fall back to SoX.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-15 20:00:31
With every ogg vorbis file i try to process i get "Application provided invalid, non monotonically increasing dts
to muxer in stream"

I've just uploaded a slightly modified version which should fix the issue (source code and win32 binary): http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bacondither on 2012-02-16 07:38:04
Vorbis files works fine for me now. 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-02-18 06:18:33
I've just uploaded a slightly modified version which should fix the issue (source code and win32 binary): http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)

Vorbis files works fine for me now. 

The Linux binary is now available as well.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-03-18 18:35:39
Version 0.9.6-3 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-28 18:37:13
HI - new user. I don't mean to sound dumb, but is there a way to offset the resulting gain before it is written to a new file?

The reason I ask, is our company (TV broadcaster) has decided to adopt a reference of -24db based on itu1770 for mixed television programmes, and I was wondering if this tool would be of any use here. -23db is within our delivery spec, but out of curiosity (just me playing around)  i wondered if this tool could be used in our commercial suites to make a gain adjusted copy of the final .wav files that will comply with our delivery spec.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-28 19:35:26
HI - new user. I don't mean to sound dumb, but is there a way to offset the resulting gain before it is written to a new file?

The reason I ask, is our company (TV broadcaster) has decided to adopt a reference of -24db based on itu1770 for mixed television programmes, and I was wondering if this tool would be of any use here. -23db is within our delivery spec, but out of curiosity (just me playing around)  i wondered if this tool could be used in our commercial suites to make a gain adjusted copy of the final .wav files that will comply with our delivery spec.



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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-03-29 07:05:16
The reason I ask, is our company (TV broadcaster) has decided to adopt a reference of -24db based on itu1770 for mixed television programmes, and I was wondering if this tool would be of any use here. -23db is within our delivery spec, but out of curiosity (just me playing around)  i wondered if this tool could be used in our commercial suites to make a gain adjusted copy of the final .wav files that will comply with our delivery spec.

There's an undocumented "--preamp=<float>" option. The preamp is in dB relative to -23 LUFS. i.e. in your case -1.0.

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[blockquote]'--command=sox "%TRACK%" "%DN%\%BN%.wav" gain "%TGDB%"'[/blockquote]or[blockquote]"--command=sox '%TRACK%' '%DN%\%BN%.wav' gain '%TGDB%'"[/blockquote]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-29 22:43:46
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[blockquote]'--command=sox "%TRACK%" "%DN%\%BN%.wav" gain "%TGDB%"'[/blockquote]or[blockquote]"--command=sox '%TRACK%' '%DN%\%BN%.wav' gain '%TGDB%'"[/blockquote]


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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-30 03:55:22
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!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-31 04:04:55
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.

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-03-31 08:09:30
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:The following script "r.bat" seems to do the job:

Code: [Select]
@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: [Select]
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: rojgreen on 2012-03-31 09:33:17

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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: audioworld on 2012-04-01 20:23:37
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-04-01 21:22:09
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?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: audioworld on 2012-04-04 22:52:31
Sure, and I just see that TR 3285-2 is already published an not a draft any more:
BWF Metadata Specifications (http://tech.ebu.ch/docs/tech/tech3285.pdf)
please see pages 10-12ff.

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

best regards, karl.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-04-06 11:29:43
I was wondering if it would be possible to use BWF (Broadcast Wave Format) Tags alternatively.

Version 0.9.7 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: audioworld on 2012-04-06 21:19:13
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"
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-04-07 17:30:09
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/ (http://sourceforge.net/projects/r128gain/files/).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-04-08 15:12:16
Quote
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
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: TZOTZIOY on 2012-05-02 13:25:18
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-02 17:02:47
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.

...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: TZOTZIOY on 2012-05-02 20:36:22
  • 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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-03 06:41:33
  • 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:

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: TZOTZIOY on 2012-05-04 13:24:52
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).
[/li][/list]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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-04 21:27:19
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-18 19:51:27
Version 1.0-alpha-1 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
What's new?
(http://r128gain.sourceforge.net/upload/120518/win32.jpg)
Native Win32
(http://r128gain.sourceforge.net/upload/120518/gtk3.jpg)
GTK3 under Ubuntu 11.10 Linux
(http://r128gain.sourceforge.net/upload/120518/gtk2.jpg)
GTK2 under Debian 6.03 Linux
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: v0n on 2012-05-24 19:10:32
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: longnvl on 2012-05-25 08:06:23
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?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-25 09:00:44
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".
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dr.schanker on 2012-05-25 22:15:18
Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:
[blockquote]'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[/blockquote]
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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-26 07:34:35
Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:
[blockquote]'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[/blockquote]

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() (http://msdn.microsoft.com/en-us/library/ff770599.aspx) to convert the command line from OEM to UNICODE. Unfortunately __wgetmainargs() (http://msdn.microsoft.com/en-us/library/ff770599.aspx) seems not to be available on systems with older Windows versions, as it is on my Vista.

The alternative is using CommandLineToArgvW() (http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx) in conjunction with GetCommandLineW() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx). Unfortunately CommandLineToArgvW() (http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391%28v=vs.85%29.aspx) 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.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-26 07:38:20
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 ...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-05-27 13:53:32
Version 1.0-alpha-2 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/ (http://sourceforge.net/projects/r128gain/files/)[/blockquote]
under linux even as a command line utility

64 bit linux distros which most of us use these days

Calling the new alpha ('r128gain-1.0-alpha-1-win32-native') directly from the commandline gives the Windows error popup:
[blockquote]'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[/blockquote]
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.

What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dr.schanker on 2012-05-28 06:53:55
Thank you for the fast update.
As described, no more crashing - tested 'r128gain-1.0-alpha-2-win32-native' and 'r128gain-1.0-alpha-2-win32-cli'.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Darkflames0 on 2012-06-18 09:59:59
Hi,
I don't know if it's the good place to post, but it's the only forum I have found about r128gain.
I have just updated my sox version to 14.4.0 but it seems that now the r128gain encoder is no longer working, printing me this error :
Code: [Select]
Error loading SoX

I'm on a 64bits Ubuntu using the cli version, what can I do to solve this problem.
I would like to precise that before I updated SoX it was working well.
Thx
Darkflames0
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-06-19 07:05:17
Hi,
I don't know if it's the good place to post, but it's the only forum I have found about r128gain.
I have just updated my sox version to 14.4.0 but it seems that now the r128gain encoder is no longer working, printing me this error :
Code: [Select]
Error loading SoX

I'm on a 64bits Ubuntu using the cli version, what can I do to solve this problem.
I would like to precise that before I updated SoX it was working well.
Thx
Darkflames0

At start-up R128GAIN tries to load "libsox.so" from the (sub-)folder "r128gain-tools". The error message "Error loading SoX" is generated in case loading "libsox.so" fails.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: chi on 2012-06-19 13:13:24
At start-up R128GAIN tries to load "libsox.so" from the (sub-)folder "r128gain-tools". The error message "Error loading SoX" is generated in case loading "libsox.so" fails.


On Debian-based systems, several format handlers are separate modules that are loaded by libsox. I’d guess there might be a version mismatch between those modules (probably now updated to 14.4.0) and this local libsox.so that pbelkner mentions.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-06-19 15:30:04
At start-up R128GAIN tries to load "libsox.so" from the (sub-)folder "r128gain-tools". The error message "Error loading SoX" is generated in case loading "libsox.so" fails.


On Debian-based systems, several format handlers are separate modules that are loaded by libsox. I’d guess there might be a version mismatch between those modules (probably now updated to 14.4.0) and this local libsox.so that pbelkner mentions.

The "libsox.so" provided with R128GAIN is compiled from the SoX 14.4.0 sources. Further, (most of) the external dependencies (as e.g. "libFLAC.a") are statically linked to the provided "libsox.so".

EDIT: But yes, this might be the reason. Given it is the reason, the solution could be to substitute the local "libsox.so" from the (sub-)folder "r128gain-tools" with the system's version.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kode54 on 2012-07-30 13:44:12
I've uploaded a modified lib1770 and posted some details about it [a href='index.php?act=findpost&pid=803753']here[/a]. It may be useful if you ever get around to implementing a multi-threaded scanner. It also makes it possible to compile the library with MSVC, by guarding some C99 code and providing C89 alternatives. I hope Microsoft decides to adopt C99 some day, though. I didn't include the full distribution or the Makefiles, but I did throw in a MSVC 2010 project file.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-07-31 06:59:54
I've uploaded a modified lib1770 and posted some details about it [a href='index.php?act=findpost&pid=803753']here[/a]. It may be useful if you ever get around to implementing a multi-threaded scanner. It also makes it possible to compile the library with MSVC, by guarding some C99 code and providing C89 alternatives. I hope Microsoft decides to adopt C99 some day, though. I didn't include the full distribution or the Makefiles, but I did throw in a MSVC 2010 project file.

Thanks a lot, kode54. Do you have any information regarding a performance gain due to the multithreaded interface? I guess in practice it is bounded by I/O anyway. At least this is true for the current implementation of R128GAIN because it reads the input files sequentially. Do you think it would be a better idea to read and process the files constituting an album in parallel? At least a bounded number of them? How many?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kode54 on 2012-07-31 08:35:12
It may be a good idea to ask Peter about what sort of reading and buffering he does with foo_rgscan, as it seems to gain a lot more over mere parallelization.

For starters, I would try processing up to four files at a time, depending on how many processors and/or cores are available, and also buffer (at least parts of) those files sequentially before processing. Probably a little complicated, and may not be worth the effort. Hmm...
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: skamp on 2012-07-31 08:39:09
Queue and cache files sequentially, and work on them in parallel as each file is done getting cached.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-07-31 10:07:57
Queue and cache files sequentially, and work on them in parallel as each file is done getting cached.

Yes, of course. I've thought about it for a minute a while ago, but just for a minute.

The point is that it adds a lot of complexity to the program. But it's not obvious to me whether it really contributes to the program's over all performance.

After all the files have to be read from disk. That's a mechanical (i.e. slow) operation, at least these days in almost all cases, putting some hard constraints to the program's overall performance.

Another point is that parallel processing makes only sense to me on machines with more than one core. The number of effective parallel threads is limited by the number of available cores.

That's why I asked the question. Maybe ther're some measurements available comparing parallel vs. sequential implementations in order to justify whether adding much complexity to the program is really worthwhile.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: skamp on 2012-07-31 10:43:06
The point is that it adds a lot of complexity to the program. But it's not obvious to me whether it really contributes to the program's over all performance. […] Maybe ther're some measurements available comparing parallel vs. sequential implementations in order to justify whether adding much complexity to the program is really worthwhile.


See this (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=93478&view=findpost&p=797706), for instance. Both caudec and fb2k's RG scanner show a tremendous advantage in performance with that sort of implementation, in such cases where data can be computed much faster than it can be read off a HDD. Multiple concurrent reads on HDDs kill their performance and create a much larger bottleneck than necessary.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-07-31 11:57:28
See this (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=93478&view=findpost&p=797706), for instance.

Ok, I understand that you are an expert for such kinds of programs.

On top of your Caudec thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=93478) you define the constraints under which this kind of optimization makes sense (higlighting by me):

It leverages multi-core CPUs with lots of RAM by copying input files to a tmpfs mount, and running multiple processes concurrently (one per file and per codec).

I'm not certain whether the majority of users will fit into this. Hence we end up with a similar question: Is it worthwhile to add the complexity to a program when it is not obvious how many people will really profit from it?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: skamp on 2012-07-31 13:04:08
Ok, I understand that you are an expert for such kinds of programs.

Hardly!

Is it worthwhile to add the complexity to a program when it is not obvious how many people will really profit from it?

I guess it depends on how you look at it. The trend is to have multiple CPU cores, and more and more RAM. I'd say that taking that trend into account is forward thinking and future proofing, hence worthwhile. My motivation behind caudec was to leverage the added processing power of my gear at the time. Owners of recent hardware will greatly benefit from the added complexity, while there isn't really a downside for owners of older hardware. Depends on how motivated you are I guess, and how much fun you think you'll have doing it
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-08-08 10:22:58
Any chance you would add command line options for setting Sox & FFmpeg to different folders...than the assumed default.

--path-sox
--path-ffmpeg

I'd just like to only have one copy of each on my system is all.

Thanks for your time and all your effort.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-08-15 17:11:28
Version 1.0-alpha-3 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
Any chance you would add command line options for setting Sox & FFmpeg to different folders...than the assumed default.

--path-sox
--path-ffmpeg

I'd just like to only have one copy of each on my system is all.

Thanks for your time and all your effort.

What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-08-17 18:57:59
Sweet many many thanks for this!
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-08-17 21:59:33
Version 1.0-alpha-4 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
I've uploaded a modified lib1770 and posted some details about it [a href='index.php?act=findpost&pid=803753']here[/a]. It may be useful if you ever get around to implementing a multi-threaded scanner. It also makes it possible to compile the library with MSVC, by guarding some C99 code and providing C89 alternatives. I hope Microsoft decides to adopt C99 some day, though.

Queue and cache files sequentially, and work on them in parallel as each file is done getting cached.

What's new?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kode54 on 2012-08-18 00:23:50
You made a typo on line 85 of bs1770_ctx.c:

Code: [Select]
-    bs1770_nd_t *rp=rp+ctx->size;
+    bs1770_nd_t *rp=mp+ctx->size;
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-08-18 04:29:00
You made a typo on line 85 of bs1770_ctx.c:

Code: [Select]
-    bs1770_nd_t *rp=rp+ctx->size;
+    bs1770_nd_t *rp=mp+ctx->size;

Thanks a lot, kode54. I've uploaded r128gain-1.0-alpha-5 as well as lib1770-0.8.1.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Goran Tomas on 2012-09-23 09:31:08
I have a labeling consistency question - why do you have options labeled as R128-1 and R128-2?

There is no R128-1 and R128-2. There is R128 and there are ITU BS.1770-1 and ITU BS.1770-2. R128 is based on ITU BS.1770-2.

This might confuse people and it's not technically correct to refer to something that doesn't exist (such as R128-1 or R128-2).


Regards,
Goran Tomas
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-09-23 20:01:06
There is no R128-1 and R128-2.

From a formal point of view you may be right. But if you have a look at the standard document's (http://tech.ebu.ch/docs/tech/tech3341.pdf) history (on page 5) you'll notice that there's
Among others the two versions differ as follows:
For the sake of simplicity R128GAIN refers to "Tech 3341" (2010) as R128-1 and to "Tech 3341-2011" as R128-2.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Goran Tomas on 2012-09-23 20:32:04
Exactly. R128 was revised and from that point refers to ITU BS.1770-2. If you measure/normalize something according to ITU BS.1770, it's no longer valid to call it R128 compliant. It has to be ITU BS.1770-2. There's only one R128 recommendation. That's why I'm saying this is confusing to the users. It refers to something that doesn't exist.

My suggestion would be to have an ITU BS.1770 measurement and have a R128 measurement. This would be technically correct and would be relateable exactly to the documents and recommendations as they exist. Moreover, this expands the potential use of this tool to much larger territories such as the USA, because the US standard (ATSC A/85) at the moment uses ITU BS.1770. So, a European user would use R128 and have gated measurement (as it is now, with 10LU relative gate and an absolute gate). A US user would use ITU BS.1770 and have no relative gate (only -70LUFS absolute gate) as this is what's valid for their territory.

This is exactly what some professional product do, to be able to be compliant to both A/85 and R128. I wouldn't introduce more confusion with two R128 revisions (there's already too much confusion). The 2010 R128 revision has been superseded and the current revision is valid and it's called only R128.


Regards,
Goran Tomas
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: unsword on 2012-09-25 02:26:35
Firstly - Thanks to pbelkner for the hard work and diligence put into producing an excellent piece of software

Using the command line version I have been able to update to gated techniques a tool to measure the loudness of audio associated with MPEG-2 video files which was hacked together over a year ago using FFMPEG, SOX and the BBC BS.1770 based loudness software.

I need to make one point regarding the previous posting:

... Moreover, this expands the potential use of this tool to much larger territories such as the USA, because the US standard (ATSC A/85) at the moment uses ITU BS.1770. So, a European user would use R128 and have gated measurement (as it is now, with 10LU relative gate and an absolute gate). A US user would use ITU BS.1770 and have no relative gate (only -70LUFS absolute gate) as this is what's valid for their territory.


ATSC A/85 does not mandate any specific version of BS-1770. It actually says "Users should utilize the current version of BS-1770 for measurements". This has resulted in some confusion as to whether gated measurement techniques should be used - but those in the broadcasting leading the efforts in this field are very clear that gated measurements as introduced in BS1770-2 should be used. I have heard that an update to ATSC A/85 is likely to be published shortly and expect this topic will be clarified.

Oh - and just to add to the fun (and confusion ?) - ITU-R BS.1770-3 was just published 

http://www.itu.int/dms_pubrec/itu-r/rec/bs...;!PDF-E.pdf (http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-I!!PDF-E.pdf)

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Goran Tomas on 2012-09-25 11:27:19
ATSC A/85 does not mandate any specific version of BS-1770. It actually says "Users should utilize the current version of BS-1770 for measurements". This has resulted in some confusion as to whether gated measurement techniques should be used - but those in the broadcasting leading the efforts in this field are very clear that gated measurements as introduced in BS1770-2 should be used. I have heard that an update to ATSC A/85 is likely to be published shortly and expect this topic will be clarified.


Indeed, the A/85 is unclear which BS.1770 standard it refers to and this has generated some confusion in the broadcast industry. However, my experience is opposite to yours. From what I've seen, broadcasters and manufacturers have concluded that A/85 refers to the original BS.1770 because that's what existed when the A/85 was published, and not BS.1770-2. But you could easily argue both cases, which is why I hope that the ATSC will revise A/85 document to make this explicit.

My comments were made to suggest an improvement to the labeling in the tool provided (which I think is great and will be very useful) and make those labels more technically correct. If you Google R128-1 or R128-2, these don't exist. This adds to the confusion and in my opinion, can unnecessarily make this tool look less professional. And that would be a shame as, like I said, this could be very, very useful to a lot of people - consumers and professionals alike.


Regards,
Goran Tomas
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-09-25 16:05:29
My comments were made to suggest an improvement to the labeling in the tool provided (which I think is great and will be very useful) and make those labels more technically correct. If you Google R128-1 or R128-2, these don't exist. This adds to the confusion and in my opinion, can unnecessarily make this tool look less professional. And that would be a shame as, like I said, this could be very, very useful to a lot of people - consumers and professionals alike.

For some intermediate time I'd prefer to have the two choices. Maybe it's of some advantage to re-label them to "R128-2010" and "R128-2011", respectively, in order to avoid confusion.

Indeed, the A/85 is unclear which BS.1770 standard it refers to and this has generated some confusion in the broadcast industry. However, my experience is opposite to yours. From what I've seen, broadcasters and manufacturers have concluded that A/85 refers to the original BS.1770 because that's what existed when the A/85 was published, and not BS.1770-2. But you could easily argue both cases, which is why I hope that the ATSC will revise A/85 document to make this explicit.

As far as I can see there is no practical difference between BS.1770 (http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-0-200607-S!!PDF-E.pdf) and BS.1770-1 (http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-1-200709-S!!PDF-E.pdf) w.r.t loudness measurement. Both versions have no concept of overlapping blocks and gating. There's also no obvious difference w.r.t true peak measurement.

Both, BS.1770-2 (http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-2-201103-S!!PDF-E.pdf) and BS.1770-3 (http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-I!!PDF-E.pdf), have the same concept of loudness measurement using overlapping blocks and gating (as proposed by EBU R128-2010, but with different overlap and different gating threshold). The algorithm for true peak measurement has changed in both versions. BS.1770-3 makes a low pass filter mandatory and removes any DC processing.

As far as I can see ATSC A/85-2011 (http://www.atsc.org/cms/standards/a_85-2011a.pdf) refers to BS.1770 and BS.1770-1, i.e. no overlapping and no gating. ATSC A/85-2011 defines the target loudness to -24 LKFS and the maximum peak level to -2 dB TP.

Unfortunately it is not possible yet to fully adjust R128GAIN according to ATSC A/85-2011. To some extend it is possible by setting "Partition" to 1 and "Gate" to some positive value. But there's no way to configure the target loudness using the GUI, the command line provides a "--preamp" option for achieving this. But, of course, R128GAIN's next version should provide options for switching off gating, choosing the target loudness, and for choosing a A/85-2011 profile similar to the options for choosing R128-2010 and R128-2011 profiles.

EDIT: Sorry for having overlooked the following:

ATSC A/85 does not mandate any specific version of BS-1770. It actually says "Users should utilize the current version of BS-1770 for measurements". This has resulted in some confusion as to whether gated measurement techniques should be used - but those in the broadcasting leading the efforts in this field are very clear that gated measurements as introduced in BS1770-2 should be used. I have heard that an update to ATSC A/85 is likely to be published shortly and expect this topic will be clarified.

This makes it a bit harder to provide a A/85-2011 profile then stated above, but it should be possible anyway.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: punkrockdude on 2012-09-26 00:37:14
Thank you very much for the Linux GTK version. I really appreciate it. While I'm writing I might as well ask how to make the new files keep tags they processed files had?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: unsword on 2012-09-26 10:28:46
Regarding an ATSC A/85 - a revision is certainly in order. If you read section 5.2 it talks about how periods of quiet will impact the accuracy of an integrated measurement and that pausing or gating would improve this - and the fact that gating may be introduced into BS1770 'in the future' - the future is now !.

I would definitely like to see the option to define the target loudness as either -23 or -24, or some other user-definable value, since ATSC A/85 does not mandate -24, it simply recommends it in the absence of any defined in-house dialnorm value. While the defacto standard in the US has become -24 LKFS it's up to individual facilities and broadcasters to define their own standards - and then of course make everything match...

One feature which would be useful when examining long-form TV programming is some type of data export of loudness analysis trend. You can analyze a 10 minute segment of a show and get an integrated loudness value but it doesn't give you any indication of the quality of the mix. If the mix is good - i.e. the levels are consistent and well matched between scenes or presenters - then an adjustment to the overall level up or down will typically bring it to the target loudness. But if the mix is bad (poorly produced show and/or not mixed using loudness measurement techniques) then applying a scaling adjustment might make the 'number' right but it will still sound bad.

Being able to scan files and derive a report which assess their suitability to be normalized, or indicate if other processesing or even a remix is required would be very helpful.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-07 18:34:17
Hello.

First of all thx for all your efforts. These are very much appreciated.

I do have some comments /questions.

I just tried the Linux 64bit and 32bit cli version Alpha 5 on Ubuntu 12.04.


1. I do have problems with the file management of flac files: 

r128gain <options>  --in-place    "indir"  -o  "indir" 
r128gain <options>  --in-place    *flac -o  .

the program tells me that the original files can not be overwritten, respectively generates a new directory even though --in-place is active.
I checked permissions - these are OK.

What am I doing wrong??

It works when choosing another directory as output directory


2. I can run the binary from command line,  but somehow it doesn't work when started from a bash script ( to run a batch conversion job)
    I tried to trace it - but there's not any output written.

3. --sox refers to a path. It might be more benefitial to use the actual library file.  The Ubuntu original sox library is e.g. called /usr/lib/libsox.so.1 

4. The program writes db-values and "LU" as a unit into the tags. I think it might be an idea - due to app-parser compatibility reasons - to stay with db as unit.
  After all  we're still talking about gain adjust in db.  This way compatibility issues with certain applications reading the full RPG tags can be avoided.

5. output mode quiet. I  tried --loglevel=0  --progress=off to get the app quietly working. Nothing wokred as expecetd. It seems that there'll always be output to stdout.
    Would be nice to have a working "-q" option in place.

6. Are those peak options
    --peak=[off|sample|true]

  and these

    --no-peak
    --sample-peak
    --true-peak

    redundant ?

  Maybe you could remove this redundancy to avoid confusion!!?

7. I'm also quite confused by

    --r128              Run in EBU R128-2 compliance mode (default).
    --r128-2            Run in EBU R128-2 compliance mode (default).
    --r128-1            Run in EBU R128-1 compliance mode.
    --rg                Run in ReplayGain compliance mode.
    --compliant=[r128-2|r128-1|rg]  Run in respective compliance mode.
    --r128-compatible  Calibrate output according to EBU R128.
      --rg-compatible    Calibrate output according to ReplayGain.

  There also seems to be some redundancy in above options.
  I think only  entries 2,3,4 should stay to avoid confusion - if I interprete the intention behind it correctly.


That's my initial feedback after an hour working with the app.

Looking forward to your feedback.

THX a lot.
SC
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-09 07:14:09
I do have some comments /questions.

Thanks a lot for the feedback.

1. I do have problems with the file management of flac files: 

r128gain <options>  --in-place    "indir"  -o  "indir" 
r128gain <options>  --in-place    *flac -o  .

the program tells me that the original files can not be overwritten, respectively generates a new directory even though --in-place is active.
I checked permissions - these are OK.

What am I doing wrong??

It works when choosing another directory as output directory

Probably you're right. Unfortunately I can't verify it right now because I don't have access to my development environment during the next few days.

2. I can run the binary from command line,  but somehow it doesn't work when started from a bash script ( to run a batch conversion job)
    I tried to trace it - but there's not any output written.

This sounds a bit strange. Unfortunately I can't verify it right now because I don't have access to my development environment during the next few days.

3. --sox refers to a path. It might be more benefitial to use the actual library file.  The Ubuntu original sox library is e.g. called /usr/lib/libsox.so.1
 
R128GAIN looks for "libsox.so". I should change this to "libsox.so.1". Changing the meaning of "--sox" would cause an inconsistency to the "--ffmpeg" switch.

4. The program writes db-values and "LU" as a unit into the tags. I think it might be an idea - due to app-parser compatibility reasons - to stay with db as unit.
  After all  we're still talking about gain adjust in db.  This way compatibility issues with certain applications reading the full RPG tags can be avoided.

I'm not very lucky with this myself. Having it this way is due to some discussions you'll find up this thread. The discussion was about whether R128GAIN is allowed or not to re-use the ReplayGain tags. Maybe R128GAIN should provide a "--db" switch forcing dB instead of LU, TP etc.

5. output mode quiet. I  tried --loglevel=0  --progress=off to get the app quietly working. Nothing wokred as expecetd. It seems that there'll always be output to stdout.
    Would be nice to have a working "-q" option in place.

"--loglevel" is the FFmpeg loglevel, it is just passed to FFmpeg. "--progress=off" suppresses the display of percentages. R128GAIN should provide a "--quiet" switch in order to suppress any output.

6. Are those peak options
    --peak=[off|sample|true]

  and these

    --no-peak
    --sample-peak
    --true-peak

    redundant ?

  Maybe you could remove this redundancy to avoid confusion!!?

They are redundant.

7. I'm also quite confused by

    --r128              Run in EBU R128-2 compliance mode (default).
    --r128-2            Run in EBU R128-2 compliance mode (default).
    --r128-1            Run in EBU R128-1 compliance mode.
    --rg                Run in ReplayGain compliance mode.
    --compliant=[r128-2|r128-1|rg]  Run in respective compliance mode.
    --r128-compatible  Calibrate output according to EBU R128.
      --rg-compatible    Calibrate output according to ReplayGain.

  There also seems to be some redundancy in above options.
  I think only  entries 2,3,4 should stay to avoid confusion - if I interprete the intention behind it correctly.

The "--*-compatible" switches are different from the others. The others produce output in full accordance with the respective standard. The "--*-compatible" switches modify the output w.r.t units (RG: dB, R128: LU/TP) and target loudness. I suspect that the command "r128gain --rg-compatible ..." is what is meant by ReplayGain2 (cf. http://www.hydrogenaudio.org/forums/index....showtopic=89841 (http://www.hydrogenaudio.org/forums/index.php?showtopic=89841), http://wiki.hydrogenaudio.org/index.php?ti...0_specification (http://wiki.hydrogenaudio.org/index.php?title=Talk:ReplayGain_2.0_specification)), i.e. ITU BS.1770 with traditional RG reference level and units.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-09 09:37:37
Thx for the feedback.

Some more thoughts

** I'd get along with  a tagunit switch --tagunit=[db|LU|TP]
** And a switch which refers to  a different LU reference base of -18LU or -23LU  --  this way you'd be able skip those IMO still confusing --*compatible options.

** sox and ffmpeg switches are both kind of inconsistant.  I think there need to be reference to the lib AND to the binary respectively the PATH.
    --sox=  --ffmpeg= could refer to the binary -- I might want to distinguish between the binaries as supplied by r128gain and my own and than the lib references  --soxlib= --ffmpeglib=



And one more:

If you'd introduce a "-i" switch you'd be consistant to the -o switch.


-o should not be required if --in-place is used ( though I'd rather call --in-place "--overwrite" to clearly show its impact)


Below my option wishlist summary for the cli implementation

--peak=[off|sample|true]            ## [default=true]
--tagunit=[db|LU|TP]                  ## units written to RPG tags [default=db]
--mode=[rg|128-1|128-2]            ## [default=128-2]
--reference=[-18|-23]                ## [default=-23]

--sox=                                      ##path to sox binary OR binary if specified [default=/usr/share/r128gain/bin] 
--ffmpeg=                                  ##path to ffmpeg binary OR binary if specified [default=/usr/share/r128gain/bin]
--libsox=                                    ##path to sox library OR library if specified [default=/usr/share/r128gain/lib]
--libffmpeg=                              ##path to ffmpeg library OR library if specified [default=/usr/share/r128gain/lib]

--> package should always be installed in /usr/share/r128gain the binary should be linked from /usr/local/bin to /usr/share/r128gain/bin ( you might change tools to bin)

--overwrite                                ## overwrites existings files respectively existing tags. Audio data remain untouched!!
-i                                              ## input file|filelist|directory  e.g.  track.flac|*flac|/music/CD1
-o                                              ## output base directory where "input file|filelist|directory" will be copied/saved -- not required in case --overwrite is used
--format=[flac|wav|bwf]              ## output format flac/wav/bwf -- not required if --overwrite if used. If not used  input format=output format

                                                  Note1: If flac en- or recoding takes place a Flac Compression Level option ( -C [0-8] ) -- see sox -- should be introduced.
                                                  Note2: the todays "flac" only  option would be obsolete with --format.

OPTIONAL:


--group=[list|dir|tag]              ## a new option that specifies what files are to be taken to calculate the "common" value.
                                                  Eg: If you've got  tons of files in one directory it might be better to read out the album tag and take that as the common denominator for applying album LU/RPG tags.
                                                        --group=list would cover e.g. *flac  --group=dir  would cover /music/CD1 




That'll be it for now.  Gotta run. 

Cheers
SC
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-09 13:37:10
Some more thoughts

Thank you for all the suggestions. Some of them are already under consideration, cf. some of the discussions above (e.g. defining the reference level).

Of most importance to me for further development of R128GAIN is to provide the ability of applying the gain to the output possibly including transcoding to a different format. Currently this is possible by using the "--command" option but I feel that it would be preferable to have R128GAIN supporting it natively. This would be a natural extension of the "--flac" option as already pointed out by you.

Regarding the command line I don't see any need to alter the general structure. The main idea is to have up to four sections:
Viewed this way "-o" is a separator (between the mandatory list of input files and the optional output folder) rather a switch. Hence an "-i" option is not only not needed but would be rather confusing by suggesting a free order of the command line's arguments.

Regarding your proposal for grouping by tags I'm not considering it currently. I've thought about it at the beginning but came to the conclusion that it would contribute much to the program's ever growing complexity without a real need. Instead I'd like to encourage users to use their file system in a way that it is thought for, i.e. not having 1000's or even 10.000's files in one folder but instead grouping them in a natural way by using sub-folders. After all that's the reason why file systems usually provide the means of folders.

To wrap up, my priority is to extend the abilities with respect to the output (including applying the gain and transcoding) rather then re-arranging the command line. This will, of course, include a way for defining the quality / compression ratio as long as it is mappable to FFmpeg.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-09 14:39:13
My last post looked a bit wild I guess.

I just tried to structure and make it a bit more consistant  -  based on my brief experiences with the app - the commands a little. You'll find similar  structures with sox etc.

It's meant to be just a sort of  a feedback.

I don't really ask for new features. Mainly everything is there. Just the help descriptions and command syntax could IMO use some more refinement..

The grouping of tags by album is a feature that dbPoweramp offers  for RPG tags. That's really an option.
I personally can't even make use of it.


However. I'd be happy if you could look into the problems related to overwriting existing files and the script problem.


Most of the other stuff I can introduce by myself by script (swapping LU with db is pretty easy to accomplish by metaflac and sed command etc.)

THX

Keep up the good work.

I do deliver stuff to the community FOC by myself. I know how it is. Probably life would have been easier to just offer
a simple commandline app.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-09 16:25:56
Problem report:
################

I.

Case 1: all r128gain files are moved to one directory


./r128gain --sox="." --in-place --compliant=r128-2 --true-peak --tags=rg /tmp/music/CD1 -o /tmp/tmp

==error loading sox

###############

Case 2:  r128gain in /usr/local/bin, libs and tools are in the original directory structure


r128gain --sox="./r128gain-tools/" --in-place --compliant=r128-2 --true-peak --tags=rg /tmp/music/CD1 -o /tmp/tmp
or
r128gain --sox="/tmp/r128gain-1.0-alpha-5/r128gain-tools/" --in-place --compliant=r128-2 --true-peak --tags=rg /tmp/music/CD1 -o /tmp/tmp


==error loading sox

Case 3:  r128gain in original directory structure and libs and tools also in the original directory structure

./r128gain --sox="./r128gain-tools/" --in-place --compliant=r128-2 --true-peak --tags=rg /tmp/music/CD1 -o /tmp/tmp


That's the only way I get it to work.


I also tried other senarios -- e.g.

Case 4. set sox path to /usr/lib and linked libsox.so.1 to libsox.so

again same problem as above.


I am wondering if there's something wrong with the path references.

Or I am just to stupid.


Another one:

II.

I downloaded the 32bit CLI version. Could it be that it is the same as the 64bit CLI version?? The binary tells my "permission denied"


THX
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-09 16:53:39
I downloaded the 32bit CLI version. Could it be that it is the same as the 64bit CLI version?? The binary tells my "permission denied"

Why are you concluding that the two versions are the same? Obviously both versions behave differently: the 64 bit version executes on your 64 bit system, whereas the 32 bit version doesn't.

The versions are build using 32 bit and 64 bit Ubuntu running in respective VMs on Windows Vista.  The file name (containing "linux" vs. "linux64") is automatically derived from "uname -a" during the build.

Regarding the other questions: I'm not able to access my development environment during the next few days.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-09 17:14:45
I downloaded the 32bit CLI version. Could it be that it is the same as the 64bit CLI version?? The binary tells my "permission denied"

Why are you concluding that the two versions are the same? Obviously both versions behave differently: the 64 bit version executes on your 64 bit system, whereas the 32 bit version doesn't.

The versions are build using 32 bit and 64 bit Ubuntu running in respective VMs on Windows Vista.  The file name (containing "linux" vs. "linux64") is automatically derived from "uname -a" during the build.

Regarding the other questions: I'm not able to access my development environment during the next few days.


I assumed they are different. But the 32 bit version didn't run on a 32 bit system. The 64bit version worked without
problems on a 64 bit system.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-14 15:47:37
Version 1.0-alpha-6 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
What's new?
(http://r128gain.sourceforge.net/upload/121014/r128gain-win32.jpg)
Code: [Select]
$ r128gain --help
An EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.
For details refer to "http://r128gain.sourceforge.net/".

Usage: r128gain [options] (file|directory)+ [-o <directory> [flac|mkv]]
Options:
  --r128              Run in EBU R128-2011 compliance mode (default).
  --r128-2011         Run in EBU R128-2011 compliance mode (default).
  --r128-2010         Run in EBU R128-2010 compliance mode.
  --a85               Run in ATSC A/85:2011 compliance mode.
  --a85-2011          Run in ATSC A/85:2011 compliance mode.
  --rg2               Run in ReplayGain2 compliance mode.
  --rg                Run in ReplayGain compliance mode.
  --reference=<float>  Set reference loudness in LUFS.
  --r128-compatible   Calibrate output according to EBU R128.
  --rg-compatible     Calibrate output according to ReplayGain.
  --db                Use dB as unit rather then LU/TP.
  --partition=<int>   BS.1770 overlap
                      (overlap in % = (1 - 1/partition) * 100%,
                      default: 4, i.e. 75% overlap).
  --gate=<float>      BS.1770 gate (-10.0 .. -8.0, default: -10.0).
  --rg-calibration=<float>  Aequivalent to use for ReplayGain
                      loudness (default: -18.0).
  --no-peak
  --sample-peak
  --true-peak
  --range=on,--range  Calculate loudness range (default).
  --range=off,--no range  Don't calculate loudness range.
  --tags=[rg|bwf]     Write ReplayGain (default) or BWF tags.
  --fast              Switch off up-sampling and don't calculate
                      loudness range.
  --mono=off          Treat mono as stereo (default).
  --mono=on,--mono    Don't treat mono as stereo.
  --quiet             Supress output to stdout.
  --progress=on       Display progress (default).
  --progress=off      Don't display progress.
  --traditional       Format output traditionally.
  --command=<string>  Run command on each track.
  --overwrite         Overwrite already existing output files.
  --in-place          Overwrite original files.
  --loglevel=<integer>  Set FFmpeg loglevel.
  --regression        Calculate linear regression between EBU R128
                      and ReplayGain.
  --duration          Print out duration.
  --version           Display version information.
  --ffmpeg=<path>     Directory of the FFmpeg shared libraries.
  --sox=<path>        Directory of the SoX shared libraries.
  --help              Display this information.
$ _
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-14 16:33:15

Whow. Great. Thx a lot for considering some of my feedback.


Did you manage to replicate/solve my reported problems on the  PATH subject  in post #409 on the CLI version?


Q:

What is considered superior A/85 or R128.

By reading this

http://www.merging.com/uploads/assets/Merg...ambiguation.pdf (http://www.merging.com/uploads/assets/Merging_pdfs/FinalCheck/LoudnessStandardsDisambiguation.pdf)


I'd guess it's probably better to stay with EBU.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-14 17:04:42
Whow. Great.

Thanks a lot

Thx a lot for considering some of my feedback.

Feedback is always very welcome

Did you manage to replicate/solve my reported problems on the  PATH subject  in post #409 on the CLI version?

Unfortunately I was not able to reproduce it, except regarding "libsox.so.1".

What is considered superior A/85 or R128.

Neither. Both are flavors of ITU BS.1770. EBU R128 is the European variant whereas ATSC A/85 is for the U.S. and Canada. The main difference between the two is the reference loudness, EBU R128: -23 LU, ATSC A/85: -24 dB.

I'd guess it's probably better to stay with EBU.

It depends on where you're located.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-14 17:24:16
--reference=-23LUFS

is above how it has to look like? What means float here? -23.00?

THX.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-14 17:50:03
--reference=-23LUFS

is above how it has to look like? What means float here? -23.00?

THX.

Just "--reference=-23" or "--reference=-23.0", if you like, without any unit.

EBU R128-2011 is the default and it's reference loudness is -23 LU, hence it shouldn't make any difference whether you supply "--reference=-23.0" or not.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-14 19:47:23
Version 1.0-alpha-6 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]

There was a minor glitch with the ReplayGain2 radio button. I've uploaded 1.0-alpha-6-2 with a fix.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-14 20:18:45
I stiil don't get the cli app started from a bash script.

There seems to be  something going wrong with the environment/shell.

Do you want me to post the script?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-14 20:46:11
I stiil don't get the cli app started from a bash script.

There seems to be  something going wrong with the environment/shell.

Do you want me to post the script?

I did the following:

Code: [Select]
peter@ubuntu:~$ ./hello
bash: ./hello: Permission denied
peter@ubuntu:~$ chmod +x hello
peter@ubuntu:~$ ./hello
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
/h/TEMP/O
  analyzing ...
    [1/1] "01_oh_susannah.flac": -10.9 LUFS (-12.1 LU)
        peak: -0.2 TPFS, range: 6.2 LU
    [ALBUM]: -10.9 LUFS (-12.1 LU)
        peak: -0.2 TPFS, range: 6.2 LU
  done.
Done.
peter@ubuntu:~$ cat hello
r128gain /h/TEMP/O
peter@ubuntu:~$ uname -a
Linux ubuntu 3.0.0-26-generic #43-Ubuntu SMP Tue Sep 25 17:19:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
peter@ubuntu:~$

I first got the "Permission denied" from the script and not from "r128gain".
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-15 08:37:30
Enclosed some more subjects:


1. Script  - directory given as argument
##############################

Code: [Select]
#!/bin/bash -x

loop () {
find /tmp  -iname '*.flac' -printf '%h\n' | sort -u | while read "I"
do
  r128gain  --sox=/usr/lib  --r128-2011 --true-peak --reference=-27 --in-place --tags=rg --db "$I"
done
}

cli () {
r128gain  --sox=/usr/lib  --r128-2011 --true-peak --reference=-27 --in-place --tags=rg --db "$1"
}

#loop
cli $1

exit 0



the cli()  works, the loop() doesn't - that's my earlier reported problem.

######################################


2. Core Dump
#############################################################

While running above cli() , I experienced a core dump when r128gain accessed a sub-directory with no audio files. As argument $1 /tmp/ has been given.

Code: [Select]
./test.sh: line 10:  2140 Segmentation fault      (core dumped) r128gain --sox=/usr/lib --r128-2011 --true-peak --reference=-27 --in-place --tags=rg --db "$1"


Note: You should check if there are audio files in the directories -- see my above loop function

######################################

Beside that

* my PATH/lib and startup problems got solved
* db as unit into RG tags works
* --in-place works now
* Spaces in filenames and directories are also covered

Great progress.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-15 09:36:31
Now some words to the first tests related to R128 performance.

What I did in the past.

I
1. inroduced RG tags
2. introduced an audio system specific offset (differs from stereo to stereo)
3. introduced my own gain tag ( additional VC adjustments based on subjective listeningtests with 1. and 2. applied)

I ran the r128-2011 on some overcompressed and some "normal" and vocal material.

It's IMO better then the RG algorithm on the first glance.

It works quite good on my normal material. (pretty much in line with my own listening tests)
But on the overcompressed material it's still much too loud.
On my vocal music CD. The adjust is not high enough.  This one is also much too load.

Of course you can turn it also around. The normal music  would then be turned down too much in comparision to the compressed music.

What knobs would you guys recommend to adjust to get me closer to the real thing?? Basically my normal material can stay as it is and the "loud" material should be taken down.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-15 10:28:15

I'm wondering if/how the loudness range parameter gets accounted for within r128gain.


The results (RG tags)  seem to look much better, if I'd take the loudness range into account.

My "normal" test CDs come with a LR of ~17 and
my "loud" CDs with ~8. That's quite a difference. 
(There are also some in-betweens.)


Adding that LR difference of normalCD[LR]-loudCD[LR] - by taking my normal CDs as  a kind of reference -  I end up at  ~-8db additional attenuation on my "loud" tracks.

Guess what. That would bring them much further to my own listening tests results done on the RG tags.   

Does anybody got an opinion about that??

BTW: I also tested  r128-2010-g8 . The differences to r128-2011-g10 are neglectable compared to above mismatch at this stage.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-15 15:05:37
I just tried the RG2 algorithm as supplied by r128gain Alpha 6.

That's IMO worse then RG1.



They all seem to have severe difficulties to figure out the right album gain.

If I load the first track of an album, I don't need more than 10s to figure out if it is to loud or to low.
And than the volume control usually stays that way. I don't need to scan the full CD to figure it out.

Not any of the known algorithms can IMO accomplish that. They all still seem to be pretty far off target.

I'll keep trying for some more time. Otherwise I'm gonna keep my own RG method.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-10-16 21:37:19
Hello,
running the 2 versions of R128GAIN
  - R128GAIN v1.0.alpha5 and
  - R128GAIN v1.0.alpha6-2
on the EBU R128 test vector
the results are not the same, alpha 6-2 is giving wrong results.

How is that possible?
Thanks
Jean

Code: [Select]
R128GAIN v1.0.alpha5
DlgItemUrl sucessfully loaded.
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\1
  analyzing ...
    [1/3] "1kHz Sine -20 LUFS-16bit.wav": -20.0 LUFS (-3.0 LU)
        peak: -19.9 TPFS, range: 0.0 LU
    [2/3] "1kHz Sine -26 LUFS-16bit.wav": -26.0 LUFS (3.0 LU)
        peak: -25.9 TPFS, range: 0.0 LU
    [3/3] "1kHz Sine -40 LUFS-16bit.wav": -40.0 LUFS (17.0 LU)
        peak: -39.8 TPFS, range: 0.0 LU
    [ALBUM]: -22.0 LUFS (-1.0 LU)
        peak: -19.9 TPFS, range: 20.0 LU
  done.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\2
  analyzing ...
    [1/9] "seq-3341-1-16bit.wav": -23.0 LUFS (-0.0 LU)
        peak: -22.9 TPFS, range: 0.0 LU
    [2/9] "seq-3341-2-16bit.wav": -33.0 LUFS (10.0 LU)
        peak: -32.7 TPFS, range: 0.0 LU
    [3/9] "seq-3341-2011-8_seq-3342-6-24bit-v02.wav": -23.0 LUFS (0.0 LU)
        peak: -2.6 TPFS, range: 15.3 LU
    [4/9] "seq-3341-3-16bit-v02.wav": -23.0 LUFS (0.0 LU)
        peak: -23.0 TPFS, range: 13.0 LU
    [5/9] "seq-3341-4-16bit-v02.wav": -23.0 LUFS (0.0 LU)
        peak: -23.0 TPFS, range: 13.0 LU
    [6/9] "seq-3341-5-16bit-v02.wav": -23.0 LUFS (-0.0 LU)
        peak: -20.0 TPFS, range: 6.0 LU
    [7/9] "seq-3341-6-5channels-16bit.wav": -23.0 LUFS (0.0 LU)
        peak: -24.0 TPFS, range: 0.0 LU
    [8/9] "seq-3341-6-6channels-WAVEEX-16bit.wav": -23.0 LUFS (0.0 LU)
        peak: -24.0 TPFS, range: 0.0 LU
    [9/9] "seq-3341-7_seq-3342-5-24bit.wav": -23.0 LUFS (-0.0 LU)
        peak: -8.9 TPFS, range: 4.8 LU
    [ALBUM]: -23.2 LUFS (0.2 LU)
        peak: -2.6 TPFS, range: 15.6 LU
  done.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\3
  analyzing ...
    [1/4] "seq-3342-1-16bit.wav": -22.6 LUFS (-0.4 LU)
        peak: -20.0 TPFS, range: 10.0 LU
    [2/4] "seq-3342-2-16bit.wav": -16.8 LUFS (-6.2 LU)
        peak: -15.0 TPFS, range: 5.0 LU
    [3/4] "seq-3342-3-16bit.wav": -20.0 LUFS (-3.0 LU)
        peak: -20.0 TPFS, range: 20.0 LU
    [4/4] "seq-3342-4-16bit.wav": -24.5 LUFS (1.5 LU)
        peak: -20.0 TPFS, range: 15.0 LU
    [ALBUM]: -19.2 LUFS (-3.8 LU)
        peak: -15.0 TPFS, range: 25.0 LU
  done.
Done.
Hit enter to continue ...


Code: [Select]
R128GAIN v1.0.alpha6-2
DlgItemUrl sucessfully loaded.
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\1
  analyzing ...
    [1/3] "1kHz Sine -20 LUFS-16bit.wav": -20.6 LUFS (-2.4 LU)
        peak: -19.9 TPFS, range: 0.0 LU
    [2/3] "1kHz Sine -26 LUFS-16bit.wav": -26.6 LUFS (3.6 LU)
        peak: -25.9 TPFS, range: 0.0 LU
    [3/3] "1kHz Sine -40 LUFS-16bit.wav": -40.6 LUFS (17.6 LU)
        peak: -39.8 TPFS, range: 0.0 LU
    [ALBUM]: -22.6 LUFS (-0.4 LU)
        peak: -19.9 TPFS, range: 20.0 LU
  done.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\2
  analyzing ...
    [1/9] "seq-3341-1-16bit.wav": -23.6 LUFS (0.6 LU)
        peak: -22.9 TPFS, range: 0.0 LU
    [2/9] "seq-3341-2-16bit.wav": -33.6 LUFS (10.6 LU)
        peak: -32.7 TPFS, range: 0.0 LU
    [3/9] "seq-3341-2011-8_seq-3342-6-24bit-v02.wav": -21.9 LUFS (-1.1 LU)
        peak: -2.6 TPFS, range: 17.7 LU
    [4/9] "seq-3341-3-16bit-v02.wav": -23.4 LUFS (0.4 LU)
        peak: -23.0 TPFS, range: 13.0 LU
    [5/9] "seq-3341-4-16bit-v02.wav": -23.7 LUFS (0.7 LU)
        peak: -23.0 TPFS, range: 13.0 LU
    [6/9] "seq-3341-5-16bit-v02.wav": -23.6 LUFS (0.6 LU)
        peak: -20.0 TPFS, range: 6.0 LU
    [7/9] "seq-3341-6-5channels-16bit.wav": -23.2 LUFS (0.2 LU)
        peak: -24.0 TPFS, range: 0.0 LU
    [8/9] "seq-3341-6-6channels-WAVEEX-16bit.wav": -23.1 LUFS (0.1 LU)
        peak: -24.0 TPFS, range: 0.0 LU
    [9/9] "seq-3341-7_seq-3342-5-24bit.wav": -23.6 LUFS (0.6 LU)
        peak: -8.9 TPFS, range: 4.7 LU
    [ALBUM]: -23.0 LUFS (-0.0 LU)
        peak: -2.6 TPFS, range: 16.2 LU
  done.
E:\R128GAIN Test\0-EBU Loudness Test Set v03 (wav)\3
  analyzing ...
    [1/4] "seq-3342-1-16bit.wav": -23.2 LUFS (0.2 LU)
        peak: -20.0 TPFS, range: 10.0 LU
    [2/4] "seq-3342-2-16bit.wav": -17.5 LUFS (-5.5 LU)
        peak: -15.0 TPFS, range: 5.0 LU
    [3/4] "seq-3342-3-16bit.wav": -20.7 LUFS (-2.3 LU)
        peak: -20.0 TPFS, range: 20.0 LU
    [4/4] "seq-3342-4-16bit.wav": -25.2 LUFS (2.2 LU)
        peak: -20.0 TPFS, range: 15.0 LU
    [ALBUM]: -19.8 LUFS (-3.2 LU)
        peak: -15.0 TPFS, range: 25.0 LU
  done.
Done.
Hit enter to continue ...

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-17 07:05:44
Oh.

Just realized that I've been using alpha-6 and not alpha-6.2

jangk interesing findings.

magnitude looks almost like differences beween R128 - 2010 and 2011.

Have you tried explicitely setting mode, reference level and gate?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-10-17 07:58:03
Quote
Have you tried explicitely setting mode, reference level and gate?


No, just using the standard (R128-2011)

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-17 15:14:57
Hi folks.

Just a quick question.

I'm wondering how ISO 226:2003 compares to all the algorithms supplied by r128gain??

Has anybody experience with that one??

THX
SC
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-17 17:08:01
alpha 6-2 is giving wrong results.

Many thanks for the hint. I've uploaded corrected source code and win32 binaries: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/). Linux binaries will follow.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-10-17 20:45:19
Quote
Many thanks for the hint.


You are welcome - thank you for your tremendeous work !

r128gain-1.0-alpha-6-3-win32-native performs perfectly.

Best regards
Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-19 18:58:01
Linux binaries will follow.

The Linux binaries are available: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: unsword on 2012-10-19 22:37:10
Thanks for the additon of the ATSC A/85 support and your continued work on this project.

Is there any difference between the following command line options ?

Code: [Select]
--a85               Run in ATSC A/85:2011 compliance mode.
--a85-2011          Run in ATSC A/85:2011 compliance mode.




Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-20 05:33:24
Thanks for the additon of the ATSC A/85 support and your continued work on this project.

Is there any difference between the following command line options ?

Code: [Select]
--a85               Run in ATSC A/85:2011 compliance mode.
--a85-2011          Run in ATSC A/85:2011 compliance mode.

Currently there isn't any difference. The idea is that in case the standard evolves "--a85" should always refer to the latest version.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-20 08:05:07

Did you manage to have a look at the two issues (script/coredump)  I reported some posts back?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-20 11:14:26
Did you manage to have a look at the two issues (script/coredump)  I reported some posts back?


NO.

Just checked it out by myself.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: unsword on 2012-10-20 15:50:17
Thanks for the additon of the ATSC A/85 support and your continued work on this project.

Is there any difference between the following command line options ?

Code: [Select]
--a85               Run in ATSC A/85:2011 compliance mode.
--a85-2011          Run in ATSC A/85:2011 compliance mode.

Currently there isn't any difference. The idea is that in case the standard evolves "--a85" should always refer to the latest version.


Thanks - I follow the logic
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-22 14:43:33
Hi.

--quiet

won't seem to work in latest alpha-6-3 cli-64.


Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-22 16:41:02
Hi there.

I'm preparing the big run now. On a couple of thousands songs I calculated more then 24 hours duration.

I tested the new Linux cli version ( as well as the old ones) on /tmp mounted into /dev/shm. And now on a HDD.

The HDD testrun is  >40% slower, than my /dev/shm (RAMDISK). And even the duration of  a conversion on ramdisk takes about 11s per track.


I'm wondering if r128gain uses a RAM buffer or if it stores the temporay files on disk.

If it buffers on HDD, things might get improved if I could select a "--temp=/tmp" option to use the RAMdisk as buffer.


What do you think?

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-10-25 04:38:20
Okay I just ran into a crash on WinXP SP3...probably asking for it to some degree.

Firstly I removed from .\r128gain-tools\:
avcodec-54.dll
avdevice-54.dll
avfilter-3.dll
avformat-54.dll
avutil-51.dll
ffmpeg.exe
postproc-52.dll
swresample-0.dll
swscale-2.dll

I then set FFMpeg's path via the command line:
r128gain.exe --ffmpeg=..\FFMpeg\ ...(other commands)...
or
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg\" ...(other commands)...

Both pathing methods resulted in a crash...now if I don't remove the above files...everything is fine...but given that since those files are present in a normal shared FFMpeg release...shouldn't that make the ones present in R128Gain redundant...and thus unnecessary?

However in ether case...required or not...R128Gain should catch the error and simply bitch...not blow up.

Another thing to note...when I went:
r128gain.exe --help > ReadMe.txt

I got a blank file...and not one that contained all the command line help information.
r128gain.exe --help

Does display everything correctly in the console...but I can't seem to pipe it to a text file.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-10-25 05:55:58
Now I thought I read somewhere in the thread that R128Gain supported all formats that FFMpeg handles...It works fine with WAV & FLAC but when I try MP3 & AAC I get no love.

r128gain.exe --r128-2011 --true-peak --reference=-23 --in-place --tags=rg "C:\test\test.mp3"

Am I missing something?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-25 07:06:25
Now I thought I read somewhere in the thread that R128Gain supported all formats that FFMpeg handles...It works fine with WAV & FLAC but when I try MP3 & AAC I get no love.

r128gain.exe --r128-2011 --true-peak --reference=-23 --in-place --tags=rg "C:\test\test.mp3"

Am I missing something?

You should update the FFmpeg DLLs from the sub-folder "r128gain-tools" with the corresponding from the latest Zeranoe build: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-25 07:26:43
I then set FFMpeg's path via the command line:
r128gain.exe --ffmpeg=..\FFMpeg\ ...(other commands)...
or
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg\" ...(other commands)...

Both pathing methods resulted in a crash...now if I don't remove the above files...everything is fine...but given that since those files are present in a normal shared FFMpeg release...shouldn't that make the ones present in R128Gain redundant...and thus unnecessary?

I can't reproduce this one. Most likely you link to a binary incompatible FFmpeg. You should use the binaries from Zeranoe: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/)

Another thing to note...when I went:
r128gain.exe --help > ReadMe.txt

I got a blank file...and not one that contained all the command line help information.
r128gain.exe --help

Does display everything correctly in the console...but I can't seem to pipe it to a text file.

For whatever reason R128GAIN writes the help text to stderr and not to stdout. Please use

Code: [Select]
r128gain.exe --help 2> ReadMe.txt
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-10-25 08:44:04
Thanks for the quick reply.

I updated FFMpeg, both my independent install and the "r128gain-tools" which resulted in a working setup.

I was using a earlier build from zeranoe only a month or so old for my install.

So packaged R128Gain FFMpeg failed as noted prior...but once updated to the latest works fine.

However removing the files again as I noted in my prior post, and using --ffmpeg caused a crash yet again...so the --ffmpeg is mute since there is a dependency for having it in ".\r128gain-tools\".

Also --ffmpeg when using full path...if it has a trailing backslash it fails, but if it doesn't it works fine.
Works:
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg" ...(other commands)..

Fails:
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg\" ...(other commands)..

This issue isn't present when I performed relative pathing.
Works:
r128gain.exe --ffmpeg=..\FFMpeg\ ...(other commands)..
r128gain.exe --ffmpeg=..\FFMpeg ...(other commands)..

Thanks for all the help and effort on this project, it is appreciated.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-25 09:32:05
Works:
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg" ...(other commands)..

Fails:
r128gain.exe --ffmpeg="W:\My Projects\Video Gain\BIN\FFMpeg\" ...(other commands)..

This issue isn't present when I performed relative pathing.
Works:
r128gain.exe --ffmpeg=..\FFMpeg\ ...(other commands)..
r128gain.exe --ffmpeg=..\FFMpeg ...(other commands)..

Many thanks for the detailed report. The error seems to be special to XP (we had already another one of this kind). Unfortunately I don't have access to XP during the next few days.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-25 10:05:56
Hi.

Since I can not run the r128gain in script mode ( the bug still exists), I'd like to make another proposal for the cli version.

I used to check the files if rpg tags existed prior ro conversion. This way I avoid conversions where not needed.

That's very convenient if you scan your entire music directory all the time . Or if the conversion stops (forced stop) and restarts somewhere in the middle of the process.

Basically what's needed is an option that allows to skip conversion in case RPG tags exist.


I really hope that the script bug gets fixed sooner or later. Otherwise usage of r128gain is very limited in cli mode. Above I could have easily implemented by myself.

THX.





Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-26 13:29:41
Hi there.

I just had one of those Murphy's Law experiences.

A huge batch conversion which was running for hours, just caused a core dump .

It was finished with the analysis of one CD at that point in time.

When starting to write the data to disc, r128gain dumped with:

"11000 Floating Point exception (core dumped)."

What a mess. 

Now I do have to run the whole stuff all over again, since the problem mentioned in my last post,
won't let my continue where the program caused the core dump.


A  feature (option) that allows to skip  analyse files with already written rpg(EBU)-tags  would help a lot here.


Or even better - please try to fix my scripting issue. I can check it then by myself and run r128gain on a folder by folder basis.



THX
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-26 14:13:00

What a disaster. 

I just figured that r128gain messed up some of my files in that last directory, where the coredump took place.

I've got some dead bodies called:

X92jzl.flac
kuzTIz.flac
LLQuv7.flac



One hint: It's been Hirez 24/88.2 data and 28 files in a single directory or so. Maybe there's resource issue. I do have 8GB RAM in my machine.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-27 09:58:54
Two more things on the CLI.

1. File permissions gets changed to 600 and ownership gets also changed by r128gain
    It would be nice to protect file attributes or at least make sure that permissions are 666 after writing the new files.
2. While scanning the files a percentage counter runs. If you type "enter" that counter jumps randomly from one percentage to another ( far off) value.
    Not sure if that has any impact on the analysis.  It looks like problem on the first glance.



And one remark:

Just let me know if you're no longer interested in my feedback or the CLI version is put low on your priority list.
I noticed, that you obvisouly respond much quicker to other requests recently.
At least from my perspective - I'm encountering rather critical worst case issues - audio files are getting corrupted -  with this app and I'm willing to support.
At least a - "I'll look into it (next week/month/year)" or "I can't reproduce it" would be appreciated.

THX
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-27 19:41:19
I've uploaded a slightly enhanced version: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/).Please note that FFmpeg's libavutil needs now to be version 52.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-29 14:36:08
Info:

with Alpha-6-4 Linux-cli-64

--chown
--chmod
--progress=off
--quiet

don't work.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Zao on 2012-10-29 14:42:00
don't work.

What's the problem and how does it manifest? "Don't work" is a rather vague description 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-29 14:55:25
don't work.

What's the problem and how does it manifest? "Don't work" is a rather vague description 


It's simple -- all options cover a single simple feature.  Non of those does what it is supposed to do.

1. Output is not quiet
2. Progress is still showing
3. Permissions are still 600 instead of original 666 after files being written ( umask is 644 btw)
4. Owner gets changed

I'm not running my stuff in a virtual environment btw.

THX
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-29 16:30:38
don't work.

What's the problem and how does it manifest? "Don't work" is a rather vague description 


It's simple -- all options cover a single simple feature.  Non of those does what it is supposed to do.

Could you please let us know, at least, the command line you are using?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: RonaldDumsfeld on 2012-10-29 17:03:26
I also have a problem getting R128GAIN to work as expected.

Despite having a suspicion the solution is embarrassingly simple I'm forced to admit to being stuck.

Quote
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)
    Unpack using 7z: http://www.7-zip.org/ (http://www.7-zip.org/)
    Double click "r128gain.exe" from the Windows Explorer.
    Hit the "Choose" button and select your WAV/FLAC file.
    Hit the "Ok" button.


When I execute the above by starting the exe file I get the R128GAIN v1.0-alpha-6-3(FFmpeg edition) window displayed
and a command line window opens with 'GigItemurl successfully loaded. _' Appears.

When I enter the target file name into the input window and hit 'ok'

the command line window reports

Sox successfully loaded
FFmpeg sucessfully loaded
Done
Hit enter to continue ..

So I hit enter..... and nothing constructive happens.

All windows close.

What am I doing wrong?

Windows Vista 64 system. All drivers and OS fully up to date. No other known issues. Intel i7-920 ASUS P6T Deluxe V2. No o/c.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-29 18:47:26
When I enter the target file name into the input window and hit 'ok'

I'm a bit uncertain what you mean by "enter the target file name ...". At a minimum you have to provide an input. If you are interested just in analyzing the input then that's all what is needed.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: RonaldDumsfeld on 2012-10-29 19:20:23
Quote
I'm a bit uncertain what you mean by "enter the target file name ..."


When I execute (double click on) R128GAIN.exe it brings up a windows command line box and the standard windows parameter box I've seen from other peoples screen shots.

The first option on the latter is labeled 'input' with a choose option. I figure that's the place you enter a target file to be analysed. Right?
Quote
If you are interested just in analyzing the input then that's all what is needed.


Yes. So why does nothing happen? Where should the analysis appear?

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 11:10:37
So why does nothing happen?

What kind of file are you adding to the input?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 11:27:01

Here's my commandline (started from a bash script):

Code: [Select]
r128gain --quiet --progress=off --chmod --chown --sox=/usr/share/r128gain/r128gain-tools --r128-2011 --true-peak --gate=-10 --reference=-27 --in-place --tags=rg --db /tmp
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 12:50:12
Here's my commandline (started from a bash script):

Code: [Select]
r128gain --quiet --progress=off --chmod --chown --sox=/usr/share/r128gain/r128gain-tools --r128-2011 --true-peak --gate=-10 --reference=-27 --in-place --tags=rg --db /tmp

You should have "--r128-2011" in front of any other option. This kind of option loads a complete profile including all default settings, i.e. this kind of option effectively overwrites any other setting in front of it.

Code: [Select]
r128gain --r128-2011 --quiet --progress=off --chmod --chown --sox=/usr/share/r128gain/r128gain-tools --true-peak --gate=-10 --reference=-27 --in-place --tags=rg --db /tmp

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 13:05:01
--quiet

won't seem to work in latest alpha-6-3 cli-64.

Meanwhile I've learned that the current implementation is no guarantied to work (cf. e.g. http://www.linuxmisc.com/9-unix-programmer...32581e41ffc.htm (http://www.linuxmisc.com/9-unix-programmer/fe37b32581e41ffc.htm)). The next release will fix this. Meanwhile you should avoid "--quiet" and prefer the following instead:

Code: [Select]
r128gain ... >/dev/null

That's exactly the same what the next version will do in the presence of "--quiet".
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: RonaldDumsfeld on 2012-10-30 13:12:56
Quote
What kind of file are you adding to the input?


.mp3  - More specifically a selection of downloads from Beatport which you asked me to take a look at in another thread.

I've tried it with other file types from various sources of course but the result is always the same.

I'm at a loss where to look for diagnostics. Just seems to disappear without leaving a trace.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 13:29:59
Quote
What kind of file are you adding to the input?


.mp3

In order to allow "r128gain" recognizing MP3 you have to upgrade the FFmpeg DLLs from the folder "r128gain-tools" with their counter parts from the latest Zeranoe build: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/).

I get the R128GAIN v1.0-alpha-6-3(FFmpeg edition) window displayed

Since the alpha-6-3 release they have bumped FFmpeg's libavuitil to version 52. To make "r128gain" working with the latest FFmpeg build from Zeranoe you have also to upgrade "r128gain" to at least alpha-6-4: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 13:44:28
You should have "--r128-2011" in front of any other option. This kind of option loads a complete profile including all default settings, i.e. this kind of option effectively overwrites any other setting in front of it.


THX. I reckon that's a workaround for now!?!?

That's IMO a very "dangerous" behaviour you're describing. People can have settings overwritten without noticing it. Dependencies of options should be covered by the program.
Even if put into the "help" area, the risk of not getting as result what was intented is pretty high. 

THX for letting me know.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 13:56:11
--quiet

won't seem to work in latest alpha-6-3 cli-64.

Meanwhile I've learned that the current implementation is no guarantied to work (cf. e.g. http://www.linuxmisc.com/9-unix-programmer...32581e41ffc.htm (http://www.linuxmisc.com/9-unix-programmer/fe37b32581e41ffc.htm)). The next release will fix this. Meanwhile you should avoid "--quiet" and prefer the following instead:

Code: [Select]
r128gain ... >/dev/null

That's exactly the same what the next version will do in the presence of "--quiet".


First of all. Good to see that I was not wrong. 

Routing to >/dev/null is of course the easy way. Though I'd say it's better to avoid the printfs . 


Scripting issue - once more:

Could it be that my earlier reported script problem is also located in the shell environment area.
I'm running all kind of shell scripts since years and never had a problem with loops. You're also running a recursive loop inside your program.
Maybe those loops interfere somehow. This problem is really bugging me.

Cheers
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 14:16:34
I'm running all kind of shell scripts since years and never had a problem with loops. You're also running a recursive loop inside your program.
Maybe those loops interfere somehow.

I'm not certain what the intention of your script is. I suspect that you try to descent down a directory tree. "r128gain" is doing exactly that.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 14:55:56
I'm running all kind of shell scripts since years and never had a problem with loops. You're also running a recursive loop inside your program.
Maybe those loops interfere somehow.

I'm not certain what the intention of your script is. I suspect that you try to descent down a directory tree. "r128gain" is doing exactly that.


1. I'm running quite some other actions on my files.
2. I can move files around, I can change permissions
3. I can run tailor made loops with certain search masks
asf. asf

I used to use metaflac for applying rg-tags btw. That worked without problems by handing over *flac.


In my opinion/experience CLI programs don't need to implement  smart recursive functions or similar. Like sox,flac,ecasound,metafac you name it. You hand over a set of files
an that's it. Much less hazzle for the programer.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 15:02:37
One more:

If you go for >/dev/null  solution. Please seperate stdout from stderr, to avoid that everything goes straight to /dev/null   

>/dev/null  2>/tmp/error.log

Though I'd rather say. Skip the >/dev/null thing. Take out --quiet if you don't intend to surpress the printfs.

THX
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-10-30 15:28:13
I used to use metaflac for applying rg-tags btw. That worked without problems by handing over *flac.

That's the same with "r128gain": if you provide a list of FLACs it will process exactly these FLACs. You may use wildcards as well, i.e. "*.flac".

As far as I can see, your script does something else. Try the following:

Code: [Select]
find /tmp  -iname '*.flac' -printf '%h\n' | sort -u

It gives you a list of directories including all sub-directories. "r128gain" will traverse recursively each directory. Your script will having run "r128gain" multiple times on the same sub-directories potentially colliding with itself.

You simply don't need the loop.

In my opinion/experience CLI programs don't need to implement  smart recursive functions or similar. Like sox,flac,ecasound,metafac you name it. You hand over a set of files
an that's it. Much less hazzle for the programer.

That's your opinion. I prefer to have just a program without the need for writing additional scripts.

EDIT: If you change "$I" to something like "$I/*.flac" it may work, provided the shell expands the wildcard.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: soundchekk on 2012-10-30 15:50:08
That's your opinion.


You missed " my experience". 

Mainly all cli tools are pretty basic, though extremely "flexible".

But. Never mind.

I talked too much anyhow.


THX again for providing your toolbox to the community.

I'm outta here.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: nfranzke on 2012-11-05 20:15:16
Hello,

i followed this discussion trying to catch the most important points.
i am not into programming, though - being left with a more or less "basic" question concerning the output of r128gain.exe:
basically, the GUI works quite fine, giving me results after having specified input file.(my OS = Win7 64)
But:
1.the resulting analysis (in my case: -25.3 LUFS |-10.0 TPFS  | range 13.8 LU ) - i would like the analysis be shown not only in the commandline but in a separate (explorer)window. is decent for being batch processed.
2.i would like to be able to find the appropriate syntax for the CLI also: i did not get the point, which option should be specified for the output of the results ?
(r128gain.exe --r128-2011 --true peak PfadWavOrdner\*.wav  -->Results of analysis?
3.the resulting analysis showed a wrong prefix in my case:
FFmpeg successfully loaded
analyzing...
  [1/1] "test.686.wav": -25.3 LUFS <2.3LU>
but it should read minus 2.3 LU (referring to -23LUFS=0LU), right?

Hope you guys do not get nervous about plain simple probs,
nice work, this r128gain...
Greez Nico
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-06 07:19:54
1.the resulting analysis (in my case: -25.3 LUFS |-10.0 TPFS  | range 13.8 LU ) - i would like the analysis be shown not only in the commandline but in a separate (explorer)window. is decent for being batch processed.
2.i would like to be able to find the appropriate syntax for the CLI also: i did not get the point, which option should be specified for the output of the results ?
(r128gain.exe --r128-2011 --true peak PfadWavOrdner\*.wav  -->Results of analysis?

I'm not sure what you mean. If you like to have the EBU R128 analysis from the command line you may type something like

Code: [Select]
r128gain file1.wav file2.wav file3.wav

or

Code: [Select]
r128gain infolder\*.wav

If you want to have the results saved in some file it looks like

Code: [Select]
r128gain file1.wav file2.wav file3.wav > analysis.txt

or

Code: [Select]
r128gain infolder\*.wav > analysis.txt

If you want to have the results written as REPLAYGAIN tags the corresponding commands look like

Code: [Select]
r128gain file1.wav file2.wav flac file3.wav -o outfolder flac

or

Code: [Select]
r128gain infolder\*.wav -o outfolder flac

3.the resulting analysis showed a wrong prefix in my case:
FFmpeg successfully loaded
analyzing...
  [1/1] "test.686.wav": -25.3 LUFS <2.3LU>
but it should read minus 2.3 LU (referring to -23LUFS=0LU), right?

It depends on the interpretation of the term "gain". The gain is the amplification which have to be applied in order to get the target loudness.

Hope you guys do not get nervous about plain simple probs,

You're welcome.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Stone Free on 2012-11-06 15:37:41
In order to allow "r128gain" recognizing MP3 you have to upgrade the FFmpeg DLLs from the folder "r128gain-tools" with their counter parts from the latest Zeranoe build: http://ffmpeg.zeranoe.com/builds/win32/shared/ (http://ffmpeg.zeranoe.com/builds/win32/shared/).

Since the alpha-6-3 release they have bumped FFmpeg's libavuitil to version 52. To make "r128gain" working with the latest FFmpeg build from Zeranoe you have also to upgrade "r128gain" to at least alpha-6-4: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/).
I still don't get what I have to do to get it to recognise AAC files with .MP4 extensions.

Do both Sox.exe and FFMPeg.exe both go in the r128-tools folder?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: nfranzke on 2012-11-06 16:23:06
Thanks for your immediate reply, your code samples will work -
i was uncertain about the ability of r128gain to work serially, now it is self-explanatory.

Code: [Select]
r128gain file1.wav file2.wav file3.wav > analysis.txt

or

Code: [Select]
r128gain file1.wav file2.wav file3.wav


best regards,
nfranzke





Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-11-06 22:58:59
Hello,

I just tried to tag some FLAC files with R128GAIN v1.0.alpha6-4, and the program crashed repeatedly during the writing process.
It also happens with earlier versions.

I found out that it happens consequently with FLAC files with embedded album art.

Removing the album art with e.g. mp3tag solved the problem. R128GAIN wrote RG information to the tags and did not crash.

Is this a bug in R128GAIN ???

Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-07 07:07:47
Sox.exe

It's not about SoX at all.

FFMPeg.exe

It's not about the FFmpeg tool itself, it's about the related DLLs:
go in the r128-tools folder?

That's right:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-07 07:11:34
Code: [Select]
r128gain file1.wav file2.wav file3.wav > analysis.txt

I have to correct this a bit. In order to avoid having the "analysis.txt" spammed with the progress messages you should provide the option "--progress=off", i.e.

Code: [Select]
r128gain --progress=off file1.wav file2.wav file3.wav > analysis.txt
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-07 07:15:58
Removing the album art with e.g. mp3tag solved the problem. R128GAIN wrote RG information to the tags and did not crash.

Thanks for the hint. Possibly it's a bug, I've never tried it with embedded album art.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-11-07 07:44:49
Thank you for the quick reply.

Do you think you can fix R128GAIN the way it will work also with embedded artwork?

I would prefer not to strip artwork from all my flac-files.

Thanks a lot
Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-07 08:27:40
Do you think you can fix R128GAIN the way it will work also with embedded artwork?

Hopefully yes. But first I have to have a closer look into it.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-11-07 09:01:52
Thank you and good luck 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: unsword on 2012-11-09 15:29:53
Just realized that when run with the --a85 option the Loudness result is still notated in LUFS - although the same thing, I think it should be reported as LKFS in accordance with ATSC A/85

Thanks
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-11 20:19:12
Version 1.0-alpha-7-1 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
What's new?

(http://r128gain.sourceforge.net/upload/121111/r128gain-win32.jpg)
Code: [Select]
$ r128gain --help
An EBU R128 (http://tech.ebu.ch/loudness) compliant loudness scanner.
For details refer to "http://r128gain.sourceforge.net/".

Usage: r128gain [options] (file|directory)+ [-o <directory> [<format>]]

Options:
  --r128              Run in EBU R128-2011 compliance mode (default).
  --r128-2011         Run in EBU R128-2011 compliance mode (default).
  --r128-2010         Run in EBU R128-2010 compliance mode.
  --a85               Run in ATSC A/85:2011 compliance mode.
  --a85-2011          Run in ATSC A/85:2011 compliance mode.
  --rg2               Run in ReplayGain2 compliance mode.
  --rg                Run in ReplayGain compliance mode.
  --reference=<float>  Set reference loudness in LUFS.
  --r128-compatible   Calibrate output according to EBU R128.
  --rg-compatible     Calibrate output according to ReplayGain.
  --db                Use dB as unit rather then LU/TP.
  --partition=<int>   BS.1770 overlap
                      (overlap in % = (1 - 1/partition) * 100%,
                      default: 4, i.e. 75% overlap).
  --gate=<float>      BS.1770 gate (-10.0 .. -8.0, default: -10.0).
  --rg-calibration=<float>  Aequivalent to use for ReplayGain
                      loudness (default: -18.0).
  --no-peak           Don't calculate the maximum peak.
  --sample-peak       Calculate the maxium peak without up-sampling.
  --true-peak         Calculate the maxium peak at 192 kHz (default).
  --range=on,--range  Calculate loudness range (default).
  --range=off,--no range  Don't calculate loudness range.
  --tags=[rg|bwf]     Write ReplayGain (default) or BWF tags.
  --fast              Switch off up-sampling and don't calculate
                      loudness range.
  --mono=off          Treat mono as stereo (default).
  --mono=on,--mono    Don't treat mono as stereo.
  --quiet             Supress output to stdout.
  --progress=on       Display progress (default).
  --progress=off      Don't display progress.
  --traditional       Format output traditionally.
  --cpown             Copy owner attributes (experimental).
  --cpmod             Copy access rights (experimental).
  --command=<string>  Run command on each track.
  --overwrite         Overwrite already existing output files.
  --in-place          Overwrite original files (not recommended).
  --loglevel=<integer>  Set FFmpeg loglevel.
  --regression        Calculate linear regression between EBU R128
                      and ReplayGain.
  --duration          Print out duration.
  --version           Display version information.
  --ffmpeg=<path>     Directory of the FFmpeg shared libraries.
  --sox=<path>        Directory of the SoX shared libraries.
  --lame=<path>       Directory of the Lame shared libraries.
  --magick=<path>     Directory of the ImageMagick shared libraries.
  --help              Display this information.

Format:
  mkv                 Wrap into MKV container (recommended).
  flac                Encode into FLAC (not recommend).
  lame [album|track [<float>]]  Convert into MP3 and apply album (default)
                      or track gain with quality (default: 2.0).
$ _
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jangk on 2012-11-11 21:08:23
Hi,

with the new version, R128GAIN did not crash anymore while treating flac files with embedded artwork (on a sample of 20 files).

Thank you very much for your responsiveness.

Best regards
Jean
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-19 17:06:30
There was a report over there at the FFSoX Player thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978) regarding an issue with FFmpeg's OOG decoder (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=81613&view=findpost&p=814615). That issue also affects R128GAIN, hence you should upgrade to version 1.0-alpha-7-2:
[blockquote]http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-11-21 01:54:56
First, thank you for the excellent implementation of EBU-R128.  After watching the youtube videos on the Loudness Wars from 2011, I'm convinced that R128 is best measure for loudness of general material that we have.

I recently purchased The Lord of the Rings extended blu-ray set, and ran into a problem.  As you might know, the three films are split into two discs each.  The soundtrack is DTS MA 6.1 24-bit, which results in very large files when combined from the two discs.  Due to the size of soundtracks, I always use FLAC to help audio processing tools deal with the file sizes.  Unfortunately though, it appears that r128gain has difficulty with FLAC files over 4GB in size.  Once the progress reaches 100%, it remains there for a long time before failing due to a malloc error.  However, SoX does not have this limitation for processing gain on FLAC files greater than 4GB in size (in this case a 6.92GB file).

I was able to circumvent this issue by having r128gain process the two parts as an album, and then use SoX to apply the gain to the whole FLAC soundtrack.  I realize that having FLAC files greater than 4GB is pretty uncommon, but if r128gain could handle them natively, I believe others would benefit in the future.

Again, thank you for this project as I know how much effort it takes to do these sorts of projects.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-11-21 02:58:53
@ pbelkner -

Thanks for everything thus far and all the hard work.

I'm not sure but I thought that R128Gain worked on MP4 files...not sure if there was some change in FFMpeg or what...or if I'm just recalling correctly.

At present I don't see any tags set or anything in the atoms...which I think is the only place tags are placed on MP4's (.mp4, .m4a, .m4v, .m4b)

AtomicParsley (http://atomicparsley.sourceforge.net/) should display all atom information in a MP4 container.

Code: [Select]
AtomicParsley.exe path\to.mp4 -t


Which should display something like:
Quote
Atom "----" [replaygain_track_gain] contains: -9.07 dB
Atom "----" [replaygain_album_gain] contains: -9.07 dB
Atom "----" [replaygain_album_peak] contains: 1.116816
Atom "----" [replaygain_track_peak] contains: 1.116816


Or

Quote
Atom "----" [replaygain_track_gain] contains: 0.53
Atom "----" [replaygain_track_peak] contains: 0.27
Atom "----" [replaygain_track_minmax] contains: 96,179


The last one is what is written by AACGain (http://aacgain.altosdesign.com/)...the first one clue...just an example I seen on the web.

Maybe the following lib might be of use: TagLib (http://taglib.github.com/)

Again many thanks for all that you have done.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: skamp on 2012-11-21 09:12:04
Am I doing it right?

Code: [Select]
./r128gain --rg-compatible --in-place --tags=rg ./album.flac


"album.flac" is a 74 minutes album. That command took 264 seconds to complete on 2.2 GHz mobile Core i7, vs. 19 seconds for the equivalent metaflac command, and 13 seconds for fb2k. That's 14-20 times slower 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-21 16:59:08
Am I doing it right?

Code: [Select]
./r128gain --rg-compatible --in-place --tags=rg ./album.flac


"album.flac" is a 74 minutes album. That command took 264 seconds to complete on 2.2 GHz mobile Core i7, vs. 19 seconds for the equivalent metaflac command, and 13 seconds for fb2k. That's 14-20 times slower 

In order to avoid comparing apples with beans you should provide the "--fast" option. The "--fast" option switches off calculating the loudness range and calculating true peak which is on by default and not done by the other tools. Especially true peak calculation is really time consuming because of up-sampling.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: skamp on 2012-11-21 17:54:16
I see. The equivalent would actually be the following command line (--fast suppresses peak calculation):

Code: [Select]
./r128gain --rg-compatible --sample-peak --range=off --tags=rg --in-place ./album.flac


That command completes in 30 seconds. Still a ways off from metaflac and fb2k, but much better. I have to say, the default settings are so slow, they're downright off-putting.

A few observations:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-23 09:43:26
I'm not sure but I thought that R128Gain worked on MP4 files...not sure if there was some change in FFMpeg or what...or if I'm just recalling correctly.

This has never worked and by looking into the respective FFmpeg muxer "libavformat/movenc.c" it seems to be impossible (at least for now).

That's the reason why "r128gain" offers the MKV format: The untouched audio and video streams taken from the MP4 container are just wrapped into a MKV container which can be tagged as intended.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-11-25 19:51:11
Version 1.0-alpha-7-3 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
What's new?
Some remarks:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: xTobix on 2012-11-26 21:10:59
Hi Peter,

thanks for the update indeed!
Version 1.0-alpha-7-3 released:
[blockquote]Home: http://r128gain.sourceforge.net/ (http://r128gain.sourceforge.net/)
Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]


Your comments are much appreciated too.
In fact, I would much appreciate if you would consider to increase the scanner performance (decrease the CPU+HDD consumption time) since this is my main reason to not convert my entire music library from RG to EBU.

Happy coding,
xTobix
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-11-27 23:11:36
Quote
Unfortunately though, it appears that r128gain has difficulty with FLAC files over 4GB in size. Once the progress reaches 100%, it remains there for a long time before failing due to a malloc error. However, SoX does not have this limitation for processing gain on FLAC files greater than 4GB in size (in this case a 6.92GB file).

I did some more digging into this issue, and I was mistaken.  It turns out the problem isn't the file size, but the number of samples that the file contains.  If there are more than 2^29 (536.87M) samples, then r128gain hits 100% and hangs.  To reproduce the issue, use SoX to create a stereo 24-bit pinknoise file:

contains 533M samples and finishes
Code: [Select]
SoX -S -n -c 2 works.flac synth 3:10:00 pinknoise

contains 547M samples and hangs
Code: [Select]
SoX -S -n -c 2 fails.flac synth 3:15:00 pinknoise

I believe the issue is simply a 32-bit integer being used for counting the number 4x oversampling samples to process.  My 2 cents.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: jaynyc on 2012-11-28 17:59:15
hi.  just tried this for the first time, very impressive.  i am able to successfully scan:
and successfully write tags for all except M4A (AAC). The program crashes for M4A (AAC) when it tries to write.
Code: [Select]
  Problem Event Name:	APPCRASH
  Application Name: r128gain.exe
  Application Version: 0.0.0.0
  Application Timestamp: 50b266f2
  Fault Module Name: avformat-54.dll
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 50b2545c
  Exception Code: c0000094
  Exception Offset: 00232a9b
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1033
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789


I followed the instructions on the project home page

Quote
In order to upgrade to full FFmpeg support (i.e. to all FFmpeg    supported formats and codecs, unfortunately not including Wavpack)    do the following:   

  • Google for "ffmpeg autobuild".
  • Pick the latest W32 shared build and substitute the corresponding      DLLs in R128GAIN's sub-directory "r128gain".

What am I doing wrong?  thank you

--jay
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nologic on 2012-11-29 23:59:01
@ jaynyc -

I posted about this just a few posts above yours...however there is a work around...well haven't tried it but should work.

What needs to be done for the time being is to process the file with R128Gain, then take that information and pass it to AACGain.

Code: [Select]
r128gain.exe --r128-2011 --true-peak --db "C:\test.mp4" --command="aacgain.exe /r /f /g %TGDB% \"%NAME%\""
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-02 18:05:06
What am I doing wrong?

Nothing.

I've tried to reproduce the crash but was unable. According to your report the program crashes in "libavformat", hence future versions of FFmpeg may avoid this.

But anyway, even if the program doesn't crash it is currently unable to write tags to MP4. You may consider Nologic's advice:

Code: [Select]
r128gain.exe --r128-2011 --true-peak --db "C:\test.mp4" --command="aacgain.exe /r /f /g %TGDB% \"%NAME%\""
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-02 18:27:03
Writing tags to a flac file seems to completely replace the existing vorbis comments block, without using existing padding, thus forcing a full rewrite of the entire file. That's highly inefficient, and padding blocks were meant to avoid exactly that. Use them!

In fact, I would much appreciate if you would consider to increase the scanner performance (decrease the CPU+HDD consumption time) since this is my main reason to not convert my entire music library from RG to EBU.

I believe the issue is simply a 32-bit integer being used for counting the number 4x oversampling samples to process.  My 2 cents.

Most if not all of these issues are introduced by the frameworks on which "r128gain" is based. Fortunately we can expect them to disappear as time evolves.

In the meantime some specialized tools may help out, as e.g. "flac1770":[blockquote]http://www.hydrogenaudio.org/forums/index....showtopic=98163 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98163)[/blockquote]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: flloyd on 2012-12-04 00:55:16
How do I get R128Gain to work with MP3s on Linux/Ubuntu? All of the help I've ssen for MP3s references Win32 builds of FFMPEG which I'm assuming would not work on Linux. Is there a way to get R128Gain to use my current or new install of FFMPEG or Libav (since I believe that's what Ubunutu now uses)?

Thanks in advance for any input.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-04 07:09:11
How do I get R128Gain to work with MP3s on Linux/Ubuntu? All of the help I've ssen for MP3s references Win32 builds of FFMPEG which I'm assuming would not work on Linux. Is there a way to get R128Gain to use my current or new install of FFMPEG or Libav (since I believe that's what Ubunutu now uses)?

Thanks in advance for any input.

You have two options:
Please note that R128GAIN is not guarantied to run with LIBAV. The binaries are build using FFmpeg.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-12-04 18:28:33
Quote
Most if not all of these issues are introduced by the frameworks on which "r128gain" is based. Fortunately we can expect them to disappear as time evolves.

I was able to reproduce the hanging issue outside r128gain by running:
Code: [Select]
sox -V -S -r 48000 -b 24 -n -n synth 3:10:00 pinknoise rate 96000 rate 192000

So I dove into the SoX source code and located the problem in the rate effect.  They are improperly casting
size_t to an int which fails at the 2^31 boundary for integers.  To fix the issue I created a patch file.

sox-14.4.0.patch:
Code: [Select]
diff -cr sox-14.4.0/src/rate.c sox-14.4.0/src-update/rate.c
*** sox-14.4.0/src/rate.c    Tue Dec 27 22:15:32 2011
--- sox-14.4.0/src-update/rate.c    Tue Dec  4 11:04:47 2012
***************
*** 397,403 ****
    size_t remaining = samples_out - p->samples_out;
    sample_t * buff = calloc(1024, sizeof(*buff));
  
!   if ((int)remaining > 0) {
      while ((size_t)fifo_occupancy(fifo) < remaining) {
        rate_input(p, buff, (size_t) 1024);
        rate_process(p);
--- 397,403 ----
    size_t remaining = samples_out - p->samples_out;
    sample_t * buff = calloc(1024, sizeof(*buff));
  
!   if (samples_out > p->samples_out) {
      while ((size_t)fifo_occupancy(fifo) < remaining) {
        rate_input(p, buff, (size_t) 1024);
        rate_process(p);

and added it to r128gain's Makefile:
Code: [Select]
.PRECIOUS: unpack/$(SOX)/configure
unpack/$(SOX)/configure: $(DOWNLOAD)/$(SOX).tar.bz2
    mkdir -p unpack
    tar xfvj $< -C unpack
    cd unpack; patch -p0 -i $(SRC)/patch/$(SOX).patch    <---- added
    touch $@

I also submitted a bug report to the SoX sourceforge team.  In the meantime you are welcome to use this patch file
if you wish.  Thanks again for r128gain, it is a great tool.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: flloyd on 2012-12-05 02:07:17
How do I get R128Gain to work with MP3s on Linux/Ubuntu? All of the help I've ssen for MP3s references Win32 builds of FFMPEG which I'm assuming would not work on Linux. Is there a way to get R128Gain to use my current or new install of FFMPEG or Libav (since I believe that's what Ubunutu now uses)?

Thanks in advance for any input.

You have two options:
  • Copy FFmpeg's shared objects (*.so) from the installation directory to R128GAIN's "r128gain-tools" folder.
  • Start R128GAIN with the option "--ffmpeg" pointig to the directory where FFmpeg's shared objects (*.so) are located.
Please note that R128GAIN is not guarantied to run with LIBAV. The binaries are build using FFmpeg.


Since I am using Ubuntu I am unfortuantely stuck with Libav. Trying option number two I get the following error:
Code: [Select]
'/home/chris/Downloads/r128gain-1.0-alpha-7-3/r128gain' --rg2 --ffmpeg=/usr/lib/x86_64-linux-gnu/ --overwrite '/home/chris/Desktop/(2003) Glass Wars'
SoX sucessfully loaded.
Error loading FFmpeg.
Falling back to SoX.
/home/chris/Desktop/(2003) Glass Wars
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
Done.


When I tried downloading FFMPEG files from here (https://launchpad.net/~jon-severinsson/+archive/staging/+build/3976808) and replacing the files in the r128gain-tools folder I get the following error:
Code: [Select]
'/home/chris/Downloads/r128gain-1.0-alpha-7-3/r128gain' --rg2 --overwrite '/home/chris/Desktop/(2003) Glass Wars'
SoX sucessfully loaded.
Error loading FFmpeg.
Falling back to SoX.
/home/chris/Desktop/(2003) Glass Wars
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
formats: no handler for file extension `mp3'
Done.


Any suggestions?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-05 07:17:27
I also submitted a bug report to the SoX sourceforge team.  In the meantime you are welcome to use this patch file if you wish.

Many thanks for resolving this and providing the patch.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-05 07:22:39
Since I am using Ubuntu I am unfortuantely stuck with Libav. Trying option number two I get the following error:

This is most likely due to an incompatibility between FFmpeg and Libav (probably a missing method in Libav which is used by r128gain).

When I tried downloading FFMPEG files from here (https://launchpad.net/~jon-severinsson/+archive/staging/+build/3976808) and replacing the files in the r128gain-tools folder I get the following error:

This is completely outdated. "r128gain" uses "libavutil" 52, "libavcodec" 54, and "libavformat" 54.

Via FFmpeg http://ffmpeg.org/download.html (http://ffmpeg.org/download.html) I've found the following:
[blockquote]https://launchpad.net/~jon-severinsson/+archive/ffmpeg (https://launchpad.net/~jon-severinsson/+archive/ffmpeg)[/blockquote]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-07 16:39:05
3. The program will not recurse thru directories of 96000 sample rate albums and higher. It crashes immediatley and the window closes in an instant. So if there is a mix of 44100 and 96000 it won't run(on this machine anyway). Or even if only 96000 sample rate albums are in the directory it still crashes.

Unfortunately I'm not able to reproduce this. I did the following:
Code: [Select]
$ uname -a
Linux ubuntu 3.5.0-19-generic #30-Ubuntu SMP Tue Nov 13 17:48:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Are you using FLAC as well?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Singtoh on 2012-12-08 01:02:16
Hello Pbelkner,

Yes I am using flac. Hmm, I will try my little test again and report what happens. I just let it do about 50 normal 44100 flac albums last night and it seems that it worked alright. Is there a way I can output a log, or am I missing where an output log may be being put??. As I said before, I cannot get r128gain to compile and I have no command line capability with r128gain or flac1770, I just run r128gain by clicking the icon in my home directory. It feels like I am missing something here because normally I do a ./configure, make && make install with other programs and everything is usually ok. Whenever I try it with r128gain, it fails immediatly with the same error as I have seen someone post here before.(can't remember the exact error. sorry?). I just compiled Audacity, along with ffmpeg the other day and had no issues?? I'll get back to you after I try this again with a directory full of vinyl rips 24/96 I have.

Cheers,

Singtoh
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Singtoh on 2012-12-08 03:15:28
3. The program will not recurse thru directories of 96000 sample rate albums and higher. It crashes immediatley and the window closes in an instant. So if there is a mix of 44100 and 96000 it won't run(on this machine anyway). Or even if only 96000 sample rate albums are in the directory it still crashes.

Unfortunately I'm not able to reproduce this. I did the following:
  • Converted the EBU R128 test vector from WAV to 96 kHz FLAC (using "sox in.wav out.flac rate 96k").
  • Moved the resulting FLACs into two subfolders, "3341" and "3342".
  • Let both, the GTK2 and GTK3 edition run on the root.
  • Everything works as expected:

    Code: [Select]
    SoX sucessfully loaded.
    FFmpeg sucessfully loaded.
    /h/MinGW/msys/1.0/home/home/ebu-loudness-test-setv03-flac-96
    /h/MinGW/msys/1.0/home/home/ebu-loudness-test-setv03-flac-96/3341
      analyzing ...
        [1/12] "1kHz Sine -20 LUFS-16bit.flac": -19.9 LUFS (-3.1 LU)
            peak: -19.9 TPFS, range: 0.0 LU
        [2/12] "1kHz Sine -26 LUFS-16bit.flac": -25.9 LUFS (2.9 LU)
            peak: -25.9 TPFS, range: 0.0 LU
        [3/12] "1kHz Sine -40 LUFS-16bit.flac": -40.0 LUFS (17.0 LU)
            peak: -39.8 TPFS, range: 0.0 LU
        [4/12] "seq-3341-1-16bit.flac": -22.9 LUFS (-0.1 LU)
            peak: -22.9 TPFS, range: 0.0 LU
        [5/12] "seq-3341-2-16bit.flac": -33.0 LUFS (10.0 LU)
            peak: -32.7 TPFS, range: 0.0 LU
        [6/12] "seq-3341-2011-8_seq-3342-6-24bit-v02.flac": -23.0 LUFS (0.0 LU)
            peak: -2.6 TPFS, range: 15.2 LU
        [7/12] "seq-3341-3-16bit-v02.flac": -22.3 LUFS (-0.7 LU)
            peak: -23.0 TPFS, range: 13.0 LU
        [8/12] "seq-3341-4-16bit-v02.flac": -23.0 LUFS (0.0 LU)
            peak: -23.0 TPFS, range: 13.0 LU
        [9/12] "seq-3341-5-16bit-v02.flac": -23.0 LUFS (-0.0 LU)
            peak: -20.0 TPFS, range: 6.0 LU
        [10/12] "seq-3341-6-5channels-16bit.flac": -23.0 LUFS (0.0 LU)
            peak: -24.0 TPFS, range: 0.0 LU
        [11/12] "seq-3341-6-6channels-WAVEEX-16bit.flac": -23.0 LUFS (0.0 LU)
            peak: -24.0 TPFS, range: 0.0 LU
        [12/12] "seq-3341-7_seq-3342-5-24bit.flac": -23.0 LUFS (-0.0 LU)
            peak: -8.9 TPFS, range: 4.8 LU
        [ALBUM]: -23.0 LUFS (-0.0 LU)
            peak: -2.6 TPFS, range: 16.0 LU
      done.
    /h/MinGW/msys/1.0/home/home/ebu-loudness-test-setv03-flac-96/3342
      analyzing ...
        [1/4] "seq-3342-1-16bit.flac": -22.6 LUFS (-0.4 LU)
            peak: -20.0 TPFS, range: 10.0 LU
        [2/4] "seq-3342-2-16bit.flac": -16.8 LUFS (-6.2 LU)
            peak: -15.0 TPFS, range: 5.0 LU
        [3/4] "seq-3342-3-16bit.flac": -20.0 LUFS (-3.0 LU)
            peak: -20.0 TPFS, range: 20.0 LU
        [4/4] "seq-3342-4-16bit.flac": -24.5 LUFS (1.5 LU)
            peak: -20.0 TPFS, range: 15.0 LU
        [ALBUM]: -19.2 LUFS (-3.8 LU)
            peak: -15.0 TPFS, range: 25.0 LU
      done.
    Done.
    Hit enter to continue ...
Code: [Select]
$ uname -a
Linux ubuntu 3.5.0-19-generic #30-Ubuntu SMP Tue Nov 13 17:48:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Are you using FLAC as well?


Hello Pbelken,

Well, I am at a bit of a loss?? The test I ran the other day was run three times each to be sure it failed consistently. Today I have run a mix of a few albums 24bit and 16bit and it ran rite thru. The only thing I did differently was downloaded the FLAC1770 v0.2.0 and extracted it to the r128gain folder in my home folder, weather that has anything to do with it I am not sure?? Here is the output I am getting from terminal now with a mix of albums:

SoX sucessfully loaded.
FFmpeg sucessfully loaded.
/media/Storage/processmusic/12replaygain
/media/Storage/processmusic/12replaygain/2008-07-14 - The Stranger (bonus disc Live at Carnegie Hall 1977) - Sony BMG Music Entertainment  GB
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e28e0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26e29c0] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26bc940] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x26bcb40] max_analyze_duration 5000000 reached at 5015510
[flac @ 0x2748aa0] max_analyze_duration 5000000 reached at 5015510
Consider increasing the value for the 'analyzeduration' and 'probesize' options
  analyzing ...
    [1/12] "08 Band Introductions.flac": [flac @ 0x2748aa0] max_analyze_duration 5000000 reached at 5015510
88.1 dBFS (0.9 dB)
        peak: -1.0 dBFS, range: 12.1 dB
    [2/12] "06 The Entertainer.flac": [flac @ 0x26edc00] max_analyze_duration 5000000 reached at 5015510
94.9 dBFS (-5.9 dB)
        peak: 0.8 dBFS, range: 13.7 dB
    [3/12] "11 Say Goodbye to Hollywood.flac": [flac @ 0x26edc00] max_analyze_duration 5000000 reached at 5015510
97.5 dBFS (-8.5 dB)

a couple of more errors after it ran for about 15 mins.
flac @ 0x2797c60] invalid predictor order: 19 > 0
[flac @ 0x2797c60] decode_frame() failed
[2/9] "06 Rosalinda's Eyes.flac" ... [flac @ 0x2767360] max_analyze_duration 5000000 reached at 5034667
[flac @ 0x2797c60] sample/frame number mismatch in adjacent frames
done.

I don't know of course what the above errors mean?? Anyway, just to report on last nights run. It seems all is ok with those albums but just a little "bug" or glitch happened. Every album was stripped of it's artwork except for the first 2 tracks of each album, and todays runs all the artwork is stripped as is "normal" at this point I guess?? Kinda weird?? Also yesterday, r128gain crashed out of the blue as it was running along nicely, so I restarted it and it ran to the end?? Don't know, please let me know if I can, or how I can get a log other than what is running in the terminal so I can post it for your enjoyment:) I'm not an expert on linux, but I have done a few compilations of kernels and programs and such, so if I can be more helpful, please let me know??

Thanks again,

Cheers,

Singtoh
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-12-08 04:10:07
Many thanks for resolving this and providing the patch.


Glad to help the cause (the patch was committed to git on SoX btw).  One thing I noticed in this adventure.  I see that you are upconverting until >= 192k is reached, instead of just doing 4x oversampling.  For 44.1k and 48k material that would be fine (176.4k and 192k respectively).  But what about 24bit/96k material?  I would assume True Peak would require upconverting to 384k to get an accurate reading.  Just curious.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2012-12-08 08:36:15
From the pdf file available at http://www.itu.int/rec/R-REC-BS.1770-3-201208-I/en (http://www.itu.int/rec/R-REC-BS.1770-3-201208-I/en) :

Quote
The 4 × over-sampling filter increases the sampling rate of the signal from 48 kHz to 192 kHz. This higher sample rate version of the signal more accurately indicates the actual waveform that is represented by the audio samples. Higher sampling rates and over-sampling ratios are preferred (see Appendix 1 to this Annex). Incoming signals that are at higher sampling rates require proportionately less over-sampling (e.g. for an incoming signal at 96 kHz sample rate a 2 × over-sampling would be sufficient.)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-08 09:38:59
I see that you are upconverting until >= 192k is reached, instead of just doing 4x oversampling.  For 44.1k and 48k material that would be fine (176.4k and 192k respectively).  But what about 24bit/96k material?  I would assume True Peak would require upconverting to 384k to get an accurate reading.

From the pdf file available at http://www.itu.int/rec/R-REC-BS.1770-3-201208-I/en (http://www.itu.int/rec/R-REC-BS.1770-3-201208-I/en) :

Quote
The 4 × over-sampling filter increases the sampling rate of the signal from 48 kHz to 192 kHz. This higher sample rate version of the signal more accurately indicates the actual waveform that is represented by the audio samples. Higher sampling rates and over-sampling ratios are preferred (see Appendix 1 to this Annex). Incoming signals that are at higher sampling rates require proportionately less over-sampling (e.g. for an incoming signal at 96 kHz sample rate a 2 × over-sampling would be sufficient.)

Having based flac1770 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98163) on Secret Rabbit Code (SRC) (http://www.mega-nerd.com/SRC/) rather then the SoX (http://sox.sourceforge.net/) resampler I have some doubts whether it is possible to compute "true peak" in any reliable way. SRC gives completely different results then SoX even depending on the quality setting.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2012-12-08 10:41:07
AFAIK the passband width of Best Sinc SRC is ~96% which is close to SoX default (95%). So thier peak values should be very close (although not identical).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-09 17:47:54
To fix the issue I created a patch file.

I also submitted a bug report to the SoX sourceforge team.  In the meantime you are welcome to use this patch file if you wish.

I've uploaded a new version using the patch: https://sourceforge.net/projects/r128gain/f...s/r128gain/1.0/ (https://sourceforge.net/projects/r128gain/files/r128gain/1.0/).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Nekit1234007 on 2012-12-09 18:13:44
You might wanna make a separate program for Opus, like you did for FLAC. Although recent FFmpeg understands Opus, your program tags OggOpus files incorrectly. Valid Opus files should be tagged differently using its own recommendation for tagging loudness data. See the spec (http://tools.ietf.org/html/draft-terriberry-oggopus-01), Ctrl+F for “R128”.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-12-10 21:17:46
To fix the issue I created a patch file.

I also submitted a bug report to the SoX sourceforge team.  In the meantime you are welcome to use this patch file if you wish.

I've uploaded a new version using the patch: https://sourceforge.net/projects/r128gain/f...s/r128gain/1.0/ (https://sourceforge.net/projects/r128gain/files/r128gain/1.0/).

Thank you for the fast turn-around.  r128gain-1.0-alpha-7-5 works great.  Also, thank you for the clarification on 96k material only requiring 2x oversampling.  I sometimes forget that we are dealing with 20-20kHz music, so that makes perfect sense.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bandpass on 2012-12-10 22:22:30
I have some doubts whether it is possible to compute "true peak" in any reliable way. SRC gives completely different results then SoX even depending on the quality setting.



AFAIK the passband width of Best Sinc SRC is ~96% which is close to SoX default (95%). So thier peak values should be very close (although not identical).


Does the spec say anything about what passband width should be used?

And is there a specific test signal that's proving difficult to determine the true peak for?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: bandpass on 2012-12-11 14:35:01
Okay, from the example coefs in the spec, the transition band is from 5/6 to 7/6 of nyquist, stopband attenuation 40dB, passband ripple 0.1dB.  Here's how to match it with SoX (there's no way to do it with SRC):

sox --plot=octave -n -n upsample 4 sinc -a 40 -t 8k -24k > ebu.m
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2012-12-11 17:18:04
Out of curiosity I tried a long upconvert using:
Code: [Select]
SoX -V -S -r 192000 -b 24 -n -n synth 3:15:00 pinknoise sinc -a 40 -t 8k -24k

and sure enough, the same hang occurs in SoX.  So, I searched through all of their code and found
two more instances in dft_filter.c and tempo.c where SoX will hang like it did for rate.c.  I submitted
a bug report to them and patched my own SoX.  Here is my updated patch file in case you want
to try and use the upsample method bandpass describes:
Code: [Select]
diff -cr sox-14.4.0/src/rate.c sox-14.4.0-update/src/rate.c
*** sox-14.4.0/src/rate.c    Tue Dec 27 22:15:32 2011
--- sox-14.4.0-update/src/rate.c    Tue Dec  4 11:04:47 2012
***************
*** 397,403 ****
    size_t remaining = samples_out - p->samples_out;
    sample_t * buff = calloc(1024, sizeof(*buff));
  
!   if ((int)remaining > 0) {
      while ((size_t)fifo_occupancy(fifo) < remaining) {
        rate_input(p, buff, (size_t) 1024);
        rate_process(p);
--- 397,403 ----
    size_t remaining = samples_out - p->samples_out;
    sample_t * buff = calloc(1024, sizeof(*buff));
  
!   if (samples_out > p->samples_out) {
      while ((size_t)fifo_occupancy(fifo) < remaining) {
        rate_input(p, buff, (size_t) 1024);
        rate_process(p);
diff -cr sox-14.4.0/src/dft_filter.c sox-14.4.0-update/src/dft_filter.c
*** sox-14.4.0/src/dft_filter.c    Wed Mar  2 19:47:52 2011
--- sox-14.4.0-update/src/dft_filter.c    Tue Dec 11 11:25:29 2012
***************
*** 108,114 ****
    size_t remaining = samples_out - p->samples_out;
    double * buff = lsx_calloc(1024, sizeof(*buff));
  
!   if ((int)remaining > 0) {
      while ((size_t)fifo_occupancy(&p->output_fifo) < remaining) {
        fifo_write(&p->input_fifo, 1024, buff);
        p->samples_in += 1024;
--- 108,114 ----
    size_t remaining = samples_out - p->samples_out;
    double * buff = lsx_calloc(1024, sizeof(*buff));
  
!   if (samples_out > p->samples_out) {
      while ((size_t)fifo_occupancy(&p->output_fifo) < remaining) {
        fifo_write(&p->input_fifo, 1024, buff);
        p->samples_in += 1024;
diff -cr sox-14.4.0/src/tempo.c sox-14.4.0-update/src/tempo.c
*** sox-14.4.0/src/tempo.c    Sat Jan 21 16:33:13 2012
--- sox-14.4.0-update/src/tempo.c    Tue Dec 11 11:34:31 2012
***************
*** 151,162 ****
    size_t remaining = samples_out - t->samples_out;
    float * buff = lsx_calloc(128 * t->channels, sizeof(*buff));
  
!   if ((int)remaining > 0) {
!     while (fifo_occupancy(&t->output_fifo) < remaining) {
        tempo_input(t, buff, (size_t) 128);
        tempo_process(t);
      }
!     fifo_trim_to(&t->output_fifo, remaining);
      t->samples_in = 0;
    }
    free(buff);
--- 151,162 ----
    size_t remaining = samples_out - t->samples_out;
    float * buff = lsx_calloc(128 * t->channels, sizeof(*buff));
  
!   if (samples_out > t->samples_out) {
!     while ((size_t)fifo_occupancy(&t->output_fifo) < remaining) {
        tempo_input(t, buff, (size_t) 128);
        tempo_process(t);
      }
!     fifo_trim_to(&t->output_fifo, (int)remaining);
      t->samples_in = 0;
    }
    free(buff);

Unlike the rate effect, beware that sinc automatically adds rate after itself to make the output rate the same as the input rate unless the output rate is specified with a -r switch.  Also, the upsample+sinc is faster than the rate+rate currently being used in the effect chain.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: flloyd on 2012-12-14 20:51:32
Since I am using Ubuntu I am unfortuantely stuck with Libav. Trying option number two I get the following error:

This is most likely due to an incompatibility between FFmpeg and Libav (probably a missing method in Libav which is used by r128gain).

When I tried downloading FFMPEG files from here (https://launchpad.net/~jon-severinsson/+archive/staging/+build/3976808) and replacing the files in the r128gain-tools folder I get the following error:

This is completely outdated. "r128gain" uses "libavutil" 52, "libavcodec" 54, and "libavformat" 54.

Via FFmpeg http://ffmpeg.org/download.html (http://ffmpeg.org/download.html) I've found the following:
[blockquote]https://launchpad.net/~jon-severinsson/+archive/ffmpeg (https://launchpad.net/~jon-severinsson/+archive/ffmpeg)[/blockquote]


Thanks for the repsonse, unfortuantely that jon-severinsson link was the same link that I listed and as you stated it is outdated. I tried to find other sources that use "libavutil" 52, "libavcodec" 54, and "libavformat" 54 but unfortunately I couldn't find any linux builds that were all up to date (for example ArchLinux's build is still libavutil 51 (https://www.archlinux.org/packages/extra/i686/ffmpeg/files/)).

Is there any chance r128gain could be built with MP3 support or are their legal/technical problems preventing that?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2012-12-15 08:15:03
Is there any chance r128gain could be built with MP3 support or are their legal/technical problems preventing that?

Indeed, I hesitate distributing binary releases including a full FFmpeg build in order to potenially avoid such issues. Anyway, you may consider building "r128gain" yourself.

I've successfully tested the following procedure for building "r128gain" as of today with the latest "r12gain" release (i.e. version=1.0-alpha-7-6) on Ubuntu 12.10 (32-bit) using VMware Player 5.0.1, build-894247, on Windows Vista:
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: nu774 on 2012-12-16 02:46:00
I was able to reproduce the hanging issue outside r128gain by running:
Code: [Select]
sox -V -S -r 48000 -b 24 -n -n synth 3:10:00 pinknoise rate 96000 rate 192000

So I dove into the SoX source code and located the problem in the rate effect.  They are improperly casting
size_t to an int which fails at the 2^31 boundary for integers.  To fix the issue I created a patch file.

Although your patch fixes the problem, the actual cause of the problem is not 32bit integer overflow.
Actual problem was quite simple: rate_flush() couldn't be called more than once.
Look at the code:
Code: [Select]
 1  static void rate_flush(rate_t * p)
2  {
3    fifo_t * fifo = &p->stages[p->num_stages].fifo;
4    uint64_t samples_out = p->samples_in / p->factor + .5;
5    size_t remaining = samples_out - p->samples_out;
6    sample_t * buff = calloc(1024, sizeof(*buff));
7
8    if (samples_out > p->samples_out) {
9      while ((size_t)fifo_occupancy(fifo) < remaining) {
10        rate_input(p, buff, (size_t) 1024);
11        rate_process(p);
12      }
13      fifo_trim_to(fifo, (int)remaining);
14      p->samples_in = 0;
15    }
16    free(buff);
17  }

At line 14, p->samples_in is cleared out to zero.
Therefore, next time you enter this function, samples_out (at line 4) will become zero, samples_out - p->samples_out will be negative (at line 5), but it's asigned to size_t (unsigned integer type)....
You see? this was not expected at all.

This re-entrance to draining code could possibly be caused by larger output than the buffer size (so sox cannot drain out whole remaining samples at once).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: lvqcl on 2012-12-16 08:11:19
Although your patch fixes the problem, the actual cause of the problem is not 32bit integer overflow.
Actual problem was quite simple: rate_flush() couldn't be called more than once.

This re-entrance to draining code could possibly be caused by larger output than the buffer size (so sox cannot drain out whole remaining samples at once).


I tested old version of SoX with the commandline from post #515, and also I changed "synth 3:15:00" to "synth 0:01:00". SoX always tried to drain the rate effect twice, regardless of the number of input/output samples.

The previous code:
Code: [Select]
static void rate_flush(rate_t * p)
{
  fifo_t * fifo = &p->stages[p->output_stage_num].fifo;
  uint64_t samples_out = p->samples_in / p->factor + .5;
  size_t remaining = samples_out - p->samples_out;
  sample_t * buff = calloc(1024, sizeof(*buff));

  if ((int)remaining > 0) {
    while ((size_t)fifo_occupancy(fifo) < remaining) {
      rate_input(p, buff, (size_t) 1024);
      rate_process(p);
    }
    fifo_trim_to(fifo, (int)remaining);
    p->samples_in = 0;
  }
  free(buff);
}


1st call: draining always succeeds, then p->samples_in is set to 0, but p->samples_out isn't.

2nd call: samples_out = 0, so remaining = -p->samples_out. If p->samples_out is less than 2^31 then "(int)remaining" is less than 0 and rate_flush does nothing. But when p->samples_out >= 2^31, the bug occurs.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: nu774 on 2012-12-16 08:37:21
Although your patch fixes the 1st call: draining always succeeds, then p->samples_in is set to 0, but p->samples_out isn't.

2nd call: samples_out = 0, so remaining = -p->samples_out. If p->samples_out is less than 2^31 then "(int)remaining" is less than 0 and rate_flush does nothing. But when p->samples_out >= 2^31, the bug occurs.

Oh, I see. Thanks for the clarification.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: JJZolx on 2013-01-08 05:18:45
What audio codecs does the current 1.0 alpha 7-6 operate on? Is it still only FLAC, WAV and WV, as stated in the first post?

The --help states:
  --overwrite        Overwrite already existing output files.
  --in-place          Overwrite original files (not recommended).

What's the difference? This tool does nothing more than add tagging fields to existing files, correct? That generally doesn't require the file to be overwritten unless a new tag is added.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dfavor on 2013-01-13 20:47:21
Current r128gain-1.0-beta-src-ffmpeg.tar contains
r128gain-1.0-beta/download/ffmpeg-export-snapshot.tar.lzma which
makes unpacking + building with automatic tools difficult.

Please consider providing a file like
r128gain-1.0-beta-src-ffmpeg.tar.gz or
r128gain-1.0-beta-src-ffmpeg.tar.lzma
to make auto building with normal tools easier.

Thanks.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dfavor on 2013-01-14 14:13:06
Current r128gain-1.0-beta-src-ffmpeg.tar contains
r128gain-1.0-beta/download/ffmpeg-export-snapshot.tar.lzma which
makes unpacking + building with automatic tools difficult.

Please consider providing a file like
r128gain-1.0-beta-src-ffmpeg.tar.gz or
r128gain-1.0-beta-src-ffmpeg.tar.lzma
to make auto building with normal tools easier.

Thanks.


Ah... I see... the lzma file is drop in the ../download directory and
is unpacked during build.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: flloyd on 2013-02-07 04:55:32
pbelkner - Thanks for including the ffmpeg source and instructions. I finally got time to try this again and I was able to build and run R128GAIN succesfully on 64bit Ubuntu 12.10. Only hitch was that it failed to download ImageMagick-6.8.1-3 from SourceForge since that version is now gone. Was able to find it elsewhere though and put it in the proper folder and the build went fine.

Thanks for all the help. It is very appreciated.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: amatala on 2013-03-06 13:27:05
First I wanted to say thanks for all the hard work which went into developing this great tool - it's very helpful indeed! 

I wanted to use it to set BWF tags to my FLAC files, but as already pointed by other users before, the tool was triggering a full file re-write and messed up some tags like the Vendor string which I did not want to be overwritten.

So instead of using the r128gain tool for writing the tags, I chose to use the "command" option to invoke the metaflac utility and write only the tags I needed without impacting anything else. This even allows to preserver the file time stamp in order to avoid having to back it up again after the change (this info can be easily recalculated in case the file has to be restored).

The command I'm currently using on Windows looks like this:

r128gain "--command=metaflac --no-utf8-convert --preserve-modtime --remove-tag=LoudnessValue --remove-tag=MaxTruePeakLevel --remove-tag=LoudnessRange --set-tag=LoudnessValue=%TLDB:.=% --set-tag=MaxTruePeakLevel=%TPDB:.=% --set-tag=LoudnessRange=%TRDB:.=% \"%TRACK%\"" "c:\temp\test" -o temp

This seems to be working great - I'm currently busy doing some volume testing, but so far - so good! 
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: westis on 2013-04-27 11:03:49
How can I use this tool to normalize mpeg-2 and h.264 files?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-04-28 11:38:32
How can I use this tool to normalize mpeg-2 and h.264 files?

You may consider re-wrapping them into a MKV container by choosing the MKV format.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: westis on 2013-04-28 12:34:28
How can I use this tool to normalize mpeg-2 and h.264 files?

You may consider re-wrapping them into a MKV container by choosing the MKV format.


Thanks for your reply. I need the final file in H.264/AVC/MPEG-4 Part 10, since this is for TV broadcasting. I tried separating audio and video, to normalize the audio and then merge audio and video together. But the audio doesn't change. I have downloaded the shared autobuild of ffmpeg and replaced the dll's in the r128gain-tools folder.

The script that I use is one that Charalampos Tsimpouris helped me adapt from his script at http://1024.gr/blog/normalize-audio-movies...and-sox-windows (http://1024.gr/blog/normalize-audio-movies-using-ffmpeg-and-sox-windows). It looks like this:

Code: [Select]
echo off
cls
echo Script by http://1024.gr

cd /d %~dp0

echo Extracting audio to "%~1_clean.wav"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1" -ac 2 -y "%~1_clean.wav"

echo Getting max amplitude and normalizing to "%~1_clean.wav"..
r128gain-1.0-beta-2\r128gain.exe --in-place "%~1_clean.wav"

echo Extracting video to "%~1_clean.avi"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1" -map 0:0 -vcodec copy -y "%~1_clean.avi"

echo Creating new video file into "%~1_new.avi"..
r128gain-1.0-beta-2\r128gain-tools\ffmpeg.exe -i "%~1_clean.avi" -i "%~1_clean.wav" -vcodec copy "%~1_new.avi"

:clear
echo Cleaning..
del "%~1_clean.wav"
del "%~1_clean.avi"
pause


If I remove deleting the temporary files at the end, I compared the cleaned audio with the original audio and there is no change after running it through r128gain. Are we doing anything wrong in the script above?

In the above case we used it on avi files, but same result regardless of video format.

Cheers,
Daniel
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-04-28 14:33:36
I tried separating audio and video, to normalize the audio and then merge audio and video together.

In principle this should work.

But the audio doesn't change.

That's right because "r128gain" doesn't apply the gain. You may use the "--command" option in order to let SoX apply the gain:

Code: [Select]
r128gain "--command=sox %TRACK% %BN%-norm.wav gain %TGDB%" C:\Windows\Media\chord.wav -o .
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: J.Fleming on 2013-05-09 03:39:27
Crashes on 2 different computers for me after I click OK using default settings, no log files are written.

I'm guessing this needs SSE2... both computers I tried are PIII.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-05-09 21:23:23
Version 1.0 RC1 released:
[blockquote]Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
What's new?

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2013-05-11 22:05:06
I noticed that the 14.4.1 windows build of SoX doesn't include FLAC or W64 support.  I did some searching and found this posted on their project forum:
Quote
Unfortunately, there was a build problem in the 14.4.1 release leading to libflac and libsndfile being left out of the Windows binary.

I don't know what the fix is, just letting you know of this issue.  In the meantime, I'll continue using SoX 14.4.0 with R128GAIN RC1 due to WAVs above 4GB in size not working properly (hence why I use FLAC).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-05-12 20:29:35
I noticed that the 14.4.1 windows build of SoX doesn't include FLAC or W64 support.

This may be true for the official distribution, but it doesn't hold for the build coming with R128GAIN (which is crippled in other ways).

I did some searching and found this posted on their project forum:
Quote
Unfortunately, there was a build problem in the 14.4.1 release leading to libflac and libsndfile being left out of the Windows binary.

Meanwhile there are "sox-14.4.1a-win32.*" builds available.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: MrMod on 2013-05-21 16:45:18
Thank you for adding FLAC support to the RC2 build.  Works great.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: BFG on 2013-05-22 16:13:41
I decided to give R128Gain (latest RC2 build) a try last night after reading about it here and hearing good things about it.  At first, I couldn't get it to work on my MP3s, but as directed I updated FFmpeg and then it was able to do so.  However, the R128Gain-modified MP3s seem to be missing all the ID3 and other metatags.  Is there any simple way to tell R128Gain to simply pass through all tags other than the original ReplayGain one?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-05-25 14:23:41
I decided to give R128Gain (latest RC2 build) a try last night after reading about it here and hearing good things about it.  At first, I couldn't get it to work on my MP3s, but as directed I updated FFmpeg and then it was able to do so.  However, the R128Gain-modified MP3s seem to be missing all the ID3 and other metatags.  Is there any simple way to tell R128Gain to simply pass through all tags other than the original ReplayGain one?

Unfortunately I'm not able to reproduce this. The result should be the same as in

Code: [Select]
ffmpeg -i "in.mp3" -c copy -y "out.mp3"

You may list the meta data seen by FFmpeg by means of

Code: [Select]
ffmpeg -i "in.mp3"

or

Code: [Select]
ffmpeg -i "out.mp3"
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-07-14 14:01:17
Finally version 1.0 released:
[blockquote]Download: http://sourceforge.net/projects/r128gain/files/r128gain/1.0/ (http://sourceforge.net/projects/r128gain/files/r128gain/1.0/)[/blockquote]
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dawnrazor on 2013-07-19 22:13:43
Just to be sure before I trash my whole library - I'm intending to run r128gain on all my mp3s, then write the results to the replaygain tag and convert those to Soundcheck values for use in iTunes. Will my mp3s stay as they are (apart from the tags) or will they be re-encoded during the process?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: db1989 on 2013-07-19 23:39:27
They will not be re-encoded. RG data are stored in dedicated fields in the tags.

Even if you were using the method of MP3gain and similar tools, the adjustments would be written to gain fields in the MP3 (quantised to 1.5 dB), but the audio data itself would remain untouched.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dawnrazor on 2013-07-20 09:27:41
They will not be re-encoded.


Thanks for the info. I was just wondering how it works with the parallel level and peak adjustments that are required to achieve r128 compliance.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: db1989 on 2013-07-20 13:02:09
Sorry, but what do you mean? These algorithms just analyse the entire stream, determine the peak and average perceptual loudness, and write corresponding data to tag fields, thus enabling levelling of the volume during subsequent playback. None of this requires rewriting of the stream in even a temporary form, nor any sort of parallelism.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dawnrazor on 2013-07-21 07:46:12
Sorry, but what do you mean? These algorithms just analyse the entire stream, determine the peak and average perceptual loudness


On the production side, you have to work on both aspects to not end up with a file that either has correct peaks but incorrect average loudness, or vice versa. I'm just wondering how a single tag value can result in r128 compliant playback when you, for example, have a track with correct occasional peaks but way too low average loudness.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: db1989 on 2013-07-21 12:03:04
The two data are stored in separate fields. The player should provide options to (A) normalise average perceptual loudness and also (B) override the adjustment invoked by step A if it would result in clipping according to the specified peak, thus preventing clipping. The user then chooses the combination of options that suit them. Here, straight from the original author, why the user should use clipping prevention but might choose not to: http://hydrogenaudio.org/forums/?showtopic=62625#entry559266 (http://hydrogenaudio.org/forums/?showtopic=62625#entry559266)
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: dawnrazor on 2013-07-28 17:46:06
The two data are stored in separate fields. The player should provide options to (A) normalise average perceptual loudness and also (B) override the adjustment invoked by step A if it would result in clipping according to the specified peak, thus preventing clipping.


Thanks for claryfing. I suppose r128gain then is not for me, as I'm using iTunes and it will rely on a single value. I justed wanted to make sure beforehand, because in another discussion I stumbled over statements saying r128gain would sum up its result in a single value (which I couldn't believe).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-07-28 18:02:05
as I'm using iTunes and it will rely on a single value.

Could you please let us know what kind of value this is?

What "r128gain" does is (as already mentioned) to calculate a set of values and store them as tags in the audio or video file. The most important of theses values (at least to me) is the gain which has to be applied to the audio in order to achieve the loudness required by some standards (e.g. EBU R128 or ATCS A/85). Other values stored are the maximum (inter-sample) peak and the loudness range.

Regarding the maximum (inter-sample) peak: Having applied the gain in order to achieve the loudness as defined by the mentioned standards (-23 dBFS or -24 dBFS, respectively) the maximum (inter-sample) peak typically is between -10 dBFS and -15 dBFS, in seldom cases -6 dBFS at a maximum (for a typical mixture of rock and pop music), i.e. in practice there's no need for limiting.

EDIT: In order to get an idea of what we are talking about you may consider using Winamp in conjunction with the FFSoX Player plugin (http://sourceforge.net/projects/in-ffsox/f...in_ffsox-2/0.0/ (http://sourceforge.net/projects/in-ffsox/files/in_ffsox-2/0.0/)). The pugin's file information dialog gives some information about a track's maximum peak and whether it's clipping:

(http://r128gain.sourceforge.net/upload/130728/in_ffsox.jpg)
In this particular case the maximum inter-sample peak without a gain applied would clip with +0.41 dBFS. On the other hand the EBU R128 gain is between -9.9 dB (track) and -10.9 (album) resulting in an effective maximum peak of about -10.0 dBFS during playback with the gain applied.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: kareha on 2013-08-02 16:08:32
Just wondering if this is worth using over foobars RG implementation?
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: [JAZ] on 2013-08-02 16:15:38
@kareha: Current foobar2000 versions use the R128 algorithm to calculate replaygain values, so it is not needed to use the application, because it already uses the algorithm.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Pat_ on 2013-08-02 19:12:56

The two data are stored in separate fields. The player should provide
Regarding the maximum (inter-sample) peak: Having applied the gain in order to achieve the loudness as defined by the mentioned standards (-23 dBFS or -24 dBFS, respectively)


Hi,
I've given R128GAIN V1.0 a try. Nice work.
I like the idea of additional meta-data tags besides the standard 4 replaygain tags. Especially tags for REPLAYGAIN_ALGORITHM and REPLAYGAIN_REFERENCE_LOUDNESS (and of course the 2 loudness ranges as specified by EBU-R128).

Question
On the user interface it is possible to specify an offset value ('ReplayGain Calibration') defaulting to -18. However, after running the loudness scanner it does seem hold on the Reference Loudness (default -23 LUFS), regardless of the calibration value (default -18 LUFS). If I compare a loudness scan on the same file with Foobar2000 (v1.2.9), which uses -18 by default I get a different value.

(1) I'm confused because I can modify both Reference Level AND Calibration value for both options "EBU R128" and "Replaygain"
I would have assumed that the replaygain value is calculated as RG =  (Reference Value) - (Loudness), with Loudness measured according ITU-1770-2. For EBU-R128 compliance, the reference value is -23 LUFS to offset content for normalized loudness. For use with music files on portable devices, the recommended reference value is -18 dB for normalized loudness (Wolters et al. (2010), page 11). Can you help me out?


(2) How could I afterward inspect the meta-date of a file to see which calibration value was used?


Thanks

----------------
Wolters, Mundt, Reidmiller (2010). Loudness normalization in the age of portable media players, Audio Engineering Society,
[Note1] http://www.dolby.com/uploadedFiles/Assets/...dia-Players.pdf (http://www.dolby.com/uploadedFiles/Assets/US/Doc/Professional/AES128-Loudness-Normalization-Portable-Media-Players.pdf)

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-08-03 07:28:37
On the user interface it is possible to specify an offset value ('ReplayGain Calibration') defaulting to -18. However, after running the loudness scanner it does seem hold on the Reference Loudness (default -23 LUFS), regardless of the calibration value (default -18 LUFS). If I compare a loudness scan on the same file with Foobar2000 (v1.2.9), which uses -18 by default I get a different value.

RG and EBU R128/ITU BS.1770 use completely unrelated metrics and postulate some default or reference loudness w.r.t. there their algorithms, i.e. 89 dB and -23 LUFS, respectively. To my understanding these absolute values don't have any meaning on their own and there is no means to relate them to each other from a theoretical point of view.

However, you may apply the algorithms to some audio and may compare the resulting absolute loudness with the respective reference loudness and those getting the gain you have to apply in order to attenuate the audio's loudness to the reference level. And, of course, you can compare the gain calculated from RG with it's counterpart calculated by EBU R128/ITU BS.1770.

If you do this kind of comparison with a larger set of audio files you'll soon discover that the difference between the two gains is not a constant, i.e. it is varying. That's no surprise because the two gains are based on completely different algorithms. However, you can do some statistics in order to figure out the mean difference between the two gains for a given set of audio files (regression).

Those kinds of statistics came to the impression that 89 dB in RG world is (in mean) equivalent to -18 LUFS in EBU R128/ITU BS.1770 world (for details cf. the respective discussion up this thread).

As far as I can see, you're looking for ITU BS1770 algorithm with metrics taken from RG world. That's what is called RG2 in "r128gain".

(1) I'm confused because I can modify both Reference Level AND Calibration value for both options "EBU R128" and "Replaygain"
I would have assumed that the replaygain value is calculated as RG =  (Reference Value) - (Loudness), with Loudness measured according ITU-1770-2. For EBU-R128 compliance, the reference value is -23 LUFS to offset content for normalized loudness. For use with music files on portable devices, the recommended reference value is -18 dB for normalized loudness (Wolters et al. (2010), page 11). Can you help me out?

Assuming you're looking for RG2 the command would be (if you are using the GUI just choose the respective radio button from the "Compliant" group):

Code: [Select]
$ r128gain --rg2 --overwrite input/Track01.flac -o output
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
analyzing ...
  [1/1] "Track01.flac": 96.2 dBFS (-7.2 dB)
      peak: 0.2 dBFS, range: 3.9 dB
  [ALBUM]: 96.2 dBFS (-7.2 dB)
      peak: 0.2 dBFS, range: 3.9 dB
writing ...
  [1/1] "Track01.flac" ... done.
done.

Please note that the result is slightly different to the one from classical RG:

Code: [Select]
$ r128gain --rg --overwrite input/Track01.flac -o output
SoX sucessfully loaded.
FFmpeg sucessfully loaded.
ReplayGain sucessfully loaded.
analyzing ...
  [1/1] "Track01.flac": 96.9 dBFS (-7.9 dB)
  [ALBUM]: 96.9 dBFS (-7.9 dB)
writing ...
  [1/1] "Track01.flac" ... done.
done.

(2) How could I afterward inspect the meta-date of a file to see which calibration value was used?

Code: [Select]
$ r128gain-tools/ffmpeg -i output/Track01.flac
ffmpeg version 2.0 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul 14 2013 13:18:11 with gcc 4.7.3 (rubenvb-4.7.4-release)
  libavutil      52. 39.100 / 52. 39.100
  libavcodec     55. 18.102 / 55. 18.102
  libavformat    55. 12.102 / 55. 12.102
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 80.101 /  3. 80.101
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
Input #0, flac, from 'Track01.flac':
  Metadata:
    REPLAYGAIN_ALGORITHM: EBU R128
    REPLAYGAIN_REFERENCE_LOUDNESS: 89.00 dBFS
    REPLAYGAIN_TRACK_GAIN: -7.25 dB
    REPLAYGAIN_TRACK_PEAK: 1.023053
    REPLAYGAIN_TRACK_RANGE: 3.94 dB
    REPLAYGAIN_ALBUM_GAIN: -7.25 dB
    REPLAYGAIN_ALBUM_PEAK: 1.023053
    REPLAYGAIN_ALBUM_RANGE: 3.94 dB
    ENCODER         : Lavf55.12.102
  Duration: 00:05:44.49, bitrate: 838 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
At least one output file must be specified

Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: Pat_ on 2013-08-04 10:26:57
As far as I can see, you're looking for ITU BS1770 algorithm with metrics taken from RG world. That's what is called RG2 in "r128gain".


Thanks, this clarifies.

So basically, Gain Adjustment at album or track level can be chosen to be calculated as:

EBU-128 compliant      : GainAdjust (LUFS)= -23 LUFS - (Integrated Programme Loudness calculated with R128 algorithm) LUFS
Replaygain v1.0 (RG)  : GainAdjust (dB)    = -89 dBFS - (Loudness calculated with replaygain 1.0 algorithm) dBFS
Replaygain v2.0 (RG2) : GainAdjust (dB)    = -18 dBFS - (Integrated Programme Loudness calculated with R128 algorithm) dBFS

For ReplayGain v2.0 (RG2), it is assumed that the integrated proramme loudness expressed in LUFS can be interpreted as dBFS because the relationship with the offset of -18 dBFS was empirically determined by correlation analysis (linear regression) between values of classical RG and R128 determined loudness.

The GainAdjust values calcuated are stored in the original meta-data tags of ReplayGain 1.0 for compatibility reasons. I guess this was part of my confusion. The meta-data name is called REPLAYGAIN_xxxx, but the VALUE should be interpreted either as R128 compliant, ReplayGain v1.0 adjustment or ReplayGain v2.0 adjustment.

Would it not be a good idea to note this difference in the tag "REPLAYGAIN_ALGORITHM"? To distinguish the "METHOD" of calculating the values stored in the REPLAYGAIN at album and track level.

REPLAYGAIN_ALGORITHM = "EBU-128"
REPLAYGAIN_ALGORITHM = "ReplayGain 1.0"
REPLAYGAIN_ALGORITHM = "ReplayGain 2.0"

Technically, the algorithm for determining loudness is either R128 or RG 1.0
The METHOD of adjusting the playback gain (replaygain_xxxx tags) is EBU-128 compliant, RG 1.0 compliant or RG 2.0 compliant.
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-08-04 12:09:41
REPLAYGAIN_ALGORITHM = "EBU-128"
REPLAYGAIN_ALGORITHM = "ReplayGain 1.0"
REPLAYGAIN_ALGORITHM = "ReplayGain 2.0"

There are only two algorithms: (classical) ReplayGain and ITU BS.1770. RG2 is nothing else than another variant of ITU BS.1770 (adding just another reference level to the EBU R128 and ATSC A/85 flavors, cf. also http://tech.ebu.ch/Jahia/site/tech/cache/b...he/off?id=16080 (http://tech.ebu.ch/Jahia/site/tech/cache/bypass/events/ibc11/cache/off?id=16080)).

Upcoming versions of "r128gain" will correct this (potentially breaking compatibility with prior versions).
Title: R128GAIN: An EBU R128 compliant loudness scanner
Post by: pbelkner on 2013-08-06 21:16:05
Support by me via HA forum is discontinued.