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: Replaygain + Flac (Read 6877 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Replaygain + Flac

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

Replaygain + Flac

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

Replaygain + Flac

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

Replaygain + Flac

Reply #3 –
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
"To understand me, you'll have to swallow a world." Or maybe your words.

Replaygain + Flac

Reply #4 –
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 ;-)

Replaygain + Flac

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

Replaygain + Flac

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

Replaygain + Flac

Reply #7 –
Ooooops...

I was just not reading (the MPC thingie confused me) carefully! Sorry... didn't mean to offend anybody.
dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

Replaygain + Flac

Reply #8 –
excuse me, but: isn't clipping not a problem with lossless formats?  so replaygain would just be used to equalize volume across different cds?

Replaygain + Flac

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

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

Replaygain + Flac

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

Replaygain + Flac

Reply #11 –
Quote
Correction: it uses "--scale 0.5"...  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.

Replaygain + Flac

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

Replaygain + Flac

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

Replaygain + Flac

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

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

Replaygain + Flac

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

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

Replaygain + Flac

Reply #16 –
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

Replaygain + Flac

Reply #17 –
Quote
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 don't think you can calculate the album gain just from the tracks gains.

Josh

Replaygain + Flac

Reply #18 –
Quote
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'.

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. 

Replaygain + Flac

Reply #19 –
Quote
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

Replaygain + Flac

Reply #20 –
Quote
Quote
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! 
"I have learned a lesson from the lessons I have learned"

Replaygain + Flac

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

Replaygain + Flac

Reply #22 –
Quote
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]) )
 

Replaygain + Flac

Reply #23 –
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?)