Skip to main content

Notice

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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #100
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #101
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #102
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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #103
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:

Quote
Originator code
[blockquote]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[/blockquote]
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
If I don't reply to your reply, it means I agree with you.


R128GAIN: An EBU R128 compliant loudness scanner

Reply #105
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #106
Quote
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
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #107
Quote
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #108
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #109
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
If I don't reply to your reply, it means I agree with you.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #110
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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #111
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #112
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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #113
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!

R128GAIN: An EBU R128 compliant loudness scanner

Reply #114
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


R128GAIN: An EBU R128 compliant loudness scanner

Reply #115
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #116
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


R128GAIN: An EBU R128 compliant loudness scanner

Reply #118
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.

Quote
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

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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #119
v0.4 released[blockquote]http://sourceforge.net/projects/r128gain/files/
http://r128gain.sourceforge.net/
[/blockquote]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:
  • First we tag the MP3 file:
    Code: [Select]
    $ 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.
  • Then we test which tags are set:
    Code: [Select]
    $ 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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #120
Wow, you are quite productive!

R128GAIN: An EBU R128 compliant loudness scanner

Reply #121
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.

R128GAIN: An EBU R128 compliant loudness scanner

Reply #122
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
Quote from: Notat link=msg=0 date=
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

[blockquote]-18 - R128 LUFS loudness[/blockquote]
instead of -23 - loudness into the RG tags. Otherwise, you're losing backward compatibility, like Notat mentioned.

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

R128GAIN: An EBU R128 compliant loudness scanner

Reply #123
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)



R128GAIN: An EBU R128 compliant loudness scanner

Reply #124
Easy instant switching between both would help a lot.

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

v0.4.6 released[blockquote]http://sourceforge.net/projects/in-ffsox/files/[/blockquote]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

[blockquote]-18 - R128 LUFS loudness[/blockquote]
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.