<div dir="ltr"><div><div><div><div><div><div>I can confirm these problems on Arch Linux. I have tested it with kid3. If I use kid3 3.3.0-3, which was built against TagLib 1.9.1, and currently dynamically links to TagLib 1.10 on Arch Linux, I have the same situation: Saved tags are stored with wrong characters. If I build kid3 against TagLib 1.10, the problems disappear. As Walter Schineis reported, the problems are solved when downgrading to TagLib 1.9.1. This looks like a binary incompatibility between the two versions.<br><br></div>I have used abi-compliance-checker and found the following:<br><br></div>In TagLib 1.9.1, we had the following<br><br>    String(const wstring &s, Type t = WCharByteOrder);<br>    String(const wchar_t *s, Type t = WCharByteOrder);<br><br></div>where WCharByteOrder is a private static const String::Type, which will be initialized to UTF16LE on little endian systems (as most of our PCs are).<br><br></div>In TagLib 1.10 we have<br><br>    String(const wstring &s, Type t = UTF16BE);<br>    String(const wchar_t *s, Type t = UTF16BE);<br><br></div>with a default of UTF16BE. The default encoding seems to have changed from UTF16LE to UTF16BE. If a program is built against TagLib 1.9.1 and uses one of these String constructors with a default parameter for the type, the compiler will assign the value of WCharByteOrder (which still exists in TagLib 1.10 and is still UTF16LE) to the type parameter. The code in the constructor in TagLib 1.10 now tries to do something for compatibility with TagLib 1.8 (had same signatures for these constructors as TagLib 1.10), but this will fail if the application was linked against TagLib 1.9.1.<br><br></div><div>So it seems that TagLib 1.10 is compatible with TagLib 1.8, but not with TagLib 1.9. The ChangeLog contains<br><br>    Fixed backwards-incompatible change in TagLib::String when constructing UTF16 strings.<br><br></div><div>It seems that applications linked against TagLib 1.9 have to be recompiled.<br></div></div>