GNOME Bugzilla – Bug 564182
TagLib# fails to find MPEG header in amazon mp3 file
Last modified: 2009-02-12 01:30:52 UTC
Got an amazon mp3 file from a user, it imports into Banshee 1.4.1, but TagLib# isn't able to parse it (but nautilus/RB see all the metadata just fine): [Warn 15:17:23.417] Caught an exception - MPEG audio header not found. (in `taglib-sharp') at TagLib.Mpeg.AudioFile.ReadStart (Int64 start, ReadStyle propertiesStyle) [0x00000] at TagLib.NonContainer.File.Read (ReadStyle propertiesStyle) [0x00000] at TagLib.NonContainer.File..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] at TagLib.Mpeg.AudioFile..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000]
Assigning to dekushrub - he said he'd look into it.
OK, I got the unit tests running with MonoDevelop (2.0 alpha 2) and on the command line with "make test" from either the root or tests/ directories. svn up for the fixes
Created attachment 124471 [details] Example of modifying the tests to (temporarily) test the amazon mp3 If you copy the file to tests/samples/amazon.mp3 and apply this patch, then run make test, you'll get the same error we're getting in Banshee.
OK, I found the problem, in Mpeg/AudioFile.cs line 232, it expects to find the header in the first 16 bytes of the file, but it's not there.
Ok, but it should really be starting it's 16KB search after the header, so it seems the value of where-does-the-header end is wrong.
OK, there are two bugs - one, it's failing to parse the id3v2 tag after detecting it's header, throws this exception (that was smothered with catch {}): TagLib.CorruptFileException: Frame data incomplete. at TagLib.Id3v2.Frame.FieldData (TagLib.ByteVector frameData, Int32 offset, Byte version) [0x00125] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Frame.cs:510 at TagLib.Id3v2.Frame.SetData (TagLib.ByteVector data, Int32 offset, Byte version, Boolean readHeader) [0x00014] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Frame.cs:378 at TagLib.Id3v2.AttachedPictureFrame..ctor (TagLib.ByteVector data, Int32 offset, FrameHeader header, Byte version) [0x00012] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Frames/AttachedPictureFrame.cs:235 at TagLib.Id3v2.FrameFactory.CreateFrame (TagLib.ByteVector data, System.Int32& offset, Byte version) [0x00264] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/FrameFactory.cs:215 at TagLib.Id3v2.Tag.Parse (TagLib.ByteVector data) [0x000bc] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Tag.cs:872 at TagLib.Id3v2.Tag.Read (TagLib.File file, Int64 position) [0x00066] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Tag.cs:809 at TagLib.Id3v2.Tag..ctor (TagLib.File file, Int64 position) [0x00058] in /home/gabe/Projects/taglib-sharp/src/TagLib/Id3v2/Tag.cs:146 The other bug was properly setting the start position counter if there was an exception like the above, so that when we then went to look for the actual MPEG header we were first scanning the (in this case) 60KB of id3v2 data (including coverart). Fixing the second one is trivial, but it'd be nice to log these exceptions maybe, and then actually fix the first bug so we can actually get the metadata out.
I just wanted to report that even after editing the metadata in Banshee, Banshee has problems reporting songs that experience this bug to Last.FM
Created attachment 124766 [details] [review] Patch that fixes the bug This patch fixes the bug for me - all my other music still imports fine, and now so does the song you sent me.
how do you patch that file to the banshee installation?
It's a patch against taglib# - so check taglib-sharp out from svn (it's in mono svn) and apply that from the top directory with patch -p0 < my_patch.file
I committed this, marking as fixed.
*** Bug 533689 has been marked as a duplicate of this bug. ***