This is a bug in id3lib. As can be seen in the Kid3 source code: mp3file.cpp:465 // This will not work with buggy id3lib. A BOM 0xfffe is written before // the first string, but not before the subsequent strings. Prepending a // BOM or changing the byte order does not help when id3lib rewrites // this field when another frame is changed. So you cannot use // string lists with Unicode encoding.
Kid3 uses the pipe character to separate strings in string lists. The IPLS frame contains a string list with alternating involvement, involvee strings, see http://www.id3.org/id3v2.3.0#sec4.4. So in this example, "Vocal|Artist Name" is a string list with involvement "Vocal" and involvee "Artist Name" and more could follow. Unfortunately, id3lib does not correctly encode string lists when UTF16 is used as encoding. You have the following possible workarounds: - When using string lists, do not use UTF16 encoding. You can set "ISO-8859-1" as text encoding for ID3v2 in the Kid3 settings. Kid3 will automatically use UTF16 when a field contains non-ASCII characters. This will let you correctly encode those involved people lists if they contain only ASCII characters. - You can use ID3v2.4.0, where these problems do not exist. However, not all devices support ID3v2.4.0. For the Debian maintainers: Please reassign this bug to libid3-3.8.3c2a. Unfortunately, id3lib is not actively maintained, but I will try to fix the bug there and send a patch for id3lib. Regards, Urs _______________________________________________ pkg-kde-extras mailing list firstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras