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
pkg-kde-extras@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras

Reply via email to