How can I select ID3V2.3 and UTF8

Now you made it Chinese for me :slight_smile:
Please translate it to "basic foreign English" so I can try to pick it up..

And if you have any idea on what I wrote one post above, why it is happening?

special characters screwed

How exactly?

I made a series of screenshots according to my 1...5 steps above, hopefully this shows what happens.
Please note, that on the player screen those 2-2 chars (OUou) appearing with tilde (~) and hat (^) instead of double accents (") are font related within the player. The rest comes thru though:

0 - spec. chars as they appear in winword
0 - spec. chars as they appear in Mp3tag

Ah... OK, then I split then the rest into separate posts due to new user 3 pcs/post limit


1 - tag written by Mp3tag v2.4/UTF8 (note the 30 chars limit)
2 - tag written by Mp3tag v2.3/UTF16 - total mess
3 - tag edited in wmp with original string - all ok


4 - tag writen by Mp3tag v2.3/ISO-8859-1 - double accents disappeared
5 - tag edited again in wmp with original string - all ok again


Ok the player
doesn't read v2.4/UTF8 at all
doesn't understand v2.3/UTF16

so only option is v2.3/ISO-8859-1 but it seems the player doesn't use ISO-8859-1 but the system language/codepage instead
What's your OS language?
For example ISO-8859-1 and cp1250 are not fully compatible

The Id3v2 standard says to use always ISO-8859-1 but some programs in the past have used system codepage instead. An old problem if you use software that cannot handle unicode.

Yes, this is exactly where I got stuck.

OS language is English, keyboard is Hungarian, language for non-Unicode programs is Hungarian, installed codepages 1250 ... 1257, ISO 8859-1 ... -15, UTF7-8, practically all OEM-s and a few more.

Acive codepage is normally 852, but everything seems to be the same even if I change it to 1252 instead

So are you saying there is nowhere to go from here?

MP3diags (link see here:

has a function to convert the tag fields encoding to utf-16 assuming the local code page.
You could try that and see if it helps.

And, of course, there is an action im MP3tag to convert the current characterset to unicode:

I tried MP3diags - seems to be a nice program, and indeed is very useful overall.
I could not find any possibility though to convert v2.4 tags to v2.3 - what would be needed for my player.

Yes, that was my step 4. above as you see, and simply did not help.

OK, I found if I go to tag editor, and change a field then save, MP3diags saves the tag in v2p3/UTF16. So I am back to zero :frowning: .

As dano suggested above, it must have to do with some code page issue hardcoded in the player.

The only way now would be to markup the special characters while still being in V2.4 format e.g. with "==" around them - this should be achievable with a replace run in MP3tag.
Then you save the tags as V2.3 with all the losses that you already know, only this time, it should be possible to replace the specially marked characters with the correct version in V2.3 UTF-16.
WMP reads V2.3 UTF-16 correctly.

I am afraid this method does not deliver the result I need. Even if I replace the marked characters in v2.3/UTF16, as we stated above the player still would not understand it correctly. (Not mentioning that such a replacement cannot be automated, so not much of an option for hundreds of files)

Yes, that is correct.

Where the problem evolves though furhter is that WMP does not care if the file already had a v2.4 and a v1.1 tag, it simply creates a third tag in v2.3, that makes everything even worse.

If I remove all tags first and let WMP create its own and sole v2.3 tag, it writes - strange enough - with Latin 1 encoding. Windows and the player can read it nicely, but then it is again falling quite out of the standard

I can keep using it as a last resort to "save" 30+ long track/album information containing special chars. Not that "elegant way", but so far the only one that works (with all known drawbacks). I hoped somewhere that Mp3tag could solve this, but I understand the developer does not want to support non-standard features.

At the end of the day, if I were able fix the code page issue that prevents v2.3/ISO-8859-1 tags properly showing the double accented chars, that would be the ultimate solution.

But then this is not an Mp3tag support question. Thanks for all your help so far.

OK, I have reached the end of the road :slight_smile: .
Just checked the ISO-8859-1 standard here, and by definition there are missing characters (from several languages actually). In my case, exactly those four above. Period.

There is an old microsoft programm called AppLocale for WinXP which might be able to force Mp3tag to write a different codepage than ISO-8859-1

What about an action that replaces exactly these specially marked character sequences?

I would never use WMP as tagging program. As soon as you have user-defined fields in a file, tagging with WMP deletes them, the information is lost.
Also, it is never quite clear, when and if information is actually saved in the files or only in the WMP database.

Perhaps it has not become quite clear:
You load the files into MP3tag in all their V2.4 beauty.
You replace the 4 single characters with something like ==O, ==A etc.
You then save the V2.4 files with V2.3 tags. This should have lead to the loss of the special character information in the old days but now, as you have them marked with ==O etc., you can easily replace all of them with the single correct characters in UTF-16.
This conversion should be necessary only once as from now on you won't be using V2.4 any more.

Using unsupported software that is decades old, is the real problem, though.

No, it was fully clear.

I simply don't intend to move to UTF16 for these very reasons:

  • first of all, the player in question does not read UTF16 correctly - please see above
  • such a move would require all my mp3 files to be converted
  • plus possibly would resuls another series of troubleshooting with other players that currently work OK.

I looked for a simple solution, it did not exist with given conditions. I take it as it is, and try to make the least hassle for moving forward.

Thanks anyway.

Haha, I already expected such a comment :slight_smile: .

You know, the coin always has another side. If a tool does what I want it to use for, and it does it simply and reliably, it can be any old, I don't care. In other words, I don't see any problem using a software just because it is considered obsolete or outdated, by others (BTW: "decades old" means several ten years old - when actually did XP come out? :wink: )

Why should I burn excess resources (like x-core processor GB ram super PC-s with W10 for example) for just to run a jukebox that as all features I needed, no less no more? That can run on a "decades old" PC, that would have been trashed anyway.

What do you use, when you need to drive in a simple screw? The latest, coolest, top notch, LiIon battery, computer-controlled torque, Makita, DeWalt, whatsoever power drill driver? That's nice, but I am 100% happy using my simple screwdriver, that is probably already 40 years old now. And I can even control the torque by my wrist :slight_smile:.

Yes, this piece of software is not supported (by the author, I guess you meant that way) any longer, but this piece of fact does not prove if it was crap or if it was not capable. I identified two shortcomings, for what there is an acceptable workaround, fair enough.

But back to the thread, I learned a lot during past few days, so thanks for your contribution.

Thanks dano. I might take a look at it.
Nevertheless, I think Mp3tag does a great job as it is, staying along with the standards, so I really have no "right" to alter this. I can live with such a "cosmetic" imperfection, missing those four characters is no big deal for a "party jukebox" :slight_smile: .

My mind kept thinking. These posts above did help me a lot to better understand the picture, and I concluded I was asking for a wrong option at the first place, that made everything too much complicated.

And I am thinking here out loud: if there was an option for v2.3 / ISO-8859-2, that would solve the "problem" of the characters missing from 8859-1 (and not only these four above, but several others languages too, like some French or German chars, etc.).

Actually, there is very little difference between the two (Latin-1 and Latin-2), and most importantly the codes below 127 are the same.
Mp3Diags takes a note on 8859-1 chars above codes 127 anyway, (suggesting to convert to UTF16, but that's a different story), so such an option (i.e., the 8859-2) would not really breach the ID3 "standard" in a big extent.

No, I don't want to sound like a broken record :slight_smile: , nor want I divert the original thread, so I drop this idea into a separate thread, where the developer can answer it with a simple "yes" or "no" (if "no", hopefully with some reasoning too.)

Once more: thanks for all your inputs above.