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

**URL:** https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208
**Category:** General Discussion
**Created:** [October 26, 2009, 1:22pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208 "2009-10-26T13:22:29Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![gvm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/48db29/32.png) [@gvm](https://community.mp3tag.de/u/gvm)
#### Post date: [October 26, 2009, 1:22pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/1 "2009-10-26T13:22:29Z")

</div>

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: [http://www.microsoft.com/communities/newsg...78-39d7b355910b](http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windowsxp.music&tid=93b45385-c345-4fd9-9b54-a35c4a8f6d0f&cat=&lang=&cr=&sloc=&p=1&mid=e7311eeb-04aa-4009-a078-39d7b355910b) and here: [http://www.microsoft.com/communities/newsg...00-10cf83e7ad5a](http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windowsmedia.player&tid=3216f2df-39eb-4536-b4a2-b59a5f00dc60&cat=en_US_783621db-7288-406a-b831-ce7ec6ec0188&lang=en&cr=US&sloc=&p=1&mid=43bcd3fa-b075-477c-9c00-10cf83e7ad5a) .

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?).

Regards,

gvm

---

<div class="post-metadata">

### Author: ![dano](https://community.mp3tag.de/user_avatar/community.mp3tag.de/dano/32/6_2.png) [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [October 26, 2009, 1:48pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/2 "2009-10-26T13:48:59Z")

</div>

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

> [@](#):
>
> If nothing else is said, strings, including numeric strings and URLs  
> [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the  
> range $20 - $FF.

Which means unicode is not allowed in TLEN ![:ph34r:](https://community.mp3tag.de/uploads/default/original/1X/d9d21e0e122fbe04cbaaa509828a996924771538.gif ":ph34r:")

---

<div class="post-metadata">

### Author: ![gvm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/48db29/32.png) [@gvm](https://community.mp3tag.de/u/gvm)
#### Post date: [October 26, 2009, 2:17pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/3 "2009-10-26T14:17:20Z")

</div>

> [@dano](#):
>
> TLEN is defined as numeric string ("0123456789" only.)  
> Also:  
> If nothing else is said, strings, including numeric strings and URLs  
> , are represented as ISO-8859-1 [ISO-8859-1] characters in the  
> range $20 - $FF.  
> Which means unicode is not allowed in TLEN ![:ph34r:](https://community.mp3tag.de/uploads/default/original/1X/d9d21e0e122fbe04cbaaa509828a996924771538.gif ":ph34r:")

Yes - I saw that, but at the time I thought "if nothing else was said" was allowing a "".  
However, looking at [url="[http://www.id3.org/id3v2.3.0#sec3.3](http://www.id3.org/id3v2.3.0#sec3.3)"][http://www.id3.org/id3v2.3.0#sec3.3](http://www.id3.org/id3v2.3.0#sec3.3) it also says explicitly:

> [@](#):
>
> All numeric strings and URLs are always encoded as ISO-8859-1.

Which would seem conclusive. MP3Tag _isn't_ ID3v2.4 compliant! 😲  
Time to post a bug report...  
Regards,  
gvm

---

<div class="post-metadata">

### Author: ![gvm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/48db29/32.png) [@gvm](https://community.mp3tag.de/u/gvm)
#### Post date: [October 26, 2009, 2:59pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/4 "2009-10-26T14:59:33Z")

</div>

> [@gvm](#):
>
> Time to post a bug report...

Bug report is here: [/t/9209/1](https://community.mp3tag.de/t/9209/1)

Regards,

gvm

---

<div class="post-metadata">

### Author: ![gvm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/48db29/32.png) [@gvm](https://community.mp3tag.de/u/gvm)
#### Post date: [October 27, 2009, 5:19pm UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/5 "2009-10-27T17:19:35Z")

</div>

> [@gvm](#):
>
> However, looking at [http://www.id3.org/id3v2.3.0#sec3.3](http://www.id3.org/id3v2.3.0#sec3.3) it also says explicitly:  
> Which would seem conclusive. MP3Tag _isn't_ _ID3v2.4_ compliant! 😲

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

gvm

---

<div class="post-metadata">

### Author: ![gvm](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/48db29/32.png) [@gvm](https://community.mp3tag.de/u/gvm)
#### Post date: [October 28, 2009, 9:54am UTC](https://community.mp3tag.de/t/windows-media-player-10-rejects-mp3tags-use-of-unicode-tlen/9208/6 "2009-10-28T09:54:34Z")

</div>

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.

gvm
