The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags (http://replaygain.hydrogenaudio.org/file_format_id3v2.html). I've added this description to my updated specification-in-progress (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#ID3v2).
I have unearthed some historical information describing storage in LAME tags (http://web.archive.org/web/20021220124832/http://users.belgacom.net/gc247244/extra/tag.html). 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 (http://en.wikipedia.org/wiki/Broadcast_wave_format), Vorbis comments (http://en.wikipedia.org/wiki/Vorbis_comment), APE (http://en.wikipedia.org/wiki/APEv2_tag), etc.?
I have unearthed some historical information describing storage in LAME tags (http://web.archive.org/web/20021220124832/http://users.belgacom.net/gc247244/extra/tag.html). Can anyone comment on whether this is worthy of inclusion in the specification?
Current spec is at mp3-tech.org (http://gabriel.mp3-tech.org/mp3infotag.html). 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?
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?
The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags (http://replaygain.hydrogenaudio.org/file_format_id3v2.html). I've added this description to my updated specification-in-progress (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#ID3v2).
Why not use the existing RVA2 frame? The specification is incomplete, but it is in use (at least by Quod Libet (https://code.google.com/p/quodlibet/) and Rockbox (http://www.rockbox.org/)).
Another option is to do it Foobar2000-style, and use VorbisGain-like information in TXXX frames (also supported by Rockbox).
I have unearthed some historical information describing storage in LAME tags (http://web.archive.org/web/20021220124832/http://users.belgacom.net/gc247244/extra/tag.html). 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.
Is anyone aware of important Replay Gain coding (ad-hoc) standards for other metadata system, e.g. broadcast wave format (http://en.wikipedia.org/wiki/Broadcast_wave_format), Vorbis comments (http://en.wikipedia.org/wiki/Vorbis_comment), APE (http://en.wikipedia.org/wiki/APEv2_tag), etc.?
Well, there's VorbisGain (http://sjeng.org/vorbisgain.html)... Foobar2000 also writes VorbisGain-style strings in APE tags.
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.
Current spec is at mp3-tech.org (http://gabriel.mp3-tech.org/mp3infotag.html). 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?
Why not use the existing RVA2 frame? The specification is incomplete, but it is in use (at least by Quod Libet (https://code.google.com/p/quodlibet/) and Rockbox (http://www.rockbox.org/)).
There is also now XRVA (http://www.id3.org/Experimental_RVA2) 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 (http://www.id3.org/Replay_Gain_Adjustment) 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.
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
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.
There is also now XRVA (http://www.id3.org/Experimental_RVA2) 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 (http://www.id3.org/Replay_Gain_Adjustment) 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).
I assume Rockbox does not write RG information.
Correct.
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).
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.
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.
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.
I added some details about MP3Gain/AACGain's APE tagging to the ReplayGain article in the HA wiki (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain#MP3Gain). Hopefully it makes sense.
I added some details about MP3Gain/AACGain's APE tagging to the ReplayGain article in the HA wiki (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain#MP3Gain). 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.
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'.
I agree, though from the first post it seemed like there was going to be a push to create a new standard rather than simply documenting how it currently used.
To which "first post" are you referring?
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 (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#Clipping_Prevention) 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.
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.
The Replay Gain proposal contains a description of how to store Replay Gain data in ID3 tags (http://replaygain.hydrogenaudio.org/file_format_id3v2.html). I've added this description to my updated specification-in-progress (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#ID3v2).
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.
push software projects to add support for that standard.
How so, exactly?
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.)
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.
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.
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.
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.
Yes absolutely. I think we should list the recommended way to implement RG, and give software that does it the main way. Then list other implementations and give examples. Theres obviously no harm in acknowledging that other implementations exist, so long as you're clear what software does what.
I think we should list the recommended way to implement RG, and give software that does it the main way.
Which implies that we first define that main, recommended way.
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.
Example: I have in the past tried to use mp3gain to add ReplayGain tags to audio files, naively expecting that ReplayGain-enabled players would automatically use that information. That did not work, of course, because mp3gain created APE tags which were not supported by Quod Libet.
The current multitude of standards practically guarantees that software packages will not understand each other's ReplayGain information.
Is this an interopability problem?
Yes, if you want Replay Gain to work as a single feature accross applications.
No, if you consider volume correction as something which should be handled entirely inside a particular application, with no sharing of information between applications.
From http://mp3gain.sourceforge.net/faq.php (http://mp3gain.sourceforge.net/faq.php):
"MP3Gain stores "Analysis" and "Undo" information in special tags inside the mp3 file itself. These tags are in the APEv2 format."
MP3Gain is intended to change the volume of the mp3 data so that it will work in non-RG situations. If you also wish to use them in RG situations then scan them with an application that writes the proper tags for your player if it can't read APEv2 tags after MP3Gain has modified the data. This combined with the expectation that you've studied the software instead of just blindly applying it falls in the category of common sense.
However, mp3gain has already been covered in this discussion and its method should be included in the spec so that people can have that information handy, including those who wish to improve Quod Libet.
The point of this should be sharing information, rather than behaving like a cabal, which is precisely what I was concerned about when I first saw this discussion. I am encouraged in knowing that this was not Notat's intention but figured others will have different opinions.
Example: I have in the past tried to use mp3gain to add ReplayGain tags to audio files, naively expecting that ReplayGain-enabled players would automatically use that information. That did not work, of course, because mp3gain created APE tags which were not supported by Quod Libet.
I don't think mp3gain is even capable of implementing tag based replaygain. AFAIK it writes the undo information to APEv2 tags, NOT the replaygain value for the track. I think in this case mp3gain was doing the right thing and behaving as expected and you just misunderstood its purpose.
Mp3gain also stores the RG information. It is the "Analysis" part in the quote I have above.
First off, the immediate project under discussion here is documentation of current Replay Gain practices in specification (as opposed to proposal) format. I think improvements should also be discussed, I appreciate your comments and have an eye on producing an updated version of Replay Gain once the current version is documented. The existing implementations need to be supported going forward so documenting existing practices (however ugly they may be) is the first step.
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.
RVA2 does not feature a means of storing separate gains for album and track. It may be useful to help get Replay Gain to work on players that don't support it natively but it is not sufficient functionality for a full Replay Gain implementation.
RGAD, as described in the original ReplayGain document, is not actually part of any ID3 specification.
But it is in wide enough use that it is acknowledged by keepers of the ID3 standard. (http://www.id3.org/Replay_Gain_Adjustment)
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)?
As far as I know there is RGAD, the same data structures are used for APE and a separate format is used in Vorbis commments. Vorbis doesn't do ID3 or APE so all are apparently necessary. If I have this understanding wrong, let me know. Please bring any others you are aware of to my attention.
RVA2 does not feature a means of storing separate gains for album and track. It may be useful to help get Replay Gain to work on players that don't support it natively but it is not sufficient functionality for a full Replay Gain implementation.
Current software which supports RVA2 looks for a string "track" or "album" in the RVA2 description field (mp3gain, Quod Libet, Audacious, Mpg123). So in practice RVA2 does support a full Replay Gain implementation, although this practice is not properly documented in the ID3 standard. (The specification of RVA2 is in any case incomplete.)
As far as I know there is RGAD, the same data structures are used for APE and a separate format is used in Vorbis commments. Vorbis doesn't do ID3 or APE so all are apparently necessary. If I have this understanding wrong, let me know. Please bring any others you are aware of to my attention.
The APEv2 tags as implemented by mp3gain and Audacious do not follow the structure of the RGAD tag. Those APE tags are based on text strings, much like the Vorbis tags, while RGAD has a binary structure.
I think RVA2 absolutely deserves mentioning. When I looked into these matters, about a year ago, I found several players supporting RVA2 (mpg123, Quod Libet, Rockbox) and only one free software package with working support for RGAD (madplay, currently unmaintained).
There is also the TXXX ID3 tag, already mentioned in this thread by Lear. Apparently this tag was introduced by Foobar2000 and is now also supported by Quod Libet, Audacious and others.
However, mp3gain has already been covered in this discussion and its method should be included in the spec so that people can have that information handy, including those who wish to improve Quod Libet.
Do you think Quod Libet should be improved to understand APEv2 tags?
Maybe instead Mp3gain should be improved to write RVA2 tags (recent versions of Mp3gain actually already do that).
My point: as long as there is no recognized standard, it is impossible to tell which software needs improving and in what direction. Which leaves us with the current situation: program A and B both claim to support Replay Gain, yet they don't understand each other's tags.
The point of this should be sharing information, rather than behaving like a cabal, which is precisely what I was concerned about when I first saw this discussion. I am encouraged in knowing that this was not Notat's intention but figured others will have different opinions.
I think we could do both. Document current practice, then identify the practice which seems to have most momentum and recommend that for future implementations. And then actually implement it in existing free software.
Thanks for all the good discussion and information. Thanks for setting me straight (again).
It will be useful to document all the different formats that RG data is stored and I will do that. Singlethread makes a good point it would be even more useful if the new specification indicated the preferred method for each tagging system. It looks like the original proposal intended to define a scheme for a list of file formats (http://replaygain.hydrogenaudio.org/file_format.html). It looks like we're in a position to finish that work.
- I think RGAD needs to be the preferred method for ID3 because that's what's spelled in David Robinson's original proposal. I assume this is also the method with the most momentum but I invite comments on that assumption.
- The only other method mentioned in the original proposal is for LAME tags. This did not get momentum and only applies to MP3 files where ID3 can be used so I don't think the specification should recommend it.
- The newer REPLAYGAIN_* method should be recommended for Vorbis comment tags. The older RG_* format is incomplete.
- It sounds like there's only one encoding format in use for APEv2 and so no choice to be made there.
I believe this would give good direction for future implementations on all major tagging systems. Is there anything missing?
I think RGAD needs to be the preferred method for ID3 because that's what's spelled in David Robinson's original proposal. I assume this is also the method with the most momentum but I invite comments on that assumption.
If this means ID3v2.4 then I strongly disagree. What is wrong with the way it is currently written as TXXX? Is the fact that the text is identical to what is used in APEv2 tags and Vorbis comments a bad thing?
Is there anything missing?
Has it been mentioned that foobar2000 writes RG information to CUE Sheets?
Do you think Quod Libet should be improved to understand APEv2 tags?
If the intention is to be able to read them then yes absolutely, though I am not so sure this is such a great idea.
Maybe instead Mp3gain should be improved to write RVA2 tags (recent versions of Mp3gain actually already do that).
I am not opposed to this as an option, though I think care should be exercised around the possibility that undo information might get inadvertently removed by another application. If documenting this in the spec will help prevent it then then that's great, again I'm in favor of full disclosure of methods used in the most common applications.
Which leaves us with the current situation: program A and B both claim to support Replay Gain, yet they don't understand each other's tags.
It is my understanding that Mp3gain was never intended to implement RG as a solution for RG-aware players.
identify the practice which seems to have most momentum and recommend that for future implementations. And then actually implement it in existing free software.
If this means compatibility problems with more commonly-used software then I think this is a mistake. ATM, we're looking at a solution to a problem that doesn't seem to exist when using software as it was intended.
It is not like I haven't encountered these issues before. I have written scripts that transfer RG information between APEv2, ID3v2.3 and Lame tags, though I have not found them practical.
I think RGAD needs to be the preferred method for ID3 because that's what's spelled in David Robinson's original proposal. I assume this is also the method with the most momentum but I invite comments on that assumption.
It seems to me that RVA2 is currently most widely implemented. But I may be wrong, or there may be other reasons to prefer RGAD over RVA2. Do you have a (partial) list of software supporting RGAD?
If this means ID3v2.4 then I strongly disagree.
RGAD could in principle be used with any version if ID3v2, but has not been part of any ID3v2 specification.
RVA2 is specified in ID3v2.4, although it has been unofficially backported to ID3v2.3 in the form of the XRVA tag.
It would probably be a mistake for me to question why people are still clinging to ID3v2.3, seven years after the release of ID3v2.4.
What is wrong with the way it is currently written as TXXX?
I think there is nothing wrong with an application introducing a proprietary ID3 tag for internal use. Or would you suggest that TXXX should be the preferred, standardized method for storing ReplayGain?
Maybe instead Mp3gain should be improved to write RVA2 tags (recent versions of Mp3gain actually already do that).
I am not opposed to this as an option, though I think care should be exercised around the possibility that undo information might get inadvertently removed by another application.
I did not mean the undo information, I mean actual Replay Gain analysis, to be applied by playback software. Whatever its
original intend, mp3gain can currently perform RG analysis without modifying the MP3 bitstream.
If this means compatibility problems with more commonly-used software then I think this is a mistake.
Greynol, you seem to be concerned that standardizing Replay Gain would have adverse effects. I just don't see how that would work. How would standardization
cause new compatibility problems?
I take it that you are a satisfied user of a program that handles Replay Gain fully internally, so nothing needs to be changed for you. However I certainly see potential for dividing the role of RG analysis and RG playback between separate programs. Which requires standardization of the format used for storing RG information.
My primary concern is that new implementations will not write TXXX tags which I would wager to guess is actually the most widely used method. I am of the opinion that it should be the preferred method. I think it's presumptuous to call it proprietary. Remember, David's is a
proposed standard!
I did not mean the undo information, I mean actual Replay Gain analysis, to be applied by playback software.
That does not change my concern over other applications removing undo information.
Whatever its original intend, mp3gain can currently perform RG analysis without modifying the MP3 bitstream.
I understand. (BTW and not to nitpick, it's inten
t not intend; I'm just saying this because it is a common mistake non-native English speakers make).
It would probably be a mistake for me to question why people are still clinging to ID3v2.3, seven years after the release of ID3v2.4.
Yes, most certainly. That you seem to suspect this gives me the impression that you aren't exactly in touch with what people typically use.
Please realize that I actually have no personal stake on decisions being made regarding ID3 tagging. While I do use MP3 and RG, I scale during encoding. IOW, I don't add RG tags to my lossy files (needless to say I don't use mp3gain either).
Has it been mentioned that foobar2000 writes RG information to CUE Sheets?
Can you point me to details on this?
RGAD, RVA2, XRVA, TXXX - various people (including myself) are making uncited claims as to which is most popular. I have proposed that we document all and pick one as recommended going forward. Apart from the popularity contest, I consider RGAD to be the frontrunner because it is the ID3 method described in the RG proposal (http://replaygain.hydrogenaudio.org/file_format_id3v2.html). If we want to continue the popularity discussion, participants are going to have to start coughing up actual data on it.
If this means compatibility problems with more commonly-used software then I think this is a mistake. ATM, we're looking at a solution to a problem that doesn't seem to exist when using software as it was intended.
It is not like I haven't encountered these issues before. I have written scripts that transfer RG information between APEv2, ID3v2.3 and Lame tags, though I have not found them practical.
We should be careful not to get too bunched up about this. A RG "interoperability" option that is always available is to re-analyse the audio file. Other metadata generally cannot be regenerated in this way. RG is still quite useful and functional even if the data is not stored with the sound file. The use of metadata not necessary for players with their own database.
The standard should document the different formats RG data has been stored. This is useful for players which would like to or need to avoid analysis. The standard should recommend a preferred means of storing RG data for each tagging system. Constraining the number of different ways we do things is the reason for writing standards.
Very popular players like foobar2000 and Winamp use TXXX.
XMplay, MediaMnkey, J.River - ?
Can you point me to details on this?
An example of CUE file with RG info:
REM GENRE Electronic
REM DATE 2012
PERFORMER "Somebody"
TITLE "AlbumName"
REM REPLAYGAIN_ALBUM_GAIN -7.48 dB
REM REPLAYGAIN_ALBUM_PEAK 0.979682
FILE "test.wav" WAVE
TRACK 01 AUDIO
TITLE "intro"
REM REPLAYGAIN_TRACK_GAIN -6.54 dB
REM REPLAYGAIN_TRACK_PEAK 0.711406
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "outro"
REM REPLAYGAIN_TRACK_GAIN -7.84 dB
REM REPLAYGAIN_TRACK_PEAK 0.979682
INDEX 01 00:30:50
I consider RGAD to be the frontrunner because it is the ID3 method described in the RG proposal (http://replaygain.hydrogenaudio.org/file_format_id3v2.html).
I don't think this is sound reasoning, especially when your first concern is to document current practices. Jumping to recommendations or mandating a standard prior to getting this information is not a good idea, especially if the one that is chosen (and exactly who is choosing anyway?) is not commonly used.
Besides software players, how is RG handled in hardware and firmware such as Squeezebox, Sonos and Rockbox solutions?
How do the mp3tag filters handle RG (I'm specifically talking about those that convert RG to soundcheck)?
I don't think this is sound reasoning, especially when your first concern is to document current practices. Jumping to recommendations or mandating a standard prior to getting this information is not a good idea, especially if the one that is chosen (and exactly who is choosing anyway?) is not commonly used.
Besides software players, how is RG handled in hardware and firmware such as Squeezebox, Sonos and Rockbox solutions?
How do the mp3tag filters handle RG (I'm specifically talking about those that convert RG to soundcheck)?
I'm always looking for an easy way to make a decision. I understand that it might not be the best basis. But, as I said, if we're going to make the determination by assessing popularity of current practices, we need data, we're going to need to do some research.
lvqcl reports that WinAmp and foobar2000 use TXXX. What else do we know?
All contributions are appreciated.
I'm possibly not qualified to chip in on this but the lack of standardised replaygain tags has been a pet hate of mine for several years and I think it's great that it's being discussed. I love to see a standard agreed upon.
Something that has got to me a bit is that my music player of choice on linux, mpd, will read foobar2000 style tags on mp3s but foobar2000 is windows only. My linux tagger of choice, quod libet, will read foobar2000 style tags but doesn't write them, giving a slightly paradoxical situation. I'd love propper aac replaygain compatibility too but that's another issue.
As for what would be the best choice for a standard I really can't say, although I suspect a degree of pragmatism is likely to be necessary if widespread adoption is the goal.
It sounds like you're well qualified to help us figure out which ID3 tags are generated and read by which players. If you don't have the tools to inspect the tags, you can upload (http://www.hydrogenaudio.org/forums/index.php?showforum=35) example files created by different players and others can download the files and tell us what tags are in them.
A command line tool like metamp3 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=49751&view=findpost&p=445436) will list every tag in an mp3 file, e.g. metamp3 *.mp3 lists all tags in matching mp3 files (you may also use the --info argument to list the lametag contents and bitrate distributions).
dBpoweramp also uses those specific TXXX tags. I say standardize on this, as TXXX tags works on both ID3v2.3 and ID3v2.4.
A happy new year to you all.
RGAD, RVA2, XRVA, TXXX - various people (including myself) are making uncited claims as to which is most popular. I have proposed that we document all and pick one as recommended going forward. Apart from the popularity contest, I consider RGAD to be the frontrunner because it is the ID3 method described in the RG proposal (http://replaygain.hydrogenaudio.org/file_format_id3v2.html). If we want to continue the popularity discussion, participants are going to have to start coughing up actual data on it.
But RGAD is obsolete, as it doesn't contain peak album amplitude. And if RVA2 - which
is part of the official ID3v2 standard - is to be used, the RG specification should include values for the identification string, as well as information on how the peak volume is to be interpreted.
My impression from the discussion, is that the popularly of a particular method of tagging is contingent on the number of programs/players that use it. I think that the best method is the number of users using a particular method. As an example: if one program uses method A and 10 programs use method B, but 100,000 users use that one program and 5,000 users for the other 10 combined, that method A should be the standard to start with.
But RGAD is obsolete, as it doesn't contain peak album amplitude.
This was also the case with the original Vorbis comment format. This situation prompts a question for me. What are players supposed to do with album peak amplitude information?
Clearly, peak level allows you to predict whether clipping will occur. The Replay Gain proposal suggests that you use that information to either activate a limiter or lower the gain below target. The proposal doesn't say whether you do this on an album basis or a track basis. The new specification needs to address this.
When in album playback mode, do we always want to do clipping prevention based on album peak level? If we're actually playing the album, ideally we might want to. What if we're only playing a portion of the album? What if we're playing several albums back-to-back?
Does anyone bother to switch modes dependent on how they're using the player? Is there a way players could automatically choose the best mode? I personally use album playback mode full time. I find it works well even in shuffle play - a track that was intended to be quieter in the context of an album usually sounds better played more quietly in the context of a playlist. With the way I use album playback mode, I would prefer that clipping prevention be based on track peak levels, not on album peak levels.
Example: I have in the past tried to use mp3gain to add ReplayGain tags to audio files, naively expecting that ReplayGain-enabled players would automatically use that information. That did not work, of course, because mp3gain created APE tags which were not supported by Quod Libet.
QL includes a plugin for converting APE tags to id3v2.4 tags (RVA2 in this case).
What are players supposed to do with album peak amplitude information?
I'd say not confuse users. Default: album gain => album peak, track gain => track peak. Optionally allow all combinations through advanced options.
In my opinion, the available options for tagging containers should be evaluated with respect to how well they would support future extensions of the standard. I'm thinking about more advanced, especially gated, scanning methods, which shouldn't break legacy devices, but could improve results for modern players. Any methods for which such future extension would be a PITA should be marked as deprecated. There should also not be more than one recommended method per file format. Existing files can always be rescanned and tagged. That's not nice, but in the long term the price of carrying the ballast of multiple formats forever would be higher.
I'd say not confuse users. Default: album gain => album peak, track gain => track peak. Optionally allow all combinations through advanced options.
I don't see this as a user issue. It is a player developer issue. Even advanced users should not be confronted with these design decisions. Are we concerned about confusing developers?
It seems like there's nothing preventing us from choosing the best technical solution and documenting it carefully. I should reiterate that the RG proposal doesn't include a concept of
album peak. I don't know if this was an intentional or unintentional omission. In any case, album peak is in use and the new RG specification probably needs to describe how to calculate it and what a player do with it.
Album peak is required if you want to guarantee both during album gain playback: 1. Neither clipping nor limiting 2. 100% correct relative loudness. Without album peak information you either have to sacrifice 1 or 2.
So if album peak information is available AND playback is set to album mode AND clipping prevention is set to "audiophile", then album peak should be used to lower the gain of any track relative to the whole album. In all other cases limiting and track gain should be the best trade-off, respectively track peak based scaling during "audiophile" track mode playback.
That's an accurate but incomplete summary. There are two adverse effects of using album peak: 1/ Greater chance of inconsistent loudness album to album. 2/ Unnecessary gain reductions when using album mode for general playlist or shuffle playback.
But RGAD is obsolete, as it doesn't contain peak album amplitude.
This was also the case with the original Vorbis comment format. This situation prompts a question for me. What are players supposed to do with album peak amplitude information?
Some history: Album peak was first discussed here (http://www.hydrogenaudio.org/forums/index.php?showtopic=1709). Then 2Bdecided mentioned some things to improve (http://www.hydrogenaudio.org/forums/index.php?showtopic=15445) in the ReplayGain spec, and one thing was the addition of album peak.
Does anyone bother to switch modes dependent on how they're using the player?
I do, sort of. I've set Rockbox to use track gain when shuffle is on, album gain otherwise. When shuffling, album gain can make the volume a bit low for my taste on some tracks (from loud rock albums).
I've put some more work into the Metadata and Metadata format sections (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#Metadata) of the specification draft.
I'm not yet happy with the quality of the Metadata section. I'll have another look at it later with fresh eyes. If anyone else wants to try and help me untangle this section, I'd appreciate it.
I've added a comprehensive list of audio file formats to the Metadata format section (http://wiki.hydrogenaudio.org/index.php?title=Replay_Gain_specification#Metadata_format). Each file type then supports zero one or more metadata formats. Please have a look at this list and heple ne fill in any missing information, let me know if I've missed any important formats or if any that I have included are not worthy of mention. It's a zoo out there!
Finally, I've concluded that three metadata formats are worthy of recommendation by new ReplayGain implementations: ID3v2, Vorbis comments and APEv2. Actually I'm not entirely convinced of that last one because it seems that every file format I found that supports APEv2 also supports ID3v2. So, convince me...
I have not yet composed descriptions of how ReplayGain uses the three metadata formats. I plan to document the TXXX method for IDv3. The RGAD method will be documented as historical in an appendix (http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_legacy_metadata_formats). Vorbis comments use "REPLAYGAIN_" tags. Former "RG_" tags will be in the appendix.
Finally, I've concluded that three metadata formats are worthy of recommendation by new ReplayGain implementations: ID3v2, Vorbis comments and APEv2. Actually I'm not entirely convinced of that last one because it seems that every file format I found that supports APEv2 also supports ID3v2. So, convince me...
WavPack only supports ID3v1 and APEv2 (according to wavpack.com). Does APE really support ID3v2? Rockbox only supports APEv2 for APE... So yes, APEv2 is needed.
And ID3v2 isn't used for MP4, it has its own format.
I have completed editing the metadata section of the specification. Please have a look and see if you can suggest or make any improvements.
One question I had was about various flag values (http://wiki.hydrogenaudio.org/index.php?title=APE_Tags_Header) for APEv2. I could not find any explanation for how the header and footer related tage are to be used. I'm also unsure whether to recommend that the tags be written with read-only or read-write attribute.