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 28795 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replay Gain tagging

Reply #25 –
Quote from: greynol on
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.

Replay Gain tagging

Reply #26 –
Quote from: saratoga on
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.

Quote from: greynol on
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.

Replay Gain tagging

Reply #27 –
From 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.

Replay Gain tagging

Reply #28 –
Quote from: singlethread on
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.

Replay Gain tagging

Reply #30 –
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.

Quote from: singlethread on
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.

Quote from: singlethread on
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.

Quote from: singlethread on
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.

Replay Gain tagging

Reply #31 –
Quote from: Notat on
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.)

Quote from: Notat on
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.

Replay Gain tagging

Reply #32 –
Quote from: greynol on
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.

Quote from: greynol on
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.

Replay Gain tagging

Reply #33 –
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. 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?

Replay Gain tagging

Reply #34 –
Quote from: Notat on
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?

Quote from: Notat on
Is there anything missing?

Has it been mentioned that foobar2000 writes RG information to CUE Sheets?
 

Replay Gain tagging

Reply #35 –
Quote from: singlethread on
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.

Quote from: singlethread on
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.

Quote from: singlethread on
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.

Quote from: singlethread on
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.

Replay Gain tagging

Reply #36 –
Quote from: Notat on
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?

Quote from: greynol on
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.

Quote from: greynol on
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?

Quote from: greynol on
Quote from: singlethread on
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.

Quote from: greynol on
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.

Replay Gain tagging

Reply #37 –
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!

Quote from: singlethread on
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.

Quote from: singlethread on
Whatever its original intend, mp3gain can currently perform RG analysis without modifying the MP3 bitstream.
I understand.  (BTW and not to nitpick, it's intent not intend; I'm just saying this because it is a common mistake non-native English speakers make).

Quote from: singlethread on
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).

Replay Gain tagging

Reply #39 –
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. If we want to continue the popularity discussion, participants are going to have to start coughing up actual data on it.

Replay Gain tagging

Reply #40 –
Quote from: greynol on
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.

Replay Gain tagging

Reply #41 –
Very popular players like foobar2000 and Winamp use TXXX.
XMplay, MediaMnkey, J.River - ?

Replay Gain tagging

Reply #42 –
Quote from: Notat on
Can you point me to details on this?


An example of CUE file with RG info:

Code: [Select]
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

Replay Gain tagging

Reply #43 –
Quote from: Notat on
I consider RGAD to be the frontrunner because it is the ID3 method described in the RG proposal.

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

Replay Gain tagging

Reply #44 –
Quote from: greynol on
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.

Replay Gain tagging

Reply #45 –
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.

Replay Gain tagging

Reply #46 –
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 example files created by different players and others can download the files and tell us what tags are in them.

Replay Gain tagging

Reply #47 –
A command line tool like metamp3 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.

Replay Gain tagging

Reply #48 –
Quote from: Notat on
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. 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.

Replay Gain tagging

Reply #49 –
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.
Glass half full!