Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: R128GAIN: An EBU R128 compliant loudness scanner (Read 389550 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #250
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
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #251
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #252
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.

R128GAIN: An EBU R128 compliant loudness scanner

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



R128GAIN: An EBU R128 compliant loudness scanner

Reply #256
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?



R128GAIN: An EBU R128 compliant loudness scanner

Reply #257
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...

R128GAIN: An EBU R128 compliant loudness scanner

Reply #258
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
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #259
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.


R128GAIN: An EBU R128 compliant loudness scanner

Reply #261
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?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #262
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:
  • 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).
  • 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).

R128GAIN: An EBU R128 compliant loudness scanner

Reply #263
@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?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #264
@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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #265
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:
[blockquote]Home: http://r128gain.sourceforge.net/
Download: http://sourceforge.net/projects/r128gain/files/[/blockquote]
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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #266
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)
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

R128GAIN: An EBU R128 compliant loudness scanner

Reply #267
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.
  • 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.
  • 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: [Select]
    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: [Select]
    r128gain --progress=off --gate=-10.0 e:\!tmp > out.txt

R128GAIN: An EBU R128 compliant loudness scanner

Reply #268
thanks for explanation(s).
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

R128GAIN: An EBU R128 compliant loudness scanner

Reply #269
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.
ruxvilti'a

R128GAIN: An EBU R128 compliant loudness scanner

Reply #270
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #271
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)
ruxvilti'a

R128GAIN: An EBU R128 compliant loudness scanner

Reply #272
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #273
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #274
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.