Skip to main content

Topic: R128GAIN: An EBU R128 compliant loudness scanner (Read 248058 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • benski
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #150
This was done on a 45,000 track test library.

My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

I assume you both did the comparison in track mode and I am curious if the results are the same in album mode.

Duh, I see now looking at lvqcl graphic is that it contains both track and album mode so I assume the result is the averaging of the two.  I am still curious what the results are when just comparing track or album mode.


I compared only track mode.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #151
Track mode (2124 tracks): foo_R128 = foo_RG - 0.62
Album mode (175 albums): foo_R128 = 0.93*foo_RG - 1.01

  • C.R.Helmrich
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #152
My small (~2000 tracks only) comparison of foo_r128scan vs. foo_rgscan:

http://img816.imageshack.us/img816/5396/rgr128.png

Nice plot! My first question would be: could you give us the names of the songs on which the two algorithms strongly diverge, esp. the ones at [R128=-2, RG=6], [R128=-6ish, RG=1ish], [R128=1.5, RG=-2.5]?

The same question of course also goes to benski, if he has such data!

Edit: Guess I should have read this first.

Chris
  • Last Edit: 26 January, 2011, 06:22:54 PM by C.R.Helmrich
If I don't reply to your reply, it means I agree with you.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #153
Yes, that thread.

I also uploaded 3 short (~20 sec) samples here: http://www.hydrogenaudio.org/forums/index....showtopic=86429
  • Last Edit: 26 January, 2011, 06:27:21 PM by lvqcl

  • benski
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #154
I got snowed in today and don't have access to the data at the lab at the office.  I'll find some outlier tracks tomorrow (there were some major ones!) and post details.

  • jangk
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #155
This might be of interest:

Grimm Audio has published an EBU R128 compliant Loudness scanner and Loudness Normalizer called "Level One".

There is a Demo ready for download in the web shop.
Here is the link to the manual: Manual Download

Jean

  • spies
  • [*][*]
  • Members (Donating)
R128GAIN: An EBU R128 compliant loudness scanner
Reply #156
url="http://www.grimmaudio.com/index.html"]Grimm Audio[/url] has published an EBU R128 compliant Loudness scanner and Loudness Normalizer called "Level One".

Looks nice and perhaps I will download the demo but € 450.00 excl. VAT! 

R128GAIN: An EBU R128 compliant loudness scanner
Reply #157
Hi guys. Is it the oversampling which makes the scanning procedur really slow and is the volume supposed to be quite alot quieter than replay gain? Regards.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #158
Is it the oversampling which makes the scanning procedur really slow

Yes. You may switch it off by disabling "True Peak".

The next version will have a bit faster "True Peak" mode.

is the volume supposed to be quite alot quieter than replay gain? Regards.

It is about 5 dB quieter compared to ReplayGain. You may switch on ReplayGain compatible mode, it makes it about 5 dB louder.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
R128GAIN: An EBU R128 compliant loudness scanner
Reply #159
is the volume supposed to be quite alot quieter than replay gain? Regards.

It is about 5 dB quieter compared to ReplayGain. You may switch on ReplayGain compatible mode, it makes it about 5 dB louder.

This is the confusion I was referring to earlier.

Have you considered the suggestion of using different tag names when writing incompatible gain information?

Regards,
David

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #160
This is the confusion I was referring to earlier.

As it seems there is a lot of confusion out there:
  • If I go to the EBU R128 page the first thing I see is -23 LUFS. Written in boldface and highlighted by blue color. If you like to blame someone go there.
  • If I see something labeled EBU R128 conformant than that's exactly what I expect.
  • What seems to be completely mixed-up in this forum is the difference between BS.1770 and EBU R128. EBU R128 is essentially -23 LUFS, about 5 dB below RG.
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.

This tool is about EBU R128 in it's entirety, not only about BS.1770.

EDIT: The following are some out of the reasons why I don't like to have any ad-hoc assumptions regarding the correlation between R128 and RG in the tool:

More specifically, regression analysis indicated that the gain adjustment should actually be -17.5 - 1.05*R128  (e.g. an R128 value of -10LU would correspond to -8.55dB gain adjustment)

Especially this one:

but I don't like the idea of having the beta coefficient not be 1.0.
  • Last Edit: 28 January, 2011, 05:48:51 PM by pbelkner

R128GAIN: An EBU R128 compliant loudness scanner
Reply #161
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #162
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Yep. That's the whole reason for "true" peak. Exactly the same you can expect to happen during playback, i.e. even if the record itself technically doesn't clip, during playback it may happen. I observed clipping according to "true peak" up to 1 dB for brickwall limited records (not restricted to them).
  • Last Edit: 28 January, 2011, 06:19:03 PM by pbelkner

  • jangk
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #163
Quote
Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled?


Yes exactly, please google for "Intersample Peaks".

Recommended comprehensive reading: 0dBFS+ Levels in Digital Mastering

Jean

  • Notat
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #164
As it seems there is a lot of confusion out there:
  • If I go to the EBU R128 page the first thing I see is -23 LUFS. Written in boldface and highlighted by blue color. If you like to blame someone go there.
  • If I see something labeled EBU R128 conformant than that's exactly what I expect.
  • What seems to be completely mixed-up in this forum is the difference between BS.1770 and EBU R128. EBU R128 is essentially -23 LUFS, about 5 dB below RG.
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.

If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags. You should not be reusing ReplayGain tags. You will do as you will, I suppose; there is no tag police to enforce this and documentation for ReplayGain tags is just now coming into existence.

  • Notat
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #165
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.

  • [JAZ]
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #166
Have you considered the suggestion of using different tag names when writing incompatible gain information?

Why should I? The ones who want ReplayGain's about -18 LUFS & BS.1770 can easily customize the tool accordingly. The next version will offer even more options.


If i get a file with ReplayGain information, as in the file has the tags used by a Replaygain-compatible scanner to indicate gain i would expect that tool to conform to the replaygain standard meaning for those tags. It is not important what is used to calculate the tags, or the amount of difference from the reference implementation. What is important is that the tags mean exactly what Replaygain says it means.


If you write replaygain tags, you ought to write them with the meaning that Replaygain applies.
If you want to conform to R128, the tags need to be different, and those can be in conformance with what R128 says.

So you got the option wrong. Specifying replaygain in your tool should specify "write the scanning data as replaygain-compatible tags", while r128 should mean "write the scanning data as a new tag format which is not the replaygain tags".


Else, you're just making a double standard, and this is what you are being warned about repetitively in this thread.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #167
If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags. You should not be reusing ReplayGain tags. You will do as you will, I suppose; there is no tag police to enforce this and documentation for ReplayGain tags is just now coming into existence.

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.

The tool makes it obvious to any user when it is in accordance with RG and when not. If you don't like the idea to have "True Peak" for RG I change the tool accordingly.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #168

If you write replaygain tags, you ought to write them with the meaning that Replaygain applies.
If you want to conform to R128, the tags need to be different, and those can be in conformance with what R128 says.

It's not me writing the tags. It's possibly you by hitting the button. If you don't like it just leave it.


this is what you are being warned about repetitively in this thread.

WTF?

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #169
If you want to do loudness normalization in strict accordance with R128 specifications you should create and use R128 tags.

If i get a file with ReplayGain information, as in the file has the tags used by a Replaygain-compatible scanner to indicate gain i would expect that tool to conform to the replaygain standard meaning for those tags. It is not important what is used to calculate the tags, or the amount of difference from the reference implementation. What is important is that the tags mean exactly what Replaygain says it means.

Just to make it clear for another time: the tool follows benski's proposal to indicate the difference:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #170
Scanned lossless files with replaygain showed 1.00000 peaks at highest now shows over 1.00000. Does this have something to do with the True Peak option and is it checking if the file clips when being oversampled? Regards

Same goes for the peak measurement. ReplayGain specifies storing sample peak. Storing true peak in ReplayGain tags is not in accordance with the proposal. Admittedly, the interoperability problems created by such a non-standard implementation are fairly minor and unobtrusive.

Done.

The next release will flag  checked "True Peak" as non RG compliant.

  • Nick.C
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #171
.... but surely if you are using existing ReplayGain tag names then a legacy program will not be able to differentiate using the new REPLAYGAIN_ALROGITHM tag as it will ignore it. Is there therefore a risk that the program will apply the wrong gain?
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #172
.... but surely if you are using existing ReplayGain tag names then a legacy program will not be able to differentiate using the new REPLAYGAIN_ALROGITHM tag as it will ignore it. Is there therefore a risk that the program will apply the wrong gain?

The algorithm is applied during scan time, not at playback time. Both, RG and R128, scan the files, determine a gain, and write it to a tag. At playback time the player reads the tag and applies the gain accordingly. That's all.

The discussion is only about the loudness against which the gain is measured. RG says (about) -18.0 LUFS, R128 says -23 LUFS, hence R128 appears quieter during playback (by about 5 dB).

Hi guys. Is it the oversampling which makes the scanning procedur really slow and is the volume supposed to be quite alot quieter than replay gain? Regards.

That's the only consequence. It's just like discussing Fahrenheit vs. Celsius. If you don't like the one, chose the other. It's just one click on the GUI. The player will apply exactly the gain value according to the standard you've chosen.

It's your choice. Nothing is hard coded. The tools does nothing behind your back. It does exactly what you tell it. It's all visible on the GUI.

  • [JAZ]
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #173
Just to make it clear for another time: the tool follows benski's proposal to indicate the difference:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0
or
REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done



That tells which algorithm was used to calculate the tags, not to which reference level the gains are based on. Replaygain expects it to be compared to -89dB (K-14 if you preffer). You can make the calculation with R128 at -23LUs, but when saving a replaygain tag, the gain needs to be relative to -89dB.


So no, this is not "A click on the GUI" neither about the unit used in the value. LUs vs dBs would be like Fahrenheit vs Celsius. A different base for the gain information is not.
  • Last Edit: 29 January, 2011, 04:33:01 PM by [JAZ]

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #174
You can make the calculation with R128 at -23LUs, but when saving a replaygain tag, the gain needs to be relative to -89dB.

Are you really know what you are talking about? Sure?

Ever heard about the difference between absolute and relative values? What of the two you guess is a gain?