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.

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.

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?

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

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.

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.

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.

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

This is wonderful idea.Replay Gain is so cool too but usage is limited for audioI 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 normalizePlease keep it up!thank you so much

I think it might be worth doing something likeREPLAYGAIN_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).

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

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

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

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

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.

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 (Notat @ Jan 15 2011, 18:16)

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

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:

QUOTE (Notat @ Jan 15 2011, 18:16)

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.

QUOTE (C.R.Helmrich @ Jan 15 2011, 20:55)

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