id3 tag version differences result in confusing behaviour (e.g. rhythmbox, easytag)

Bug #120538 reported by wvengen
44
This bug affects 6 people
Affects Status Importance Assigned to Milestone
easytag (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Different programs on the desktop use different id3 versions when writing. This results in confusing behaviour: when Rhythmbox writes an id3 tag, EasyTag doesn't show any id3 information (anymore).

How to reproduce:
- Add/change id3 of an mp3 file in EasyTag
- Import the mp3 into Rhythmbox
- Change the tag in Rhythmbox
- Open the mp3 in EasyTag
- Result: it seems as if the id3 tag has disappeared from the file, all fields are empty

  $ file test.mp3 $ file test.mp3
  test.mp3: Audio file with ID3 version 23.0 tag, MP3 encoding
  $ id3v2 -l test.mp3
  id3v2 tag info for test.mp3:
  TIT2 (Title/songname/content description): test
  TPE1 (Lead performer(s)/Soloist(s)): test
  TALB (Album/Movie/Show title): test
  $ # import into Rhythmbox, rename title to "test2"
  $ file test.mp3
  test.mp3: Audio file with ID3 version 24.0 tag, MP3 encoding
  $ id3v2 -l test.mp3
  test.mp3: No ID3 tag

Rhythmbox writes id3 tags as version 2.4, while EasyTag only recognizes versions up to and including 2.3. Console program id3v2 shows similar behaviour; both use libid3, while Rhythmbox uses a gstreamer plugin. This is quite confusing for a user just wanting to maintaining his/her music collection.
The same problem can occur when the mp3 is used on embedded mp3 players that only support id3 up to a certain version.

Possible solutions would be:
1) Keep the id3 version if an existing tag is found; a user can always use a tagging-management tool to convert explicitely
2) A desktop-wide preference for preferred id3 version, and implement it for id3 tag writing in officially supported Ubuntu applications
3) Define an id3 tag version used for writing that is consistent across the desktop (or only officially supported Ubuntu applications), at least fixed per release

Revision history for this message
wvengen (wvengen) wrote :

Oh, bug #64905 is an example of this problem.

Changed in easytag:
status: New → Confirmed
Revision history for this message
Daria Michalska (sansana) wrote :

Another problem with this bug is Rhythmbox (and nautilus' audio properties) not being able to display correct idtags . Ex Falso and Windows applications show the correct ones.

Also, it is not possible to change the tags in Rhythmbox so they can be properly displayed.

There's an example of this bug in an attachment.

Revision history for this message
Matthew McGowan (mmcg069) wrote :

I dunno if this is related... but rhythmbox also seems to have a propensity for mangling my id3 tags... its really frustrating and i have spent nearly two hours fixing them up today. I like the functionality of rb but this has driven me to not use rb until this issue is resolved. Could a setting be included for rb to leave the library alone... ?

Revision history for this message
dulles (dulles) wrote :

Confirmed. I used RB to sort out all my music and I was completely befuddled when gtkpod didn't load half my stuff into my iPod. It appears as though anything with id3v2.4 was not recognized by gtkpod and therefore not loaded. Highly confusing.

Symptoms: editing an id3 in RB causes id3ed to declare that the mp3 has no tag whatsoever; at least some id3 tags written via RB appear to be tagless to EasyTag; at least some id3 tags writen via RB appear tagless to Gtkpod.

Hate to do it, but I'm also dropping RB until this gets resolved.

Revision history for this message
Fabian Zeindl (fabian-xover) wrote :
Revision history for this message
Jerome COUDERC (easytag) wrote :

Which version of EasyTAG is concerned for this problem? Because since version 2.1.1, the ID3v2.4 tags were supported.

Revision history for this message
wvengen (wvengen) wrote :

Ok, tested again, now with EasyTAG 2.1.2 (don't know what version of previous test was).
  $ ffmpeg -i /usr/share/sounds/warning.wav warning.mp3
  (...)
  $ file warning.mp3
  warning.mp3: MPEG ADTS, layer III, v1, 64 kBits, 44.1 kHz, Monaural
  $ id3v2 -2 -t 'foo' warning.mp3
  $ file warning.mp3
  warning.mp3: Audio file with ID3 version 23.0 tag, MP3 encoding
  $ easytag warning.mp3
  <shows title as 'foo'>
  <set title to 'test' and save>
  $ file warning.mp3
  warning.mp3: Audio file with ID3 version 24.0 tag, MP3 encoding
  $ id3v2 -l warning.mp3
  warning.mp3: No ID3 tag
now open in rhythmbox, it shows title='test', genre=artist=album=year='Unknown'.
edit title in rhythmbox and set it to 'test2'.
  $ file warning.mp3
  warning.mp3: Audio file with ID3 version 24.0 tag, MP3 encoding
  $ strings warning.mp3 | grep test
  test2TPE1
  $ easytag warning.mp3
  <look and see that title='test2', artist=album=genre='Unknown'
EasyTAG settings are id3v2 version 2.4 and id3v1 disabled. So it seems that EasyTAG handles 2.4 tags now, which makes it work with Rhythmbox. This is great progress.

But still, interoperability between EasyTAG and Rhythmbox was just an example. There still are tools that don't work well together. I haven't found a command-line tool that works with id3v2.4 tags in default Ubuntu repositories. And what to do with mp3 players supporting only up to a certain id3 version? Maybe relying on id3v1 for that would be ok (as mentioned in bug 180110 comment 2), provided that all (important) applications also write id3v1 if it is present / turned on. Rhythmbox appears to remove any id3v1 tag present (just tested with RB 0.11.2-0ubuntu4 and gstreamer0.10-plugins-good 0.10.6-0ubuntu4; I don't know enough about gstreamer plugins to known which do the work: id3demux, taglib, xingheader or mad -- try `gst-inspect | grep mux | grep -i 'id3\|mp3'`).

Revision history for this message
Jouko Holopainen (jouko-holopainen) wrote :

I filed, perhaps incorrectly, a variation of this problem in bug 5465.

There is problem with interoperability of Rhythmbox and SanDIsk Sansa player. The player *seems* (not 100% sure) to have problems with v2.x tags. There is no way (that I know) to force Rhythmbox to use v1.x tags.

Revision history for this message
Emmanuel Rodriguez (potyl) wrote :

I also have a SanDisk Sansa player and find out that the MP3s created by sound-juicer can't be displayed in the MP3 player.

I wrote a Gstreamer plugin that fixes this issue. With this plugin the MP3s have ID3 v2.3 tags which is more portable.

The source code of the plugin (tar.gz) an the instructions can be downloaded from Gstreamer's Bugzilla page:

http://bugzilla.gnome.org/show_bug.cgi?id=459226

Revision history for this message
Alvaro Kuolas (kuolas) wrote :

Apparently Rhtythmbox in Hardy doesn't save information to it's TAG... it's save it under {home}/.gnome2/rhythmbox/rhythmdb.xml

So, why not in the properd tag?
This is annoying.

Revision history for this message
wvengen (wvengen) wrote :

@Alvaro: you could check the permissions on your file and directory. Also the type of tag can be important, not all tag types may support writing. If you need further help in resolving this issue, please visit http://www.ubuntuforums.org/ or https://answers.launchpad.net/ . If it appears to be a bug, you can file a new bug report. Thanks.

Revision history for this message
Alvaro Kuolas (kuolas) wrote :

Thank you for your help. I've searching and I believe it's fixed in Intrepid.

I just found that it's a nightmare ID3v1 AND ID3v2. A very useful feature/plugin for Rhythmbox should be able to deal with this. On the bug tracking system gnome-bugs #459226 that problem it's being addressed.

Revision history for this message
Emmanuel Rodriguez (potyl) wrote :

If you find the plugin in GStreamer's Bugzilla #459226 helpful (http://bugzilla.gnome.org/show_bug.cgi?id=459226) please leave a comment in the upstream bugzilla. If more people find the plugin useful and show interest then the bug could be closed faster and the plugin could end up ip the next release of GStreamer. Also feel free to request new features through the Bugzilla channel. As soon as I get some spare time I will try to add them.

Revision history for this message
Ken Foskey (foskey) wrote :

I have a music file that I have modified in easytag to reflect the correct artist. It still shows incorrectly in Rhythmbox. I grep for the incorrect spelling of the artist name and the MP3 matches still.

I can provide a copy of the file in question as a sample. I can only forward sample by email directly to a developer. Ta Ken

Revision history for this message
Kiri (kiri) wrote :

easytag 2.1.6 has newer id3 tag support. I'm marking it as fixed. If it is not fixed, please re-open.

Changed in easytag (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Alfredo Pironti (alfredo.pironti) wrote :

I confirm the bug is still present with easytag 2.1.6. A file edited with easytag shows the previous id3 tags in rhythmbox.

Any procedure to delete/reset *all* tags in a file, and to write them just once?

Changed in easytag (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Kip Warner (kip) wrote :

Just in case anyone's curious, upstream EasyTAG allegedly now supports ID3v2.4.

Revision history for this message
matus71@gmail.com (matus71) wrote :

please remove easytag-aac which you probably have, and install "easytag". Easytag-aac do not allow you to change id3v2.4 to id3v2.3. When you install easytag, go to preferences and change tag to id3v2.3, your media hardware should have no more problems with reading cover of album.

Revision history for this message
pooky2483 (ponchorat1968) wrote :

I am also having problems with EasyTAG 2.1.7 and Banshee 2.6 (2.6.0)
I write the info to the mp3's, such as Genre - Audiobook to, say 22 mp3's and then in Banshee theres no time on some of them and where 'Audiobook' is it just has 'Audio' but usually its just blank also the other fields are tagged as 'Unknown'.

I also have this problem with ripped cd's using Asunder 2.1 as the info comes up as Unknown in Banshee where I could have spent some time entering the correct tag info. But in EasyTAG the info is there.

To me, this sounds like a problem with Banshee...

I have also commented on the existing bug report for Banshee...
https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/159178

Revision history for this message
John Baptist (jepst79) wrote :

This bug persists in Ubuntu 14.04.

Please, someone fix it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.