GNOME Bugzilla – Bug 568129
ID3 v2.3 Tag Support
Last modified: 2020-03-17 08:15:49 UTC
I just ripped a CD into MP3 tracks and imported the tracks into my Sansa Fuze MP3 Player. The MP3's played just fine but the Fuze did NOT recognize or read the MP3 ID3 Tags. After doing some digging, I discovered that Banshee (presumably via gstreamer) created MP3 ID3 Version 2.4 tags. Most MP3 Players on the market do NOT read version 2.4 tags. (Sanze Fuze, Sony Walkman MP3 players etc). But most can read version 2.3 ID3 tags. I suspect the real problem is with gstreamer. See http://bugzilla.gnome.org/show_bug.cgi?id=459226 In the post above, you can build another gstreamer plugin (called id3v23mux) that will create mp3 ID3 version 2.3 tags. In Sound Juicer or Rhythmbox, you cam modify the gstreamer pipeline for the MP3 encoding and replace the default tag generator, id3v2mux, with a tag generator that creates version 2.3 tags, id3v23mux. I tried it and it works great. Unlike Rhythmbox, Banshee does not let you modify the gstreamer pipeline. Pity. It would be great if the developers would consider adding support for version 2.3 ID3 tags. That way many more MP3 players would work properly with Banshee. Most of the code to do so is in the post above in the gnome bugzilla. Rob P.S. Tested Banshee 1.4.1 on Ubuntu Hardy Heron with a Sanza Fuze MP3 Player.
I think you can work around this by turning "Write metadata to file" on in Preferences, selecting any tracks you ripped in Banshee, right click them -> Edit then hit Save. I think taglib# will then write out the id3v2.3 tags, but I may be wrong.
Thanks for the tip. I just tried it, I right clicked on a track and clicked "Edit Track Info". I even changed some metadata like the track name. And clicked SAVE. But the track looks like it still has a version 2.4 tag. An easy way to check is using the "file" command in terminal: e.g. file '/home/ubuntu/Music/Nirvana/MTV Unplugged in New York/02. Come as You Are.mp3' Response: /home/ubuntu/Music/Nirvana/MTV Unplugged in New York/02. Come as You Are.mp3: Audio file with ID3 version 24.0 tag, MP3 encoding 24.0 tag means version 2.4 tag. Looks like a bug in file :-) I know one way to fix these tags. Use EasyTag. (Not easytag-aac. just the easytag package in Ubuntu). Click Settings - Preferences, Choose the "ID3 Tag Settings". Change id3v2.4 to id3v2.3. Now Easytag will save v2.3 tags. Now when you load any track with v2.4 tags and save changes, easytag will save it as a v2.3 tag. (the file command shows the track with a version 23.0 tag which is really a version 2.3 tag)
I also tried the change the Global gstreamer MP3 encoder settings using gconf-editor. It does not look like Banshee (unlike Sound Juicer) uses this global setting. Pity.
I don't know if "Most MP3 Players" is true but it seems to be true at least for most of the cheaper ones and also many popular ones like all (?) of the Sansas. I have encountered this myself because my GF has a e260 :(
I also tried loaded MP3's ripped with version 2.4 ID3 tags into my friend's Sony Walkman MP3 Player. Same problem. The Sony Walkman MP3 Player will not read the version 2.4 ID3 tags.
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
I recently bought a Philips GoGear Spark music player and got bitten by this too. Spark has support for UTF-16 and ISO-8859-1 with both id3v2.3 and id3v2.4 but not UTF-8 which is usually used with id3v2.4. I just changed all my mp3 files to UTF-16 (with musicbrainz Picard) and that way got around the problem. The real problem came up when I decided to transcode flac files to Spark with banshee. As flac specs demand that all comments inside flac container should be in utf-8, all the transcoded mp3 files now had utf-8 style tags too. After finding this bug, I got to know the gst plugin id3mux where you could specify which version of the id3 tag you wanted. I made a patch for the lame audio-profile so that it's now possible to use either id3v2mux or id3mux. With id3mux it's also possible to select if you want to include id3v1 and/or id3v2 tags and which version of id3v2 tags. While updating the audio-profile, I also found a corner-case bug at ProfileConfigurationDialog.cs. When changing visibility of a checkbox with 'enables' or 'disables' parameter, banshee crashes on: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. This is caused by the fact that on line 218 we add ".label." prefixed key for everything else than checkbox. I'll attach a patch to fix that too.
Created attachment 163473 [details] [review] Patch to enable selection of id3mux and settings for it
Created attachment 163474 [details] [review] fix the cornercase of enabling and disabling of checkbox
Hey Corec, So your id3v2 patch only fixes the bug for when ripping or transcoding mp3 files, not when they're directly transferred from the library to the device, right? I wonder if we could use Taglib# to remove the offending id3v2 version and ensure only the acceptable one is in the file, to solve the problem entirely.
(In reply to comment #10) > Hey Corec, > > So your id3v2 patch only fixes the bug for when ripping or transcoding mp3 > files, not when they're directly transferred from the library to the device, > right? > > I wonder if we could use Taglib# to remove the offending id3v2 version and > ensure only the acceptable one is in the file, to solve the problem entirely. Sorry for not replying sooner. Yeah, my id3v2 patch unfortunately only works in situations where you're transcoding or ripping stuff. If we could alter tag types before/after moving the files to a device, that would fix the problem in all cases. A quick glance to taglib# source code indicated that namespaces Taglib.id3v2 and Taglib.id3v1 don't implement File class at all. Am I to interpret this as a sign that taglib# doesn't support writing for mp3's, only reading..? If taglib# actually supports saving of id3 tags (as it probably does and I'm just misunderstanding the code), we could at least remove tag types by overriding File.RemoveTags(TagTypes). This would help when we have a device that for example doesn't support id3v2 at all.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.