GNOME Bugzilla – Bug 577468
[id3demux] Frames not extracted if tag is unsynchronised
Last modified: 2009-04-24 18:03:41 UTC
Please describe the problem: The ID3v2 standard allows for unsyncronization tags. When tagging with id3v2 tools if you have non binary data and/or only latin1 encoding setting to unsync works. If you use any other encoding, or have large binary bit of data (like APIC), the tag can not be read. Steps to reproduce: 1. I wrote 3 programs using 3 different languages and API and each case I set unsync to be enabled. The 3 API where MP3::Tag (Perl, unsync is enabled by default). id3lib (C++, mytag.SetUnsync(false)) python-eyed3 (python, enable with tag.header.unsync = 1) 2. Find any mp3 with APIC or uses UTF16 encoding in it's text fields. 3. Use mp3 tag tool (or program) with unsync enabled. Actual results: Rhythmbox will be unable to parse the tags. If you then get the tool and disable unsync and re-write the ID3v2 header it will then work. Expected results: Does this happen every time? Yes. Other information: Please contact me for example python/perl or C++ code which can cause this issue, but I believe that if unsync is enabled on *any* tagger and it does it properly you will see this issue when you have non-trivial data in the tags.
When using a tag tool, make sure only ID3v2 tag is written and is 2.3.0. If you have any other tags written out which rhythmbox supports (such as ID3v1) it will *appear* to work when in fact it is reading the older tag. If you are using MP3::Tag, you can see that tags *can* be seen when you disable unsync, in MP3::Tag unsync can be disabled like: $mp3->config( 'id3v23_unsync' => undef); Another easy way to trigger the bug is, leave unsync on, and write out a new tag as utf8.
Does 'gst-launch-0.10 -t filesrc location=file.mp3 ! decodebin ! fakesink' show these tags like it does for regular id3 tags?
No it doesn't. With unsync disabled it shows the tag's correctly, with unsync enabled I get: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". ID3v2 frame: buffer of 75630 bytes, type: application/x-gst-id3v2-apic-frame, version=(int)3 FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 320000 has crc: FALSE channel mode: stereo FOUND TAG : found by element "mad0". layer: 3 mode: stereo emphasis: none bitrate: 320000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 3496595718 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
OK, moving this to GStreamer.
Here is what it looked like when the tag was when unsync was disabled: FOUND TAG : found by element "id3demux0". image: buffer of 75603 bytes, type: image/jpeg, image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_UNDEFINED album: Album genre: Pop title: Sample artist: ArtistIsSet track number: 1 date: 2008-01-01 FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 320000 has crc: FALSE channel mode: stereo FOUND TAG : found by element "mad0". layer: 3 mode: stereo emphasis: none bitrate: 320000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 3294817873 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
Could you attach a sample of a tag that doesn't work properly?
Created attachment 131925 [details] Working.mp3 has unsync disabled and works in gstreamer/rhythmbox, Broken.mp3 is unsynced and doesn't workl The Broken.mp3 however is readable by other tag readers and reported as being valid. (e.g. taglib/id3lib/MP3::Tag/EyeD3/kid3). I used a small file (borrowed from MP3::Tag examples) with no tags, tag a few properties and add an image. This was all done with unsync disabled and saved as Working.mp3. I took Working.mp3 and ask for the tags to be written unsync.. result is Broken.mp3. I can reproduce this with 3 different implementations of unsync ID3v2 2.3 tags (MP3::Tag, id3lib and eyed3). So I believe their implementation of unsync is valid.
*** Bug 579788 has been marked as a duplicate of this bug. ***
This should fix it: commit 0ff1b18cbb105f33b5d9682cda23f2c389d75d3f Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri Apr 24 02:11:28 2009 +0100 id3demux: add unit test file for unsynced id3 tags commit a85d7b7059d1955666fe0b93f5dcacdc3e02426b Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri Apr 24 01:51:35 2009 +0100 id3demux: parse unsynchronised tags properly We didn't handle unsynchronization at all up to now, which might have caused frames to not be extracted - esp. frames after an APIC picture frame. Fixes #577468. Doesn't handle unsyncing of individual frames yet, but I don't have test files for that at hand. Will try to fix that up too tho'.