More Unicode Problems With Windows Media Player 10 - Comment Description Tags

This is just a note to document the issue and the workaround, in case anyone else runs across it.

After KB968816, Windows Media Player 10 will refuse to play any MP3 that has a COMM (comment) tag with a Unicode "description" of longer than three characters (don't even think of asking why it might choose to do that - it's Microsoft!). Attempting to play such a file gives the error message:

Windows Media Player encountered an unknown error. This can occur when another program or operating system component encounters a problem but does not communicate the nature of the problem to the Player.
MP3Tag uses Unicode to write the description part of the COMM tag, so files written by MP3Tag (recent versions) become unplayable by WMP10. This would seem to be a problem with Windows Media Player, not MP3tag, since the ID3v2.3 standards state that it is permissible to use Unicode for this.

The workaround for this is to:

  1. View the Extended Tags (Alt-T)
  2. Identify the offending comment tag - it will have the name "COMMENT " where will be a string of greater than 3 characters.
  3. Edit the offending Comment tag (double-click it)
  4. Change the comment description by changing its name to "COMMENT ", where is some suitable three-character (or less) new description for the comment. If this is the only comment for this file, it can be re-named to simply "COMMENT".
This problem became apparent when rewriting my mp3 files to get rid of the previous Unicode problems (see here). :frowning: Regards,


I should have mentioned that MP3Tag treats a few iTunes comments as "special", in order to preserve compatibility - the following are never written as Unicode, and so its safe to ignore the following comments - they won't break WMP10:


I believe that there are also some comments specific to MusicMatch that are also safe (preserved as non-unicode), and its possible that some other iTunes ones exist too.



Just to clarify, since not everyone will be familiar with the structure of comment tags, most "normal" comments are unaffected by this issue - only ones with a "description".

Each comment (COMM) frame contains two text strings- a description and the actual comment itself (plus language and encoding descriptors). In most cases, the description is just null. There can be several comment frames in a tag, however, and if there are, and they are specified as different languages, then at least one of them must have a description.

The problem described here only arises if the description part is longer than 3 (Unicode) characters.