I was looking at the source to replaygain from the mppdec-1.93j tarball. It seems relatively easy to add support for other codecs, and I would volunteer to add FLAC, but I have a couple of questions:
1. Does it belong there? i.e. replaygain seems to be part of the MPC distro instead of in a package of its own.
2. Who maintains the replaygain code?
3. Will they take a patch for FLAC support? I'll try to do minimal damage.
4. FLAC will use Vorbis comments to store the ReplayGain tags, but has a standard for the names/formats of the tags been agreed upon yet for Vorbis? Or is it more like "vorbisgain is the de facto standard but it may change later"?
Josh
Full Version: Replaygain + Flac
You may also find it worthwhile to poke around the Vorbisgain source.
Maintaining Replaygain support in a given format seems to be pretty much left up to whoever decides to implement it for a given format. Everyone's gone their own way, with mp3gain, vorbisgain, and mpc's replaygain.
As far as the tag names go, vorbisgain is the de facto standard for now. You could just as easily use a metadata block if you wanted to, although tags are probably easier for a human to edit at a later date. There was talk, once upon a time, of adding replaygain support into libvorbis itself, but that seems to have disappeared for the time being.
Maintaining Replaygain support in a given format seems to be pretty much left up to whoever decides to implement it for a given format. Everyone's gone their own way, with mp3gain, vorbisgain, and mpc's replaygain.
As far as the tag names go, vorbisgain is the de facto standard for now. You could just as easily use a metadata block if you wanted to, although tags are probably easier for a human to edit at a later date. There was talk, once upon a time, of adding replaygain support into libvorbis itself, but that seems to have disappeared for the time being.
I'm a FLAC/Vorbis user, and I like the idea of being able to use similar tools to manage the two formats, so I'm all for "poking around" the Vorbisgain source and seeing if it can easily be adopted for FLAC. When I chose FLAC and Vorbis for my primary codecs, I envisioned and hoped for these two open source codecs to complement each other and build off each other's successes. Regardless of how it's coded, I'd really like a "gain" tool for FLAC.
The problem is not replaygain calculation and writing tags to the file, but decoder support: The current FLAC decoder for Winamp and the built-in decoding options are very minimal (
and ReplayGain support probably would be quite a big codecgange.
I think such a step should be planned with the FLAC developer(s) before, though it's a good idea.
dev0
and ReplayGain support probably would be quite a big codecgange.I think such a step should be planned with the FLAC developer(s) before, though it's a good idea.
dev0
QUOTE
I think such a step should be planned with the FLAC developer(s) before, though it's a good idea.
You know that jcoalson IS the .flac developer...
How does winamp3 do it? are they doing wavgain on the fly to the wav output? It works pretty well on .flac and .shn, but the settings are never saved, and rescanning is a drag...
I can't code worth a damn, but I am happy to test ;-)
dev0: Well, Josh IS the man behind FLAC. Nobody better to do it.
It certainly would be wonderful to have Replaygain in FLAC though. So would an updated DirectShow codec, but hey, beggars can't be choosers.
It certainly would be wonderful to have Replaygain in FLAC though. So would an updated DirectShow codec, but hey, beggars can't be choosers.
I would love to see this developed. I've used MPC for 3/4 of a year and love how its replaygain function works. Putting it into FLAC would be a great feature in my opinion.
Ooooops...
I was just not reading (the MPC thingie confused me) carefully! Sorry... didn't mean to offend anybody.
dev0
I was just not reading (the MPC thingie confused me) carefully! Sorry... didn't mean to offend anybody.
dev0
excuse me, but: isn't clipping not a problem with lossless formats? so replaygain would just be used to equalize volume across different cds?
QUOTE(Ardax @ Oct 22 2002 - 08:31 PM)
You may also find it worthwhile to poke around the Vorbisgain source.
Maintaining Replaygain support in a given format seems to be pretty much left up to whoever decides to implement it for a given format. Everyone's gone their own way, with mp3gain, vorbisgain, and mpc's replaygain.
As far as the tag names go, vorbisgain is the de facto standard for now. You could just as easily use a metadata block if you wanted to, although tags are probably easier for a human to edit at a later date. There was talk, once upon a time, of adding replaygain support into libvorbis itself, but that seems to have disappeared for the time being.
Maintaining Replaygain support in a given format seems to be pretty much left up to whoever decides to implement it for a given format. Everyone's gone their own way, with mp3gain, vorbisgain, and mpc's replaygain.
As far as the tag names go, vorbisgain is the de facto standard for now. You could just as easily use a metadata block if you wanted to, although tags are probably easier for a human to edit at a later date. There was talk, once upon a time, of adding replaygain support into libvorbis itself, but that seems to have disappeared for the time being.
Yeah, I found the vorbisgain source a little later. There are slight differences between that and replaygain in gain_analysis.c; vorbisgain has some comment that Frank did some improvements, but replaygain has #ifdef KLEMM in places with differences, so I'm not sure which is newer/better.
The main difference I see is that vorbisgain is doing the decoding in-process, so to add FLAC to that one requires a little bit more work on the make system too, whereas replaygain decodes with an external binary. I guess FLAC could go in either one, or I could just copy one and integrate it in the FLAC distro.
As for use in the players, that's step 2. Although it seems to me this is another thing that does not belong in an input plugin; the values ought to be able to be passed out to the dsp section of the player.
Josh
QUOTE(jcoalson @ Oct 23 2002 - 07:43 AM)
Yeah, I found the vorbisgain source a little later.
VorbisGain has been written so that adding other codecs should be fairly simple (e.g., most Vorbis specific stuff is located in vorbis.c).
QUOTE
There are slight differences between that and replaygain in gain_analysis.c; vorbisgain has some comment that Frank did some improvements, but replaygain has #ifdef KLEMM in places with differences, so I'm not sure which is newer/better.
The MPC replaygain uses slightly different algorithms to calculate the gain, yes. VorbisGain uses the "original" ReplayGain algorithm (as implemented by Glen Sawyer), while Frank Klemm has done some tweaks on it. I don't know which is best, if any.
QUOTE
The main difference I see is that vorbisgain is doing the decoding in-process, so to add FLAC to that one requires a little bit more work on the make system too, whereas replaygain decodes with an external binary. I guess FLAC could go in either one, or I could just copy one and integrate it in the FLAC distro.
I doubt that. I think Frank "gets away" with callling an external binary (isn't that less portable, btw?) because MPC already stores peak values in the mpc file (AFAIK). In Vorbis that isn't the case, which would mean you'd loose the peaks by using an external binary (unless it supports an unclipped floating point file format).
Correction: it uses "--scale 0.5"...
No OggDec supports that, AFAIK.QUOTE
As for use in the players, that's step 2. Although it seems to me this is another thing that does not belong in an input plugin; the values ought to be able to be passed out to the dsp section of the player.
Winamp3 supports this, AFAIK. Not Winamp2.
QUOTE(Lear @ Oct 23 2002 - 07:38 AM)
Correction: it uses "--scale 0.5"... No OggDec supports that, AFAIK.
No OggDec supports that, AFAIK.Shouldn't be too difficult to add, right? Would be nice if we could use the same replaygain tool for all files.
QUOTE(jcoalson @ Oct 23 2002 - 03:09 AM)
4. FLAC will use Vorbis comments to store the ReplayGain tags, but has a standard for the names/formats of the tags been agreed upon yet for Vorbis? Or is it more like "vorbisgain is the de facto standard but it may change later"?
Vorbisgain is the de facto standard but is not officially approved, meaning that it may change later.
Interesting thread guys, thanks.
In MCF we had a replaygain field preserved in the codec headers, should we better use vorbisgain now ?
Will try to send the MCF devs here ... again i maybe miss the point completely ...
In MCF we had a replaygain field preserved in the codec headers, should we better use vorbisgain now ?
Will try to send the MCF devs here ... again i maybe miss the point completely ...
QUOTE(jcoalson @ Oct 23 2002 - 01:43 AM)
The main difference I see is that vorbisgain is doing the decoding in-process, so to add FLAC to that one requires a little bit more work on the make system too, whereas replaygain decodes with an external binary. I guess FLAC could go in either one, or I could just copy one and integrate it in the FLAC distro.
As for use in the players, that's step 2. Although it seems to me this is another thing that does not belong in an input plugin; the values ought to be able to be passed out to the dsp section of the player.
As for use in the players, that's step 2. Although it seems to me this is another thing that does not belong in an input plugin; the values ought to be able to be passed out to the dsp section of the player.
All the current replaygain tools require that you have an already encoded file to analyze. (Everyone say "DUH Ardax!"
) If you're thinking about making replaygain part of the codec, why not integrate the analysis into the encoder directly? This way we don't have to encode the file, then turn around and decode the whole thing again to analyze it.On top of that, if the user wasn't thinking far enough ahead by adding in a padding block, the flacgain tool (whatever it becomes) would have to re-write the entire file, since metadata must be before the audio stream (unless I've read your spec incorrectly).
I realize that this is probably more work than hacking one of the current tools, but it would fall under the "very cool" category.
@ChristianHJW: If you've already got a spot carved out for replaygain in the headers, you should be fine. That's probably the best place for it, as long as the user can still manually tune the gain values if desired. I'm guessing that vorbisgain used comment tags to get a working something now rather than later. (Lear?)
QUOTE(Ardax @ Oct 23 2002 - 02:35 PM)
QUOTE(jcoalson @ Oct 23 2002 - 01:43 AM)
The main difference I see is that vorbisgain is doing the decoding in-process, so to add FLAC to that one requires a little bit more work on the make system too, whereas replaygain decodes with an external binary. I guess FLAC could go in either one, or I could just copy one and integrate it in the FLAC distro.
All the current replaygain tools require that you have an already encoded file to analyze. (Everyone say "DUH Ardax!"
) If you're thinking about making replaygain part of the codec, why not integrate the analysis into the encoder directly? This way we don't have to encode the file, then turn around and decode the whole thing again to analyze it.On top of that, if the user wasn't thinking far enough ahead by adding in a padding block, the flacgain tool (whatever it becomes) would have to re-write the entire file, since metadata must be before the audio stream (unless I've read your spec incorrectly).
I realize that this is probably more work than hacking one of the current tools, but it would fall under the "very cool" category.
The only thing that complicates that is that to calculate the album gain you have to pass over all the data for the album before you can tag each track, so it's not totally 'one pass'. This will make the command-line interface a little more complicated. So that is step "1.5" I guess.
You are right about the padding. In the next release I will probably have the encoder always add a small amount of padding by default unless you say '--no-padding'.
Josh
OT : Excuse this thread if it seems like complete garbage but i am sure i have had FAR to much JD 
Anyways, you could incorporate the analysis for the Radio gain in the encoder and have the tag written as default for each individual track, if a user wasn't interested, they wouldn't even notice it.
Then for the Album gain, could you not add a command line switch which could analyse the list of input files and from their' "Radio" Replay Gain tags, calculate the Album gain???
I know Vorbis Stores four tags for Replay gain, is this due to clipping in Lossy formats? if so would only two tags be needed for lossless Replaygain???
Anyways,
I am great to see new ideas being implemented for FLAC, i added a padding field to all my several hudred FLAC's when Josh metioned Tagging, then it came! Now replaygain is in the works, this is great, i have no need for lossy compression anymore, gain changes throughout FLAC files in my library are a killer!!!
Again i appolagise if this is a waste of time, maybe more on the ball tommorrow!
Kristian
Anyways, you could incorporate the analysis for the Radio gain in the encoder and have the tag written as default for each individual track, if a user wasn't interested, they wouldn't even notice it.
Then for the Album gain, could you not add a command line switch which could analyse the list of input files and from their' "Radio" Replay Gain tags, calculate the Album gain???
I know Vorbis Stores four tags for Replay gain, is this due to clipping in Lossy formats? if so would only two tags be needed for lossless Replaygain???
Anyways,
I am great to see new ideas being implemented for FLAC, i added a padding field to all my several hudred FLAC's when Josh metioned Tagging, then it came! Now replaygain is in the works, this is great, i have no need for lossy compression anymore, gain changes throughout FLAC files in my library are a killer!!!
Again i appolagise if this is a waste of time, maybe more on the ball tommorrow!
Kristian
QUOTE(kritip @ Oct 23 2002 - 04:54 PM)
Anyways, you could incorporate the analysis for the Radio gain in the encoder and have the tag written as default for each individual track, if a user wasn't interested, they wouldn't even notice it.
Then for the Album gain, could you not add a command line switch which could analyse the list of input files and from their' "Radio" Replay Gain tags, calculate the Album gain???
Then for the Album gain, could you not add a command line switch which could analyse the list of input files and from their' "Radio" Replay Gain tags, calculate the Album gain???
I don't think you can calculate the album gain just from the tracks gains.
Josh
QUOTE(jcoalson @ Oct 23 2002 - 04:32 PM)
The only thing that complicates that is that to calculate the album gain you have to pass over all the data for the album before you can tag each track, so it's not totally 'one pass'. This will make the command-line interface a little more complicated. So that is step "1.5" I guess.
You are right about the padding. In the next release I will probably have the encoder always add a small amount of padding by default unless you say '--no-padding'.
You are right about the padding. In the next release I will probably have the encoder always add a small amount of padding by default unless you say '--no-padding'.
Ah, yes. I forgot all about album gain. That does complicate things.
Having padding by default is definitely a good idea.
All that's left is to buy a big enough hard drive for me to flac my entire CD collection.
QUOTE(Ardax @ Oct 23 2002 - 08:17 PM)
All that's left is to buy a big enough hard drive for me to flac my entire CD collection.
Make sure to save the cue sheet when you rip, the be-all end-all to audio CD archiving will be in flac 1.0.5
Josh
QUOTE(jcoalson @ Oct 23 2002 - 10:51 PM)
QUOTE(Ardax @ Oct 23 2002 - 08:17 PM)
All that's left is to buy a big enough hard drive for me to flac my entire CD collection. :D
Make sure to save the cue sheet when you rip, the be-all end-all to audio CD archiving will be in flac 1.0.5
Josh
Yay!
QUOTE(Infrared Archer @ Oct 26 2002 - 10:10 AM)
QUOTE(jcoalson @ Oct 23 2002 - 10:51 PM)
QUOTE(Ardax @ Oct 23 2002 - 08:17 PM)
All that's left is to buy a big enough hard drive for me to flac my entire CD collection.
Make sure to save the cue sheet when you rip, the be-all end-all to audio CD archiving will be in flac 1.0.5
Josh
Yay!
Does all this indented quoting make anyone else dizzy?
Seriously thought, I've never seen a point to bin/cue rather than just ripping to seperate tracks. Perhaps someone who does it can explain to me why they do it.
QUOTE(jcoalson @ Oct 24 2002 - 01:50 AM)
I don't think you can calculate the album gain just from the tracks gains.
Why not? Isn't the gainvalues a measure of how loud the file is? Shouldn-t it be possible to average it over a couple of files then? Something along the line of: AlbumGain = 10 * log_10 ( Sum( TrackLength[N] * 10^(TrackGain[N] / 10) ) / Sum(TrackLength[N]) )
To answer my own question: No, it does not seem to work. When I tried it on one album my average of the trackgains was -5.56 dB and the real albumgain was -5.93 dB.
Guess it must be this part that makes it impossible to average (from replaygain.org):
"3. Statistical Processing
Where the average energy level of a signal varies with time, the louder moments contribute most to our perception of overall loudness. For example, in human speech, over half the time is silence, but this does not affect the perceived loudness of the talker at all! For this reason, the RMS values are sorted into numerical order, and the value 5% down the list is chosen to represent the overall perceived loudness of the signal."
(by the way, why is the replaygain that is displayed when calculating it 1 mB less than what is written in the file?)
Guess it must be this part that makes it impossible to average (from replaygain.org):
"3. Statistical Processing
Where the average energy level of a signal varies with time, the louder moments contribute most to our perception of overall loudness. For example, in human speech, over half the time is silence, but this does not affect the perceived loudness of the talker at all! For this reason, the RMS values are sorted into numerical order, and the value 5% down the list is chosen to represent the overall perceived loudness of the signal."
(by the way, why is the replaygain that is displayed when calculating it 1 mB less than what is written in the file?)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.