GNOME Bugzilla – Bug 331368
Gstreamer doesn't recognise tags
Last modified: 2006-03-02 13:23:30 UTC
Please describe the problem: The tags for the attached file are not recognised by Gstreamer. I have plugins-good 0.10.2 installed. Steps to reproduce: $ gst-launch -t playbin uri="file://$PWD/21 paradiso.mp3" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none Setting pipeline to PLAYING ... New clock: audioclock0 Actual results: Expected results: Does this happen every time? Other information: Tags were written with kid3 <http://kid3.sourceforge.net/>
Rats, it's too large for Bugzilla. I've put it on my web site: <http://robots.org.uk/stuff/bug.mp3>
I can reproduce this. The tag does appear to be incorrect, as the MCDI frame is 256 bytes long -- it should be 8*(n+1)+4 bytes long, where n is the number of tracks, and no value of n makes it 256. However, unless GStreamer is trying to parse the MCDI frame (and I can't believe it is) it shouldn't matter. The frame length is given as 256 bytes, and it is 256 bytes long, so the invalid data is safely contained.
Damn - that's a distinction between v2.3.0 and v2.4.0 that had previously escaped me. Thanks, guys - fixed in CVS: * gst/id3demux/id3tags.c: (id3demux_id3v2_frames_to_tag_list): ID3 2.3.0 used synch-safe integers for the tag size, but not for the frame size. (Fixes #331368) I get: track number: 21 artist: Yoko Kanno album: Wolf's Rain OST1 date: 2003-01-01 genre: Anime title: paradiso
A heads up -- as of 4.9, iTunes wrote (and may still write) 2.4 tags, but uses non-sync-safe ints (i.e. 2.3-style) for the frame size. This tends to break a lot of files with APIC or other large frames found in the wild.
Wow, that's broken. Does anything cope with it? I don't relish the thought of checking 'oh no frame at the indicated offset, let's try again as if it were non-synch-safe' I much prefer the 'apple should fix their shit' approach
iTunes copes with it, and that's probably the single most popular tagger around. Mutagen, the ID3 reader/writer we wrote for Mutagen, also copes with it. You're right that it's difficult to get correct.
Do you have any samples of the ID3 tags that iTunes produced at that point? Not the attached music, but the tags would be useful.
I've scanned my collection and unfortunately it looks like I've fixed all of mine. And again, our test is frame-level so it's probably not much use to id3demux.
Fair enough. Thanks for the heads up.
*** Bug 333070 has been marked as a duplicate of this bug. ***