foobar2000 replaygain reference level seems low Options

[aconverse]

The replaygain reference level in foobar2000 seems low.

I scanned http://replaygain.hydrogenaudio.org/proposal/ref_pink.wav from the original replaygain proposal, with a reference SPL of 89 dB. I was expecting to see a gain of +6 dB (as this file was supposed to generate +0 dB for 83 dB SPL). Instead I'm seeing +2.35 dB. Any ideas what's going on?

[xnor]

ReplayGain is not peak-normalization. Increase the gain on the Playback page (preamp) if you want less 'loss of volume' but check that you don't run into clipping (that's what the prevent clipping according to peak option is for).

[aconverse]

I'm completely confused about how peak normalization and pre-amp relate to what I asked. I'm not even complaining about a loss of volume. The gain here is positive after all. The gain just isn't as large as the replaygain spec says it should be.

The replaygain spec says this file (-14 dB pink noise) should have a gain of +6 dB. Clipping is not a concern here because the file has 10.9 dB of head room. As shown in the screen shows foobar only computes a replaygain of +2.35 dB.

[kode54]

The current ReplayGain scanner does not use the original ReplayGain algorithm any more. Instead, it uses the EBU R128 algorithm, converting the resulting LUFS 1:1 to a decibel offset to achieve a reference level of -18 LUFS.

[xnor]

I'm sorry aconverse, I completely misunderstood what you were asking.

[aconverse]

Thanks kode54, that clears things up

[xnor]

Hmm but when using r128gain with the ref_pink file using the ReplayGain profile (-18 LUFS) the resulting file is boosted by 6 dB.

edit: hmm the result doesn't change if I change the target LUFS...

This post has been edited by xnor: Jul 29 2012, 02:41

[kode54]

using the ReplayGain profile

And when you do that, it uses libreplaygain to scan the file.

[xnor]

I see. When using EBU R128-2 it reports -23.4 LUFS for the ref_pink file.

Instead, it uses the EBU R128 algorithm, converting the resulting LUFS 1:1 to a decibel offset to achieve a reference level of -18 LUFS.

-18 - (-23.4) = +5.4 dB, no?




This post has been edited by xnor: Jul 29 2012, 20:13

[kode54]

Maybe libebur128 needs some work, then. I found the same LUFS result with lib1770, regardless of using R128-1 or R128-2 mode.

lib1770 needs some work before it could be used in this scanner as well, as it doesn't support multi-threaded scanning, and my dodgy attempt to add that resulted in non-matching album gain levels.

[xnor]

R128-2 and -1 result in different LUFS here:

2:
[1/1] "ref_pink.wav": -23.4 LUFS (0.4 LU)

1:
[1/1] "ref_pink.wav": -23.5 LUFS (0.5 LU)


edit: I don't know much about R128/BS.1770 or the libraries that implement them. Just wondering why there's such a big difference in fb2k from the +6 or +5.4 dB.

edit2: I checked some music tracks and there the r128gain ebu r128-2 results line up fine with fb2k (referenced to -18 LUFS). Why wouldn't the ref_pink file?

edit3: The VST plugin 'AC-R128' measures the ref_pink file with -20.4 LUFS. So maybe it's just r128gain that's wrong.

This post has been edited by xnor: Jul 30 2012, 01:44

[kode54]

I have modified a version of lib1770 which may be useful for testing with this or the example programs:

http://kode54.foobar2000.org/moo/lib1770.7z

• I added a few _MSC_VER tests in various places to remove C99isms when compiling with MSVC.
• I also added a multi-threaded interface in bs1770_ctx_m.*.
  
  • The API is identical to bs1770_ctx.*, with the addition of creating an instance for N tracks, adding samples to each track, collecting info for each track, and collecting info for the entire album set.
  • Function calls for adding samples and collecting the track LUFS or track LRA may be overlapped with other threads, as long as each track number is only operated on by a single thread at a time.
  • Function calls to collect album LUFS or album LRA operate on the object as a whole, and thus must not overlap with any other threads.
  • Due to how the object uses multiple stats collection objects instead of a single instance, all tracks must be flushed by collecting their LUFS or LRA output before collecting the album output.
  • Note that the album LRA function may be incorrectly implemented, as I only guessed that it would be safe to scan each track separately, then pick out the minimum and maximum levels from each.
  • It also assumes that the gate level for each album job should be collected by averaging the gate levels of each track. This seems to line up with libebur128 as far as scan results. Well, except for that one result on ref_pink.

[Case]

That ref_pink file is mono, and for some reason R128Gain thinks it is half as loud as stereo file. foobar2000 scans mono files as stereo.

[xnor]

That ref_pink file is mono, and for some reason R128Gain thinks it is half as loud as stereo file. foobar2000 scans mono files as stereo.

Indeed, that's the case, Case. Surprisingly even Adobe Audition has that behavior. +5.4 dB as mono, +2.4 dB as stereo.

I just discovered that R128Gain has an option for this: "--mono=on,--mono Don't treat mono as stereo." This fixes things, but I'm wondering why this is 'force stereo' option is enabled by default.

edit: Maybe 'mono' means only the center channel is being used. But isn't it more common to play the mono files on the left and right channel (aka 'dual mono')?

edit2: libebur128 http://www.hydrogenaudio.org/forums/index....st&p=751044

This post has been edited by xnor: Jul 30 2012, 19:05

[pbelkner]

I just discovered that R128Gain has an option for this: "--mono=on,--mono Don't treat mono as stereo." This fixes things, but I'm wondering why this is 'force stereo' option is enabled by default.

AFAIK this is not backed by EBU R128. The option was added because of user request.

[xnor]

AFAIK this is not backed by EBU R128. The option was added because of user request.

The r128 doc doesn't say much at all. It's based on ITU-R BS.1770, which is the technical standard for measuring loudness. 1770-2 definitely does mention mono (center channel) and dual mono (left and right channel).

This post has been edited by xnor: Jul 31 2012, 12:54

[pbelkner]

I have modified a version of lib1770 which may be useful for testing with this or the example programs:

http://kode54.foobar2000.org/moo/lib1770.7z

There's a new version of "lib1770" available:

• It should compile with MSVC (cf. "nmake.mak" in source folder "msvc").
• Because of restructured code in order to avoid duplicated computations there's a performance boost of about 40%.
• The library now supports parallel computations (cf. "example2.c"). Parallel computation may bring another 50% performance boost.

[Martin F.]

The current ReplayGain scanner does not use the original ReplayGain algorithm any more. Instead, it uses the EBU R128 algorithm, converting the resulting LUFS 1:1 to a decibel offset to achieve a reference level of -18 LUFS.

Is it possible to change the value to match dBpoweramp’s default of −23 LUFS? I haven’t found a preference for that.

[kareha]

The current ReplayGain scanner does not use the original ReplayGain algorithm any more. Instead, it uses the EBU R128 algorithm, converting the resulting LUFS 1:1 to a decibel offset to achieve a reference level of -18 LUFS.

Is it possible to change the value to match dBpoweramp’s default of −23 LUFS? I haven’t found a preference for that.

Is this the reason why foobar and dbpoweramp produce different RG values?

[garym]

Is it possible to change the value to match dBpoweramp’s default of −23 LUFS? I haven’t found a preference for that.

Is this the reason why foobar and dbpoweramp produce different RG values?

Yes. In dbpa one can change the setting to -18 LUFS.

[Sandrine]

Sorry to butt in with a really basic question: Since we're in a foobar2000 forum, I'm assuming you're using lib1770.dll in foobar2000. I can't find that file anywhere in my foobar2000 folders, though. How do you use it?

[Case]

Is it possible to change the value to match dBpoweramp’s default of −23 LUFS? I haven’t found a preference for that.

Is this the reason why foobar and dbpoweramp produce different RG values?

Yes. In dbpa one can change the setting to -18 LUFS.

I'm disappointed in Spoon. He should know better and not break standards.

[Case]

Sorry to butt in with a really basic question: Since we're in a foobar2000 forum, I'm assuming you're using lib1770.dll in foobar2000. I can't find that file anywhere in my foobar2000 folders, though. How do you use it?

Your assumption is incorrect. foobar2000 uses libebur128 with some speed optimizations.

[Sandrine]

Your assumption is incorrect. foobar2000 uses https://github.com/jiixyj/libebur128"]libebur128[/url] with some speed optimizations.

Glad to know it's not me then but people posting unrelated info where it's confusing.

[Martin F.]

Is it possible to change the value to match dBpoweramp’s default of −23 LUFS? I haven’t found a preference for that.

Is this the reason why foobar and dbpoweramp produce different RG values?

Yes. In dbpa one can change the setting to -18 LUFS.

I'm disappointed in Spoon. He should know better and not break standards.

From this thread:

The proposed standard for Opus is R128 gain with a reference level of -23 LUFS.

From Loudness Metering: ‘EBU Mode’ metering to supplement loudness normalisation in accordance with EBU R 128:

For an ‘EBU Mode’ meter, the target loudness level shall be -23.0 LUFS = 0.0 LU (as defined in EBU R 128).

So dBpoweramp looks standard to me and that’s the reason I’d like to adjust foobar2000 rather than dBpoweramp.