If you search for information about WMA, you will quickly find the definition "WMA track number is a string". This was also mentioned 10 years ago, here
However that definitely doesn’t apply to us as end users.
The Two-Layer Reality
The confusion often arises because users see a String in the SDK/API and assume the underlying file format supports Alphanumeric values (like "A1" or "12-B"). However, the architectural truth is split into two layers:
| Layer | Role | Data Type |
|---|---|---|
| ASF Container (Physical) | How data is written to the disk | WORD (16-bit Unsigned Integer) |
| API / SDK (Interface) | How software communicates with the file | String (WSTR) |
Key Technical Points
- The Physical Constraint: The ASF (Advanced Systems Format, used for WMA audio files) specification explicitly defines the
WM/TrackNumberattribute as a WORD (a 16-bit unsigned integer data type, not a human-readable word composed of letters!). This means the actual bits stored in the file header can only represent a whole number between 0 and 65'535. - The API Abstraction: The Windows Media SDK often passes metadata values as Strings for the sake of uniformity. When you "write/save" a track number via the API, the system takes your String (e.g., "10"), converts it to an Integer, and packs it into that 16-bit slot.
- Why Alphanumeric Fails: If you attempt to pass an alphanumeric value like "A1" to the API, the underlying writer will fail to convert it to a
WORD. Since the physical container has no "String" field for this specific attribute, the data simply cannot be stored.
Thats also the reason why we see this error message in Mp3tag, if we try to save "A1" into a WMA file from the Tag Panel or try to fill the TRACK (WM/Tracknumber) from a WebSource Script like the one from Discogs or MusicBrainz:
I can confirm that a Websource Script leaves a zero (0) into TRACK after showing the above error message for a WMA file.
The same is true if you try it from the Tag Panel.