EBU R128 Loudness Normalization

[manolito]

For the last two days I have educated myself a little about the EBU R128 recommendation for audio normalization. An AVStoDVD user over at videohelp requested that this standard should be integrated into the software (which creates DVDs, nothing that would be broadcasted).

I do understand the concept, but I am not sure if this is something that should be used for DVDs (or Audio CDs or BluRays). I see that users have a need for a uniform loudness perception across different media, but is EBU R128 the solution?

The standard has been developped for (and by) broadcasting people. Even before this standard was adopted, broadcasters peak-normalized their content to -9 dBFS which is much lower than what you see on audio CDs or DVDs (usually around -2dB to -3 dB). The reason is that in broadcasting the content is much more diverse compared to CDs or DVDs, with an emphasis on spoken content.

The overall result when applying this EBU R128 standard is that broadcasts are around 3 dB quieter than they were with the old -9 dB standard. This EBU standard will eventually be adopted for online content, too. But does it make sense for Audio CDs, DVDs or BluRays?


Any comments welcome... :)


Cheers
manolito

[smok3]

short one: It does make sense, It is a thing of discipline, It does directly fight the loudness war. It does directly fight bad mixing/mastering "ideas".

example scans: https://bash-o-saurus-rex.googlecode.com/git/bash/user_bin/r128-example-scans_rockTop250.txt

p.s. If you are for some reason worried about levels being low, its probably easy to add some correctional number (user defined) to the calculated value.

[Sparktank]

It really depends on the source material.

I find film scores to have the opposite effect desired when using the EBU r128 for normalization.
There are parts of musical composition (namely classical and score music (the "classical" music written for fim and television)) that are intended to be played quietly, but not so quiet you have to adjust your volume. You can hear it perfectly well on the current volume. EBU tends to dramatically increase that level and make it blare louder than the rest of the music that is naturally loud.

It's a good option if you know when and where to use it.

As a "night-time" mode for film, it would be good if you don't want to wake the whole house up and still enjoy the dynamic depth of audio of whatever show/movie you're watching.
I'd add a heavily compressed audio track as a secondary track on the authored disc as an option for such playback situations.

But, I think I'd rather go with using SoX for that type of dynamic compression. You're also given more control over boosting certain channels, like the center channel where a majority of the dialogue will be.

EBU R128 would be good for quick and dirty applications, for introductory levels.

[smok3]

EBU tends to dramatically increase that level and make it blare louder than the rest of the music that is naturally loud.
You are in for some serious reading time, since you have absosmurfly no idea what you are talking about.

[Sparktank]

You are in for some serious reading time, since you have absosmurfly no idea what you are talking about.

I'm talking about personal experience on some film scores that sucked using EBU R128.

This should be taken over to HydrogenAudio. They smurfing love this smurf.

On that note, I'll just mark down everyone's time of the month on a personal calendar and back out from here.
So many people here are becoming more and more hostile like animals in captivity that get too old and senile.

[pandy]

short one: It does make sense, It is a thing of discipline, It does directly fight the loudness war. It does directly fight bad mixing/mastering "ideas".

Can you explain how it can prevent loudness war?

Whole concept of EBU R128 is wrong as it is in bad place (level equalization shall be performed at headend not at media).
In fact whole idea behind R.128 is to create good environment for advertisements.

Quality loss related to EBU R.128 implementation is to high...

[detmek]

Quality loss??? I use EBU R128 in foobar to make my music equally loud and it acts as automatic volume knob. How much quality can you loose by using volume knob?

It may reduce dynamic range if your audio file is 16-bit and has more then 86-90dB of dynamic range (like to see one, movie track or song) but human ear usually can't hear more then 35-40dB of dynamic range. And every song I have does not have nowhere near that high dynamic range.

You may change audio in unwanted way if you use plugin that adjusts loudness level by not scanning whole file. That leads to reducing dynamic range and altering loudness of some parts it unwanted or unexpected ways. So, just scan whole file and calculate loudness for it.

BTW, I asked a few months ago if it would be possible to add a feature to video players or audio decoders to read ReplayGain tags and adjust loudness during playback, just like audio players, but I didn't get any answer. That way audio would stay untouched and user can choose to use or not to use ReplayGain during playback. So far I can scan and tag MKV and MP4 containers using foobar2000.

[nevcairiel]

But, I think I'd rather go with using SoX for that type of dynamic compression. You're also given more control over boosting certain channels, like the center channel where a majority of the dialogue will be.


What.

EBU R128 is not dynamic compression, not at all, not even close.

All it defines is a reference volume level and an algorithm on how to measure the volume level of a song/movie/etc.
Its basically ReplayGain with a more thought-out implementation and industry adoption, plus multi-channel support for movies.

It does NOT change the quality of the audio.
It does NOT change the dynamic range (unless like mentioned your sample used literally the entire dynamic range of the digital domain, which would not be perceivable by anyone)

All EBU R128 does is calculate a *static* volume adjustment for every movie, show or music track, so that they all sound about the same volume. Volume differences within one title are not affected (ie. the dynamic range stays untouched).
Music players generally also have a "album" mode where the average of the entire album is used to preserve intentional volume differences between tracks on the same album (assuming they are all mastered to the same reference anyway)

I can only second a previous comment about reading and understanding what EBU R128 actually does and is meant to accomplish.

[manolito]

Thanks nevcairiel for pointing out all the important facts about EBU R128, couldn't have said it any better (I was just about to write a reply to the folks who quite obviously don't bother to enter a discussion without having a clue what they are talking about... :mad: )

Whatever, the AVStoDVD user who originally requested this feature made it clear that he has no intention to bring this standard to DVDs. He wants his DVD compilations (different tracks with different audio levels) to be watchable without correcting the playback audio level, and that from his experience the EBU R128 method to determine the correction factor is much more accurate than the ReplayGain method. And instead of the standard broadcast level of -23 LUFS he prefers a level of -11 LUFS (which IMO is a little high and requires a hard limiter at the end of the chain).

I think that I will add this feature to AVStoDVD, and I will include a user definable reference level to override the -23 LUFS default level. Thanks to ffmpeg, SoX and R128Gain this can be implemented quite easily using only open source tools.



Cheers
manolito

[pandy]

Quality loss??? I use EBU R128 in foobar to make my music equally loud and it acts as automatic volume knob. How much quality can you loose by using volume knob?


Plenty - read about re-quantization already quantized signal.
http://en.wikipedia.org/wiki/Quantization_%28signal_processing%29


It may reduce dynamic range if your audio file is 16-bit and has more then 86-90dB of dynamic range (like to see one, movie track or song) but human ear usually can't hear more then 35-40dB of dynamic range. And every song I have does not have nowhere near that high dynamic range.

Any adjustment of the already quantized signal introduce distortions.

Of course there is possible to reduce those distortions but it imply usage of the:dithering, noise shaping and if possible oversampling.


You may change audio in unwanted way if you use plugin that adjusts loudness level by not scanning whole file. That leads to reducing dynamic range and altering loudness of some parts it unwanted or unexpected ways. So, just scan whole file and calculate loudness for it.


In headend there is not possible to scan whole file - all adjustments need to be applied in real time, if your sources are from various providers then decoding -> adjustment -> reencoding is required - this lead to unavoidable loss of quality.

EBU R128 IMHO should be applied at CPE stage where correct requantization processing can be applied.

What.

EBU R128 is not dynamic compression, not at all, not even close.

True


All it defines is a reference volume level and an algorithm on how to measure the volume level of a song/movie/etc.
Its basically ReplayGain with a more thought-out implementation and industry adoption, plus multi-channel support for movies.

Partially true, first EBU R128 is based on Dolby Technical Bulletin 11 and as such it extend Dolby approach to perceived loudness (Dolby use different loudness reference level than analog studios and as such other audio codecs but at the same time Dolby use metadata to control final loudness and it is less affected by requantization problem). Dolby problem was that MPEG or AAC was perceived as louder when compared with Dolby (bad for Dolby business).
As i support industry good practices and i understand need of standardization for loudness level and loudness equalization then i disagree with proposed by EBU R128 concept of signal path.
IMHO loudness level measurement should be implemented at the end device and should be controllable by customer (i should be able to turn it off in same way as i can ignore Dolby metadata) - practical implementations for CPE are usually not inline with EBU recommendations.

Second EBU R128 cover various aspects of audio reproduction - it describe not only levels and how to measure but also describe detailed implementation of the signal path - this directly affect way how audio signals are decoded and processed - at the end of this path there DAC (and analog audio output) and/or digital audio outputs (S/PDIF, HDMI).


It does NOT change the quality of the audio.


Nope - after passing/propagating for fully EBU R128 compliant signal path audio level is different - at analog audio usually SNR is lowered (THD increased), on digital domain (S/PDIF, HDMI) only requantized signal (usually PCM) is available.



It does NOT change the dynamic range (unless like mentioned your sample used literally the entire dynamic range of the digital domain, which would not be perceivable by anyone)


It equalize loudness level to match/fulfill target value.


All EBU R128 does is calculate a *static* volume adjustment for every movie, show or music track, so that they all sound about the same volume. Volume differences within one title are not affected (ie. the dynamic range stays untouched).
Music players generally also have a "album" mode where the average of the entire album is used to preserve intentional volume differences between tracks on the same album (assuming they are all mastered to the same reference anyway)

I can only second a previous comment about reading and understanding what EBU R128 actually does and is meant to accomplish.

EBU R128 is more than loudness level meter and loudness level value, this is complex system to manipulate audio signal in real time and as such it directly affect audio signal quality.

I recommend EBU – TECH 3344 "Practical guidelines for distribution systems in accordance with EBU R 128" to understand implication for EBU R128 in practice.

[smok3]

IMHO loudness level measurement should be implemented and end device and should be controllable by customer (i should be able to turn it off in same way as i can ignore Dolby metadata).

That would mean changing all of the consumer devices, but yes.

EBU R128 is more than loudness level meter and loudness level value, this is complex system to manipulate audio signal in real time and as such it directly affect audio signal quality.
example?

what is a "cpe stage" ?

Any adjustment of the already quantized signal introduce distortions.

Of course there is possible to reduce those distortions but it imply usage of the:dithering, noise shaping and if possible oversampling.

I don't remember the multi-generation tests from this domain, any links? At what generation it does become audible?

[manolito]

Interesting discussion, but I'd like to bring this whole thing back to the real world... ;)

No need to complain about this standard, for almost all TV and radio stations in my country (Germany) this standard is here, like it or not. The public TV stations started to adopt it in 2012, the private stations followed, and today the vast majority of all broadcasters observe it. And this is not about to please the advertisers as pandy suspects, just the opposite is true.

More and more viewers and listeners complained that commercials were much louder than the rest, these complaints even reached the European Commission. As a result a task force consisting mainly of broadcasting engineers was put together, and they hammered out this standard. (BTW it is a recommendation, not a mandatory standard).

My point is if and how this can be useful for DVD creation. There is a legitimate need for users to have a uniform loudness level for the multiple tracks of a compilation DVD. The older approach to achieve this was ReplayGain, but now everybody agrees that the loudness detection method of EBU R128 gives much better results.

The standard broadcasting level of -23 LUFS probably does not make much sense for DVDs, but of course the reference level can be brought up to -18 LUFS, maybe even to -14 LUFS. This brings the overall loudness to a level comparable with current commercial DVDs.

The problem with these higher reference levels is that the result might run into clipping. For my plugin implementation I use SoX to apply the gain correction determined by ffmpeg. As I see it SoX has two methods to deal with clipping:

1. Use the "gain" effect with the -l parameter.
2. Use the "vol" effect and add a "limitergain" parameter.

Both are not well documented. Right now I tend to use the second method with a limitergain value of 0.025. But I need to do more listening tests...
(any SoX specialists out there? )

Anyways, the concept works well, my favorite right now is to first apply DynamicAudioNormalizer (default settings) followed by EBU R128 loudness normalizing to -14 LUFS.


Cheers
manolito

[hello_hello]

My 2 cents.....

I've been using ReplayGain for years. I wouldn't leave home without it. Most of the MP3s on my MP3 player are ReplayGained courtesy of MP3Gain, although on occasion I've used foobar2000's ReplayGain scanner and MP3 volume adjusting capabilities instead. These days the foobar2000 ReplayGain scanner uses the EBU R128 standard instead of the original ReplayGain algorithm. I haven't compared them a lot but for standard audio (CD tracks) they don't seem to differ all that much (maybe 1dB or so).

Several times I've extracted the audio from a bunch of episodes of a TV show (from DVD) and run ReplayGain on them. ReplayGain tends to see them as having the same average volume, give or take a dB or so. If EBU R128 can do a better job for those making their own DVD compilations etc, that must be a good thing.

I've never quite understood why ReplayGain hasn't caught on when it comes to the audio accompanying video (in MKVs and MP4s etc), in respect to using ReplayGain tags and adjusting the volume on playback. It's fairly universally supported by software audio players, but then again, it's largely unsupported by hardware audio players.....
Even video conversion GUI's tend to completely ignore it as a rule and stick to "peak normalisation", which isn't always useful for keeping relative volumes the same. I use foobar2000 for most of my audio conversion so I scan and convert that way.

EBU R128 is not dynamic compression, not at all, not even close.

For the record, there's a foobar2000 "compressor" dsp that uses the EBU R128 algorithm/method for doing it's thing.
http://www.foobar2000.org/components/view/foo_r128norm
I don't really understand how it works exactly, but I assume that's what's being referred to. It does "compress".
I've tested it a little on some stereo soundtrack audio and it seems to work pretty well, but you've got no control over what it's doing.

If anyone cares..... there's a zip file at the end of this post (http://forum.videohelp.com/threads/367532-Need-clarification-of-reverb-settings-in-Potplayer-%28audio%29?p=2350819&viewfull=1#post2350819) containing some audio compression samples. The R128Norm DSP is one of them. I still prefer the WinAmp RockSteady (http://uploadgeneration.info/Winamp/www.winamp.com/plugin/rocksteady-2-1/1099.html) DSP. These days if I was going to compress while re-encoding audio I'd probably do it with foobar2000, the Winamp DSP Bridge (http://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components/Winamp_DSP_Bridge_%28foo_dsp_winamp%29) and RockSteady, or something similar.....
I use ffdshow and RockSteady to compress the audio on playback all the time (I downmix to stereo first).

The problem with these higher reference levels is that the result might run into clipping. For my plugin implementation I use SoX to apply the gain correction determined by ffmpeg.

Are you still referring to using EBU R128 for running a ReplayGain scan? Wouldn't it work the same way, with the same option to adjust the volume according to the scan results and to adjust it further if need be to prevent clipping?
If so, couldn't you scan a bunch of audio files destined for a DVD compilation using "AlbumGain", then if any need to have their volume reduced further to prevent clipping, they'd all be reduced by the same amount to keep the relative volumes the same. That sort of thing......

Anyone know how the R128 levels of -23 LUFS and -18 LUFS etc translate into the old ReplayGain target volume of 83dB, or 89dB as is now the standard for music? I haven't got my head around that one yet.

[nevcairiel]

The old ReplayGain reference would be around -18 LUFS (which is -18 dBFS), 5dB louder than the -23 LUFS EBU R128 reference.
And its a good thing that its lower too, since RG didn't always manage to create a uniform volume level since some tracks would clip otherwise, which should be a much rarer problem with the EBU R128 reference.

The biggest advantage of EBU R128 over RG is however proper and official support for multi-channel, which makes it actually usable for video.

[manolito]

@ hello_hello

I browsed through the discussion of this foobar2000 DSP, and it behaves quite differently compared to the original EBU R128 standard. While the EBU standard requires that the whole file is scanned first and then the gain is adjusted to reach the desired reference level, the foobar DSP works in 1-pass mode. It uses a lookahead buffer and adjusts the volume dynamically. This works like an Automatic Gain Control (sounds pretty similar to DynamicAudioNormalizer), and it does "compress" the overall dynamics of a stream.

In my AVStoDVD plugin you gan get this behavior by applying DynamicAudioNormalizer first and use EBU R128 Loudness Normalization as post-processing.


Like nevcairiel I also remember reading in one of the many articles I went over that to get a loudness matching ReplayGain the reference level should be around -18 LUFS. For my tests I used Video DVDs mostly, and using EBU R128 on them with -18 LUFS reduced the loudness a bit compared to the original.

If you want to make your own tests on material you already treated with ReplayGain, you can use current versions of FFmpeg to scan the files. Use this command line:
ffmpeg.exe -nostats -i %1 -filter_complex ebur128 -f null -


Cheers
manolito

[xooyoozoo]

If you want to make your own tests on material you already treated with ReplayGain, you can use current versions of FFmpeg to scan the files. Use this command line:


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.

[hello_hello]

If you want to make your own tests on material you already treated with ReplayGain, you can use current versions of FFmpeg to scan the files. Use this command line:

I'll have a bit of a play soonish. Probably tomorrow.

I assume the EBU R128 "compressor" DSP uses the EBU R128 algorithm for determining volume, but it works with tiny sections at a time and adjusts the level accordingly. I have no doubt in that respect it works in a similar manner to DynamicAudioNormalizer.

The EBU R128 "compressor" DSP has nothing to do with foobar2000's normal ReplayGain scanning, which scans the whole file with the EBU R128 method and saves the results in tags etc, just as ReplayGain has always done.

I don't know if you listened to the samples I linked to but even though the EBU R128 DSP did a pretty good job of compressing the audio, it doesn't always compress short loud bits well. The sample contains a section of mostly low background noise, then a bunch of gunshots. The EBU R128 DSP actually amplified one of those gunshots a tad compared to the original audio.

Mind you it's hard to compare compression. I did it by running ReplayGain on each sample (and the original audio) and adjusted each accordingly. So they all have the same ReplayGain target volume after compression.

The one advantage the EBU R128 compressor DSP has over the other compressors is it's output file will effectively have the default ReplayGain target volume applied as a result of it's compression. Well, my little test encodes did at least. I ran ReplayGain on them and the EBU R128 compressor samples didn't require any further volume adjustment. The others did.

I included the original audio with the samples if you'd care to try DynamicAudioNormalizer as a comparison. I had a play with it a while back and found it quite good. The output sounded very much like the output from the RockSteady DSP (my compression settings) after I fiddled with a few of DynamicAudioNormalizer's options (http://forum.doom9.org/showthread.php?p=1689004#post1689004) to suite my taste.

Off the topic of compression and back to normal ReplayGain......

One of the things I liked about MP3Gain for applying ReplayGain to MP3s is it lets you easily adjust the target volume and it tells you whether there'll be clipping as you do. I often lowered the target volume to 86dB or 83dB for "soundtrack" audio as it tends to me more dynamic (I think 83dB is the SMPTE standard) but I'd sometimes lower it enough so none of the audio would have peaks causing clipping and then I'd apply TrackGain. Thinking about it, it's probably the same end result as using "AlbumGain" with a further volume reduction as required to prevent clipping. Either way a group of audio files are all adjusted to the same target volume, but the manually changing the target volume method let me feel in control. ;)

The old ReplayGain reference would be around -18 LUFS (which is -18 dBFS), 5dB louder than the -23 LUFS EBU R128 reference.
And its a good thing that its lower too, since RG didn't always manage to create a uniform volume level since some tracks would clip otherwise, which should be a much rarer problem with the EBU R128 reference.

ReplayGain using EBU R128 for scanning hasn't changed anything in respect to the ReplayGain's target volume.
Originally, the ReplayGain target volume was (I think) 83dB, but lots of people complained about it being too quiet, so it was pretty quickly changed to 89dB and it's been 89dB ever since. Unfortunately though, 89dB doesn't provide enough headroom for "soundtrack" audio, which is why I often lowered it to 86dB or 83dB when applying ReplayGain with MP3Gain.

Anyway, I dragged out an MP3 which I know was ReplayGained with MP3Gain and I checked the tags.
Track Gain -0.48dB, Peak 0.384223
I then ran a ReplayGain scan on it with Foobar2000 which apparently now uses the EBU R128 method for scanning.
Track Gain -0.56dB, Peak 0.384235

So they're a little different (it might even be due to the decoding) but they're basically the same. So whatever the EBU R128 equivalent of ReplayGain's target volume of 89dB might be (around -18 LUFS), the ReplayGain target volume hasn't changed, which makes sense I guess. It'd be a little odd if all the MP3's I scanned yesterday are now 6dB too loud because the ReplayGain scanning method was changed. Foobar2000 still shows the ReplayGain target volume as being 89dB by default (buried in it's preferences).

I guess talking about ReplayGain here is "my bad" so I hope I haven't confused things. This thread's about "EBU R128 Loudness Normalization" and I referred to "EBU R128 Loudness Normalization" and "ReplayGain" as being one and the same, given EBU R128 is sometimes used for ReplayGain scanning these days, and they would be, except it appears the original EBU R128 target volume has been increased for ReplayGain so it's not actually EBU R128 anymore. Sign.......
In my defence though, manolito referred to changing EBU R128 reference levels earlier, which probably helped shift my brain into ReplayGain mode. :)

I assume ffmpeg's EBU R128 volume adjustment would result in -23 LUFS as it should be. Or can you tell ffmpeg to apply ReplayGain too? Or would you just specify the appropriate target volume for ReplayGain in the command line? Although if ffmpeg doesn't apply ReplayGain as such, then you probably would miss out on some of the fun stuff, such as adjusting a group of files together via AlbumGain or using the ReplayGain "track peak" results to further adjust the volume and prevent clipping. They're the ReplayGain options I mentioned in an earlier post, in case what I was talking about wasn't clear at the time.

I'm too tired. Time for bed.

[pandy]

That would mean changing all of the consumer devices, but yes.

yes but IMHo in real life this is only one solution that can work - side to this with modern DSP present in each HDTV decoder imlementing device similar to LM100 is trivial.


example?

what is a "cpe stage" ?


Look at EBU – TECH 3344 - CPE means any customer device.


I don't remember the multi-generation tests from this domain, any links? At what generation it does become audible?

Be more specific - i don't understand "multi-generation tests" term - sorry.

Audible distortions - talk with vinyl hipsters - from mathematical perspective this is obvious - divide integer by fraction.
Re-quantization without additional processing will produce distortions spectraly correlated with signal.

Btw: EBU-R128 is not a standard - this is recommendation, it may be used voluntary by various bodies and similar end results are expected - but one again this is purely voluntary.

[manolito]

@ hello_hello

I think you are confusing ReplayGain with EBU R128 a little bit... ;)

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).

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.

For EBU R128 the standard reference level of -23 LUFS has been established for broadcasting, not for other applications like Audio CDs, MP3, DVD or Blu-Ray. Even before EBU R128 the standard broadcasting level has always been lower than for other media (-9 dB peak), because broadcasting has to cover a much wider spectrum of different source material than other media.

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 RepülayGain method, and it handles 6-ch audio which ReplayGain does not.

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.


Cheers
manolito

[smok3]

The R128Gain software can do it all in one step
And how is that supposed to work? (time travel of some sort?)

[hello_hello]

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

Not too much.....

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.

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.

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).

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]

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/index.php?showtopic=86424&st=0&p=759785&#entry759785

[hello_hello]

@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.

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.

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]

According to ha users, they are actually quite similar (rg and r128), example:
http://www.hydrogenaud.io/forums/index.php?showtopic=86424&st=0&p=759785&#entry759785

Just look at the following post:
http://www.hydrogenaud.io/forums/index.php?showtopic=86424&view=findpost&p=761876
and things do not look this similar now...


Cheers
manolito

[hello_hello]

Just look at the following post:
http://www.hydrogenaud.io/forums/index.php?showtopic=86424&view=findpost&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]

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... :p

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]

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]

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.

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.

http://s27.postimg.org/xcc3oavrn/Replay_Gain.gif

It's so absurd, I asked about it (http://www.hydrogenaud.io/forums/index.php?showtopic=106505&st=0&p=871057&#entry871057) 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]

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?title=ReplayGain_2.0_specification


Cheers
manolito