<div dir="ltr"><div>Hi Urs,</div><div><br></div>The parameter <span style="font-size:13.125px">UTF16BE and UTF16LE are somewhat confusing. Unlike their name, UTF16BE means "the system byte order" and UTF16LE means "contrary to the </span><span style="font-size:13.125px">system byte order" in TagLib 1.8 and 1.10. I introduced </span><span style="font-size:13.125px">WCharByteOrder in v1.9 to straighten it out, but it caused some binary incomatibility between v1.8 and v1.9, so we reverted it in v1.10.</span><div><span style="font-size:13.125px"><br></span></div><div><span style="font-size:13.125px">Privately, I think that either way (keep the compatibility with v1.8 or v1.9) is logical accordingly. v1.9 is not compatible with older versions, but has been used for a long time...<br></span><div><span style="font-size:13.125px"><br></span></div><div><span style="font-size:13.125px">Regards,</span></div><div><span style="font-size:13.125px">Kageyu</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-09 6:07 GMT+09:00 Urs Fleisch <span dir="ltr"><<a href="mailto:urs.fleisch@gmail.com" target="_blank">urs.fleisch@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<br>_______________________________________________<br>
taglib-devel mailing list<br>
<a href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/taglib-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/taglib-devel</a><br>
<br></blockquote></div><br></div>