GNOME Bugzilla – Bug 322154
id3 tag not correctly readed.
Last modified: 2006-02-08 17:42:24 UTC
Version details: CVS id3 tags not loaded with some mp3 files. Older versions of gstreamer however load the id3 tags correctly, and so do applications that doesn't use gstreamer like xmms and mplayer. I can't publish the file because of license things, but if you guide me I will give you as many information as I can in order to identify and fix this bug. I ripped it using sound-juicer but removed and added (many times before realizing that maybe it is a bug in gst-plugings) the id3tags using easytag. This is the 0.8 branch in CVS.
Could be related to bug #306627 or bug #320767, you might want to try one of those patches. I'm having problems with rhythmbox reading and writing tags correctly after having been ripped via sound-juicer (see bug #323658).
Claudio: can you give this a try with GStreamer 0.10, with gst-plugins-good >= 0.10.1 ? There is new id3 parsing code there. Thanks.
I am using now GStreamer 0.10 from CVS (gst-plugins-good > 0.10.1) and now everything works much better, but only the genre is not loaded correctly. I get instead of "Grunge" and "Other" the genres "(6)" and "(12)" respectively.
Jan, can you have a look at this?
Claudio, is it possible that you can give me just the ID3 portions of the file, and not the copyrighted music portion? I'll need both the ID3v2 and ID3v1 tags. ID3v2 is at the start of the file, ID3v1 is at the end. You can determine the size of the ID3v2 tag with a command like: GST_DEBUG=id3demux:5 gst-launch filesrc location=/path/to/file.mp3 ! id3demux ! fakesink 2>&1 | grep ID3v2 and look for a line like: DEBUG (0x80509d8 - 0:00:00.430592000) id3demux(20778) gstid3demux.c(736):gst_id3demux_read_id3v2:<id3demux0> Read ID3v2 tag of size 149 You can then extract that many bytes from the start of the file: dd if=/path/to/file.mp3 bs=1 count=NUMBER_OF_BYTES of=/path/to/id3v2.tag Extracting the ID3v1 tag is almost as easy. ID3v1 tags are always 128 bytes and must always be at the end of the file. So, you want to compute the starting byte as OFFSET=(size of the file - 128) and then run: dd if=/path/to/file.mp3 bs=1 skip=OFFSET count=128 of=/path/to/id3v1.tag Attach those for me, and I can have a look at the genre information.
Created attachment 57493 [details] ID3v1 tag Track number: 2 Title: Brother Artist: Alice in Chains Album: MTV Unplugged Year: 1996 Genre: Grunge
Created attachment 57494 [details] ID3v2 tag Track number: 02/ Title: Brother Artist: Alice in Chains Album: MTV Unplugged Year: 1996 Genre: Grunge
OK, the new id3demuxer needs to do more work to parse these Genre fields. There's 2 disparate ways the fields might be encoded, it seems: http://www.id3.org/id3v2.3.0.html#TCON http://www.id3.org/id3v2.4.0-frames.txt (search from TCON) In 2.3.0, there can be multiple ID3v1 genre numbers listed in parenthesis, as well as a plain string 'refinement' eg: (6)(32)Foobar In 2.4.0, there can be multiple NULL-terminated genre strings in the one field. 3 cheers for over engineered specifications.
Fixed in CVS: * gst/id3demux/id3tags.c: (id3demux_read_id3v2_tag): * gst/id3demux/id3tags.h: * gst/id3demux/id3v2frames.c: (id3demux_id3v2_parse_frame), (parse_comment_frame), (parse_text_identification_frame), (id3v2_tag_to_taglist), (id3v2_are_digits), (id3v2_genre_string_to_taglist), (id3v2_genre_fields_to_taglist), (parse_split_strings), (free_tag_strings): Rewrite parsing of text tags to handle multiple NULL terminated strings. Parse numeric genre strings and ID3v2 type "(3)(6)Alternative" style genre strings. Parse dates that are only YYYY or YYYY-mm format. (Fixes #328241 and #322154)
I confirm that the commit fixes all my issues.