IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
Replay Gain tagging, ID3, LAME, Others?
Notat
post Dec 28 2010, 04:03
Post #1





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



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.?
Go to the top of the page
+Quote Post
mjb2006
post Dec 28 2010, 06:37
Post #2





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (Notat @ Dec 27 2010, 20:03) *
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?
Go to the top of the page
+Quote Post
greynol
post Dec 28 2010, 08:39
Post #3





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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?


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
Lear
post Dec 28 2010, 10:20
Post #4


VorbisGain developer


Group: Developer
Posts: 140
Joined: 10-January 02
Member No.: 973



QUOTE (Notat @ Dec 28 2010, 04:03) *
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... smile.gif Foobar2000 also writes VorbisGain-style strings in APE tags.
Go to the top of the page
+Quote Post
Notat
post Dec 28 2010, 17:11
Post #5





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (greynol @ Dec 28 2010, 00:39) *
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.

Go to the top of the page
+Quote Post
Notat
post Dec 28 2010, 17:21
Post #6





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (mjb2006 @ Dec 27 2010, 22:37) *
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?
Go to the top of the page
+Quote Post
Notat
post Dec 28 2010, 17:57
Post #7





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (Lear @ Dec 28 2010, 02:20) *
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?

QUOTE (Lear @ Dec 28 2010, 02:20) *
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 (VorbisGain README)
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

Go to the top of the page
+Quote Post
lvqcl
post Dec 28 2010, 17:58
Post #8





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
Lear
post Dec 28 2010, 21:08
Post #9


VorbisGain developer


Group: Developer
Posts: 140
Joined: 10-January 02
Member No.: 973



QUOTE (Notat @ Dec 28 2010, 17:57) *
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).
Go to the top of the page
+Quote Post
mjb2006
post Dec 28 2010, 21:36
Post #10





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (lvqcl)
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.

This post has been edited by mjb2006: Dec 28 2010, 21:46
Go to the top of the page
+Quote Post
lvqcl
post Dec 28 2010, 22:36
Post #11





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



QUOTE (mjb2006 @ Dec 28 2010, 23:36) *
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.
Go to the top of the page
+Quote Post
mjb2006
post Dec 29 2010, 07:51
Post #12





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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.
Go to the top of the page
+Quote Post
mjb2006
post Dec 29 2010, 13:28
Post #13





Group: Members
Posts: 755
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



I added some details about MP3Gain/AACGain's APE tagging to the ReplayGain article in the HA wiki. Hopefully it makes sense.
Go to the top of the page
+Quote Post
godrick
post Jan 1 2011, 23:54
Post #14





Group: Members
Posts: 305
Joined: 31-December 10
Member No.: 86948



QUOTE (mjb2006 @ Dec 29 2010, 14:28) *
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.

This post has been edited by godrick: Jan 1 2011, 23:59
Go to the top of the page
+Quote Post
saratoga
post Jan 2 2011, 06:15
Post #15





Group: Members
Posts: 4844
Joined: 2-September 02
Member No.: 3264



QUOTE (greynol @ Dec 28 2010, 02:39) *
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'.
Go to the top of the page
+Quote Post
greynol
post Jan 2 2011, 07:43
Post #16





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
Notat
post Jan 2 2011, 16:58
Post #17





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



To which "first post" are you referring?
Go to the top of the page
+Quote Post
Notat
post Jan 2 2011, 17:00
Post #18





Group: Members
Posts: 581
Joined: 17-August 09
Member No.: 72373



QUOTE (godrick @ Jan 1 2011, 15:54) *
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.
Go to the top of the page
+Quote Post
greynol
post Jan 2 2011, 17:25
Post #19





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Notat @ Jan 2 2011, 07:58) *
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.

QUOTE (Notat @ Jan 2 2011, 08:00) *
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.


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
singlethread
post Jan 2 2011, 22:35
Post #20





Group: Members
Posts: 7
Joined: 2-January 11
Member No.: 86997



QUOTE (Notat @ Dec 28 2010, 04:03) *
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.
Go to the top of the page
+Quote Post
greynol
post Jan 2 2011, 22:44
Post #21





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (singlethread @ Jan 2 2011, 13:35) *
push software projects to add support for that standard.

How so, exactly?


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
singlethread
post Jan 2 2011, 22:55
Post #22





Group: Members
Posts: 7
Joined: 2-January 11
Member No.: 86997



QUOTE (greynol @ Jan 2 2011, 22:44) *
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.)
Go to the top of the page
+Quote Post
greynol
post Jan 2 2011, 23:00
Post #23





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (singlethread @ Jan 2 2011, 13:55) *
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?

QUOTE (singlethread @ Jan 2 2011, 13:55) *
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.

This post has been edited by greynol: Jan 2 2011, 23:45


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post
saratoga
post Jan 2 2011, 23:58
Post #24





Group: Members
Posts: 4844
Joined: 2-September 02
Member No.: 3264



QUOTE (greynol @ Jan 2 2011, 16:44) *
QUOTE (singlethread @ Jan 2 2011, 13:35) *
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.
Go to the top of the page
+Quote Post
greynol
post Jan 3 2011, 00:04
Post #25





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Jan 3 2011, 00:09


--------------------
YOUR EYES CANNOT HEAR!!!!!!!!!!!
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd July 2014 - 05:14