![]() Finding out if they're more likely to be one encoding or another requires some knowledge of the languages often used by that encoding and even then, it's naturally just heuristics, not a 100% reliable thing. In encodings other than UTF-8, which can be legal or illegal, the others are basically just bitstreams. See, the problem is that validity isn't straight-forward. If there are other problems with interoperability in applications that actually are using unicode, feel free to report those separately. Honestly, on Winamp, I just don't really care since well, it's dead. If you want them fixed, please talk to the authors. All of the other mentioned things are command line Open Source utilities. From the way that I see things, it mostly seems to be that Winamp is broken and that's the core of the problem. I was also impressed to see that as of 5.0 iTunes finally updated their implementation to support ID3v2.4 (and as such UTF-8). Funda, yes, most Wiindows applications support ID3v2, as was said earlier, that includes WMP, Foobar 2000, iTunes, etc. This confused me at first too as at a quick glance one looks like a transliteration of the other.) (One thing that you may want to note though - our two "Ilya"s are not the same. My opinion is mostly similar to Sergey's, which I've stated in other reports and thusfar didn't feel particularly motivated to repeat here. In ideal world with ideal standards that might be fine, but ID3 always was lousy. What I see for now is more like "Let's close our eyes and don't look at cruel non-standard-compliant world". I can implement this patches if you'll commit them, but I have no clue about that. Add ~/.tagrc file support with "ID3v1_8bit_encoding = " and "ID3v2_8bit_encoding = ", again unoverrideable by app (but overrideable if app use custom StringHandler, as it probably know what is it doing. Possible solution to all this topic: Add recoding string handler into taglib itself (as a regular subclass to StringHandler), and make it be able to recode both ID3v1 and ID3v2 tags. Without this, taglib is not i18n-compliant (at all). Possible solution to latter problem: Make ~/.tagrc file support, where you can say "ID3v2 encoding = UTF16" and force UTF16, or "ID3v2 encoding = intag" and force in-tag encoding field to be used, UNOVERRIDABLE by apps. This cause: 1) latin alphabet people see their latin1 tags even in mistagged files 2) everyone else have 0% chance to see their tags correctly, because most software is written by latin alphabet people and they would likely force latin1 here, which cause every non-latin tag to break. It have got an ID3v2 'default encoding' option, which overrides id3v2 tags' encoding field. Please, please, don't tell me about standards. So why does taglib, on default setup, write garbage ID3v1 tags? Or else that's like having first fax machine in the world. Here we have non-latin1 (cp1251) data in ID3v2 tag. ![]() Yes, Windows Media Played does the trick displaying tags in both files fine. "Thanx comrade Stalin for our brigth childhood" (c) - utterly not std compliant. Winamp5 - id3v2.mp3 readable, taglib.mp3 garbage. JuK is one of few apps actually having encoding switched to UTF-8, does not help. mp3 tagged with id3lib-using id3v2 program. And 100% tags unreadable with default behavior. TagLib offers solution in case of ID3v1 but do nothing in case of ID3v2. ![]() REMARK: 95% non-latin1 tags contain standard-prohibited encodings like cp-* mostly (thanx to windows apps, they just don't care when doing everything. Soultion: Somehow detect if encoding is 8bit/utf8. Europe gets its latin¨auts, but everyone other sees only garbage in written tags. This makes sure no tag with non-european language (like russian) would ever be written properly. TagLib offers developer to select encoding for ID3v2 - latin1, utf8, utf16(le/be).ĭevelopers unaware of i18n (like those who wrote kde metadata plugin) tends to select latin1 (or keep default, that's it).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |