Bugs reported in Debian's BTS
dato at net.com.org.es
Fri Apr 20 17:15:13 CEST 2007
Hello! (please CC me on replies)
I'm the Debian maintainer for taglib, and I'm forwarding here a couple
bugs that got reported in our BTS. It'd be great if you could take a
Subject: id3v2 zero-sized frame parsing
I have many mp3 files which have id3v2 tags with zero-sized frames in
them; that is, the 4 byte frame identfier, 4 nulls, and 2 flag bytes.
This isn't an issue with other tag processing apps/libs, but taglib
fails to parse the tag after such a frame. So only the data to the first
such frame is processed, which leads to an incomplete display of file
information in the various players using taglib.
The attached patch fixes the issue.
Subject: amaroK with taglib writes ID3v1 tags in UTF16 and not writes ID3v2.
amaroK from latest debian etch writes ID3 tags competely incorrectly.
I'm reporting bug against taglib because it handles the tags themself.
ID3v1 tags should contain ISO-8859-1, ID3v2 tags should contain ISO-8895-1 or Unicode.
In present state it writes:
~% id3v2 -l newtaglib.mp3
id3v1 tag info for newtaglib.mp3:
Title : >G5<C =5 2 =0<>@4=8:0E? Artist: E/D ▒8=-70-70
Album : Year: 0 , Genre: A Capella (123)
Comment: Track: 0
That is, unicode in ID3v1 (violation) and no ID3v2 tag.
You can also diagnose this problem with easytag - easytag shows broken tag for amaroK-tagged
files and marks file red (== broken, I guess) if you strip ID3v1 tag with `which id3v2`.
That happen if I use ru_RU.KOI8-R locale and cyrillic tags.
This is very serious bug because it breaks user files, making tags unusable in any app short
Note that it writes correct ID3v1 tag if I happen to use latin script, but still no sensible ID3v2.
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
«Ara que ets la meva dona, te la fotré fins a la melsa, bacona!»
-- Terenci Moix, “Chulas y famosas”
More information about the taglib-devel