GNOME Bugzilla – Bug 792983
tags: regression parsing id3 v2.4 tags with extended header
Last modified: 2018-03-01 12:55:29 UTC
Created attachment 367542 [details] 5 seconds of silence MP3 file with ID3v2.4 tags edited with EasyTag With gst-plugins-base 1.12, UTF-8 encoded id3v2.4 tags in MP3 files are marked as broken and ignored. This causes Totem to only display the filename instead of any metadata in the id3v2 tags, and Rhythmbox to import a music file without any meaningful information. The error does not occur in gst-plugins-base 1.10. This happens with an MP3 with id3v2 tags edited using EasyTag 2.4.3 using UTF-8 as character encoding. The problem seems to be in gst-libs/gst/tag/id3v2.c, the logs for totem show the messages: 0:00:00.224698317 4663 0x7fad4013d1e0 DEBUG id3v2 id3v2.c:230:gst_tag_list_from_id3v2_tag: Reading ID3v2 tag with revision 2.4.0 of size 1024 0:00:00.224703489 4663 0x7fad4013d1e0 DEBUG id3v2 id3v2.c:591:id3v2_frames_to_tag_list: Could not extract any frames from tag. Broken or empty tag 0:00:00.224706673 4663 0x7fad4013d1e0 LOG GST_BUFFER gstbuffer.c:1582:gst_buffer_resize_range: trim 0x5615cb264b30 0-4096 size:1024 offs:0 max:4103 0:00:00.224711225 4663 0x7fad4013d1e0 WARN tagdemux gsttagdemux.c:1264:gst_tag_demux_pull_start_tag:<id3demux0> Ignoring broken start tag of size 1024 As an exercise I used id3v2.c and id3v2.h from gst-plugins-base 1.10.5 in 1.12.3; the problem disappears after installing this version. If EasyTag is generating invalid id3v2 tags, it has been doing it for the last four years. I attach a dummy MP3 test file of 5 seconds of silence with id3v2 tags edited with EasyTag, and the GST_DEBUG=6 logs of reproducing it with Totem.
Created attachment 367543 [details] Totem log file Totem log file of reproducing the attached MP3 with GST_DEBUG=6. As the full logfile is 25Mb in size, I attach just a "grep id3v2" of it.
Thanks for the report. This is related to this commit: commit da6070054f471216adac2c5879031fcebfa592d2 Author: Thomas Bluemel <tbluemel@control4.com> Date: Wed Aug 24 10:33:14 2016 -0600 id3v2: fix handling of tags with extended headers The extended header size value does not include itself. https://bugzilla.gnome.org/show_bug.cgi?id=770355
Created attachment 368263 [details] [review] id3v2: Handle different extended header sizes the various id3v2 specs handle the extended header sizes differently (because hey, it wouldn't be fun otherwise). http://id3.org/id3v2.3.0 states: "Where the 'Extended header size', currently 6 or 10 bytes, excludes itself." http://id3.org/id3v2.4.0-structure states: Extended header size 4 * %0xxxxxxx Number of flag bytes $01 Extended Flags $xx Where the 'Extended header size' is the size of the whole extended header, stored as a 32 bit synchsafe integer. An extended header can thus never have a size of fewer than six bytes. So in id3v2.4.0 it's the *whole* extended header size (a-la ISOBMFF atom), whereas in id3v2.3.0 it's the extended header size *excluding* those 4 initial bytes. And for other versions, god knows..
Pushed this, with a new unit test for ID3 v2.4 extended headers. Sorry for the breakage. Will also pick into 1.12. commit 556bc04f1c8900be7269259b8428c8e19733d470 Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Mar 1 12:43:25 2018 +0000 tests: tags: add unit test for ID3 v2.4 extended headers https://bugzilla.gnome.org/show_bug.cgi?id=792983 commit 6f5c9db1cc7b8c70c525198f25aa4085fede2c7f Author: Edward Hervey <edward@centricular.com> Date: Mon Feb 12 16:26:01 2018 +0100 id3v2: re-fix handling of v2.4 extended headers The various id3v2 specs handle the extended header sizes differently (because hey, it wouldn't be fun otherwise). http://id3.org/id3v2.3.0 states: "Where the 'Extended header size', currently 6 or 10 bytes, excludes itself." http://id3.org/id3v2.4.0-structure states: Extended header size 4 * %0xxxxxxx Number of flag bytes $01 Extended Flags $xx Where the 'Extended header size' is the size of the whole extended header, stored as a 32 bit synchsafe integer. An extended header can thus never have a size of fewer than six bytes. So in id3v2.4.0 it's the *whole* extended header size (a-la ISOBMFF atom), whereas in id3v2.3.0 it's the extended header size *excluding* those 4 initial bytes. And for other versions, god knows.. Fixes regression introduced in commit da607005. https://bugzilla.gnome.org/show_bug.cgi?id=792983