R128GAIN: An EBU R128 compliant loudness scanner Options

[googlebot]

Easy instant switching between both would help a lot.

This would be first and foremost a player feature. Are you planning to implement it?

Of course, we could continue the discussion on a purely conditional level: IF we had both types as separate tags AND the millions of playback devices and software players would adopt to the new format soon... then you could sit comfortably in your chair, switch back and forth over your collection and decide if you like R128 better than the venerable ReplayGain estimator.

For pure playback the existing tag infrastructure is totally sufficient. Testing and comparison can be accomplished with the already with the recently developed tools. We don't need separate tags for that. As a device manufacturer I wouldn't invest a penny just to let people switch back and forth between legacy and R128 measured gain values. I don't even think that the additional possibilities would outweigh the added confusion for consumers. If R128 turns out to be better, write the result properly offset into the existing tags. Add true peaks for any players which care. That's it.

This post has been edited by googlebot: Jan 13 2011, 18:49

[Notat]

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.

Have a look at the reference in post #94; further evidence that BS.1770 does a slightly better job than ReplayGain. R128 is based on and a further improvement to BS.1770.

In addition to strong acceptance in Europe, BS.1770 is specifically called out in the CALM act here in the US. The FCC is required to evaluate and, in 1 years time, require broadcasters to deploy it. It is possible the technology will be further improved in this process.

[benski]

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

[C.R.Helmrich]

Sorry for the detailed technicality, but:

Why not use the first bit (MSB) of the originator code field for precisely that? Meaning: 0 = original RG algorithm, 1 = EBU R128 algorithm. Quote from the current revision of the ReplayGain HA Wiki:

Originator code

000 = Replay Gain unspecified
001 = Replay Gain pre-set by artist/producer/mastering engineer
010 = Replay Gain set by user
011 = Replay Gain determined automatically, as described in Calculating (above)
other = reserved for future use

For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is 000 (Replay Gain unspecified), then the player should ignore that Replay Gain adjustment field.

For each Replay Gain Adjustment field, if the name code is valid, but the Originator code is unknown, then the player should still use the information within that Replay Gain Adjustment field. This is because, even if we are unsure as to how the adjustment was determined, any valid Replay Gain adjustment is more useful than none at all.

This question especially goes to David and audio player developers. Any potential disadvantages of doing it that way?

Edit: Bit pattern 100 could still be reserved for future use.

Chris

This post has been edited by C.R.Helmrich: Jan 13 2011, 20:27

[greynol]

Perhaps because we haven't identified many applications that use such a cryptic system.

Why not implement benski's suggestion?

[benski]

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.

Have a look at the reference in post #94; further evidence that BS.1770 does a slightly better job than ReplayGain. R128 is based on and a further improvement to BS.1770.

In addition to strong acceptance in Europe, BS.1770 is specifically called out in the CALM act here in the US. The FCC is required to evaluate and, in 1 years time, require broadcasters to deploy it. It is possible the technology will be further improved in this process.

I have some concerns about this paper. I need to read it again, and maybe I'll ask for the raw data and recalculate. The fact that Replay Gain using 85th percentile scored better than the default 95th percentile implies to me that there might be a calibration issue. Ideally, the calibration adjustment (a constant gain value) should be made so that it minimizes the RMS error, and I'm not sure that they did this (again - I need to re-read the paper and verify this).

Also, speech samples seemed to be overly represented in the data set.

[C.R.Helmrich]

Why not implement benski's suggestion?

For example because we don't want to waste bits in the file. Wait... so which player / file format actually implements David's original gain data format proposal (16-bit field per gain value)?

Chris

This post has been edited by C.R.Helmrich: Jan 13 2011, 20:55

[benski]

Why not implement benski's suggestion?

For example because we don't want to waste bits in the file. Wait... so which player / file format actually implements David's original gain data format proposal (16-bit field per gain value)?

Chris

I believe the only implementation of the original gain data format is in the LAME extended Xing header, which hardly anything uses for ReplayGain information, mostly because it's typically missing album gain.

This post has been edited by benski: Jan 13 2011, 21:12

[Notat]

I believe the originator code is written in a different format (ASCII) in some of the other tagging schemes. This all will be clearer to me and everyone else once I've worked this part of the document. At this point, what C.R. quoted from the new specification is just a copy of the original proposal.

There is some history regarding addition of a revision field. David has always been in favor, Garf did not feel necessity and proposed usage had been adequately demonstrated.

Once the two systems have been calibrated to one another, indications are that the difference in measurements on most material is typically just a few dB. Errors in playback with a mixture of ReplayGain and R128 scanned material will probably be no worse than the inherent variability experienced with a single system.

[C.R.Helmrich]

I see. So what's the de-facto standard (most widely used) bit stream format? The one that foobar uses, i.e. clear-text? i.e. around 70 characters = 560 bits to store two gains and a peak value? I'm speechless.

Guys and girls, feel free to define whatever format you want. I'll pass on this one.

Chris

[jdoering]

I certainly hope an extension at this point adds support for versioning or algorithm identification beyond a single bit distinction. The great part here is that with the exception of true versus sample peak; playback devices don't care about any of this (based on original intent of the ReplayGain proposal of course). I expect the inertia and compatibility issues at playback time are a lot bigger deal than on the tagging application side.

In terms of the adjustment factor; the upside there is that the values being discussed (5 versus 5.6 versus a new statistically derived value using EBU R128 on the referenced sample set) seem close enough that when playing mixed-algorithm content the cross-track results are still generally an improvement over the recommended behavior when encountering untagged tracks (e.g. use a running average as the ReplayGain spec suggests or a fixed value as the paper mentions). The ideal recommendation is of course to tag everything with one algorithm; but if it's mixed the sky shouldn't fall.

In terms of keeping separate tags for comparison, etc... I think that should remain in the realm of experimental features for an expert audience. That kind of support doesn't need any standardization and shouldn't be considered in a spec optimized for broad uptake. Considering the VorbisComment system for FLAC; it would be trivial to adjust the existing open-source tagging tools here to allow for user-specified tag names. I assume something similar could be done on an opensource player such that the tag names to read could be configured as an expert option. I don't know that it's worth doing; but I think there are a lot of contributors here could if they felt it added real testing value.

On the other hand; exposing end-users to the differences in these algorithms at playback time is probably the last thing general-consumption player want to even think about.

-Jeff

[greynol]

If you're getting up in arms over 560 bits, I'd hate to see how you feel about tagging with software like dBpoweramp, iTunes or MusicBrainz Picard.

This post has been edited by greynol: Jan 13 2011, 21:47

[benski]

Some tagging formats (particularly Vorbis comments for ogg and FLAC) don't support binary data, so plaintext is used in these cases. For ID3v2 tags, TXXX is used for consistency. Most id3v2 tags are padded anyway (to allow modification w/o re-writing the file) so it often ends up being a non-issue anyway, size-wise

[googlebot]

I see. So what's the de-facto standard (most widely used) bit stream format? The one that foobar uses, i.e. clear-text? i.e. around 70 characters = 560 bits to store two gains and a peak value? I'm speechless.

Yes, a whooping 10 MB of total overhead for a 10,000 album collection. Imagine you have 4 TB worth of FLAC files and need another disk just for those 10 MB!

This post has been edited by googlebot: Jan 13 2011, 22:24

[Nowings69]

This is wonderful idea.
Replay Gain is so cool too but usage is limited for audio
I looked for this since I gave up　read a tag from a container for movie(wihout vorbis gain in ffdshow and musepack DS filter)
Its means shows other new standards　for normalize
Please keep it up!thank you　so much

[pbelkner]

Easy instant switching between both would help a lot.

This would be first and foremost a player feature. Are you planning to implement it?

I'm considering this for my WA input plug-in.

Certainly I'm in favor with benski's proposal:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

In the meantime a player may try to make a guess based on units dB vs. LU.

[jdoering]

Certainly I'm in favor with benski's proposal:

I think it might be worth doing something like
REPLAYGAIN_ALGORITHM=ReplayGain 1.0

or

REPLAYGAIN_ALGORITHM=EBU R128

so that if you are converting your library that's already been processed with ReplayGain, you would be able to keep track of what still needs to be done

In the meantime a player may try to make a guess based on units dB vs. LU.

That's completely wrong! The existing tags should never have any units except dB. That overloads the meaning of the tags in a way that is not backward compatible. Even if a REPLAYGAIN_ALGORITHM tag is added; the units for the existing tags must be dB and should be normalized to original ReplayGain reference level.

Obviously it doesn't matter what you do to your personal library for algorithm testing purposes; but now you're talking about potential player implementations. Encouraging players to support incompatible deviations from the existing ReplayGain standard just weakens the standard - look at the ID3 tagging mess (not that it's limited to ReplayGain).

-Jeff

[pbelkner]

That's completely wrong!

It can't be wrong because it's a matter of convention.

[2Bdecided]

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?

My proposal is (and has been for a LONG time!) that there should be a tag which states the ReplayGain calculation method.

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.

Actually, while you're developing something, you have to do such things! Also, I think it's unreasonable to expect generally released software to include functionality that's only useful for testing and development - it would confuse normal users.

The process should work like this:
1. figure out the best available method of loudness matching in 2011.
2. define and document how this should work with ReplayGain tags (offset, versioning tag e.g. ReplayGain_calculation=2 or whatever, inter-sample peaks tags, etc).
3. add a pointer from all current RG documentation to this new document
4. encourage your favourite ReplayGain scanning software to switch to the new method

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.

I think it needs to be tested properly first. The evidence is that it's better, and as it's a standard I think it makes sense to go with it even if there's something else non-standard that's fractionally better still. What needs checking is that it works well with a full variety of CDs.

Cheers,
David.

[pbelkner]

v0.4 released

http://sourceforge.net/projects/r128gain/files/
http://r128gain.sourceforge.net/

What's new?

• Implements the "exponentiated" version of the R125 algorithm as proposed by C.R.Helmrich and outlined here. The R128 test vector's results are exactly reproduced (with the well known exception of the 6 channel sample).
• Sets the "REPLAYGAIN_ALGORITHM" tag to "EBU R128" as proposed by benski.
• FFmpeg based IO:
  
  • The audio streams are preserved (no re-encoding any longer).
  • Comes with minimal FFmpeg (supporting only a restricted set of "open" codecs, e.g. WAV, FLAC, OGG/Vorbis).
  • In order to upgrade to full FFmpeg support (i.e. to all FFmpeg supported formats and codecs, unfortunately not including Wavpack) do the following:
    
    • Google for "ffmpeg autobuild".
    • Pick the latest W32 shared build and substitute the corresponding DLLs in R128GAIN's sub-directory "r128gain".

As an example consider MP3 with fully upgraded FFmpeg:

1. First we tag the MP3 file:
   CODE
   $ r128gain ../sounds/01_cruise_missile.mp3 -o .
   FFmpeg successfully loaded.
   analyzing ...
     01_cruise_missile.mp3 (1/1): -16.2 LUFS, -6.8 LU (peak: 0.895013: -0.5 dBFS)
     ALBUM: -16.2 LUFS, -6.8 LU (peak: 0.895013: -0.5 dBFS)
   writing ...
     01_cruise_missile.mp3 (1/1) ... done.
2. Then we test which tags are set:
   CODE
   $ ffmpeg -i 01_cruise_missile.mp3
   FFmpeg version SVN-r26325, Copyright (c) 2000-2011 the FFmpeg developers
     built on Jan 13 2011 04:17:15 with gcc 4.4.2
     configuration: --enable-gpl --enable-version3 --enable-libgsm --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-libvpx --disable-decoder=libvpx --arch=x86 --enable-runtime-cpudetect --enable-libxvid --enable-libx264 --enabl e-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32 --enable-avisynth --enable-w32threads -- cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc' --enable-memalign-hack --enable-shared --disable-static
     libavutil     50.36. 0 / 50.36. 0
     libavcore      0.16. 1 /  0.16. 1
     libavcodec    52.108. 0 / 52.108. 0
     libavformat   52.92. 0 / 52.92. 0
     libavdevice   52. 2. 3 / 52. 2. 3
     libavfilter    1.73. 1 /  1.73. 1
     libswscale     0.12. 0 /  0.12. 0
   [mp3 @ 020afe90] max_analyze_duration reached
   [mp3 @ 020afe90] Estimating duration from bitrate, this may be inaccurate
   Input #0, mp3, from '01_cruise_missile.mp3':
     Metadata:
       title           : Cruise Missile
       artist          : Steve Morse Band
       album           : The Introduction
       TYER            : 1984
       genre           : Dance
       track           : 1
       REPLAYGAIN_ALGORITHM: EBU R128
       REPLAYGAIN_REFERENCE_LOUDNESS: -23 LUFS
       REPLAYGAIN_TRACK_GAIN: -6.8 LU
       REPLAYGAIN_TRACK_PEAK: 0.895013
       REPLAYGAIN_ALBUM_GAIN: -6.8 LU
       REPLAYGAIN_ALBUM_PEAK: 0.895013
       encoder         : Lavf52.92.0
     Duration: 00:05:35.24, start: 0.000000, bitrate: 320 kb/s
       Stream #0.0: Audio: mp3, 44100 Hz, 2 channels, s16, 320 kb/s
   At least one output file must be specified
   The original tags are preserved. The RG tags are written as expected.

[googlebot]

Wow, you are quite productive!

[Notat]

That's completely wrong!

It can't be wrong because it's a matter of convention.

It is wrong because it causes existing RG players to malfunction. Exiting players do not know about REPLAYGAIN_ALGORITHM and they assume that existing REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags are in dB units releaive to a -14 dBFS reference. Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.

This post has been edited by Notat: Jan 15 2011, 17:17

[C.R.Helmrich]

Thanks a lot for version 0.4! Regarding

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.

and

Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.

For a mixed selection of pre-loudness-war material (Kuschelrock Vols. 1 and 2, 4 CDs total), I get an average track-gain difference between the RG and R128 algorithms of exactly 4.6 dB (or LU). Since Raiden got 5.11 dB, I think the 5 dB proposed in Dolby's AES paper are well chosen. Hence, R128gain should write

-18 - R128 LUFS loudness

instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.

Chris

[benski]

I agree with Christian, you should write a 'calibrated' gain value, and use dB instead of LUFS.

As for calibration, I would think that finding a zero-order adjustment that minimized RMS difference rather than simply the average would be better. I'll test my library as well (huge mix of genres)

[pbelkner]

Easy instant switching between both would help a lot.

Sometimes dreams come true. For convenience a full quote follows:

v0.4.6 released

http://sourceforge.net/projects/in-ffsox/files/

What's new?

• Support for mixed ReplayGain and EBU R128 playback added:
  
  
  
  
  
  
  
  • The configuration allows for defining a relative gain between the two standards, typically about 5 dB. The relative gain can be adjusted according to the user's preferences.
  • It is possible to switch between the normative loudness of both approaches, -23 LUFS and 83 dB, respectively. The respective gains are adapted automatically.
  • If the "Write Comment" is checked RG respective information is written into the File Info's comment field
  
  
  
  
  
• Depending on whether the effective gain resulting from RG and pre-amp is an amplification or an attenuation up-sampling is done first or last in the processing chain, respectively, in order to avoid clipping.

That's my vision on how to deal with the different RG approaches: the player should handle it. In order to do this the player should have as much information as possible, e.g. a REPLAYGAIN_ALGORITHM tag, a REPLAYGAIN_REFERENCE_LOUDNESS tag, different units (dB, LUSF), etc.

Some recent posts point in the opposite direction, i.e. they are in favor for washing out this information:

It is wrong because it causes existing RG players to malfunction. Exiting players do not know about REPLAYGAIN_ALGORITHM and they assume that existing REPLAYGAIN_TRACK_GAIN and REPLAYGAIN_ALBUM_GAIN tags are in dB units releaive to a -14 dBFS reference. Unless I'm misunderstanding what you've done, a R128GAIN tagged file will play at a completely wrong level on a RG player.

For a mixed selection of pre-loudness-war material (Kuschelrock Vols. 1 and 2, 4 CDs total), I get an average track-gain difference between the RG and R128 algorithms of exactly 4.6 dB (or LU). Since Raiden got 5.11 dB, I think the 5 dB proposed in Dolby's AES paper are well chosen. Hence, R128gain should write

-18 - R128 LUFS loudness

instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.

I agree with Christian, you should write a 'calibrated' gain value, and use dB instead of LUFS.

As for calibration, I would think that finding a zero-order adjustment that minimized RMS difference rather than simply the average would be better. I'll test my library as well (huge mix of genres)

Fortunately there is a simple solution: With the next version R128GAIN will offer a "wash out" switch.