GNOME Bugzilla – Bug 326438
sound-juicer creates badly behaved id3 tags in mp3 files
Last modified: 2006-01-13 15:52:17 UTC
Please describe the problem: sound-juicer appears to create badly behaved id3 tags in mp3 files. It appears that duplicate tag information is written to files which can only be read by some tagging applications. Steps to reproduce: 1. rip the first track of a CD: after-rip.mp3 2. id3info after-rip.mp3 3. strings after-rip.mp3 (note duplicate taginfo) 4. cp after-rip.mp3 after-retagging.mp3 4. retag after-retagging.mp3 in tagtool 5. id3info after-retagging.mp3 6. strings after-ripping.mp3 Actual results: $ id3info after-rip.mp3 *** Tag information for after-rip.mp3 === TIT2 (Title/songname/content description): Hindewhu for you === TPE1 (Lead performer(s)/Soloist(s)): HEADHUNTERS === TALB (Album/Movie/Show title): Evolution Revolution === TRCK (Track number/Position in set): 1 *** mp3 info MPEG1/layer III Bitrate: 32KBps Frequency: 44KHz $ strings after-rip.mp3 <snip> TAGHindewhu for you HEADHUNTERS Evolution Revolution TAGHindewhu for you HEADHUNTERS Evolution Revolution (note duplicate stanza) Fixed capitalisation: HEADHUNTERS -> Headhunters in tagtool. [alex@delpy Evolution Revolution]$ id3info after-retagging.mp3 *** Tag information for after-retagging.mp3 === TIT2 (Title/songname/content description): Hindewhu for you === TPE1 (Lead performer(s)/Soloist(s)): Headhunters === TALB (Album/Movie/Show title): Evolution Revolution === TRCK (Track number/Position in set): 1 *** mp3 info MPEG1/layer III Bitrate: 32KBps Frequency: 44KHz $ strings after-retagging.mp3 <snip> TAGHindewhu for you HEADHUNTERS Evolution Revolution TAGHindewhu for you Headhunters Evolution Revolution Note that tagtool can only "see" the second appearance of the artist tag. Expected results: I would expect to only see one set of tags upon running "strings" on the mp3 file. The same disc ripped using grip only has one set of tag information. Does this happen every time? Yes. Other information: This first came to light for me in rhythmbox, because rhythmbox only "sees" the first set of tags (the one's originally assigned by sound-juicer), and doesn't see any changes, whereas other tagging applications don't see the original tags, only the modified tags. See bug #323658 for more information.
Created attachment 57092 [details] short (19 second) mp3 file created by the sound-juicer rip Adding the initially ripped mp3 file, only 19 sec.
Created attachment 57093 [details] mp3 file after retagging in tagtool mp3 file after retagging, note the repeated stanza
The first file you attached suffer from bug #320767 imo. It only has id3v1 tags from what I can tell, I dunno why, an id3v2 tag would be much better.
I have also noticed that the first track ripped from a CD only has id3v1 tag information at the end of the file, whereas second and subsequent tracks have both beginning of file (id3v2?) and end of file (id3v1?) tags. e.g. the second track on the same disc: $ strings track02.mp3 LAME3.96.1UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUTAGSlick it HEADHUNTERS Evolution Revolution [...] UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUTAGSlick it HEADHUNTERS Evolution Revolution
This doesn't look like an id3v2 tag to me... The output of hexdump -Cv ./track02.mp3 |less is generally more conclusive when debugging tag issues. The tons of LAME2.9.6.1UUUUUU look really suspicious to me at least
Sound Juicer just asks GStreamer to write tags, re-assigning.
(In reply to comment #5) > This doesn't look like an id3v2 tag to me... The output of hexdump -Cv > ./track02.mp3 |less is generally more conclusive when debugging tag issues. The > tons of LAME2.9.6.1UUUUUU look really suspicious to me at least I think you're right, it isn't an id3v2, but it's where an id3v2 would be. Actually tagtool only recognises it an id3v1 tag, again it may be an instance of bug #320767, and it's writing tag information in wrong place multiple times.
(In reply to comment #5) > This doesn't look like an id3v2 tag to me... The output of hexdump -Cv > ./track02.mp3 |less is generally more conclusive when debugging tag issues. 000000c0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| 000000d0 54 41 47 53 6c 69 63 6b 20 69 74 00 00 00 00 00 |TAGSlick it.....| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 48 45 41 44 48 55 4e 54 45 52 53 00 00 00 00 |.HEADHUNTERS....| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 45 |...............E| 00000110 76 6f 6c 75 74 69 6f 6e 20 52 65 76 6f 6c 75 74 |volution Revolut| 00000120 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 |ion.............| <snip> 005b2c70 55 55 55 55 55 55 55 55 54 41 47 53 6c 69 63 6b |UUUUUUUUTAGSlick| 005b2c80 20 69 74 00 00 00 00 00 00 00 00 00 00 00 00 00 | it.............| 005b2c90 00 00 00 00 00 00 00 00 00 48 45 41 44 48 55 4e |.........HEADHUN| 005b2ca0 54 45 52 53 00 00 00 00 00 00 00 00 00 00 00 00 |TERS............| 005b2cb0 00 00 00 00 00 00 00 45 76 6f 6c 75 74 69 6f 6e |.......Evolution| 005b2cc0 20 52 65 76 6f 6c 75 74 69 6f 6e 00 00 00 00 00 | Revolution.....| 005b2cd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 005b2ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 005b2cf0 00 00 00 00 00 00 02 ff |........| 005b2cf8
switching to the known specific version this is against, I'm using the rpms from gstreamer for Fedora Core 4 and the Livna RPM for the actual audio mp3 plugins: $ rpm -q gstreamer gstreamer-plugins gstreamer-plugins-extra-audio gstreamer-0.8.11-0.gst.1.4 gstreamer-plugins-0.8.11-0.gst.1.4 gstreamer-plugins-extra-audio-0.8.11-0.lvn.2.4
I think this is a dup of bug #320767. Marking as such. Not sure tho -- please follow 320767 to make sure the issue is resolved in the end. *** This bug has been marked as a duplicate of 320767 ***