R128GAIN: An EBU R128 compliant loudness scanner Options

[C.R.Helmrich]

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

[pbelkner]

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:

• "seq-3342-4-16bit.wav" with gate -8.0: -20.0 LUFS,
• "seq-3342-4-16bit.wav" with gate -8.1: -20.0 LUFS,
• "seq-3342-4-16bit.wav" with gate -8.2: -20.0 LUFS,
• "seq-3342-4-16bit.wav" with gate -8.3: -24.5 LUFS,
• "seq-3342-4-16bit.wav" with gate -8.4: -24.5 LUFS,
• ...
• "seq-3342-4-16bit.wav" with gate -10.0: -24.5 LUFS.

Plus the comment that lowering the gate is a step (compromise) towards the un-gated algorithm.

[pbelkner]

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:

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.

[SamDeRe81]

Hey, is this thing lossless if I use it on mp3 files?

[pbelkner]

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).

[jangk]

I found some very interesting reading on our loudness subject here at the Qualis Audio homepage:

TechNote #1 Loudness Measurements and the CALM Act and especially
TechNote #2 Understanding & Verifying Loudness Meters.

There is also a free download for a Loudness Meter Test Suite


Best regards

Jean

[oortoen]

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?

[lvqcl]

That's how replaygain was defined several years ago: http://replaygain.hydrogenaudio.org/calibration.html
gain = reference - loudness.

I think that's the main reason: to be compatible with existing software...

This post has been edited by lvqcl: Apr 24 2011, 13:00

[C.R.Helmrich]

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

This post has been edited by C.R.Helmrich: Apr 24 2011, 13:35

[oortoen]

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

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.

[Notat]

That's how replaygain was defined several years ago: http://replaygain.hydrogenaudio.org/calibration.html

The reference level was raised 6 dB after the proposal was published. This is the up-to-date version of that description.

[stereotype]

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?


This post has been edited by stereotype: Apr 27 2011, 00:04

[pbelkner]

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:

1. MP3GAIN only provides the Replay Gain algorithm. R128GAIN provides both, the Replay Gain and the EBU R128 (http://tech.ebu.ch/loudness), algorithms, with the focus on EBU R128. It's up to you to decide for yourself which of the two algorithms you find coming closer to really normalizing at equal loudness (by testing them).
2. On a technical side MP3GAIN manipulates each MP3 frame whereas R128GAIN only writes IDv2 Tags. The advantage of manipulationg each frame is that each MP3 player will honor it. The disadvantage is that it is possible only in steps of 1.5 dB. On the other hand manipulating IDv2 tags requieres a player being aware of them (as e.g. Winamp).

[drosen]

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

[pbelkner]

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

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 (see above). Luckily yesterday a respective patch was accepted.

[pbelkner]

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. Meanwhile FFmpeg has "bumped" their DLLs:

• avutil-50.dll => avutil-51.dll
• avcodec-52.dll => avcodec-53.dll
• avformat-52.dll => avformat-53.dll
• avcore-0.dll dropped

Version 0.8.5 released:

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

What's new?

• Compatible to the latest (bumped) FFmpeg versions.
• If upgraded to the latest full FFmpeg generates a XING header for MP3s, i.e. the generated MP3s contain the correct length information.

For upgrading to full FFmpeg (needed for MP3 processing) get the FFmpeg DLLs from the latest shared builds

• at Zeranoe: http://ffmpeg.zeranoe.com/builds/win32/shared/, or
• at Bizzeh: http://www.bizzeh.com/ffmpeg/free/shared/.

This post has been edited by pbelkner: May 15 2011, 16:18

[smok3]

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)

This post has been edited by smok3: May 24 2011, 11:15

[pbelkner]

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.

1. The command as given runs a regression (switch "--regression") between RG and R128 algorithms in order to determine the average loudness difference between the two with respect to your audio files. All output is written to stdout. In order to have them stored in a file you should redirect stdout to a file using the redirection operator ">".
   
   Each line prefixed with "ALBUM (<n>)" represents the next approximation. The approximate loudness difference (in dB) is the constant term.
2. If you want your files only be analyzed avoid both the "--regression" and the "-o" switches. The "-o" indicates that tagged versions of your files should be written.
   
   You can avoid the "--r128", "--r128-compatible" and "--true-peak=on" switches because they are default. If you want to have the analysis protocol written into a file redirect stdout to a the file using the redirection operator ">" , e.g.:
   
   
   CODE
   r128gain --gate=-10.0 e:\!tmp > out.txt
   
   This command does analysis only.
   
   Edit: You should add "--progress=off" in order to avoid that back-space characters are written, i.e.
   
   
   CODE
   r128gain --progress=off --gate=-10.0 e:\!tmp > out.txt

This post has been edited by pbelkner: May 24 2011, 12:28

[smok3]

thanks for explanation(s).

[AstralStorm]

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.

[Canar]

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.

[AstralStorm]

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)

[Notat]

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.

[Northpack]

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:



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.

This post has been edited by Northpack: Jun 23 2011, 10:47

[Notat]

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.

This post has been edited by Notat: Jun 24 2011, 01:59