Is there any way to tell mp3tag to encode text as UTF16-BE instead of UTF16-LE? On my Nokia E51, the tags encoded as LE display incorrectly (they miss the last letter!) in the firmware's in-built media search tool. If I could force BE, it would work!
Thanks,
wpb
No, this is unfortunately not possible.
Any chance of it being added?
Is that proven?
Yes, pretty much. I have a bunch of tagged mp3s that do work, and examining the files in a hex editor shows they're UTF16-LE encoded. My other mp3s that don't work are UTF16-BE encoded. Not exactly proof, but very strong empirical evidence!
Did you mix up LE and BE because now you say LE files work?
Maybe you can upload two files, one that works and one that does not so we can check them?
Sorry - it was early in the morning 
To confirm, BE works; LE doesn't. This is almost certainly a problem with the Nokia firmware, not a problem in mp3tag. Anyway, I can't upload examples as they're copyrighted, but here it is in code form. Just one ID3v2 text frame:
Little-endian:
54 50 45 31 00 00 00 1F 00 00 01 FF FE 4A 00 6F 00 73 00 68 00 75 00 61 00 20 00 4B 00 61 00 64 00 69 00 73 00 6F 00 6E 00
TPE1.......ÿþJ.o.s.h.u.a. .K.a.d.i.s.o.n.
Big-endian:
54 50 45 31 00 00 00 21 00 00 01 FE FF 00 4A 00 6F 00 73 00 68 00 75 00 61 00 20 00 4B 00 61 00 64 00 69 00 73 00 6F 00 6E 00 00
TPE1...!...þÿ.J.o.s.h.u.a. .K.a.d.i.s.o.n..
Notice the different byte-orders of the BOM. Does that help?
Thanks, that's also good evidence.
I suspect the problem for nokia is not the byte order, but the two missing termination bytes at the end of the field (00 00)
Now the ID3v2 standard gives a little room for interpretations, but we have decided against termination byte(s)
Unfortunately nokia made the opposite decision.
I've just stumbled over codepages ....
1200 — UCS-2LE Unicode little-endian
1201 — UCS-2BE Unicode big-endian
... don't know if this is related to this topic.
DD.20100321.1357.CET