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: Bug in Album ReplayGain calculations in FLAC? (Read 9485 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bug in Album ReplayGain calculations in FLAC?

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

Bug in Album ReplayGain calculations in FLAC?

Reply #1
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?

Bug in Album ReplayGain calculations in FLAC?

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

Bug in Album ReplayGain calculations in FLAC?

Reply #3
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...

Bug in Album ReplayGain calculations in FLAC?

Reply #4
Allright, here are the results:

Code: [Select]
Track	WAV		 MP3	->WAV		FLAC	->WAV
1 -0.40 -0.46 -0.39 -0.40 -0.40
2 0.78 0.77 0.77 0.78 0.78
3 -0.13 -0.10 -0.14 -0.13 -0.13
4 -0.60 -0.62 -0.60 -0.60 -0.60
5 5.79 5.80 5.79 5.79 5.79
6 -1.61 -1.66 -1.61 -1.61 -1.61
7 0.08 0.22 0.08 0.08 0.08
8 -0.34 -0.39 -0.35 -0.34 -0.34
9 -2.82 -2.79 -2.82 -2.83 -2.82
10 2.41 2.40 2.41 2.41 2.41
11 0.49 0.44 0.49 0.49 0.49
12 1.86 1.89 1.86 1.86 1.86
13 -1.26 -1.27 -1.26 -1.26 -1.26
14 -2.88 -2.90 -2.88 -2.89 -2.88
15 -3.39 -3.38 -3.40 [color=red]-3.39[/color] -3.39
---------
Album -1.75 -1.74 -1.75 [b]-3.39[/b] -1.75

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...

Bug in Album ReplayGain calculations in FLAC?

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

Bug in Album ReplayGain calculations in FLAC?

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

Bug in Album ReplayGain calculations in FLAC?

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


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

Bug in Album ReplayGain calculations in FLAC?

Reply #8
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%-%track%.flac"...  and I store each album in a separate directory.

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

Bug in Album ReplayGain calculations in FLAC?

Reply #9
@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 :

Code: [Select]
glob -c metaflac --add-replay-gain *.flac

Bug in Album ReplayGain calculations in FLAC?

Reply #10
That works for me!

Thanks for the tip!

Daniel

Bug in Album ReplayGain calculations in FLAC?

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


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:

Code: [Select]
dir /b *.flac > filelist.txt
metaflac --add-replay-gain @filelist.txt


I believe this would be a universal solution.

Or, what about

Code: [Select]
dir /b *.flac | metaflac --add-replay-gain


Anyway, food for thought...
Daniel

Bug in Album ReplayGain calculations in FLAC?

Reply #12

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


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


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