[Bug 770355] id3v2: Fix parsing extended header and string lists

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770355

--- Comment #8 from GstBlub <gstblub at gmail.com> ---
Created attachment 334245
  --> https://bugzilla.gnome.org/attachment.cgi?id=334245&action=edit
Failing ID3v2 tag

This is the ID3v2 tag only, you should be able to just append any MP3/AAC to
it.

It decodes fine with id3v2 --list id3.bin or exiftool -v3 -l id3.bin

  | - Tag 'COMM' (54 bytes):
  |     9fa6: 01 65 6e 67 ff fe 00 00 ff fe 4e 00 61 00 69 00
[.eng......N.a.i.]
  |     9fb6: 6d 00 20 00 4d 00 50 00 33 00 20 00 4d 00 75 00 [m. .M.P.3.
.M.u.]
  |     9fc6: 73 00 69 00 63 00 20 00 4c 00 69 00 62 00 72 00 [s.i.c.
.L.i.b.r.]
  |     9fd6: 61 00 72 00 79 00                               [a.r.y.]

Note how the COMM tag string list starts with a UTF16 BOM (ff fe), directly
followed by a null character (00 00), which indicates the string list
separator.  UTF8 strings happened to work because the data gets g_strndup()
first and then the g_utf8_validate() call uses -1 as second argument.  However,
in the case of ISO8859 the g_utf8_validate() call would always fail (due to the
null character being included in the data size) and kick it into
string_utf8_dup().

It also has the extended header that wasn't handled correctly.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.