Skip to main content

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

0 Members and 1 Guest are viewing this topic.
  • 2Bdecided
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #200
In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself, the best-fit conversion involves a slope different from 1:

Quote
The optimum slope of -0.81 indicates a dependency on loudness. This can be explained by the loudness dependent level difference between the near maximum frame power (Replay Gain) and the long term power average (ITU-R BS.1770). Due to dynamic range processing and limiting this difference tends to get smaller for louder music. This observation is supported by an experiment where in the Replay Gain procedure the near maximum frame power analysis was replaced by a long term power average. Then the least squares fit between this modified Replay Gain and the ITU-based loudness has indeed a slope of -1.
While a loudness dependent coefficient makes the two data sets match more closely, that's not what should be used here.

One algorithm or the other is a closer match to human perception. Assuming that R128 is closer to human perception, then using a loudness dependent conversion factor will give a poorer result!

Cheers,
David.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #201
If you're writing REPLAY_GAIN tags they should be 100% compatible with ReplayGain!

Could you please define what 100% compatible with ReplayGain is? Provided the following:

In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

[blockquote]RG(dB) = constant - R128(LUFS)[/blockquote]
depends on the loudness of the material you use to measure that constant. As you confirmed yourself, the best-fit conversion involves a slope different from 1:

One algorithm or the other is a closer match to human perception. Assuming that R128 is closer to human perception, then using a loudness dependent conversion factor will give a poorer result!

  • 2Bdecided
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #202
Could you please define what 100% compatible with ReplayGain is?
Not in a precise manner in a few words. Maybe the wiki version of the RG spec will do the job eventually.

However, in the meantime, I'm sure that using an intentionally different reference level to write ReplayGain tags isn't 100% compatible with ReplayGain.

It's really simple - pick a suitable conversion factor from R128 to ReplayGain, use it to convert the R128 values to ReplayGain values, store these converted values in ReplayGain tags, and store the conversion factor in an extra tag in case someone wants to get the real R128 value back later.

Or use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.

You can't mix both. Well, obviously you can - you can write software to do anything you want - but it's not very helpful.


For a suitable default conversion factor, just run ref_pink through it...
http://www.hydrogenaudio.org/forums/index....st&p=739094
...or pick the best guess from the literature, or the various suggestions from this thread. They are all remarkably close.

Cheers,
David.


  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #203
I'm sure that using an intentionally different reference level to write ReplayGain tags isn't 100% compatible with ReplayGain.

I'm not using an intentionally different reference level. In order to do so I had to know the right reference level. As you and others meanwhile confirm such reference level can never exist because the measured loudness difference beteween the two algorithms depend on style, genere, production etc.

Given that such a reference level doesn't exist (in the sense of science not bureaucracy, i.e. ad-hoc definition) your statement is trivial.

use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.

Do you have plans to hold a trade mark on an everyday word? It's very common these days ...

For a suitable default conversion factor, just run ref_pink through it...

That's just one way out of a zillion to come to a more or less meaningful definition. Simply asking Dolby (proof by authority as proposed by benski) is another.

Such a definition will by no means be any gurantee that audio tagged by the two methods will sound equally loud (see above).

Another such a definition (equally good or bad, but from my perspective a more natural choice) is to calibrate EBU R128 according to EBU R128.

From my perspective it simply makes no sense even trying to mix RG and R128.
  • Last Edit: 31 January, 2011, 10:57:46 AM by pbelkner

  • googlebot
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #204
Such a definition will by no means be any gurantee that audio tagged by the two methods will sound equally loud (see above).


That's black and white thinking applied to a domain of shades. The range of possible conversion factors discussed so far spans a range of about 0.6 dB. Many of the values discussed can give you average differences to a traditionally scanned collection of 0.1 dB or less, with few singular exceptions (with good cause), where gated scanning beats traditional RG.

Because you haven't been served with a single value, that gives a "100%" guarantee, but just something that will be much better than 1 dB on average, you choose to go for a >5 dB average error. That might satisfy black and white thinking but else it doesn't make too much sense to me.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #205
That's black and white thinking applied to a domain of shades.

Oviously you've completely missed the point.

What is the advantage of having a mean deviation of 0.5 dB in the linear term? What about the non-linearity, i.e. the dependency of the "factor" from the loudness itself?

The bottom line was that I can't hardly see any reason for mixing the two worlds. From that any definition appears to me as good or as bad as any other. However, one out of all the possible definitions seems to me as to be the natural choice.

  • Case
  • [*][*][*][*][*]
  • Developer (Donating)
R128GAIN: An EBU R128 compliant loudness scanner
Reply #206
I'm thankful that you introduced us the new loudness evaluation algorithm but what you are doing with the tool doesn't do good to anyone. Smarter people than I have already given you valid arguments why the target level should match the official ReplayGain level so I won't bother you with that. I'll just mention that ReplayGain standard defines how it is calibrated so the only proper way to calibrate R128 is to use the same method. It really is that simple.
If you do not wish to comply please use another set of tags. I'll just remind that it may be difficult to get the same amount of software and hardware support as ReplayGain has for your new set of tags.

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
R128GAIN: An EBU R128 compliant loudness scanner
Reply #207
Instead pbelkner now just drowns the user in options.

This tool is not and was never aimed for the mass market. It's aimed to the curious who want to learn something along the way.

BTW: That's the only reason why I'm bothering myself.

If this tool is just for experimentation, then I don’t see any problem with writing out the standard ReplayGain tags with a different reference level. As Ghammer points out, it’s obviously impossible to experiment with a scanner that writes newly defined tags if there’s no player that recognizes them!

But if it turns out to be impractical in the long-term to simply convert EBU scan results to standard ReplayGain values, then the goal would be to define a new set of tags for the EBU method and a recommended procedure (and perhaps set of options) for players to implement if they want to be compatible. The intent would be that this would be done in a backwards-compatible way (i.e., files scanned and tagged with the new procedure would play at an acceptable level in legacy players). Once that is in place, then the option to write the non-compliant ReplayGain tags would go away (or at least no longer be the default behavior).

The ReplayGain spec that lives here on HA should make it clear (if it doesn’t already) that the currently defined tags have a reference level that is fixed by historical usage and that using a different level (for those tags) is a violation of the spec. I would recommend that any program that writes something different pop up a dialog first that says something like FOR EXPERIMENTATION ONLY!! - the operation you are about to do will result in files that will not play at the correct level on existing players - use yada-yada option to write compliant ReplayGain tags. That would reduce the possibility of confusion, although it’s obviously up to the respective authors to decide how much frustration they would like to source.

note: I wrote this response yesterday and ended up not posting it because it seemed the discussion had moved on, but this morning [here] I see that it hasn't. Even though it's a little outdated, I think it hints at a direction.

  • jangk
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #208
Back to basics:

I am afraid, but the calculation of True Peak Level in r128gain gives wrong results:

e.g. seq-3341-1-16bit.wav reads peak = -11.5 dBFS, should be -23.0 dBFS.

Jean

  • gjgriffith
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #209
Maybe the solution is having a "treat mono as stereo" switch in the next version.

If you could, I for one would appreciate that option. I don't have that many mono flacs, but I still don't cherish the prospect of hunting them all down and treating them differently from stereo flacs.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #210
For a suitable default conversion factor, just run ref_pink through it...
http://www.hydrogenaudio.org/forums/index....st&p=739094
...or pick the best guess from the literature, or the various suggestions from this thread. They are all remarkably close.

I disagree. I tested foo_rgscan and foo_r128scan on real music tracks, and they gave really close result: foo_r128 gain = foo_rg gain - 0.63  (see posts 147-149)

ref_pink (original mono track): foo_r128 gain = foo_rg gain - 0.63;
ref_pink converted to stereo: foo_r128 gain = foo_rg gain - 3.64.

So in reality, ref_pink is not very good for comparison of RG and R128.

  • jangk
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #211
Quote
I am afraid, but the calculation of True Peak Level in r128gain gives wrong results


Sorry, I forgot to mention that it happens in the DOS window.

The tags in the converted FLAC files seem to be correct.

Jean

  • Nick.C
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #212
use different tags entirely which don't have the words "ReplayGain" in them to store the R128 value.
Do you have plans to hold a trade mark on an everyday word? It's very common these days ...
.... but equally, why should you come along and make the information contained in REPLAY_GAIN tags ambiguous by writing information into them which has been calculated using a different algorithm. This smacks of opportunism, i.e. use the fact that a fairly large number of applications recognise the REPLAY_GAIN tags to enhance the usability of the information created using the EBU R128 algorithm.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

  • googlebot
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #213
...but equally, why should you come along and make the information contained in REPLAY_GAIN tags ambiguous by writing information into them which has been calculated using a different algorithm.


David has suggested exactly that, replacing the algorithm with something better if available, over half a decade ago. Why should that be problematic?

ReplayGain hasn't been perfect for all songs and I'm enthusiastic about R128, that it could improve results in some areas. But it should be calibrated to the same target level.


  • Nick.C
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #214
The lack of matching calibration is exactly the ambiguity that I am referring to.

[edit] Well, maybe ambiguity is not the correct word in this context - but a 5dB difference is quite a difference indeed if you are shuffling tracks.... [/edit]
  • Last Edit: 31 January, 2011, 05:43:08 PM by Nick.C
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

  • bilbo
  • [*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #215
@pbelkner
I applaud you you for your hard work and your willingness to on the leading edge of bringing this into existence. Early on you received much support on your project, But all seems to have broken down on your insistence on putting R128 values into the RG tags without factoring. I believe that this has hurt what was otherwise  an excellent project. Since players use RG Tags, these tags should have RG comparable data! You should use new tags for the unmodified R128 values. I would urge you to accept this for now and proceed with your valuable project before you lose your audience for the program to a new upstart.
Glass half full!

  • Notat
  • [*][*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #216
I'm personally critical AND supportive (and often misunderstood for it). There are clearly marked settings where R128GAIN does the right thing. Things are at an experimental stage. I'm confident it will all get sorted out.

  • GHammer
  • [*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #217
The lack of matching calibration is exactly the ambiguity that I am referring to.

[edit] Well, maybe ambiguity is not the correct word in this context - but a 5dB difference is quite a difference indeed if you are shuffling tracks.... [/edit]


Perhaps I'm a bit silly, but if I were to find a new tool that was much better (or just better. or I just wanted to use the new tool), I'd likely re-scan all my audio files using the New! Improved! tool. (I'm a sucker for new things...)

I'd not hear any difference.

But, that's me. I understand on one level the points being forcefully put out for consideration. One the other hand, I don't really have an axe to grind here because of the way I operate.

As I said, I do things a wee bit differently than others. In this case, it works out well.

To me, the main idea is whether this is a "Good Thing', and if it is, why not use it to the exclusion of the original RG?

  • carpman
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #218
Something I don't understand is this. If pbelkner's tool is for "experimental purposes", can't it be made a little like WavGain, but output a wav file that is a copy of the input with the gain applied. Thus it wouldn't require tags at all for files to be played at the correct volume.

So depending on the options selected, for an input named SONG.WAV, the tool would output:

SONG_R128_TRUEPEAK_TRACKGAIN.WAV, or
SONG_R128_NOTRUEPEAK_TRACKGAIN.WAV, or
SONG_REPLAYGAIN_TRACKGAIN.WAV (for traditional replay gain) etc ..

Possibly creating directories with similar suffixes for entire albums (album gained).
ALBUM_R128_TRUEPEAK_ALBUMGAIN\SONG_R128_TRUEPEAK_ALBUMGAIN.WAV etc ..

Then people could run a whole load of stuff through it and see how each fared. This way the tags issue would be void, and we could all get on with "experimenting".

Later down the line, I agree R128 should have it's own tags. What bryant, 2Bdecided and many others are saying makes complete sense to me.

C.
PC = TAK + LossyWAV  ::  Portable = Lame MP3

  • jangk
  • [*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #219
Quote
but output a wav file that is a copy of the input with the gain applied


This is not the objective, and it doubles the storage needs.
The aim is to tag, for to have an non-destructive system (I know, you have the copy ... )

Jean

  • carpman
  • [*][*][*][*][*]
  • Developer
R128GAIN: An EBU R128 compliant loudness scanner
Reply #220
If pbelkner's tool is for "experimental purposes"...

C.
PC = TAK + LossyWAV  ::  Portable = Lame MP3

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #221
I'm confident it will all get sorted out.

I couldn't have said it any better.

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #222
I don't have that many mono flacs

A lot of Youtube videos seem to be mono. (Video processing is not possible yet, but should be in the future).

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #223
I am afraid, but the calculation of True Peak Level in r128gain gives wrong results:

e.g. seq-3341-1-16bit.wav reads peak = -11.5 dBFS, should be -23.0 dBFS.

Could it be that you've mixed up the loudness (first value -23.0 LUFS) and the peak (second value -11.5 dBFS)?

Code: [Select]
$ r128gain.exe ../sounds/ebu-loudness-test-setv01/seq-3341-1-16bit.wav
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
  seq-3341-1-16bit.wav (1/1): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)
  ALBUM: -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)

  • pbelkner
  • [*][*][*][*]
R128GAIN: An EBU R128 compliant loudness scanner
Reply #224
can't it be made a little like WavGain, but output a wav file that is a copy of the input with the gain applied.

I'm thinking about this myself. It appears to be very useful if your mobile MP3 player doesn't support RG.

Please note that one important constraint to this project is to let FFmpeg handle all I/O and not trying to re-invent it.

There is some very good documentation available for reading via FFmpeg, but unfortunately literally nothing for writing, except "ffmpeg.c" itself. Figuring out how to write via FFmpeg will take same time. A first step towards this direction is copying audio streams only as already avilable with R128GAIN. The next step propably is to extend this to copying video streams. Re-encoding streams, as this request implies, will propably require much deeper insight into FFmpeg.
  • Last Edit: 01 February, 2011, 07:03:30 AM by pbelkner