R128Scan [obsolete], Now implemented by bundled foo_rgscan Options

[GeSomeone]

In the mentioned plot, ReplayGain is 1LU louder than R128!
This is contrary to my results (R128 ~1LU louder than RG).

I'm sorry I realize that using the term "louder" was not clear enough.

What I meant was when you would apply the calculated values as shown in your results in post #62, the result would be (on average roughly) 1dB louder with the R128scan values compared to the ReplayGain values.

It made me doubt that 5 dB/LU is the best offset.

edit: I decided to test a bit myself and for some "normal" jazz, pop and rock music the (album gain) result came close. For very bass heavy tracks it become all the more clear that ReplayGain ignores the low end too much, I'm not sure R128 ignores enough of it (maybe I just have to get used it's behaviour).

note to self: don't draw conclusions from 1 picture too quickly

This post has been edited by GeSomeone: Feb 4 2011, 21:05

[grimes]

Here are the plots of my bootlegs (note: these are no professional productions):

[M]

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

Just curious (not like it's a serious issue), but...

foobar2000 reports five significant digits for ReplayGain tags. How much overhead would be involved in calculating that level of precision with foo_r128scan, and how difficult would it be to implement a "high precision" mode to go along with the "true peak" mode, for testing?

— M.

[kode54]

foo_r128scan already logs in full double precision floating point values, but display and possibly tags are limited to two significant decimal places. I don't know where you are seeing these five significant digits of ReplayGain data, but the current version uses the same fixed two digits in the SDK when converting the floating point gain values to text for writing tags.

[M]

foobar2000 reports five significant digits...

Oops! I meant six significant digits. Silly me, posting before coffee and all!

— M.

[M]

foo_r128scan already logs in full double precision floating point values, but display and possibly tags are limited to two significant decimal places. I don't know where you are seeing these five significant digits of ReplayGain data, but the current version uses the same fixed two digits in the SDK when converting the floating point gain values to text for writing tags.

I was looking at the values displayed by selecting "Edit ReplayGain Information" from within the ReplayGain context menu, with the assumption that if six decimal places are shown, there might be a reason. So foobar2000 calculates more precise values than it bothers to display, even though the display exists? Seems like an odd choice.

— M.

[GeSomeone]

On ambient style albums I like the results much better than those of ReplayGain. Less too loud tracks.
I'm pleasantly surprised.

Just a few remarks on the cosmetics, I know, the least important part

• The order in the Scan results window is the order the scans were completed, not the order of the selection (as with RGscan). So long tracks often appear later.
• The position of the result window is not remembered

BTW The file names without the path, in the progress window, make more sense than those of RGscan.

[SamDeRe81]

I was just thinking we needed a new normalizing tool and found this Thanks for your work and I am glad I erased my ReplayGain tags months ago lol

I'm going to use this to get values for FLAC files then convert those into 160 aac vbr with neraacenc. Should I wait awhile or has everything been fixed?

[kode54]

I guess the number of significant digits depends on the tags used.

[kode54]

Updated.

[SamDeRe81]

I'm tempted to start using this but I'll wait a month till all the bugs are ironed out. Hell it was just updated yesterday lol

[kode54]

But that update only fixed a bug with odd sample rates, if you'll observe the change log. Everything should be pretty stable now.

[SamDeRe81]

Alright, I'm doing my entire FLAC library now, then afterward I'll use foobar2000 to convert into NeroAACEnc 190 VBR with gain applied. Thanks for this plugin I'm on Ubuntu and don't have any good audio programs that work except foobar2000. I use that for editing not playback, thanks!

[airon]

I'd like to generate a text report for selected playlist entries, using a reference of -23dB LUFS.

How can I achieve this ?

Any pointers to where I can read up and gather information myself is appreciated. I don't want to burden anyone with having to explain basics to me, and am willing to do the leg work myself. I just need to know where to get started.

[Chinch]

Ok, I'm going to apologize ahead of time for my ignorance, but everything you guys are talking about is going way over my head.

I understand the concept of the plugin... it's a volume normalizer, like ReplayGain. I just have a few questions if someone would be nice enough to answer some "stupid" questions for me.

1) What is the fundamental difference between this plugin and the standard ReplayGain routines/plugin that I have been using forever? In dumbed down terms, please.
2) If not already explained, is this plugin, based on that R128 method deemed "better" than RG or just an alternative. I saw mention of how it resampled to 192khz, or rather would like to...
3) Does this physically normalize the waveforms, or does it write tags like RG that are read and used to adjust peaks? read that it uses standard RG tags
4) This is probably unrelated, but it kept coming up in this thread, so I will go ahead and ask: I understand what sampling rate is, and from what I know, the two main choices (for converting between two) are the SoX and PPHS DSP's. Is either one of these "superior" or "preferred" over the other, or are they just different versions of the same thing, really? I have always wondered which to use when needed. I can research some more on that topic in other threads, but if anyone has a quick answer, that'd be great.

From what I could gather from reading the posts, this is essentially an alternative to ReplayGain, which is able to more accurately find the true peaks in tracks, or at least "more accurately" determine them? If you have already RG'ed your tracks, is there a strong reason to rescan using this plugin? I don't use like super high end equipment or anything, so...

Anyway. Thanks, and I hope I haven't bothered anyone by asking those questions... I'd just like to be more educated on this topic, as this R128 algorithm or method of scanning audio files is something brand new to me.

This post has been edited by Chinch: Mar 29 2011, 07:09

[GeSomeone]

There have been a couple of fixes for libebur128. Will there be an update for this plugin?

[mrinferno]

i suspect most will likely choose to simply upgrade to foobar2000 v1.1.6 beta which now has native support for libebur128.

[kode54]

Yes, when 1.1.6 goes final, this component will be discontinued.

[SamDeRe81]

Yea I just scanned my stuff with the new foobar2000 replaygain implementation, it's .01 variance from your plugin :/ I'm not gonna waste time re-scanning and trans-coding my FLAC's again it's not that much of a difference, but :/

[GeSomeone]

it's .01 variance from your plugin

That might be a matter of rounding/truncating, the integrated RG scanner writes 2 decimals, like it always did. This plugin wrote 6 decimals. I can assure you, the difference is neglectable.

Edit: what I said seems to be the case for mp3, replaygain values in FLAC files are displayed with 6 decimals. I am very sorry for the confusion.

This post has been edited by GeSomeone: Apr 26 2011, 22:53

[SamDeRe81]

interesting

[SamDeRe81]

R128Gain was updated with EBU R128-2, will you be updating your utility to work with it?

[lvqcl]

re-read post #93 on this page...

[kode54]

Not to mention that this utility and foobar2000 itself use libebur128, not R128Gain, so any changes to R128Gain would have to be ported over to the other library.