Bugzilla – Bug 700
SlimServer truncates ID3 tag info when headers include repalygain info
Last modified: 2011-03-16 04:18:43 UTC
BEHAVIOR: I have a large library of mp3 files with ID3 v2.3 tags and replaygain <http://replaygain.org> info, generated by either mp3gain or foobar2000, in the tag. When I add these files to the SlimServer database, SlimServer truncates each ID3 tag field to only the first character. Hence, I get playlist items like: "H from I by B" instead of "Hired Gun from I Against I by Bad Brains". If I strip the replaygain info from the file, Slimserver can read the ID3 tag and everything is fine except, of course, for the lost replaygain data. EXPECTED: SlimServer should ignore the replaygain frame and properly report the track data from the ID3v2 tag. REPRODUCIBLE: This behavior is reproducible (always) on the latest nightlies. I can post an example file (or at least the relevant bytes) if that would be helpful.
I use mp3 files with id3 v2.3 tags processed by mp3gain extensively and I don't see these problems. I don't use foobar2000 though. What settings are you using for mp3gain? I apply the gain directly to the mp3 frames and have the undo information appended to the mp3 in an apev2 tag.
I should clarify. Instead of applying the gain adjustment to the mp3 data, foobar2k stores the gain offset (for track and/or album gain adj.) as a value in the ID3v2 tag. I don't expect SlimServer to read this foreign info (tho' it would be nice to have some sort of normalization feature in the server or SB) but to gracefully ignore it. I had used an older version of mp3gain without the undo storage option and had subsequently rewritten the metadata with foobar2k thereby borking the ID3v2 info. for SlimServer anyway...
Can you attach a sample file that exhibits this behavior?
Created attachment 214 [details] example mp3 file w/replaygain data written in ID3v2 tag Example file demonstrating behavior described in bug report.
Kelsey - I just checked in a fix for this to CPAN/MP3/Info.pm It will be in the nightly build for the 15th, or you can download and replace Info.pm directly from: http://cvs.slimdevices.com/*checkout*/slim/server/CPAN/MP3/Info.pm?rev=1.13 Please set this bug to fixed if the patch works for you. Thanks.
This has been fixed as part of all the UTF-8 work.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.