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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
