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: Replay Gain tagging (Read 28323 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replay Gain tagging

The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags. I've added this description to my updated specification-in-progress.

I have unearthed some historical information describing storage in LAME tags. Can anyone comment on whether this is worthy of inclusion in the specification?

Is anyone aware of important Replay Gain coding (ad-hoc) standards for other metadata system, e.g. broadcast wave format, Vorbis comments, APE, etc.?

Replay Gain tagging

Reply #1
I have unearthed some historical information describing storage in LAME tags. Can anyone comment on whether this is worthy of inclusion in the specification?

Current spec is at mp3-tech.org. I think you could make reference to it, but you shouldn't make your spec dependent on it. Or are you asking whether we think it should be the standard for storing ReplayGain info in all MP3s?

Replay Gain tagging

Reply #2
I see a suggestion that the ID3v2 specs be ammended.

Are we seriously considering mandating how players (software and hardware) as well as applications and utilities are to read and write RG information?

Replay Gain tagging

Reply #3
The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags. I've added this description to my updated specification-in-progress.

Why not use the existing RVA2 frame? The specification is incomplete, but it is in use (at least by Quod Libet and Rockbox).

Another option is to do it Foobar2000-style, and use VorbisGain-like information in TXXX frames (also supported by Rockbox).

Quote
I have unearthed some historical information describing storage in LAME tags. Can anyone comment on whether this is worthy of inclusion in the specification?

One problem is that it doesn't include any field for album peak values.

Quote
Is anyone aware of important Replay Gain coding (ad-hoc) standards for other metadata system, e.g. broadcast wave format, Vorbis comments, APE, etc.?

Well, there's VorbisGain...  Foobar2000 also writes VorbisGain-style strings in APE tags.

Replay Gain tagging

Reply #4
I see a suggestion that the ID3v2 specs be ammended.

Are we seriously considering mandating how players (software and hardware) as well as applications and utilities are to read and write RG information?

I do see problems here and it is arguable that you would want to recommend against storing RG information directly in the audio files.

However, the first phase my project is document current Replay Gain practice. Current practice does include a de-facto update of the ID3v2 specification and reading and writing of RG information in ID3 tags.


Replay Gain tagging

Reply #5
Current spec is at mp3-tech.org. I think you could make reference to it, but you shouldn't make your spec dependent on it. Or are you asking whether we think it should be the standard for storing ReplayGain info in all MP3s?

Firstmost, I would like to know whether this method of tagging is currently in use. Is this just a placeholder or do current versions of LAME write legit RG data here? If a placeholder, is anyone aware of a tool or player that generates or uses data in this field?

Replay Gain tagging

Reply #6
Why not use the existing RVA2 frame? The specification is incomplete, but it is in use (at least by Quod Libet and Rockbox).

There is also now XRVA and the original RVAD. Can anyone shed additional light on current practice with regards to usage of these three tags? RVA2 does appear to have the same basic functionality as RG's ad-hoc RGAD tag. Information at ID3.org indicates that RVA2 supersedes RGAD. I had assumed that the purpose of these mechanisms were more for user-assigned level adjustments and not so much for automatic normalization. I assume Rockbox does not write RG information. Does Quod Libet write RG information to any of these other tags?

Another option is to do it Foobar2000-style, and use VorbisGain-like information in TXXX frames (also supported by Rockbox).

It looks like this uses Vorbis comments in different format that described in the RG proposal. But it sounds like there is enough uptake on this to mention it in the updated RG specification. Thanks for bringing this to my attention.
Quote from: VorbisGain README link=msg=0 date=
Please note that as of VorbisGain 0.30, the volume change suggestions are
stored in a new format. The following is an example on how it can look:

    REPLAYGAIN_TRACK_GAIN=-7.03 dB
    REPLAYGAIN_TRACK_PEAK=1.21822226
    REPLAYGAIN_ALBUM_GAIN=-6.37 dB
    REPLAYGAIN_ALBUM_PEAK=1.21822226

Earlier versions stored the information like this:

    RG_RADIO=-7.03 dB
    RG_PEAK=1.21822226
    RG_AUDIOPHILE=-6.37 dB


Replay Gain tagging

Reply #7
LAME writes:
bytes $A7-$AA : 32 bit floating point "Peak signal amplitude"
bytes $AB-$AC : 16 bit "Radio Replay Gain" field


IIRC in_mad plugin for winamp can use these data. Also LameTag can show them.

Replay Gain tagging

Reply #8
There is also now XRVA and the original RVAD. Can anyone shed additional light on current practice with regards to usage of these three tags? RVA2 does appear to have the same basic functionality as RG's ad-hoc RGAD tag. Information at ID3.org indicates that RVA2 supersedes RGAD. I had assumed that the purpose of these mechanisms were more for user-assigned level adjustments and not so much for automatic normalization.

RGAD doesn't include album peak, which is needed for proper clip prevention when using album gain, so it should be considered deprecated. And XRVA is the same as RVA2, just for ID3V2.3, it seems. Don't know about their usage though (at the time, Quod Libet was the only RVA2-writing application I was aware of).

Quote
I assume Rockbox does not write RG information.

Correct.

Quote
Does Quod Libet write RG information to any of these other tags?

It only writes RVA2, as I recall it (or at least did, when I last looked at it).

Replay Gain tagging

Reply #9
Quote
LAME writes:
bytes $A7-$AA : 32 bit floating point "Peak signal amplitude"
bytes $AB-$AC : 16 bit "Radio Replay Gain" field

Just to clarify: it also writes an ID3 tag (using "TXXX" instead of the recommended "RGAD", though) with more precise values, including peaks.

Replay Gain tagging

Reply #10
Just to clarify: it also writes an ID3 tag (using "TXXX" instead of the recommended "RGAD", though)

LAME itself?
I cannot see any TXXX tag in an MP3 file.

Replay Gain tagging

Reply #11
Egg on my face. I was looking at a file that I had ReplayGain-scanned with foobar2000. LAME doesn't write ReplayGain info to ID3 tags.

 

Replay Gain tagging

Reply #13
I added some details about MP3Gain/AACGain's APE tagging to the ReplayGain article in the HA wiki. Hopefully it makes sense.



Please consider adding dBpoweramp (Spoon's) applications to this list.  I believe that Spoon's applications largely follow the Foobar conventions, but Spoon will need to verify that (he seems active here so he's easy to reach).

If you want to consider tagging applications and their fit with Replaygain, Mp3tag can take any of the four tags used by Foobar and others (REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, REPLAYGAIN_ALBUM_PEAK), and can also translate one of the gain tags into iTune's Sound Check format to replace iTune's proprietary method for similar purposes.

With respect to clipping prevention and previous comments regarding Replaygain and its impact on different music (pop versus classical, for example), perhaps there could be some consideration in the revised spec for the degree to which a certain gain value could result in clipping triggers, and thus dynamic range reduction.  In other words, perhaps there could be some calculation of the degree of dynamic range compression that results from the calculated Replaygain value, so that people can determine how much gain adjustment they want.  Some people may want gain adjustment but only to the point of no dynamic compression, some may want gain adjustment regardless of any dynamic compression, and some may tolerate some dynamic range compression for some gain normalization.  Perhaps Replaygain could calculate different gain adjustments based on different inputs relating to the considerations above, and people could either select one, or have Replaygain write different tags for each so that people can chose which to apply later or dynamically chose based on their specific playlist when playback occurs.

I wish I could be more articulate.  Part of my inability to explain further results from exactly what is meant by "clipping".  I typically think of clipping as reaching the limits of an unknown amplifier working with unknown speakers, but clipping could also mean exceeding the largest value that can be represented digitally.  The latter will likely also trigger the former, but the former will not necessarily be a result of the latter.  The impact of the actual playback volume further complicates this for me, but hopefully not for others.

Thanks to all for your efforts in this area.

Replay Gain tagging

Reply #14
Are we seriously considering mandating how players (software and hardware) as well as applications and utilities are to read and write RG information?


In my experience having a very clear and concise explanation of how a vendor can implement a feature significantly increases the odds that they will implement it the standard way rather then just inventing their own 'solution'.


Replay Gain tagging

Reply #16
To which "first post" are you referring?

Replay Gain tagging

Reply #17
Some people may want gain adjustment but only to the point of no dynamic compression, some may want gain adjustment regardless of any dynamic compression, and some may tolerate some dynamic range compression for some gain normalization.  Perhaps Replaygain could calculate different gain adjustments based on different inputs relating to the considerations above, and people could either select one, or have Replaygain write different tags for each so that people can chose which to apply later or dynamically chose based on their specific playlist when playback occurs.

I wish I could be more articulate.  Part of my inability to explain further results from exactly what is meant by "clipping".  I typically think of clipping as reaching the limits of an unknown amplifier working with unknown speakers, but clipping could also mean exceeding the largest value that can be represented digitally.  The latter will likely also trigger the former, but the former will not necessarily be a result of the latter.  The impact of the actual playback volume further complicates this for me, but hopefully not for others.

In the Player requirements section two clipping prevention options are discussed. In the event of anticipated clipping, the limiter method reduces dynamic range and the alternative reduces playback level. Many players do not implement these two choices, instead the have a single checkbox for "clipping prevention" which implements the latter (reduced playback level).

The clipping we're talking about is in the digital domain. If a signal that already reaches digital full-scale is further amplified, it will be clipped by the limits of the maximum digital representation for signals. We don't worry about clipping in the analog domain, We assume that any analog equipment attached to this digital system will clip at or above the level of this maximum digital signal.

Replay Gain tagging

Reply #18
To which "first post" are you referring?

Your first post, but specifically the information that was put into the site, though you already made your intentions clear and I have no further complaints.

We assume that any analog equipment attached to this digital system will clip at or above the level of this maximum digital signal.

For proper conversion inter-sample overs aren't supposed to clip either.

Replay Gain tagging

Reply #19
The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags. I've added this description to my updated specification-in-progress.


There seem to be many competing standards for ReplayGain data in ID3. My impression is that the RVA2 tag from ID3 2.4 is currently most widely supported by player software (Mpg123, Quodlibet, Rockbox, Audacious, Songbird). If you are updating the ReplayGain specification, I think a reference to the RVA2 tag would be appropriate.

RGAD, as described in the original ReplayGain document, is not actually part of any ID3 specification.

It worries me that there are many different, incompatible standards for storing Replay Gain data. Can we not agree on just one standard (at least for MP3)?

I think it should be possible to improve Replay Gain compatibility if we just pick one of the existing standards and push software projects to add support for that standard. I actually tried to do this some time ago by adding support for RVA2 to Mp3gain and to Audacious. After that I lost momentum.


Replay Gain tagging

Reply #21
How so, exactly?

Why? In order to establish Replay Gain as a standard, compatible feature.
How? By emailing them a patch they can apply to the software. (I'm not interested in closed-source software.)

Replay Gain tagging

Reply #22
I'm not interested in closed-source software.

I find this attitude quite lamentable, but maybe it will "push" closed-source software into compliance.  What do I know anyway?

In order to establish Replay Gain as a standard, compatible feature.

I think we should demonstrate how the current implementation has actually resulted in problems for end-users (please respect my intentional usage of past-tense) before deciding to impose arbitrary limits on a standard that that undoubtedly will cause problems for end-users.

Replay Gain tagging

Reply #23
push software projects to add support for that standard.

How so, exactly?


I think updating the replagain page as people are doing here is a great first step.  The current page sort of implies that the standard is immature ("I haven't tried this myself..."), which is not the case.  Replaygain has been around for a long time and is quite widely used.  We should remove that language, and add a list of applications verified to work with the replaygain standard using the tags we specified.  Basically say, "do this and you'll work with the following applications . . . and implemented by the following vendors ...".

Basically we need to let people from outside of the community know that RG is actually a stable, useful standard that can be easily implemented at no cost while bringing substantial utility to their users and customers.

Replay Gain tagging

Reply #24
As was implied early on, I think it is important that all the current implementations be grandfathered so long as they don't hinder current interoperability.  If there are problems with the current implementations and interoperability then they should be identified and addressed.