GNOME Bugzilla – Bug 614158
[id3demux] doesn't read tags from file correctly (tag with unsynced frames, data length indicator)
Last modified: 2010-03-30 15:37:27 UTC
I have found the tags from a number of my MP3 files are not being displaying correctly when they're imported to Rhythmbox. After talking to 'moch' on the #rhythmbox IRC channel, I've been told the following output and file fragment would be helpful in finding out the bug. Best regards, Carlos $ gst-launch-0.10 -t filesrc location=/tmp/example.mp3 \! decodebin \! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". track number: 1 disc count: 1 disc number: 1 ID3v2 frame: buffer of 122 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 36 bytes, type: application/x-gst-id3v2-talb-frame, version=(int)4 : buffer of 34 bytes, type: application/x-gst-id3v2-tpe1-frame, version=(int)4 : buffer of 51 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 34 bytes, type: application/x-gst-id3v2-tcom-frame, version=(int)4 : buffer of 38 bytes, type: application/x-gst-id3v2-tcon-frame, version=(int)4 : buffer of 63 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 28 bytes, type: application/x-gst-id3v2-tpub-frame, version=(int)4 : buffer of 54 bytes, type: application/x-gst-id3v2-tit2-frame, version=(int)4 : buffer of 51 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 53 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 container format: ID3 tag FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 242000 has crc: FALSE channel mode: joint-stereo FOUND TAG : found by element "flump3dec0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "flump3dec0". bitrate: 128000 FOUND TAG : found by element "flump3dec0". bitrate: 96000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock FOUND TAG : found by element "flump3dec0". bitrate: 107000 FOUND TAG : found by element "flump3dec0". bitrate: 160000 FOUND TAG : found by element "flump3dec0". bitrate: 179000 FOUND TAG : found by element "flump3dec0". bitrate: 192000 FOUND TAG : found by element "flump3dec0". bitrate: 197000 FOUND TAG : found by element "flump3dec0". bitrate: 209000 FOUND TAG : found by element "flump3dec0". bitrate: 216000 FOUND TAG : found by element "flump3dec0". bitrate: 226000 FOUND TAG : found by element "flump3dec0". bitrate: 225000 FOUND TAG : found by element "flump3dec0". bitrate: 228000 Got EOS from element "pipeline0". Execution ended after 37089819 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
Created attachment 157308 [details] first 100k of one of the troublesome files
Thanks for the bug and sample data. I can reproduce this.
This should fix the main problem: commit 9e1f5031ccda09da1b4e371850905adbac935956 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Tue Mar 30 01:50:32 2010 +0100 id3demux: fix parsing of unsynced frames with data length indicator Fixes bug #614158. If you think we should be parsing any of the extended TXXX frames, please file a separate feature request bug for that (or clone this bug), thanks!
Well, that's basically the point, I'd like the tags to be recognized. What do I clone this report as/to? I'm not too experienced with bugzilla.
> Well, that's basically the point, I'd like the tags to be recognized. In case it wasn't clear: the usual tags (artist, album, track numbers etc.) are now recognised: tpm@zingle:~/gst/git$ gst-launch-0.10 playbin2 uri=file:///home/tpm/samples/614158-id3-tags-not-extracted-unsync-length-indicator.id3 -t ... FOUND TAG : found by element "id3demux0". track number: 1 disc count: 1 disc number: 1 ID3v2 frame: buffer of 122 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 51 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 63 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 28 bytes, type: application/x-gst-id3v2-tpub-frame, version=(int)4 : buffer of 51 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 : buffer of 53 bytes, type: application/x-gst-id3v2-txxx-frame, version=(int)4 album: Ya-Ka-May artist: Galactic composer: Galactic genre: Electronic title: Friends of Science container format: ID3 tag FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 242000 has crc: FALSE channel mode: joint-stereo FOUND TAG : found by element "mad0". duration: 77000000000 bitrate: 242326 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none What's not recognised are only the freeform RANDOMFOO=BAR tags, but these are rarely interesting and not standardised.
Still, Rhythmbox does not yet recognize these files's valid tags even so.
> Still, Rhythmbox does not yet recognize these files's valid tags even so. I don't understand what you mean by that. Could you elaborate please? Which tags exactly? Have you applied my patch and built your own gstreamer0.10-plugins-good, or ... ?
Yes, I applied the patch and rebuilt gst-plugins-good on sid and reinstalled it, then ran gst-launch-0.10 on my own and saw the recognized tags. Relaunched Rhythmbox, tried importing tracks again and they're still not recognized by Artist/Album/Title.
This seems to be more of a matter of Rhythmbox's stubborn caching. I forcefully moved everything elsewhere entirely under one of my monitored directories and it's all showing up now. Sorry.
Great, thanks for confirming. Can we close the cloned bug as well, or is there valuable info in any of the TXXX tags that you think we should be extracting as well? (if yes, which?)
I see (with an hex editor...) that one of these extended tracks has ORIGINAL RELEASE = 2010 in there. Since Year is still showing as "Unknown", I think that'd be a nice thing to have.