<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Then I guess it depends on your definition of “most compatible”. If you use BE, Windows machines, Intel-based Macs, etc. will have to do the byte swapping; if you use LE, other architectures will have to do so. Does that matter?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>WRT unsync, if you aren’t using it, the BOM issue is a don’t-care. If you are using it—stop! ;-) Since you want to stay 2.3-compatible, you’re going to be using a BOM either way; unsync just complicates the issue.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you’re trying to figure out how to avoid breaking the smallest number of broken apps that don’t properly handle Unicode tags, that’s an exercise in frustration. Unless you know that a significant share of your target user base uses a known-broken app that happens to work with one but not the other, I’d say pick one, and accept that some number of misbehaving apps are going to show garbage to the user.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Paul Taylor [mailto:paul_t100@fastmail.fm] <br><b>Sent:</b> Wednesday, 27 April, 2011 11:37<br><b>To:</b> id3v2@id3.org<br><b>Cc:</b> Steve Dirickson<br><b>Subject:</b> Re: [ID3 Dev] Encoding UTF-16 (i.e UTF-16 with BOM which is the most compatible choice Little Endian or Big Endian ?)<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>On 27/04/2011 18:03, Steve Dirickson wrote: <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I think the key is that UTF-16BE is equivalent to “network byte order”. Any app that produces Unicode for external consumption really should provide the BOM. But, if it doesn’t, the only reasonable assumption the recipient can make is that the text is in network byte order. The alternative is to try heuristics and look for lots of binary zero values (or lots of the same small value) in every other byte, and then make the call based on whether those recurring values are in the even or odd bytes.</span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>I think you are missing my point Im NOT talking about the UTF-16BE encoding but the UTF-16 encoding (Which is UTF with BOM and can contain LE or BE data). I have no problem reading or writing the data but would like to know which is the most compatible choice. When embedded within an mp3 UTF-16 is not magically decoded by the operating system, it has to be decoded by the application, and Im sure there are some applications that can embed BOM LE but not BOM BE or vice versa. There is also the complication that the Byte order marks themselves in BOM LE requires unsynchronization if you are using unsynchronization whereas BOM BE does not, and applications such as Windows 7 Explorer itself don't understand unsynchronization making me think that BOM BE is more compatible. <br><br>Paul<o:p></o:p></p></div></body></html>