R128Scan [obsolete], Now implemented by bundled foo_rgscan Options

[tedgo]

This would cause that all scanned albums are quieter. Not only the albums that are still too loud after the scanning process.
So Enya would still "sing" much louder than AC/DC

This post has been edited by tedgo: Jan 30 2011, 19:22

[lvqcl]

Imho it is better to have "replaygain_correction" or "replaygain_offset" tag for manual adjustment.

[kode54]

Updated, now with error reporting.

And a correction on that target level configuration. I won't be implementing that, simply because the file tags are supposed to target a specific loudness level. If you want the player to behave as if the scanner targeted a reference level of -23 LUFS, then set your tagged files preamp slider to -5 dB, like Canar posted.

[quackalist]

I'm getting blank scan results after the last update. Also, last night when scanning using "scan selection as albums (by tags)" on multiple CD's from a box set foobar crashed



This post has been edited by quackalist: Jan 31 2011, 02:02

[tpijag]

Kode54

Issue with this newest version. I tried with all three context scan methods. Scan runs and based on the time it takes seems to be working. However, scan results window is empty and nothing gets written to files.

EDIT: Context menu item - remove replaygain tags does work. No console hint of troubles.

This post has been edited by tpijag: Jan 31 2011, 02:27

[kode54]

Updated again, thanks.

[tpijag]

Confirm issue gone and working fine for me.

thanks

[spies]

I won't be implementing that, simply because the file tags are supposed to target a specific loudness level.

Thanks for considering it just the same. I suppose as long as it stays a known reference value, which is currently -18 LUFS, I can always manipulate the tags in the files afterward if I want a different reference value stored. Not as easy as having the option up front though

I did want to note that the main reason I was interested in this option is that I am not entirely convinced that -18 LUFS will be the final target in trying to match a ReplayGain target of 89 dB on my library. I was also interested in how the proposed -23 LUFS target value for EBU R 128 compares to ReplayGain's original proposed target of 83 dB on my library. In no way am I trying to suggest that these values should be different from what they are currently. In the end I will not be mixing values from the two scanners myself since I would rescan my entire library anyway so trying to match the values from one scanner with the other is not a concern to me.

[M]

I won't be implementing that, simply because the file tags are supposed to target a specific loudness level.

Thanks for considering it just the same. I suppose as long as it stays a known reference value, which is currently -18 LUFS, I can always manipulate the tags in the files afterward if I want a different reference value stored. Not as easy as having the option up front though

Today I encountered both r128gain (pbelkner) and foo_r128scan (kode54), in that order. r128gain adds two additional tags to track the reference values — at least, when using the program with its default settings — which seemed like a good idea, at least from my own limited perspective. For now I am adding similar tags to the files I've test-tagged, so that I remember (if need be) how foo_r128scan handles things:

CODE

REPLAYGAIN_ALGORITHM : EBU R128
REPLAYGAIN_REFERENCE_LOUDNESS : -18 LUFS

- M.

[touccer]

You can implement a quiet mode to apply automatically the gain, like the default scanner does?

[quackalist]

Can also confirm both the empty scan results and foobar crashing are gone on the last update (1.20), thanks.

I did note, however, the scan result for an album I've been using to test each update are about 1 dB less than before. Can't remember it altering much, if at all, since the first version.

[grimes]

Here are some Album Gain data ReplayGain vs. EBU R128 True Peak.
(using foo_R128scan.dll Version 1.17, foobar2000 1.1.2)

[kode54]

Please note that the "true" peak method has no effect on the gain values anymore, as I don't pass the upsampled data through the scanner, I only use it for peak calculation. So, to speed up gain result comparisons, feel free to turn it off.

[mudlord]

Funny, I thought the SDK already has SSE optimized functions for calculating the peak of audio_chunks o_o

[kode54]

Not for this upsampled bullcrap. Then I have to upsample the audio before running it through the optimized peak scanner.

[romor]

Easy test which I'm sure some did before, but I just d/l papers and tests for potential reading:

CODE

                                       |  foobar2000        |  R128GAIN          |  Difference    
                                       |  gain    peak      |  gain    peak      |  gain    peak
----------------------------------------------------------------------------------------------------
01. 1kHz Sine -20 LUFS-16bit           |  1.95    0.100739  | -3.00    0.100733  |  4.95    0.000006
02. 1kHz Sine -26 LUFS-16bit           |  7.95    0.050507  |  3.00    0.050508  |  4.95   -0.000001
03. 1kHz Sine -40 LUFS-16bit           | 21.99    0.010254  | 17.00    0.010260  |  4.99   -0.000006
04. seq-3341-1-16bit                   |  4.95    0.071320  |  0.00    0.071316  |  4.95    0.000004
05. seq-3341-2-16bit                   | 14.96    0.023041  | 10.00    0.023049  |  4.96   -0.000008
06. seq-3341-3-16bit                   |  5.00    0.071472  |  0.00    0.071468  |  5.00    0.000004
07. seq-3341-4-16bit                   |  5.04    0.070801  |  0.00    0.070849  |  5.04   -0.000048
08. seq-3341-5-16bit                   |  4.95    0.100830  | -0.10    0.100845  |  5.05   -0.000015
09. seq-3341-6-5channels-16bit         |  5.02    0.063080  |  0.00    0.063132  |  5.02   -0.000052
10. seq-3341-6-6channels-WAVEEX-16bit  |  5.02    0.063080  |  0.70    0.063132  |  4.32   -0.000052
11. seq-3341-7_seq-3342-5-24bit        |  4.98    0.358332  |  0.00    0.358340  |  4.98   -0.000008
12. seq-3341-8_seq-3342-6-24bit        |  5.01    0.718294  |  0.00    0.718297  |  5.01   -0.000003
13. seq-3342-1-16bit                   |  4.59    0.100006  | -0.40    0.100088  |  4.99   -0.000082
14. seq-3342-2-16bit                   | -1.19    0.177826  | -6.20    0.177971  |  5.01   -0.000145
15. seq-3342-3-16bit                   |  2.01    0.100006  | -3.00    0.100088  |  5.01   -0.000082
16. seq-3342-4-16bit                   |  2.04    0.100006  | -3.00    0.100073  |  5.04   -0.000067

Track 10 problem is probably in it's format, but why this minor deviations? I know it's not important (can't be sensed), but curious what is causing +/- .05 difference - it's not like 6 digit error which can be overlooked. Or is it because of post #39?

[kode54]

What are you comparing there? There are two scanners for foobar2000, and the R128GAIN tool writes values that don't compare to foobar2000 by default. If you want to compare R128GAIN's output with either foo_rgscan or foo_r128scan, set Algorithm to BS.1770 and Compatible to ReplayGain. Otherwise, you need to convert the LU offset results to approximate ReplayGain dB offsets by adding 5 to them.

[romor]

Sorry if I posted wrong conclusion, but aren't "LUs" decibel units on same decibel referenced scale? I simply did not considered 5dB (no need for --rg-compatible switch), hence +/- 0.05.
I used this command line:

CODE

r128gain --r128 --true-peak=on *.wav -o c:\temp flac

than I posted tags in resulted FLACs and results made by your scanner

[edit] as said it's not big deal, only out of curiosity

This post has been edited by romor: Feb 2 2011, 07:19

[kode54]

Yeah, the results written by r128gain when using the pure --r128 mode will be in LU offsets, which are -23 - LUFS. My component applies -18 - LUFS, which is equivalent to running r128gain with the --rg-compatible switch.

[romor]

It seems like source to this in not in foobar, but from libebur128-0.1.10-win32 (or perhaps in me?), although it's author posted different results in early stage: link

libebur128-0.1.10-win32

CODE

for %x in (*.wav) do r128-sndfile.exe -r -t "%x"


                                         global
                                         loudness:     LRA:
------------------------------------------------------------------------------------------------------------
1kHz Sine -20 LUFS-16bit.wav            -19.95 LUFS    0.00    1.95382238 0.10073853  1.95382238 0.10073853
1kHz Sine -26 LUFS-16bit.wav            -25.95 LUFS    0.00    7.95382395 0.05050659  7.95382395 0.05050659
1kHz Sine -40 LUFS-16bit.wav            -39.99 LUFS    0.00   21.99266006 0.01025391 21.99266006 0.01025391
seq-3341-1-16bit.wav                    -22.95 LUFS    0.00    4.95355644 0.07131958  4.95355644 0.07131958
seq-3341-2-16bit.wav                    -32.96 LUFS    0.00   14.95986040 0.02304077 14.95986040 0.02304077
seq-3341-3-16bit.wav                    -23.00 LUFS   17.04    4.99589982 0.07147217  4.99589982 0.07147217
seq-3341-4-16bit.wav                    -23.04 LUFS   16.99    5.03591862 0.07080078  5.03591862 0.07080078
seq-3341-5-16bit.wav                    -22.95 LUFS    6.00    4.94999745 0.10083008  4.94999745 0.10083008
seq-3341-6-5channels-16bit.wav          -23.02 LUFS    0.00    5.01715778 0.06307983  5.01715778 0.06307983
seq-3341-6-6channels-WAVEEX-16bit.wav   -23.02 LUFS    0.00    5.01715778 0.06307983  5.01715778 0.06307983
seq-3341-7_seq-3342-5-24bit.wav         -22.98 LUFS    5.07    4.98024250 0.35833156  4.98024250 0.35833156
seq-3341-8_seq-3342-6-24bit.wav         -23.01 LUFS    2.24    5.00907772 0.71829414  5.00907772 0.71829414
seq-3342-1-16bit.wav                    -22.59 LUFS   10.00    4.58967232 0.10000610  4.58967232 0.10000610
seq-3342-2-16bit.wav                    -16.81 LUFS    5.00   -1.18933078 0.17782593 -1.18933078 0.17782593
seq-3342-3-16bit.wav                    -20.01 LUFS   20.00    2.01475665 0.10000610  2.01475665 0.10000610
seq-3342-4-16bit.wav                    -20.04 LUFS   15.00    2.03504371 0.10000610  2.03504371 0.10000610

r128gain

CODE

r128gain --r128 --true-peak=on *.wav

SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
1kHz Sine -20 LUFS-16bit.wav (1/16):             -20.0 LUFS,   -3.0 LU (peak: 0.100733: -10.0 dBFS)
1kHz Sine -26 LUFS-16bit.wav (2/16):             -26.0 LUFS,    3.0 LU (peak: 0.050508: -13.0 dBFS)
1kHz Sine -40 LUFS-16bit.wav (3/16):             -40.0 LUFS,   17.0 LU (peak: 0.010260: -19.9 dBFS)
seq-3341-1-16bit.wav (4/16):                     -23.0 LUFS,   -0.0 LU (peak: 0.071316: -11.5 dBFS)
seq-3341-2-16bit.wav (5/16):                     -33.0 LUFS,   10.0 LU (peak: 0.023049: -16.4 dBFS)
seq-3341-3-16bit.wav (6/16):                     -23.0 LUFS,   -0.0 LU (peak: 0.071468: -11.5 dBFS)
seq-3341-4-16bit.wav (7/16):                     -23.0 LUFS,    0.0 LU (peak: 0.070849: -11.5 dBFS)
seq-3341-5-16bit.wav (8/16):                     -22.9 LUFS,   -0.1 LU (peak: 0.100845: -10.0 dBFS)
seq-3341-6-5channels-16bit.wav (9/16):           -23.0 LUFS,    0.0 LU (peak: 0.063132: -12.0 dBFS)
seq-3341-6-6channels-WAVEEX-16bit.wav (10/16):   -23.7 LUFS,    0.7 LU (peak: 0.063132: -12.0 dBFS)
seq-3341-7_seq-3342-5-24bit.wav (11/16):         -23.0 LUFS,   -0.0 LU (peak: 0.358340: -4.5 dBFS)
seq-3341-8_seq-3342-6-24bit.wav (12/16):         -23.0 LUFS,    0.0 LU (peak: 0.718297: -1.4 dBFS)
seq-3342-1-16bit.wav (13/16):                    -22.6 LUFS,   -0.4 LU (peak: 0.100088: -10.0 dBFS)
seq-3342-2-16bit.wav (14/16):                    -16.8 LUFS,   -6.2 LU (peak: 0.177971: -7.5 dBFS)
seq-3342-3-16bit.wav (15/16):                    -20.0 LUFS,   -3.0 LU (peak: 0.100088: -10.0 dBFS)
seq-3342-4-16bit.wav (16/16):                    -20.0 LUFS,   -3.0 LU (peak: 0.100073: -10.0 dBFS)

[kode54]

You should mention that in the author's topic, in case he isn't following this one.

[Raiden]

It seems like source to this in not in foobar, but from libebur128-0.1.10-win32 (or perhaps in me?), although it's author posted different results in early stage: link

Your results are perfectly fine. It's just that I rounded the values in that test to one significant digit.

edit: R128Gain rounds values to one significant digit before it writes them to the file, while foo_r128scan and r128-* use 2 significant digits.

This post has been edited by Raiden: Feb 2 2011, 10:34

[romor]

Ah, yes, thanks for explanation. R128GAIN is presenting results with 1 digit precision and your lib with 2 digit precision

first table I posted has R128GAIN with 2 digit precision, which is not correct and reason is intermediate software I used before posting
+/- .05 should had ringed the bell, but it didn't

This post has been edited by romor: Feb 2 2011, 10:42

[GeSomeone]

Here are some Album Gain data ReplayGain vs. EBU R128 True Peak.

By looking at the pics grimes posted above, it seems that r128scan is off by 1 dB (or LU) compared with ReplayGain over large numbers of albums.
What is the logic of choosing -18 LUFS? Wouldn't -17 LUFS be closer to the target as best compatibility with RG is desirable? Like the 6 dB shift from 83 to 89 SPL that was chosen for RG.

I've seen discussion about this here and there. Information and examples from both threads still lead me to think the current R128 scanner implementation is (about) 1 LU louder on average. If it's true, it would be better to adjust it sooner than later.

[grimes]

In the mentioned plot, ReplayGain is 1LU louder than R128!
This is contrary to my results (R128 ~1LU louder than RG).
Here a similar plot R128 vs. ReplayGain of my classical productions already shown in post #62/2: