Bugzilla – Bug 5133
Track Replaygain wrong, Album Replaygain ok
Last modified: 2008-12-18 11:12:12 UTC
Customer supplied an mp3 with the following ID3v2.4.0 tags: REPLAYGAIN_ALBUM_GAIN = -8.38 dB REPLAYGAIN_ALBUM_PEAK = 1.113862 REPLAYGAIN_TRACK_GAIN = -7.86 dB REPLAYGAIN_TRACK_PEAK = 1.113862 SlimServer reads the tags as: albums replay_gain = -8.38 albums replay_peak = 1.11386 tracks replay_gain = 36.4688 tracks replay_peak = 1.11386 Where did SlimServer get 36.4688 for track gain!?! I would suggest anyone experiencing this problem to only chose "Use Album Gain (If Present)" or "Disable Volume Adjustment" until this situation is resolved.
Created attachment 2055 [details] MP3 with ID3v2.4 replaygain tags misread by SlimServer
This mp3 file contains an RVA2 frame, set to 36.468750. We use RVA2 over the REPLAYGAIN_TRACK_GAIN tag if it's present. So I don't think this is a bug. tags are: { ALBUM => "Defrosted", ARTIST => "Gotthard", COMMENT => "Track 6\0", GENRE => "Rock", "REPLAYGAIN_ALBUM_GAIN" => "-8.38 dB", "REPLAYGAIN_ALBUM_PEAK" => "1.113862", "REPLAYGAIN_TRACK_GAIN" => "-7.86 dB", "REPLAYGAIN_TRACK_PEAK" => "1.113862", RVA2 => { ID => "", MASTER => { "REPLAYGAIN_TRACK_GAIN" => "36.468750" } }, TAGVERSION => "ID3v2.4.0", TITLE => "Hole In One", TRACKNUM => 6, YEAR => 1997, }
I did miss the RVA2 tag, good catch. However when I look at the file in iTunes the volume adjustment appears to be about -50% yet we are reporting a +36.4688. Is this a different bug? It sounds familiar.
Bug 3027 might be related.
Oops, that was bug 3207.
Andy, I was curious, how did you extract the tag data in comment #2 from the file? Thanks!
I dumped those tags from within Slim::Formats::MP3::getTag.
Oh also, iTunes doesn't support id3v2.4 so it won't know about the RVA2 tag.
I did some research about the RVA2 tag in this file. The Volume adjustment is encoded as $F048. Slimserver reads this as $48F0 (least significant byte first) and gets the positive value 36.46875 (=18672/512). According to the specification (http://www.id3.org/id3v2.4.0-structure) numbers are encoded with most significant byte first ($F048). So it's the negative number -7.85742 (=-4023/512).
Doh, I'll check that out, thanks. Bug in MP3::Info I think.
Fixed in change 12315.
Won't this need to be merged into trunk?
Of course, and it's already been merged.
I installed the nightly and it works flawlessly. Thanks!