IPB

Welcome Guest ( Log In | Register )

4 Pages V  < 1 2 3 4 >  
Reply to this topicStart new topic
R128Scan [obsolete], Now implemented by bundled foo_rgscan
tedgo
post Jan 30 2011, 19:18
Post #51





Group: Members
Posts: 1089
Joined: 16-April 04
From: Bavaria, Germany
Member No.: 13548



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 wink.gif

This post has been edited by tedgo: Jan 30 2011, 19:22
Go to the top of the page
+Quote Post
lvqcl
post Jan 30 2011, 19:33
Post #52





Group: Developer
Posts: 3412
Joined: 2-December 07
Member No.: 49183



Imho it is better to have "replaygain_correction" or "replaygain_offset" tag for manual adjustment.
Go to the top of the page
+Quote Post
kode54
post Jan 31 2011, 01:27
Post #53





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
quackalist
post Jan 31 2011, 01:47
Post #54





Group: Members
Posts: 42
Joined: 18-July 03
Member No.: 7846



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
Go to the top of the page
+Quote Post
tpijag
post Jan 31 2011, 02:23
Post #55





Group: Members
Posts: 2352
Joined: 19-May 08
Member No.: 53637



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
Go to the top of the page
+Quote Post
kode54
post Jan 31 2011, 02:36
Post #56





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



Updated again, thanks.
Go to the top of the page
+Quote Post
tpijag
post Jan 31 2011, 02:41
Post #57





Group: Members
Posts: 2352
Joined: 19-May 08
Member No.: 53637



Confirm issue gone and working fine for me.

thanks
Go to the top of the page
+Quote Post
spies
post Jan 31 2011, 02:51
Post #58





Group: Members (Donating)
Posts: 73
Joined: 20-July 02
From: Foster City, CA
Member No.: 2685



QUOTE (kode54 @ Jan 30 2011, 16:27) *
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. smile.gif 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 wink.gif

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.
Go to the top of the page
+Quote Post
M
post Jan 31 2011, 04:24
Post #59





Group: Members
Posts: 964
Joined: 29-December 01
Member No.: 830



QUOTE (spies @ Jan 30 2011, 20:51) *
QUOTE (kode54 @ Jan 30 2011, 16:27) *
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. smile.gif 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 wink.gif

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.
Go to the top of the page
+Quote Post
touccer
post Jan 31 2011, 08:34
Post #60





Group: Members
Posts: 13
Joined: 14-October 10
Member No.: 84615



You can implement a quiet mode to apply automatically the gain, like the default scanner does?
Go to the top of the page
+Quote Post
quackalist
post Jan 31 2011, 10:24
Post #61





Group: Members
Posts: 42
Joined: 18-July 03
Member No.: 7846



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.
Go to the top of the page
+Quote Post
grimes
post Jan 31 2011, 21:31
Post #62





Group: Developer
Posts: 304
Joined: 12-November 07
From: Frankfurt
Member No.: 48701



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




Go to the top of the page
+Quote Post
kode54
post Jan 31 2011, 23:38
Post #63





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
mudlord
post Feb 1 2011, 03:45
Post #64





Group: Developer (Donating)
Posts: 813
Joined: 1-December 07
Member No.: 49165



Funny, I thought the SDK already has SSE optimized functions for calculating the peak of audio_chunks o_o
Go to the top of the page
+Quote Post
kode54
post Feb 1 2011, 05:48
Post #65





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



Not for this upsampled bullcrap. Then I have to upsample the audio before running it through the optimized peak scanner.
Go to the top of the page
+Quote Post
romor
post Feb 2 2011, 01:20
Post #66





Group: Members
Posts: 680
Joined: 16-January 09
Member No.: 65630



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?


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
kode54
post Feb 2 2011, 05:58
Post #67





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
romor
post Feb 2 2011, 07:12
Post #68





Group: Members
Posts: 680
Joined: 16-January 09
Member No.: 65630



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


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
kode54
post Feb 2 2011, 07:57
Post #69





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
romor
post Feb 2 2011, 08:17
Post #70





Group: Members
Posts: 680
Joined: 16-January 09
Member No.: 65630



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)




--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
kode54
post Feb 2 2011, 10:17
Post #71





Group: Admin
Posts: 4629
Joined: 15-December 02
Member No.: 4082



You should mention that in the author's topic, in case he isn't following this one.
Go to the top of the page
+Quote Post
Raiden
post Feb 2 2011, 10:19
Post #72





Group: Developer
Posts: 224
Joined: 14-September 04
Member No.: 17002



QUOTE (romor @ Feb 2 2011, 08:17) *
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
Go to the top of the page
+Quote Post
romor
post Feb 2 2011, 10:39
Post #73





Group: Members
Posts: 680
Joined: 16-January 09
Member No.: 65630



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 wink.gif


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


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
GeSomeone
post Feb 3 2011, 00:26
Post #74





Group: Members
Posts: 922
Joined: 22-October 01
From: the Netherlands
Member No.: 335



QUOTE (grimes @ Jan 31 2011, 22:31) *
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.


--------------------
In theory, there is no difference between theory and practice.
Go to the top of the page
+Quote Post
grimes
post Feb 3 2011, 11:15
Post #75





Group: Developer
Posts: 304
Joined: 12-November 07
From: Frankfurt
Member No.: 48701



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:

Go to the top of the page
+Quote Post

4 Pages V  < 1 2 3 4 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th October 2014 - 17:38