So that is the way to go. I suggest someone will create an actual ReplayGain2 standard specification at wiki. This way all applications will follow the same specs, will be updated from ReplayGain1, and will be 100% compatible with each other.

I've been contacted by jaynyy and we've discussed moving this update forward. Jay is going to start by replacing the ReplayGain 1.0 loudness measurement with BS 1770-2. There are pointers to some of the other improvements we've discussed on the wiki talk page.

Further discussions of other improvements can happen here or on the talk page.

It would be nice to have additional meta-data to distinguish between the 'old' and the 'new' algorithm.

I did some experimentation with the replaygain calculation in Foobar2000 (v1.2.9) which uses “libebur128”, a library that implements the EBU R 128 standard for loudness normalization. The four replaygain meta-data tags written by Foobar2000 using the R128 loudness standard are interpreted correctly and playback in another player was no problem (I tried Musicbee). Obviously the values calculated using the 'old' algorithm and the 'new' algorithm are different. It would be nice if the specification would add additional meta-data to make that distinction.

I have also tried the R128GAIN software and it generates the following additional tags:

Now, libebur128 used in Foobar2000 follows the offset recommendation [1] mentioned in the Replaygain 2.0 spec. It sets the reference level to -18 instead of -23. Which makes sense for music playback on portable devices and correlates well with the old replaygain loudness values. That could be reflected as:

So if these two additional tags would beccome part of the specification, then a clear distinction could be made how loudness was calculated and against which reference level replaygain is adjusted.

--------------------------------------------------------------------------------------------NOTES[1] Based on the research of Dolby Laboratories as published in May 2010 for the Audio Engineering Society. EBU-R128 is for the broadcast industry but music playback psychologically suggests a higher playback level. http://www.dolby.com/uploadedFiles/Assets/...dia-Players.pdf

Writing ReplayGain track and album gain tags with an intentionally different reference loudness is a very bad idea. It breaks existing players.

It is fine to use a new calculation method with a new reference loudness, but the values must be converted to the original reference loudness before being written to ReplayGain tags. That way, loudness matching will work on all ReplayGain compatible players across all ReplayGain tagged files.

An extra tag can be used to tell new players how to convert back to the new calculations' reference level if required, without breaking compatibility with old players. That way, you get the best of all worlds.

Consider an album with a loudness of -17 LUFs containing a track with a loudness of -16 LUFsAssuming the 5dB conversion is used (i.e. assuming -23LUFs is 5dB quieter than the (83+6)dB SPL reference of ReplayGain), then...

This is good...REPLAYGAIN_TRACK_GAIN=-2.0 dBREPLAYGAIN_TRACK_PEAK=1.0000REPLAYGAIN_ALBUM_GAIN=-1.0 dBREPLAYGAIN_ALBUM_PEAK=1.0000REPLAYGAIN_ALGORITHM = EBU R128REPLAYGAIN_CONVERT_TAG_VALUES_BACK_TO_THAT_ALGORITHM = -5 dB(might need to think of a better name for that tag )

The idea is that existing players should work as they always have, while new players have the option of doing something different.

If you write track and album tags to a new reference level, but only mention that new reference level in a new tag which existing players ignore, you prevent all existing players from using those ReplayGain tags to match loudness. This is a bad thing.

It is fine to use a new calculation method with a new reference loudness, but the values must be converted to the original reference loudness before being written to ReplayGain tags. That way, loudness matching will work on all ReplayGain compatible players across all ReplayGain tagged files.

I believe much of the confusion is because loudness metering and loudness normalization scheme are confounded. These are two separate dimensions but are NOT presented in an orthogonal way. A system should clearly indicate which method was used for measuring loudness (loudness metering) and which gain adjustment scheme was used for loudness normalization (leveling).

After a forum exchange with Peter Belkner (author of R128GAIN) and reading the standards, this is my -tentative- understanding of loudness metering and normalization.

Pbelkner's decision to write incompatible data has been criticized numerous times. It's like the guy doesn't even understand the problem of his decision. I could support use of REPLAYGAIN_ALGORITHM tag to let users and software know what tool generated the numbers but I see no reason to store any other data. Reference level must be 89 dB SPL as stated in the specs. If user wishes to use other target level he flips a switch in his player (switch being for example preamp slider, could be a dropdown menu to select R128 or ATSC or anything).I recall original ReplayGain spec suggested storing the algorithm too and perhaps even the fact that user had manually altered the numbers. Perhaps manual adjustment could be identified by storing something like REPLAYGAIN_ALGORITHM=manual.

I believe much of the confusion is because loudness metering and loudness normalization scheme are confounded. These are two separate dimensions but are NOT presented in an orthogonal way. A system should clearly indicate which method was used for measuring loudness (loudness metering) and which gain adjustment scheme was used for loudness normalization (leveling).

Yes. Both ReplayGain and EBU R128 do both very clearly though.

A choice must be made in tagging: do you store the measured loudness, or the gain change required to hit a reference loudness.

Initially the first option seems simple and attractive. However it's not, for two reasons...1) Imagine you could create a perfect algorithm that perfectly told you how loud something sounded to a human listener. You might then assume that, to reach a given reference level, you must change the volume by x dB (x being the difference between the measured loudness and the reference level). You might assume that, but you would not be quite right. If you raise the volume by 10dB, the loudness might increase by 11dB. It sounds nonsense, but look at the equal loudness curves - as things get louder, the bass and treble gets disproportionately more audible compared to the midrange. Therefore, if you want to loudness match with complete accuracy, it's no good storing how loud something is - it can only be completely accurate if you store how much gain is required to meet a given reference level.2) Far more simply, the player just wants to know what gain change to apply, so you might as well just store that.

Hence ReplayGain, not ReplayLevel (which is was called for about a week at the very start!)

Pbelkner's decision to write incompatible data has been criticized numerous times. It's like the guy doesn't even understand the problem of his decision.

I decided to stop reading that thread a long time ago because otherwise I would get annoyed every time.

QUOTE

I could support use of REPLAYGAIN_ALGORITHM tag to let users and software know what tool generated the numbers but I see no reason to store any other data. Reference level must be 89 dB SPL as stated in the specs.

Yes, it must - but it is fine (even useful) to store how the conversion from A.N.Other Algorithm to ReplayGain reference level was performed.

QUOTE

If user wishes to use other target level he flips a switch in his player (switch being for example preamp slider, could be a dropdown menu to select R128 or ATSC or anything).

That's quite a good idea. With normal ReplayGain tags, using different "reference levels" in the player is entirely equivalent to different pre-amp settings. That's always been in ReplayGain from day one. It might confuse people to add labels though. It would be easy enough to write a table for "power users".

QUOTE

I recall original ReplayGain spec suggested storing the algorithm too and perhaps even the fact that user had manually altered the numbers. Perhaps manual adjustment could be identified by storing something like REPLAYGAIN_ALGORITHM=manual.

@pbelkner: When you designed and implemented your application, you did so wanting to apply the R128 standard to the files. Since the R128 standard did not have support in most players, you opted to use the replaygain tags (and the support of players for this standard) to obtain the desired results.

You have to understand that in doing so, you are making incompatible tags (in the sense of different metrics), similarly to what Microsoft did with HTML, or OpenXML documents.

As such, it is undesiderable for ReplayGain that such files become popular, especially if legal distribution of files with those tags become a reality.

The idea prompted by Pat_ about being the responsibility of the *player* to determine which reference level the users wants (by means of a setting) is much more interesting than creating tags that have different reference levels, because then, it is impossible to have files scanned with different tools, and players cannot guarantee that the tracks played have the desired loudness.

In the end, the question is about what happens in the long run. Personal files can be whatever the user wants, and you implemented R128gain in a way that gave user control on what it ends being written in the file. The problem is when this is no longer "for personal use".

About your comment of foobar2000 and libebur, I don't have enough knowledge of libebur's API, but foobar2000 is doing what it is expected to do: generate replaygain compatible tags. Of course it won't generate the same values than the replaygain algorithm, but it won't be off 5dBs in average.

It was not my intention to stir things up. I wanted to make a positive contribution. I am but a simple user of file based music looking for ways to enjoy playback of my collection with more or less the same perceived loudness. So what about returning to the basics of the whole discussion? What are the requirements that are to be satisfied by whatever proposed solution?

I believe these are the requirements (expressed as User Stories):

As a listener ...

[US-01] As a listener of file based music I want my music player software to adjust the playback volume of music files from different albums so that I experience approximately the same perceived loudness regardless of the recorded volume of the music files.[US-02] As a listener of file based music I want to to be able to check whether the calculated gain adjustment across the collection of music files was done using the same or different method of loudness normalization so that -if necessary- I can re-run a loudness normalization to obtain adjustment gains compatible for experiencing equal perceived loudness.

As a Music Player Software ...

[US-03] As a music player software I want only the calculated Album and Track gain adjustment values so that I am not dependent of different loudness normalization methods and reference levels used for determining the playback gain adjustment.[US-04] As a music player software I want to re-use the existing four REPLAYGAIN_... meta- data tags for reading the gain adjustment across tracks and albums so that I can support the classic RG-1 loudness normalization method (backward compatibility).[US-04] As a music player software I may choose to process additional meta-data indicating peak values or loudness range so that I can present the user with options whether or not and how the playback volume is to be limited to prevent clipping.[US-05] As music player software I may choose to check whether the calculated gain adjustment across the collection of music files was done using the same or different loudness normalization method so that I can give a warning to the user that gain adjustment values may be incompatible for experiencing equal perceived loudness.

This would - in my opinion - lead naturally to the following solution design principles:[P1] The existing four REPLAYGAIN_xxxx tags are re-used and contain the calculated values for gain adjustment by a player. [P2] At least one additional meta-data tag is required to indicate the loudness normalization method that was used for calculating these values. Optionally an extra tag may be added to hold the calculated Loudness Range

This additional meta-data tag could be the following:REPLAYGAIN_Loudness_Normalization_Profilewith the following list of values:

[US-01] As a listener of file based music I want my music player software to adjust the playback volume of music files from different albums so that I experience approximately the same perceived loudness regardless of the recorded volume of the music files.[US-02] As a listener of file based music I want to to be able to check whether the calculated gain adjustment across the collection of music files was done using the same or different method of loudness normalization so that -if necessary- I can re-run a loudness normalization to obtain adjustment gains compatible for experiencing equal perceived loudness.

As a Music Player Software ...

[US-03] As a music player software I want only the calculated Album and Track gain adjustment values so that I am not dependent of different loudness normalization methods and reference levels used for determining the playback gain adjustment.[US-04] As a music player software I want to re-use the existing four REPLAYGAIN_... meta- data tags for reading the gain adjustment across tracks and albums so that I can support the classic RG-1 loudness normalization method (backward compatibility).[US-04] As a music player software I may choose to process additional meta-data indicating peak values or loudness range so that I can present the user with options whether or not and how the playback volume is to be limited to prevent clipping.[US-05] As music player software I may choose to check whether the calculated gain adjustment across the collection of music files was done using the same or different loudness normalization method so that I can give a warning to the user that gain adjustment values may be incompatible for experiencing equal perceived loudness.

This would - in my opinion - lead naturally to the following solution design principles:[P1] The existing four REPLAYGAIN_xxxx tags are re-used and contain the calculated values for gain adjustment by a player. [P2] At least one additional meta-data tag is required to indicate the loudness normalization method that was used for calculating these values. Optionally an extra tag may be added to hold the calculated Loudness Range

This additional meta-data tag could be the following:REPLAYGAIN_Loudness_Normalization_Profilewith the following list of values:

EBU-R128 (ITU-BS-1770-2 metering@-23 LUFS)

RG-1 (2001 spec metering@-89 dBFS)

RG-2 (ITU-BS-1770-2 metering@-18 LUFS/dBFS)

ATSC-A/85 (ITU-BS-1770 metering@-24 LUFS)

Note: when <empty> this would default to "RG-1" profile.

No Pat, I've already explained exactly why that won't work.

The only reason you think you absolutely need US-02 is because you've defined a way of tagging where different loudness calculations can't co-exist on existing players. If you use the solution I proposed where they can work together, then US-02 becomes a nice-to-have feature for advanced users, not (as in your suggestion) a required feature that turns loudness matching into a nightmare for everyone. Exactly the same is true for US-05.

If you write ReplayGain tags, you must write the gain required to match the reference level defined in the ReplayGain "standard". You can calculate it however you like, but you have to convert it to maintain the same target loudness before you write the tag. You can't rely on the player to do the conversion. The way you deliver your US-03 is by doing exactly what I've said. What you have said makes it impossible!

You are free to write an additional tag to state what conversion has been applied, and even what method was used for the loudness calculation. Players are free to use these in any sensible way.

If there is an easily backwards-compatible way of creating a "version 2" of something, it is foolish to instead choose the non-backwards compatible way.

So, if loudness normalization in a player or tool would be done using EBU-R128 (ITU-1770-2 loudness metering@-23LUFS), then these values SHOULD NOT be written the the "REPLAYGAIN_" properties. Only values calculated using RG-standard en RG2-standard may be written into those fields. In a sense, the four meta-data "REPLAYGAIN_..." are considered 'proprietary'. Hence the discussion about R128GAIN, where the "REPLAYGAIN_" tags are used to store LU values, not values adhering to the 89 dB reference (RG and RG2).

The reference level is calibrated to pink noise with an RMS level that is 14 dB below a full-scale sinusoid which is intended to be played back at 89 dBSPL. This is nowhere near the same thing as -89 dBFS which has no reference to playback volume.

The reference level is calibrated to pink noise with an RMS level that is 14 dB below a full-scale sinusoid which is intended to be played back at 89 dBSPL. This is nowhere near the same thing as -89 dBFS which has no reference to playback volume.

Hopefully I got the details right.

You're right. My mistake. The reference level is 89 dB SPL (sound pressure level). This would corresponds to -14 dBFS (full scale) of headroom. Is now corrected in the post above. Thx

The only reason you think you absolutely need US-02 is because you've defined a way of tagging where different loudness calculations can't co-exist on existing players. If you use the solution I proposed where they can work together, then US-02 becomes a nice-to-have feature for advanced users, not (as in your suggestion) a required feature that turns loudness matching into a nightmare for everyone. Exactly the same is true for US-05.

I did understand US-2 and US-5 with a different meaning than you do. I agree with the main idea that tag values are to be based on the same reference level, but if we understand US-2 and US-5 as identifying the method, I could understand that a user could want to apply RG2 (rg tags+r128 algo), over previous RG1 (rg tags +rg algo).

About playback support of different reference levels, maybe it could be as easy as identifying several pre-gain values with textual descriptions (i.e. -6 as ATSC, -5 as BS-1770, 0 as Replaygain and the rest just as it's gain value).

I could understand that a user could want to apply RG2 (rg tags+r128 algo), over previous RG1 (rg tags +rg algo).

Exactly. This is what prompted my entry in this forum.Given the principle that REPLAYGAIN_ tags may only be used to hold values calculated using the RG or RG2 method, there can be no real discomfort in listening experience as the levels are both set around that 89 dB target. But obviously the gains calculated with RG and RG2 will be different, not much, but different. As far as I understand it, RG2 will produce a normalization which is more on par with subjective loudness experience than RG.

Can I personally live without determining files normalized using RG or RG2 ? Of course I can. As soon as MusicBee (my music player of choice) switches from RG to RG2, I will simply re-run loudness normalization on all files.

What is learned from this discussion is that the issue is about the use or re-use of replaygain tags. Is it to store only values compliant to the RG and RG2 profile. Or can the existing replaygain tags be re-used for holding values calculated with other profiles? Clearly the answer proposed here is: only RG and RG2 profiles because otherwise there is loudness normalization anarchy. That's clear. That's fine for me. ;)

Cheers

p.s.The ReplayGain 2.0 spec page indicates "under construction"; why not explicitly state the RG(2)-exclusive use principle and publish the spec? Then it is clear for everyone (and potential developers of tools).

Just to be 100% clear: you can use ReplayGain tags to store something calculated by any reasonable method, as long as the target level matches the original ReplayGain proposal. It is helpful (I suggested it ten years ago) to also store which method was used, but not essential.