EBU R128 Loudness Normalization

[hello_hello]

Originally Posted by manolito

@ hello_hello
I think you are confusing ReplayGain with EBU R128 a little bit...

Not too much.....

Originally Posted by manolito

When you are talking abut the foobar2000 ReplayGain using the EBU R128 method for scanning, I believe this is the wrong term. If loudness scanning is done using EBU R128, then it is NOT ReplayGain any more. I would call it EBU R128 with a different reference level (e.g. -18 LUFS instead of the standard -23 LUFS).

Foobar2000 definitely uses the EBU R128 method for ReplayGain scanning, but the result isn't a lot different most of the time, so in that respect how you describe it is probably semantics. It's the target volume of 89dB or -18 LUFS which makes it ReplayGain, in my opinion. If the two scanning methods always produced dramatically difference loudness results, that'd be a different story, but mostly they don't seem to. Apparently EBU R128 is supposed to be a little more accurate. I don't know, so I won't argue with that.

http://www.foobar2000.org/changelog
1.1.6
ReplayGain scanner now uses libebur128 for improved accuracy.
https://github.com/jiixyj/libebur128
libebur128 is a library that implements the EBU R 128 standard for loudness normalisation.

https://github.com/jiixyj/loudness-scanner
Usage
The scanner also supports ReplayGain tagging.
The reference volume is -18 LUFS (5 dB louder than the EBU R128 reference level of -23 LUFS).

http://en.wikipedia.org/wiki/ReplayGain#Scanners
foobar2000: Generates metadata through included plugin using EBU R128 (but at old 89dB levels) for all supported tag formats.

Originally Posted by manolito

Both ReplayGain and EBU R128 establish a method for loudness scanning, plus they establish a reference loudness level. These two things are independent of each other. You can use ReplayGain scanning and set a reference level different from the standard 89 dB, and you can use EBU R128 scanning and also set a different reference level.

Well.....
If you scan with ReplayGain the tags saved will (should) always specify any volume change required to achieve the 89dB target volume. It couldn't work any other way. ReplayGain tagging can only work if the reference level is always the same.
Yes, some programs let you change the ReplayGain target volume and they'll use that target volume when converting etc, but they'll always write a tag relative to 89dB. Take a file that's already at the 89dB target volume. Scan it with ReplayGain while changing the target volume to 83dB, then convert it using the 83dB target volume. Any ReplayGain tag written will be +6dB. If there's no ReplayGain tag, well it's no longer ReplayGain, you've just used it's scanning to adjust the volume to some indiscriminate level.
Even if the playback device lets you change the target playback level it still needs ReplayGain tags relative to 89dB as a point of reference. If a program writes tags relative to some other reference level I can't see how that'd be anything but silly.

In respect to the discussion in this thread, ReplayGain and EBU R128 both have the same goal. ie to determine how loud the audio sounds. They mostly don't seem to disagree by much.
As an experiment I tried some movie audio (Jurassic Park). I downmixed to stereo, normalised and converted to MP3 so I could scan with MP3Gain. I also scanned the MP3 with foobar2000.
Mp3Gain/ReplayGain said it's "Track Gain" is +5.33dB (so it's level would need to be increased by 5.33dB on playback to achieve the 89dB target volume). Foobar2000/EBU R128 says it's +5.62dB.

Originally Posted by manolito

For my plugin which covers only DVD creation it makes total sense to use the EBU R128 scanning method, but employ a higher reference level like -18 LUFS. Most people seem to agree hat the EBU scanning method delivers more consistent results than the ReplayGain method, and it handles 6-ch audio which ReplayGain does not.

I'd agree in respect to scanning 6ch audio, but probably not when it comes to using a higher reference level such as -18 LUFS, assuming you're referring to adjusting the audio to that level. Unless I'm completely misunderstanding what the change in reference level would achieve.
That Jurassic Park audio I mentioned earlier.... to hit a target volume of 89dB (-18 LUFS) it needs to be increased by 5.33dB, which can't be done because it's already been normalised. Peaks at maximum, as loud as it gets. In fact after the MP3 was decoded while scanning it, both ReplayGain and EBU R128 agreed the peak level was already just a tad greater than maximum (1.003232 and 1.003263 respectively.... percentage, not dB).

89 - 5.33 = 83.67
The SMPTE reference level of 83dB or R128's -23 LUFS are looking pretty good (assuming 83dB and -23 LUFS are the same target volume).

Originally Posted by manolito

For FFmpeg the EBU R128 scanning is totally separate from the following loudness adjustment. You have to do the scanning pass, note the LUFS value, calculate the difference to the desired reference value, and then do a second pass for the loudness correction. The R128Gain software can do it all in one step, using FFmpeg for scanning and either SoX or FFmpeg for the loudness adjustment.

I've never used R128Gain. I assume this is it?
http://r128gain.sourceforge.net
I assume it's one step scan/convert process is really an automated two step process?

A look around the R128Gain site would indicate its kinda ReplayGain with a different name. Same principle, the same sort of tagging, just a different scanning method. Although it appears it does ReplayGain scanning too. I'll definitely have a play with it soon.
I assume it always writes ReplayGain tags relative to -18 LUFS, but what happens in EBU R128 mode in respect to the tags it writes when you change the reference level? Anyway, I'll have a play with it myself tomorrow. I'm keen to check it's EUR128 scan will produce the same result as foobar2000's ReplayGain scan. I assume it will....

Cheers.

[manolito]

Originally Posted by smok3

And how is that supposed to work? (time travel of some sort?)

It works by using a command line like this:

r128gain.exe --command="sox %TRACK% %BN%_normalized.wav gain %TGDB%" input.wav

Technically it is a 2-pass process, but from the user's perspective R128Gain does it in one step.


@hello_hello

The fundamental difference between RelayGain and EBU R128 is the loudness scanning method. If you want to compare the two methods, please do some googling. For the anylyzing process EBU R128 uses a K-weighting curve, channel summing and a fixed gate at -70 LU. The ReplayGain scanning is quite different, AFAIK HydrogenAudio has a detailed description. And contrary to your experience most folks say that the results of these two methods are not similar, but quite different.

You now introduce another ReplayGain feature, and this is tagging the output using Meta Data, so the real content does not get modified at all, the player has to read the Meta Data and adjust the loudness accordingly.

This concept is absent from the EBU R128 standard, because it is meant for broadcasting purposes. This does not mean that the tagging concept cannot be employed together with EBU R128 (in fact R128Gain does support tagging for FLAC output files). But for broadcasting and also for my target files (DVD creation) the tagging concept cannot be used, so the source has to be reencoded physically.

Back to semantics:
For me it is ReplayGain when the ReplayGain scanning method is used, and it is EBU R128 when the EBU scanning method is used. And this is independent from the reference level and if the output is tagged or reencoded.


Cheers
manolito

[smok3]

According to ha users, they are actually quite similar (rg and r128), example:
http://www.hydrogenaud.io/forums/ind...5&#entry759785

[hello_hello]

Originally Posted by manolito

@hello_hello

The fundamental difference between RelayGain and EBU R128 is the loudness scanning method. If you want to compare the two methods, please do some googling. For the anylyzing process EBU R128 uses a K-weighting curve, channel summing and a fixed gate at -70 LU. The ReplayGain scanning is quite different, AFAIK HydrogenAudio has a detailed description. And contrary to your experience most folks say that the results of these two methods are not similar, but quite different.

I'm aware the scanning methods work differently, but I'd disagree the results tend to be a lot different. The fact that software tends to use ReplayGain tags for EBU R128 scanning also seems to blur the line somewhat. That's what R128Gain does by default. It scans with EBU R128 and saves the results in ReplayGain tags.
Only in what to me seems like madness, it doesn't always use the ReplayGain target volume for the tags. Maybe that's a reason for people thinking the results are so different because by default they're 5dB different.

Originally Posted by manolito

You now introduce another ReplayGain feature, and this is tagging the output using MetaData, so the real content does not get modified at all, the player has to read the Meta Data and adjust the loudness accordingly.

That's how ReplayGain was supposed to work. Of course a program can use the same metadata to physically change the volume when re-encoding, and we all use it that way, but that's not how it was originally intended to be used.
The main reason I mentioned ReplayGain in the first place was due to the metadata/tagging, even if it's with EBU R128 scanning. If you're trying to adjust a whole bunch of files so they sound the same in level, a possible barrier to that is the difference in dynamic range. Audio "A" might require the same volume decrease to achieve the target volume as audio "B", but audio "A" requires a further decrease to prevent clipping. As soon as that happens, it's game over in the "sounds the same" department. The only way around it is to adjust a bunch of files as a group and if one requires a further volume adjustment, they all get the same further adjustment. For that though, you need the metadata. Either that or you'd need to use a target volume that pretty much guarantees there'll be enough headroom. ie -23 LUFS.

Adjusting a group of files together with MP3Gain is nice and easy. You just scan them with TrackGain, reduce the target volume until there's no longer any file for which MP3Gain shows clipping, and that's the magic target volume (it adjusts to that volume, but still writes tags relative to 89dB). It uses the metadata to help you set a suitable target volume for a group of files.

Originally Posted by manolito

Back to semantics:
For me it is ReplayGain when the ReplayGain scanning method is used, and it is EBU R128 when the EBU scanning method is used. And this is independent from the reference level and if the output is tagged or reencoded.

If you look at the R128Gain presets you'll see the authors of the R128Gain GUI don't quite agree. They appear to have made this distinction:

ReplayGain1 = -18 LUFS target volume, ReplayGain scanning.
ReplayGain2 = -18 LUFS target volume, EBU R128 scanning.
EBU R128 = -23 LUFS target volume, EBU R128 scanning.

Each method seems to always write the scan results as ReplayGain tags, which makes sense, as without the tags you'd just be using the scan to indiscriminately fiddle with the volume.
It's obvious if you think about it. Sure, you can scan, adjust the volume and remove the tags, but then it's just a file with a different volume. How would you later determine how loud it is? You'd scan it again.

The scanning method and the reference level can never be independent or the whole thing falls apart. For ReplayGain it's always been fixed, as far as I know, at 89dB. It appears R128Gain writes a new tag called "replay_gain_reference_loudness" which by default is -23 LUFS (or-18 LUFS for the ReplayGain presets). And sorry, but the tag is called "replay_gain_reference_loudness" no matter which scanning method you use.
If you change the reference level when scanning, TrackGain also changes accordingly.

Default of -23 LUFS
replay_gain_reference_loudness -23 LUFS
replay_gain_track_gain -9.4 LUFS

-17 LUFS
replay_gain_reference_loudness -17 LUFS
replay_gain_track_gain -3.4 LUFS

And at face value that seems fine. Software should be able to read the reference loudness tag and work back to the default of -23 LUFS etc, but there has to be a reference, and unfortunately so far the only software I've tried that seems to acknowledge the reference loudness tag exists is Mp3Tag.
Foobar2000 doesn't display it and I suspect it'll take the TrackGain at face value while assuming 89dB as the target volume, but I haven't tested that yet. MediaInfo doesn't display the reference loudness tag, but it does display this one:
REPLAYGAIN_ALGORITHM : EBU R128

I still haven't played with R128Gain a lot. So far, I've confirmed it's EBU R128 scanning and foobar2000's ReplayGain scanning produce the same result, and so far foobar2000's scanning and MP3Gain's scanning differs a little, but we're still in a 1dB difference range, and nothing close to anything which looks like it could be referred to as resembling "quite different".

So far, R128Gain's scanning works as I thought it should, but with the addition of the "replay_gain_reference_loudness" tag so fiddling with the reference level at least makes sense. Well, maybe....So far, I don't seem to be able to get R128Gain to change the volume using the GUI. All it's doing is re-writing the file with the new tags, but it's early days. I'll come back to it after a break and try again.

So far, I'm still completely failing to understand how changing the reference level is going to improve things when it comes to normalising the audio, but maybe that'll became clearer once I've got my head around R128Gain a little better.
I'm not saying you need to keep the ReplayGain tags after re-encoding. Chances are the muxing software will remove them anyway. You'll know the audio has been adjusted to the same volume for a particular DVD and that's what matters. The reference loudness used at the time doesn't matter so much as long as they're the same. I just don't get why adjusting to -18 LUFS would necessarily be better when the industry default is -23 LUFS.

[manolito]

Originally Posted by smok3

According to ha users, they are actually quite similar (rg and r128), example:
http://www.hydrogenaud.io/forums/ind...5&#entry759785

Just look at the following post:
http://www.hydrogenaud.io/forums/ind...dpost&p=761876
and things do not look this similar now...


Cheers
manolito

[hello_hello]

Originally Posted by manolito

Just look at the following post:
http://www.hydrogenaud.io/forums/ind...dpost&p=761876
and things do not look this similar now...

Out of 1275 scanned tracks, he made note of 5.
Of those five, the biggest difference was 5.7dB.
I'm not saying that's insignificant, but in the context of 1275 scanned tracks.....
Of the five he noted, the least difference was 3.09dB. Still a bit significant, but not massive.....
Pity he didn't also graph those 5 noteworthy examples with his ears to show which scanning method was getting it right.

I've never thought ReplayGain was perfect. Very, very good, but not perfect. I tend to run my audio player in random mode, so going from Billie Holiday to Billy Idol wouldn't be uncommon, and I've often thought maybe the old low-fidelity stuff is just a little bit quiet.
So I scanned Billy Idol's greatest hits. EBU R128 and ReplayGain don't differ by much. Billie Holiday.... EBU R128 seems to want to increase the TrackGain by between 1.5dB and 3dB for many of those. I guess EBU R128 and my ears agree there.

Those tests weren't particularly scientific. The MP3s were scanned by MP3Gain, their volume's adjusted to nearly 89dB, and TrackGain tags were written to make up any difference (MP3's can only be adjusted losslessly in 1.5dB increments), while I ran an EBU R128 scan on the already adjusted MP3s. Some time soon, I'll do some more accurate comparing, but I still maintain ReplayGain and EBU R128 are generally very similar. If now and then they differ by a few dB because EBU R128 is better, that's got to be a good thing, and a reason to use EBU R128 scanning for Replaygain, I'd have thought.

Anyway, I never intended to start a ReplayGain vs EBU R128 scanning debate. I just thought EBU R128 is used for ReplayGain scanning a bit these days, and ReplayGain scanning tends to save the metadata in tags (including peak level), and the metadata would be useful for determining the ideal target volume for a group of files so they could all be adjusted to the same target volume without any of them clipping. That's all.....

[hello_hello]

Wow..... it takes R128Gain 4 minutes and 20 seconds to scan my Jurassic Park MP3. Is that anywhere in the vicinity or normal?
MP3Gain does it in around 1 minute, 10 seconds and I thought it was slow. Foobar2000 zips through it in 16 seconds and it'll scan multiple files simultaneously.
R128Gain says Trackgain +5.63dB (EBU R128 scanning). Foobar2000 says TrackGain +5.62dB. I'll put the 0.01dB difference down to the decoding rather than the scanning, for the moment.

20 minutes of 5.1ch AC3: "Force Stereo" unchecked, 2 minutes 5 seconds for R128Gain, 7 seconds for foobar2000, TrackGain +4.5dB both times.
Same 20 minute AC3 with "Force Stereo" checked still takes 45 seconds. The TrackGain result changes quite a bit (11.9dB). I'll have to investigate that one as I don't understand it yet.

Why is R128Gain so unbelievably slow?

[nevcairiel]

In addition to the normal gain, R128Gain may compute the "True Peak" value as defined by EBU R128, which is a somewhat more expensive process and can slow down the computations a lot.
It may also not have a optimized FFT filter for the K-Weighting, a naive C implementation would be relatively slow.

Although, without knowing the length of said MP3, its certainly super slow to take 2 minutes for something like a 5 minute audio file.

[hello_hello]

I can't re-test for a while. Probably tomorrow. The PC's running two encodes at the moment and I don't have much time anyway.
The Jurassic Park mp3 is 2 hours, six minutes long. R128Gain took 4 minutes and 20 seconds to scan it.
The second audio was 20 minutes worth of 5.1ch AC3.

I'll report back when I've been able to re-test with the "true peak" option disabled (it was enabled).

[nevcairiel]

2 minutes for a 2 hour audio file seems like an acceptable time if True Peak is being computed. If anything, I would somehow doubt foobar2000 could decode and process the entire file in 16 seconds.
Audio decoding and processing is fast, but not that fast. 2 minutes is 60x realtime, 16 seconds is 472x realtime speed, which is just absurd.

[smok3]

Originally Posted by hello_hello

I can't re-test for a while. Probably tomorrow. The PC's running two encodes at the moment and I don't have much time anyway.
The Jurassic Park mp3 is 2 hours, six minutes long. R128Gain took 4 minutes and 20 seconds to scan it.
The second audio was 20 minutes worth of 5.1ch AC3.

I'll report back when I've been able to re-test with the "true peak" option disabled (it was enabled).

Has anyone tested:
a. what would be the difference in calculus if you only scan first 10-20 minutes?
b. if you only scan each 10th/100th/1000th sample?
(assuming we ignore the true peak)

[manolito]

FWIW I just found out that Peter Belkner published a follow-up software for R128Gain called BS1770Gain.
http://bs1770gain.sourceforge.net/

It is CLI only so far, parameters are not compatible with R128Gain. It has some interesting new features, it is more universal than R128Gain. I just hope that nobody associates its name with BS...

BTW up to now I was unaware of the newer ReplayGain2 specification. This new specs use the EBU R128 method for scanning and employ a reference level of -18 LUFS. Looks like much of the confusion between the two terms EBU R128 and ReplayGain originated from this new RG2 flavor.


Cheers
manolito

[xooyoozoo]

Originally Posted by xooyoozoo

The filter works on a single file basis, but I'd like to obtain an album-gain value. Is there a standard, "correct" way of doing so?

I'm thinking of concatenating an aggregate macro file to run through ffmpeg, but it'd be nice to save an extra processing step if that value can be trivially calculated using per-track values.

To answer my own question, ffmpeg's ebur128 filter calculates the gain value from two internal variables: integrated_sum & nb_integrated. If the values are somehow saved, "album" gain can be recalculated from any number of separate runs.

I'm getting results within <0.01 dB of results from concatenated sound files.

[hello_hello]

Originally Posted by nevcairiel

2 minutes for a 2 hour audio file seems like an acceptable time if True Peak is being computed. If anything, I would somehow doubt foobar2000 could decode and process the entire file in 16 seconds.

Disabling the True Peak calculation in R128Gain's options made a difference. That reduces the scanning time for the 2 hour, six minute mp3 to about 1 minute instead of 4 minutes 20 seconds. That also makes it a little faster than MP3Gain's scanning which took 1 minute 10 seconds.

Originally Posted by nevcairiel

Audio decoding and processing is fast, but not that fast. 2 minutes is 60x realtime, 16 seconds is 472x realtime speed, which is just absurd.

It's so absurd, I asked about it at the foobar2000 forum at one stage.
Not that the answer really meant much to me, but so far I've not seen any evidence it effects the accuracy of the scanning.

foobar2000's ReplayGain scanner is faster than probably anything else because foobar2000 can scan multiple files at once, it has very fast file decoders, it uses smart file buffering and Peter has hand optimized various ReplayGain functions.

Edit: When I get a chance, I'll do some more comparison scanning between R128Gain and foobar2000 and report back, although I suspect if foobar2000's scanning was producing inaccurate results, it's forum would be filled with posts complaining about it.

[hello_hello]

Originally Posted by manolito

BTW up to now I was unaware of the newer ReplayGain2 specification. This new specs use the EBU R128 method for scanning and employ a reference level of -18 LUFS. Looks like much of the confusion between the two terms EBU R128 and ReplayGain originated from this new RG2 flavor.

I'd just assumed ReplayGain was ReplayGain only sometimes these days it's used with EBU R128 scanning. Is there an actual ReplayGain2 specification or is it just some sort of de-facto standard?

[manolito]

http://wiki.hydrogenaud.io/index.php..._specification


Cheers
manolito