GNOME Bugzilla – Bug 340979
[id3demux] mp3 id3v2 TCON tag possible bug?
Last modified: 2006-05-10 17:15:25 UTC
Please describe the problem: I have genres, where I added parenthetical qualifiers, such as "world (hawaii)". These end up listed in the interface as "orld (hawaii". I can work around problem by avoiding this use of parenthesis, but it seems like this should be allowed. The ID3v2 documentation doesn't seem to dissallow it (the first byte doesn't start with a paren, so it shouldn't be using the ID3v1 logic). Steps to reproduce: 1. add mp3 genre (TCON) tag with value such as "world (hawaii)" 2. import into rhythmbox 3. Actual results: genre is displayed as "orld (hawaii" Expected results: genre displayed as "world (hawaii)" [or at worst, "world (unknown)" if it must believe it's using the ID3v1 refinement mechanism] Does this happen every time? yes Other information: Running under Fedora Core 5 (in case its libid3tag related, which appears to be libid3tag-0.15.1b-2.fc5)
Is it happening with gstreamer as well? Can you test « gst-launch -t playbin uri="file:///blahblah/myfile.mp3" » and check which value it gets for the genre tag? Which version of gstreamer/gst-plugins-* are you using?
Yes, apparently it is. # yum list>packages # grep -i gstreamer-plugins packages gstreamer-plugins-base.i386 0.10.5-1 installed gstreamer-plugins-good.i386 0.10.2-1 installed gstreamer-plugins-ugly.i386 0.10.2-1.lvn5 installed I assume it's that livna version, so apparently 0.10.2-1 ..
Reassigning to gstreamer as per comment #2.
Looks like reporter was using gst-plugins-good 0.10.2. Joe, can you attach the first second or so (the part that has the ID3 tags) from the file here?
Created attachment 65101 [details] first 10 blocks of mp3 file Here's the first 10 blocks. The genre is: "world, fado (portugal)"
Definitely still a problem in gstreamer CVS, using the test file in attachment #65101 [details]: gst-launch-0.10 -t filesrc location=broken-genre.mp3 ! id3demux ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". album: The Fado of Coimbra genre: orld, fado (portugal title: The Island and the Dream artist: Fernando Machado Soares track number: 1 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 25729000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... I suspect it's trying to parse those brackets as if they're numerical ID3 genres like (1)(44)
Other programs like tagtool correctly identify the genre.
This seems to fix it, haven't double-checked with tags that have the genre number as string in brackets though: --- id3v2frames.c 28 Apr 2006 11:37:22 -0000 1.15 +++ id3v2frames.c 10 May 2006 10:48:57 -0000 @@ -627,7 +627,8 @@ id3v2_genre_fields_to_taglist (ID3TagsWo break; for (pos = 1; pos < len; pos++) { - if (tag_str[pos] == ')') { + if (tag_str[pos-1] >= '0' && tag_str[pos-1] <= '9' && + tag_str[pos] == ')') { gchar *tmp_str; tmp_str = g_strndup (tag_str + 1, pos - 1);
Created attachment 65157 [details] [review] Fix ID3 genre parsing some more This patch fixes it by making the numeric-genre-string parsing check for things that aren't actually numeric or that don't start with a parenthesis. Committing after lunch.
Fixed in CVS: * gst/id3demux/id3v2frames.c: (id3v2_genre_fields_to_taglist): Fix parsing of numeric genre strings some more, by ensuring that we only try and parse strings that a) Start with '(' and b) Consist only of digits. Also, when finding an escaping '((' sequence, bust it back to '(' by swallowing the first parenthesis
*** Bug 341281 has been marked as a duplicate of this bug. ***