Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: R128GAIN: An EBU R128 compliant loudness scanner (Read 387938 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #75
I think you both have a valid point.

I also think that it is not very probable, that just because there is a tool now and some forum people decide to agree on a R128 tagging format, that there will be only a fraction of RG's device and player support anytime soon. It was different, when David started, because it filled a gap at its time, for which there were no solutions.

Until RG evolves into something allowing versioning, it can take ages. It might even never happen, since ID3 is such a mess. (The world of tagging could be such a better place without mp3.)

=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefits of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

PS An additional tag could indicate, that the values are R128 based. A user could then choose to rescan all tracks, which do not have that, yet.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #76
=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefit of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

That's exactly what I've tried to say. With R128GAIN you can do this just out of the box.

Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #77
PS An additional tag could indicate, that the values are R128 based. A user could then choose to rescan all tracks, which do not have that, yet.

R128GAIN solves this by design:
  • It takes a directory tree as input and copies the hole tree structure reursively into a second, r128 tagged tree structure.
  • The original tree is preserved. The created r128 tree is structural equivalent to the original tree.
  • If you interrupt R128GAIN and later on restart it, it will continue where you've interrupted (you should interrupt only during analysis not during encoding).

R128GAIN: An EBU R128 compliant loudness scanner

Reply #78
=> For an user with complete control over his own music library, it could be an attractive hack to rescan his library and write R128 estimated, but RG compatible, tags to his music collection. He would then have the benefit of both worlds, probably better loudness estimation due to gating, and instant playback support for most available hardware. RG enabled players don't really care what RG means or how the values were calculated. They just apply gain and prevent clipping.

That's exactly what I've tried to say. With R128GAIN you can do this just out of the box.

I agree. Just use the RG fields. The only difference would be how the RG values were calculated. The key point here is the calibration of the R128-calculated RG data to match the RG-calculated RG data. Which means...

Quote
Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.

I agree.

I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS. Taking the difference between the RG-average gain and the R128-average gain gives you the offset by which RG and R128 differ. Based on that offset we could "correct" the R128 gain values when writing them as RG-style metadata to files. Doing it that way, we wouldn't really need the additional tag that googlebot mentioned, since on average the new R128-calculated RG values are in the exact same range as the "old" RG values.

Chris
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #79
How large are the expected differences? Is there already any data? How much would the allocation of genres affect the outcome of that test?

Gating is an advantage of R128. Depending on the amount of silent passages in that huge collection, which are part of the ReplayGain but not the R128 calculation, the average result my become skewed. The calculated offset might appear larger than practically justified. Since it is a feature, that R128 rates tracks with a lot of silence differently from ReplayGain, this feature shouldn't be reduced by averaging. Maybe the collection could be gated before the comparison? But then, how much difference would remain? We could well end up close to +5.6 in the end again.  But that's speculation.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #80
True. I guess for the averaging we should leave out {not quiet but} high-loudness-range tracks (which I guess includes most classical music) and tracks with lots of silence (last track of a CD with hidden track or stuff like that). One or two seconds of silence around tracks ripped from CD shouldn't matter. You're right, the result will probably be near the pink-noise gain difference, but I just want to make sure.

Once Peter releases v0.4 which includes my optimizations, and it is confirmed that that release gives identical results to the current version, I'll start running some albums through RG and R128gain.

Chris
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #81
Code: [Select]
    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.7 LUFS, 0.7 LU (peak: 0.063133: -12.0 dBFS)


IMHO they should both be the same. But you probably already know that.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #82
Also note that storing REFERENCE_LOUDNESS for ReplayGain is not a standard and probably doesn't make any more sense here than it does for ReplayGain (current non-standard metaflac behavior notwithstanding).

Maybe it could become part of the RG standard:
  • It would help to resolve the 83 dB vs. 89 dB debate.
  • It would help to integrate playback of ReplayGain tagged and EBU R128 tagged tracks depending
on the unit dB vs. LU, provided someone figures out the mean relative loudness between the two approaches.


In various past threads (including this one by David) strong cases have been made against storing the reference level. I don't think it's needed for the original ReplayGain nor for an EU R128 based solution. In both cases the reference points are now well understood and essentially part of the standard (89 dB and -23 LU).

For existing player compatibility; I think it's a bad idea to change the meaning of the existing tags. Existing players can't be expected to do anything meaningful with REFERENCE_LOUDNESS. Further although it sounds like the one's you've tested are happily ignoring the units (dB verus LU) in the VorbisComment tags; assuming that is not a good idea for standardization. An existing player could quite reasonably ignore the tags altogether since it doesn't understand the LU unit.

Points on a homogenously processed library are good; but I don't think a player or the standard should presume that situation when reusing existing tags. A legacy player encountering a heterogeneously processed set of music might (a) ignore the new RG128 tags due to the LU units or (B) apply the value as is likely resulting in a significant loudness discrepency between true ReplayGain tags and RG128-overloaded ReplayGain tags. An update player might handle the situation better based on noticing the LU units or perhaps the REFERENCE_LEVEL. But I think there is a better way in terms of compatibility.

Assuming that some REPLAYGAIN_RG128_CONVERSION_FACTOR can be defined (for the momemt I'll allow for the situation where it is not fixed; allowing for alternative approaches such as ref_pink.wav calibaration versus averaging over a large sample set); it seems ideal to store that in a new tag and while storing ReplayGain-compatible values in the original tags. A legacy player would be able to handle heterogenous libraries reasonably (within the inherent limitations of defining a conversion factor and mixing algorithms); while an updated player could optionally use the conversion factor to convert the ReplayGain back to true EBU R128 compliant values. For a homogeneous EBU R128 library nothing is lost. The conversion factor may not provide perfect handling of heterogenous cases; but as a constant factor it can't make the situation any worse for homogenous libraries (beyond having to adjust the initial volume knob once compared to the quieter values provided by the current true EBU R128 compliant solution).

If we want a "pure" EBU R128 approach; I believe that should be stored in separate tags (as suggested earlier) either specific to this case or perhaps some generalized ReplayGain 2.0 spec that allows for explicitly indicating algorithms, etc but that doesn't overload the meaning of existing tags.

I think the current solution of overloading ReplayGain tags should be reserved for special use-cases (and thus not be a default or recommend behavior). It is only reasonable for homogenously processed libraries and is really a hack as a new RG128 compliant player doesn't need to overload ReplayGain tags in a non-standard way while compatibility with existing players can only be determined empirically since the overloading is not based on any flexibility in the existing ReplayGain/VorbisComment specs.

In terms of peak; I suspect that substituting the more accurate wave peak should be an acceptable backward-compatible replacement for the sample-peaks currently specified by ReplayGain. Updated players could assume true-peaks when the conversion factor tag is present. Legacy players won't know the difference; but it's unlikely that they were doing anything fancy about the discrepency anyway. The true-peaks should just allow improved clipping prevention.

-Jeff

R128GAIN: An EBU R128 compliant loudness scanner

Reply #83
I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS...

There is now a public link for this paper. Recommended reading. But if you can't manage to find the time, the answer can be found on page 11: RG=-18dB - LKFS

R128GAIN: An EBU R128 compliant loudness scanner

Reply #84
I disagree here. I'd rather like to see what the authors of the loudness papers I mentioned call "zero-order correction". Meaning: Take a huge audio file database (not only one file), compute the average RG value using the "old" RG algorithm. Then do the same with R128gain, using the recommended reference level of -23 LUFS...

There is now a public link for this paper. Recommended reading. But if you can't manage to find the time, the answer can be found on page 11: RG=-18dB - LKFS


Thanks for providing the public link; good read and very on-topic here. RG=-18dB - LKFS means an adjustment factor of +5 considering the -23 LKFS reference point for EBU R128. This compares to the aforementioned adjustment factor of 5.6 based on a simplistic ref_pink.wav comparison alone.

I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

-Jeff

R128GAIN: An EBU R128 compliant loudness scanner

Reply #85
I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

Please, let's re-analyze it! Otherwise we can't be sure.

Chris
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #86
Code: [Select]
    seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063133: -12.0 dBFS)
    seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.7 LUFS, 0.7 LU (peak: 0.063133: -12.0 dBFS)


IMHO they should both be the same. But you probably already know that.

Yep. I suspect that's possible for "libebur128.a" because it is based on "libsndfile.a" providing information regarding the channel map. R128GAIN instead uses a fixed (hard coded) channel map, because I coudn't figure out how to get the channel map from SoX or even more important from FFmpeg.

The goal is to have R128GAIN's IO based on FFmpeg in the near future. This will enable R128GAIN to process virtually any existing format or codec without re-encoding (as it is currently done for FLAC).

Please note that the tool is designed from a complete practical/pragmatic point of view: I want to be able to EBU R128 compliant tag my complete audio collection, including FLAC, WV, MP3, and AC3. All of them are plain 2.0 stereo anyway or multichannel downmixed to 2.0 by FFmpeg at playback time. That's the main reason for using the same tool chain for R128 analysis.

I would greatly appreciate if someone is aware on how to get the channel map from FFmpeg.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #87
I'm curious whether the the methodology in the paper and the conclusion on an adjustment factor of 5 still completely valid in terms of EBU R128. I assume the BS.1770 + silence filtering described in the paper is not precisely the same as the gating in EBU R128. Does the adjustment factor need revised statistical analysis or it should be "good enough"?

Please, let's re-analyze it! Otherwise we can't be sure.

Chris

My ad-hoc "measured" difference between RG and R128 is about 4dB. For RG I have the playback preamp at -2 dB, for R128 at +2dB to (subjectively) perceive about the same loudness shuffeling to two respective tagged huge audio collections. This pretty much matches the (theoretical) difference of about 5dB.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #88
I think the current solution of overloading ReplayGain tags should be reserved for special use-cases (and thus not be a default or recommend behavior). It is only reasonable for homogenously processed libraries and is really a hack as a new RG128 compliant player doesn't need to overload ReplayGain tags in a non-standard way while compatibility with existing players can only be determined empirically since the overloading is not based on any flexibility in the existing ReplayGain/VorbisComment specs.

If you think in terms of defining a standard, I agree. Otherwise I strongly disagree: I want to listen to R128 compliant tagged audio now.

In terms of peak; I suspect that substituting the more accurate wave peak should be an acceptable backward-compatible replacement for the sample-peaks currently specified by ReplayGain. Updated players could assume true-peaks when the conversion factor tag is present. Legacy players won't know the difference; but it's unlikely that they were doing anything fancy about the discrepency anyway. The true-peaks should just allow improved clipping prevention.

I completely agree.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #89
Jdoering's approach to just use ref_pink.wav to get a relative offset between both approaches is very reasonable.
I agree.
That is exactly how it's supposed to work.

You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

If you're comparing two loudness measurements, neither of which have a reference level, then you're stuck with comparing results from a large sample set. But if one or both have properly defined reference levels, then that should be unnecessary - and will only reveal inaccuracies in one or other algorithm with the chosen sample set. Presumably you want to remove such inaccuracies. Hard coding them into the conversion factor doesn't seem right.


But like I said - you could argue it either way. I think unless there's strong evidence to the contrary, the simple approach, "just use ref_pink", is the one to stick with.


I think (I've always thought!) that a version tag might be useful.
I think existing tags must keep their existing meanings.
Using a new calculation method with the same reference level is absolutely fine.
I think inter-sample peaks might be better in a separate tag, not in the existing peak tags. Some processing (e.g. typically that within software players) cares about the values of the actual sample data, and doesn't care at all about inter-sample overs. The player may do things differently if the real samples go above 0dB FS (e.g. introduce soft or hard limiting, or soft clipping) which may decrease quality if applied when it's only inter-sample values that go above 0dB FS. (In practice it's rare for ReplayGained audio to have significant inter-sample overs but no on-sample overs - "loud/squashed" audio like that tends to get turned down by ReplayGain to a level where there's no chance of any values above 0dB FS either on or between samples)

Cheers,
David.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #90
What is so special about pink noise? How does pink noise better appromixate the set of all possible audio inputs than a large set of audio inputs?

FWIW, analysing my library (a week of FLAC) resulted in a difference of 5.11 dB, similar to the ~5 dB other people got.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #91
Pink noise has equal energy over all octaves. It's just the reference against which all current ReplayGain values are calibrated. So it can make sense to use the same calibration for new loudness estimators instead of endless debates over which reference collection to choose, the allowed loudness range within that, etc. Even if you take the whole catalog from all major music publishers, averaging might not deliver optimal results. See the discussion above, why collection averaging might dilute the wanted differences between gating and non-gating loudness estimators.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #92
Thank you Notat for the link to AES "Loudness Normalization in Portable Players".

Very interesting on page 9 is Figure 3 showing the different frequency weighting curves for ReplayGain and for ITU-R BS1770.

Best regards

Jean

R128GAIN: An EBU R128 compliant loudness scanner

Reply #93
You can argue for or against the inclusion of an additional or different correction factor. It could be based on calculations from a large sample set, or from some theoretical presumption that one or other calculation is predictably and quantifiabley "wrong" with pink noise vs almost everything else. The latter might be justifiable, but the former wrecks the idea of having a real reference level.

The statistical processing in RG and the gate in R128 introduce non-linear behaviors that are difficult or impossible to compare mathematically or by using a single reference. This motivates the empirical/statistical approach.

Here's another (longer) study that takes a statistical approach. Loudness measurement implementation variations are considered including one with gating.

 

R128GAIN: An EBU R128 compliant loudness scanner

Reply #94
Without independent tag fields the authors of such plugins cannot start supporting EBU R128 gain control in their Replay Gain plugins.

Why not? There is a simple and reasonably accurate mapping between R128 and Replay Gain metrics.

As I've seen it now whether it is accurate enough is subject to debate.

Independent tag fields make such discussions superflous at least for people who want to have both and are willing to rescan their music once. Most importantly switching between EBU R128 and Replay Gain would not require rescanning the audio when both values are stored alongside. The implementing mapping itself is also probably an obstacle for some plugin developers (especially commerical ones where time is money) although I believe most people here would embrace it as a task.

And as I said storing EBU R128 information in a Replay Gain compatible format and tag fields should still be made available as an option. But if r128gain will never adopt its own tag fields with a relevant format then there's no appeal for loudness equalization plugin developers to adopt this method, since there's nothing to work with. EBU R128 will be too compatible to be distinct, and it will never stand a chance against Replay Gain.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #95
But if r128gain will never adopt its own tag fields with a relevant format then there's no appeal for loudness equalization plugin developers to adopt this method, since there's nothing to work with.

From where you know? R128GAIN exists just for one week. Of course, currently there is no sense in storing gain information in some new tags not a singel player out there is recognising. This early version of R128GAIN is aimed to allow you to get an practical idea of what EBU R128 is.

BTW: I'm myself a plug-in developer, and for sure one of the plug-in's next releases will support EBU R128 compliant tagging.

EBU R128 will be too compatible to be distinct, and it will never stand a chance against Replay Gain.

From where you know? EBU is not a nobody, it is the European Broadcasting Union. EBU R128 is aimed that all European broadcasters will transmit there programs at -23 LUFS according to this standard. Why would you like to have your music coming from the PC at another loudness?

R128GAIN: An EBU R128 compliant loudness scanner

Reply #96
Most importantly switching between EBU R128 and Replay Gain would not require rescanning the audio when both values are stored alongside.
I'm not sure why you'd want to do that. The whole point of anchoring ReplayGain to a known reference was so that an improved calculation could be introduced at any point without breaking anything (as could user defined values). Once an improved calculation is available, there's no reason to use the old (original) one, so no reason to have two sets of tags.

If the EBU defines a new set of tags and pushes for their adoption, then I can see that this could happen. But failing this, the existing RG tags, populated with values from another calculation (e.g. EBU R128), provide a perfectly good solution.

Don't underestimate industry inertia. Don't overestimate the EBU's interest in portable media players etc.

Cheers,
David.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #97
EBU R128 is aimed that all European broadcasters will transmit there programs at -23 LUFS according to this standard.
That is the intent, and is no doubt a "good thing". The EBU also told all EU broadcasters to use 720p. Most use 1080i. So, we'll see.

In terms of forcing a market to stick to a reference loudness, Dolby is the most successful by far. The vast majority of DVDs have dialnorm set correctly, and all AC-3 decoders use it to deliver -30dB Leq (with a fixed boost for RF / midnight mode).

Quote
Why would you like to have your music coming from the PC at another loudness?
If the world moved to such a low loudness standard it would be a wonderful thing, but I'm sure people will continue to use the pre-amp to make their music as loud as they think it should be (typically, louder!).

Cheers,
David.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #98
I'm with David.

I think we should verify the gain offset (5dB difference) and just write the new values to the old tags.  In theory, EBU R128 could just be a more accurate ReplayGain.

It might also be interesting to add some of the recommendations from EBU R128, particularly the silence gating and 66% window overlap, to ReplayGain and see if it provides a noticeable improvement.  ReplayGain could also be improved with a more up-to-date human hearing curve as well as a better filter design model (isn't Yule-Walker meant to be used for auto-regression analysis in Economics?).  10th order IIR filters aren't exactly ideal (stability issues with precision) for limited-precision digital applications.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #99
So if the old tags are used, how do I know whether audio files have been processed with r128gain or another EBU R128 implementation? The REPLAYGAIN_REFERENCE_LOUDNESS tag field? What if a Replay Gain scanner does not remove this tag field when I change from EBU R128 to Replay Gain?

Personally I'd like to be able to switch between both in an instant in order to compare their capabilities even more so because their coexistence in the PC audio domain has just started with this project, I thought that's obvious. Currently I would have to prepare two sets of audio files in order to compare them adequately, not very practical if you don't really know what music you actually need to test, as I don't remember every album where I found something odd.

@pbelkner:
Quote
Why would you like to have your music coming from the PC at another loudness?
Personally I have noticed quite some loudness differences of already replaygained music titles, as I understood it, EBU R128 does not simply has a lower base loudness, but may be better at bringing those albums to an adjusted level. But without proper testing preconditions this is not possible to proof for me. Easy instant switching between both would help a lot.

Well, if you experts tell me that EBU R128 is superior to Replay Gain then I will go with it and switch without testing... but actually I'd like to hear for myself.