I was experimenting with the new FLAC 1.1.3 and the ReplayGain settings and found something strange (a bug?) with the album replaygain values. I use Slimserver/Squeezebox to play my music (almost exclusively LAME encoded mp3 files) using the replaygain tags to adjust the volume (not changing the gain in the file itself, just creating the tags).

I encoded the same CD using LAME 3.97 and Mp3Gain and then using FLAC 1.1.3 (using the --replaygain flag) and noticed that the song replaygain settings were essentially the same (a difference of +/- 0.14) between the two, but the album replaygain values varied greatly (-1.74 vs -3.39).

After that I noticed that the last song on the CD had exactly a song replaygain of -3.39!
I also confirmed this with a second CD and found that apparently the album replaygain value used is the last song's value instead of the "average" of all songs. All songs in the album end up with an album replaygain value but just not the right value it seems.

(It might be that I'm not understanding how this is supposed to work with FLAC. I use EAC with the command-line flac.exe and these parameters: -5 --replay-gain -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s)

Regards,
Daniel

This sounds familiar to one issue with FLAC and ReplayGain that I've noticed. I don't know if it's related to the above, and it may be even intentional, I'm not sure. Anyway, if I encode an album ripped into one .wav file with cuesheet, include the cuesheet during encoding and let FLAC calculate ReplayGain values, each track (i.e. subsongs or whatever would be the correct term) in the resulting .flac has a TrackGain value equal to the AlbumGain value. Which is okay since I prefer AlbumGain anyway, but if AlbumGain is already calculated during encoding, why not figure out TrackGains as well? It shouldn't be very expensive in terms of time?

What you have to think is that the MP3 when decoded is different to the FLAC. The MP3 has gone through a psycho-achoustic engine altering the waveform, therefore a difference in ReplayGain value is correct.

Trying decoding the MP3 and Flac to wav, and use WavGain on each set of WAV's. See if the results are the same as the RG settings in your files.

Maybe so but then, why would all tracks have essentially the same track RG (within a few decimals) but the album RG would be way off (and exactly the same as the last song's)? Sounds fishy to me

I'll give it a try just for giggles but I suspect the MP3's calculated album gain will be closer to the WAV in this case...

Allright, here are the results:


First, we have the results for straight WAV from the CD
Then, the results for the MP3 files and decoded back to WAV
and finally, the results for the FLAC files and decoded back to WAV again. Not surprisingly the decoded FLAC files are the same as the original WAV files...

The only odd number in this lot is the album gain value for the FLAC files... hence my suspicion of a bug...

I can't reproduce this... is that -3.39 dB album gain on all the flac files?

in order for album gain to be calculated correctly, the analysis has to be done on all the files at once, e.g "flac --replay-gain track01.wav track02.wav ..."

if you are ripping tracks in eac it will call flac once for each track and the album gain will always be the same as the track gain. to get the album gain you will have to run metaflac after to redo the analysis, e.g. "metaflac --add-replay-gain track01.flac track02.flac ..."

elpres, what you are noticing is that flac does not add track gains to the embedded cuesheet. when you encode a whole album, flac sees one "track" and the track and album gain will be the same.

Josh

Josh,

First of all, thanks for the great work on FLAC! I'm mostly using LAME/MP3 right now because of storage considerations and my current sound system doesn't allow me to benefit from the potential added "fidelity" but as soon as this situation changes, I will be going to FLAC!

I use EAC which calls FLAC independently for each track encoded and strangely enough, each tack of an album seems to get an album gain of the same value as the last track (I thought this was pretty fancy programming to be able to do that!)

Thanks for everything and I'll start playing around with V1.1.4 (and METAFLAC for sure)

Regards,
Daniel

This is apparently a slimserver "bug" as it probably stores the album gain values per album and not per track as using mp3tag shows me different album gain values for each track (equal to the track gain)...

Running metaflac as you suggested, solves my problem...

Any chance metaflac could take this kind of parameters in future versions? "metaflac --add-replay-gain *.flac" instead of spelling out each file name (for the win version) as most of my file names are usually very long since they are specified as follows: "%track%-%name%.flac"... and I store each album in a separate directory.

Thanks,
Daniel

wildcard expansion is supposed to be done by the shell but the windows shell is lame:
http://www.hydrogenaudio.org/forums/index....mp;#entry466078

@dborn

Yes, i had the same problem as you when i used FLAC. It's really annoying that the Windows CLI dosen't expand wildcards by itself, except only on some of it's internal commands. To make up for this, then i used a great little tool called glob.exe, which is made by the REACT/metamp3 author Tycho. It is some C code that is listed on the web and which Tycho had improved upon and compiled into an win32 executable The only place i know to get it, is by downloading the REACT v2.0 distribution and to unpack it, to retrieve the executable. You can find the REACT v2.0 download in the Uploads forum section.

Then you just place it anywhere in your path environment variable(and also all your command-line tools) and then type : "glob -c" in front of your command-line. If you add an extra "*" when specifying wildcards(**.flac instead of *.flac), then you will enable glob.exe's recursive operation. Then to ReplayGain scan your FLAC track files which all is located in the same album, then just run this line from the albums directory :

That works for me!

Thanks for the tip!

Daniel

Yeah, I know... That's why I added (for the win version) as I use Unix at work...
There might be a "workaround" acceptable for everyone...
What about allowing filenames to be specified from a text file to be used as input, such as:



I believe this would be a universal solution.

Or, what about



Anyway, food for thought...
Daniel

Have a look at this thread for some suggestions on getting around this problem.