GNOME Bugzilla – Bug 533689
Cannot import files with album art embedded in ID3 tags
Last modified: 2011-01-21 11:26:52 UTC
When I attempt to import music files with album art embedded in their ID3 tags, banshee gives the import error that "MPEG audio header not found". This is obviously not the case, as opening the music files with a hex editor clearly shows the ID3 tag header is present, along with the image data in it. Furthermore, the music can be played if Media>Open Location is used (in which case the album art still does not show). The album art was added using EasyTag. There should be no problem due to different versions of ID3v2 tags, as both Gstreamer and EasyTag now use ID3v2.4. This bug is especially irritating as currently Banshee 1.0 has no MusicBrainz and album art fetching support, nor does it automatically add cover.jpg in the album folders anymore. Removing the pictures from the ID3 tags allows the music to be imported.
I can confirm this bug. The same happens to me with the new Banshee 1.0. It's definetely not a gstreamer bug the files never have caused any problems with any other gstreamer based players, after stumbling on this bug I checked them and I could see that all the problematic files had cover art in the ID3 tags.
*** Bug 538662 has been marked as a duplicate of this bug. ***
This also happens to me as well. Running Banshee 1.0 on Ubuntu 8.04. Rhythmbox imports these files with no trouble, and they also play fine in Totem.
I can also confirm this, except that in my case it only affects some files having an album art in their tags not all of them.
(In reply to comment #4) > I can also confirm this, except that in my case it only affects some files > having an album art in their tags not all of them. > Yeah, the problem is that does not import the file because it doesn't find the mpeg header, this is because this header is after the ID3 tags. I am pretty sure banshee is looking for the mpeg header in the first N kb, if the size of the image is larger than N, then, banshee can not find the mpeg tag. Which is the N number, I don't know :-P In your case, that can import them, is because the image is small enough
I'm not sure about the image size being a factor. I did the following test : I took a mp3 file without album art and added an 2.5 MB image with easytag (big enough, I think). The file imported and played without problem in banshee (with taglib-sharp 2.0.3.0). If anyone has a non working file they are willing/able to distribute, could you please attach it to the bug or post a link to it ? Please also indicate which version of taglig-sharp you're using. Updating version, as per above comments.
*** Bug 544849 has been marked as a duplicate of this bug. ***
Here is an MP3 file with a cover art that cannot be imported to Banshee. http://www.uploading.com/files/7UZ8VSPM/song_bug533689.tar.gz.html
Thanks for the file. I've been able to reproduce the bug with it. Here's the full exception : [Error 21:21:37.771] /home/lorentz/Music/Red Hot Chili Peppers - Snow ((Hey Oh)) (copy).mp3 - MPEG audio header not found. [Debug 21:21:37.774] Full import exception: TagLib.CorruptFileException: MPEG audio header not found. at TagLib.Mpeg.AudioFile.ReadStart (Int64 start, ReadStyle propertiesStyle) [0x00028] in /var/tmp/portage/dev-dotnet/taglib-sharp-2.0.3.0/work/taglib-sharp-2.0.3.0/src/TagLib/Mpeg/AudioFile.cs:236 at TagLib.NonContainer.File.Read (ReadStyle propertiesStyle) [0x0003c] in /var/tmp/portage/dev-dotnet/taglib-sharp-2.0.3.0/work/taglib-sharp-2.0.3.0/src/TagLib/NonContainer/File.cs:379 at TagLib.NonContainer.File..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00007] in /var/tmp/portage/dev-dotnet/taglib-sharp-2.0.3.0/work/taglib-sharp-2.0.3.0/src/TagLib/NonContainer/File.cs:140 at TagLib.Mpeg.AudioFile..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] in /var/tmp/portage/dev-dotnet/taglib-sharp-2.0.3.0/work/taglib-sharp-2.0.3.0/src/TagLib/Mpeg/AudioFile.cs:126 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[]) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003f] in /var/tmp/portage/dev-lang/mono-1.9.1/work/mono-1.9.1/mcs/class/corlib/System.Reflection/MonoMethod.cs:404 If I just open and save it with EasyTag, the file imports fine.
I ran into this issue with Banshee 1.2.0 as well. Using EasyTAG 2.1.4, I had to re-write tags to use UTF-16 in order for banshee to pick up the MPEG headers. UTF-8 seems to be inconsistently recognized. When I convert many to UTF-16, the import works. If I change the same files back to UTF-8, the files fail to import. Even with UTF-16, problems still exist. The tags in Banshee would sometimes show up with non-English characters. Interestingly, I was also able to get files to import by changing the EasyTAG options to save id3 tags as v2.3 instead of v2.4.
I created a Shell-script with simple GUI for Banshee Playlists. Please look here unter "MP3-CD" further down in the article: http://wiki.ubuntuusers.de/Brasero (German) Or download directly: http://media.ubuntuusers.de/wiki/attachments/31/42/burnmp3
Oh Sry, wrong bug.. was meant for this: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/117032 Sorry!
I have only run into this bug when I upgraded from Hardy 8.04 to Intrepid 8.10. Banshee worked fine in Hardy, but stopped in Intrepid, giving me a MPEG Audio Header not found error. Upgrading Banshee did not help either.
Does anyone have a file exhibiting this condition? I think the problem is in taglib-sharp, scanning for the mpeg audio header it only scans the first 16k. All my files seem ok, but if I could get ahold of a bad one, I can probably sort this out. The file that user "--" posted isn't availiable from that url any longer.
This sounds like a bug I fixed on 2008-12-15 in TagLib#. Closing this as a dupe of it since it's already closed. Please re-open if you still see this problem with Banshee 1.4.2 *** This bug has been marked as a duplicate of 564182 ***
Well.. interestingly... I just retagged my entire collection with EasyTag to v2.4 UTF-8, and Banshee read them all completely. I was actually surprised, since this had not worked before. All character encoding seems to work as expected. I'm using the latest unstable version of Banshee from the Ubuntu PPA, 1.4.2. I'll check on Hardy once I get to that machine, but Intrepid works fine.
This is sort of effecting me too, it imports them fine, but does not bring cover art with it. And I can change the cover art to be a custom cover art, but it does not embed that new cover art into the file. Is this considered a new bug? I could not find it in the list so I am considering filing a new one.