Windows Media Player 10 rejects MP3Tag's use of Unicode TLEN.

This is just a "heads up" for MP3Tag users about Microsoft's recent security update KB968816, which causes some unpleasant side-effects when using MP3Tag with Windows Media Player 10.

MP3Tag (legitimately) uses Unicode for all (AFAIK) ID3 fields, but Windows Media Player 10 (and possibly other versions) regard Unicode as invalid for the TLEN field, once KB968816 is installed.

The result is that any MP3 file that has had its TLEN tag written by MP3Tag that were playable before KB968816 are now unplayable.

I've requested that Microsoft look into this. Details are here: and here: .

Switching off Unicode use in MP3Tag using the appropriate option would prevent this, but (AFAIK) would lose the use of Unicode in all of the other fields as well, which would be a Bad Thing.

Although Microsoft seem to be clearly wrong in doing this, it is questionable whether there's any advantage in having a Unicode TLEN, since this field can only ever contain the characters "0" to "9" (any comment, Florian?).



TLEN is defined as numeric string ("0123456789" only.)

Which means unicode is not allowed in TLEN :ph34r:

Yes - I saw that, but at the time I thought "if nothing else was said" was allowing a "".
However, looking at [url=""] it also says explicitly:

Which would seem conclusive. MP3Tag isn't ID3v2.4 compliant! :astonished:
Time to post a bug report...

Bug report is here: /t/9209/1



I meant ID3v2.3, rather than ID3v2.4, but I guess that would apply too.


A little more information on this topic:

Files that have had their TLEN field written as Unicode by MP3Tag (and are therefore unplayable by WMP) also have (very minor) display issues in Windows Explorer.

In a quick test, if the columns "Audio Sample Rate" and "Channels" are selected for display (right click the column headers to do this), they are blank for affected files. Other fields may also be affected - I didn't populate every possible field to test them. The fields that are affected may also depend on the order in which the frames are stored within the ID3 - it's possible that Windows Explorer just gives up processing when it encounters the invalid field.

This isn't a major inconvenience, but does demonstrate that the effects of Microsoft's "tightening up" on non-compliant ID3s extend beyond WMP.

In another sense, it might be useful, by providing a way of detecting which file are affected, without having to open each one.