IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 7 8 9 10 11 > »   
Closed TopicStart new topic
R128GAIN: An EBU R128 compliant loudness scanner
2Bdecided
post Jan 31 2011, 12:28
Post #201


ReplayGain developer


Group: Developer
Posts: 4962
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (C.R.Helmrich @ Jan 30 2011, 14:21) *
In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

RG(dB) = constant - R128(LUFS)

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.
Go to the top of the page
+Quote Post
pbelkner
post Jan 31 2011, 12:42
Post #202





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (2Bdecided @ Jan 31 2011, 12:22) *
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:

QUOTE (2Bdecided @ Jan 31 2011, 12:28) *
QUOTE (C.R.Helmrich @ Jan 30 2011, 14:21) *
In addtion, the major issue, which is mentioned there, is that the "exact" conversion constant when using the formula

RG(dB) = constant - R128(LUFS)

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!
Go to the top of the page
+Quote Post
2Bdecided
post Jan 31 2011, 15:16
Post #203


ReplayGain developer


Group: Developer
Posts: 4962
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (pbelkner @ Jan 31 2011, 11:42) *
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.

Go to the top of the page
+Quote Post
pbelkner
post Jan 31 2011, 16:49
Post #204





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (2Bdecided @ Jan 31 2011, 15:16) *
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.

QUOTE (2Bdecided @ Jan 31 2011, 15:16) *
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 ...

QUOTE (2Bdecided @ Jan 31 2011, 15:16) *
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.

This post has been edited by pbelkner: Jan 31 2011, 16:57
Go to the top of the page
+Quote Post
googlebot
post Jan 31 2011, 17:28
Post #205





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE (pbelkner @ Jan 31 2011, 16:49) *
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.
Go to the top of the page
+Quote Post
pbelkner
post Jan 31 2011, 17:47
Post #206





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (googlebot @ Jan 31 2011, 17:28) *
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.
Go to the top of the page
+Quote Post
Case
post Jan 31 2011, 18:31
Post #207





Group: Developer (Donating)
Posts: 2137
Joined: 19-October 01
From: Finland
Member No.: 322



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.
Go to the top of the page
+Quote Post
bryant
post Jan 31 2011, 18:44
Post #208


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (pbelkner @ Jan 30 2011, 02:47) *
QUOTE (googlebot @ Jan 30 2011, 11:24) *
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.
Go to the top of the page
+Quote Post
jangk
post Jan 31 2011, 19:41
Post #209





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



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
Go to the top of the page
+Quote Post
gjgriffith
post Jan 31 2011, 19:44
Post #210





Group: Members
Posts: 7
Joined: 31-January 11
Member No.: 87795



QUOTE (pbelkner @ Jan 31 2011, 11:21) *
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.
Go to the top of the page
+Quote Post
lvqcl
post Jan 31 2011, 21:21
Post #211





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



QUOTE (2Bdecided @ Jan 31 2011, 17:16) *
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.
Go to the top of the page
+Quote Post
jangk
post Jan 31 2011, 21:26
Post #212





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



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
Go to the top of the page
+Quote Post
Nick.C
post Jan 31 2011, 23:17
Post #213


lossyWAV Developer


Group: Developer
Posts: 1774
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (pbelkner @ Jan 31 2011, 15:49) *
QUOTE (2Bdecided @ Jan 31 2011, 15:16) *
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 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
googlebot
post Jan 31 2011, 23:27
Post #214





Group: Members
Posts: 698
Joined: 6-March 10
Member No.: 78779



QUOTE (Nick.C @ Jan 31 2011, 23:17) *
...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.

Go to the top of the page
+Quote Post
Nick.C
post Jan 31 2011, 23:39
Post #215


lossyWAV Developer


Group: Developer
Posts: 1774
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



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]

This post has been edited by Nick.C: Jan 31 2011, 23:43


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
bilbo
post Feb 1 2011, 02:17
Post #216





Group: Members
Posts: 190
Joined: 16-April 07
Member No.: 42593



@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!
Go to the top of the page
+Quote Post
Notat
post Feb 1 2011, 04:11
Post #217





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



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.
Go to the top of the page
+Quote Post
GHammer
post Feb 1 2011, 04:22
Post #218





Group: Members
Posts: 223
Joined: 11-May 03
From: China
Member No.: 6546



QUOTE (Nick.C @ Jan 31 2011, 18:39) *
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?
Go to the top of the page
+Quote Post
carpman
post Feb 1 2011, 05:11
Post #219





Group: Developer
Posts: 1307
Joined: 27-June 07
Member No.: 44789



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.


--------------------
TAK -p4m :: LossyWAV -q 6 | TAK :: Lame 3.98 -V 2
Go to the top of the page
+Quote Post
jangk
post Feb 1 2011, 05:28
Post #220





Group: Members
Posts: 36
Joined: 31-December 10
Member No.: 86953



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
Go to the top of the page
+Quote Post
carpman
post Feb 1 2011, 09:28
Post #221





Group: Developer
Posts: 1307
Joined: 27-June 07
Member No.: 44789



QUOTE (carpman @ Feb 1 2011, 04:11) *
If pbelkner's tool is for "experimental purposes"...

C.


--------------------
TAK -p4m :: LossyWAV -q 6 | TAK :: Lame 3.98 -V 2
Go to the top of the page
+Quote Post
pbelkner
post Feb 1 2011, 11:07
Post #222





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (Notat @ Feb 1 2011, 04:11) *
I'm confident it will all get sorted out.

I couldn't have said it any better.
Go to the top of the page
+Quote Post
pbelkner
post Feb 1 2011, 11:12
Post #223





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (gjgriffith @ Jan 31 2011, 19:44) *
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).
Go to the top of the page
+Quote Post
pbelkner
post Feb 1 2011, 11:18
Post #224





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (jangk @ Jan 31 2011, 19:41) *
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
$ 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)
Go to the top of the page
+Quote Post
pbelkner
post Feb 1 2011, 13:02
Post #225





Group: Members
Posts: 412
Joined: 13-June 10
Member No.: 81467



QUOTE (carpman @ Feb 1 2011, 05:11) *
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.

This post has been edited by pbelkner: Feb 1 2011, 13:03
Go to the top of the page
+Quote Post

23 Pages V  « < 7 8 9 10 11 > » 
Closed TopicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th April 2014 - 04:14