[X] Can't copy some unusual TRACK tags from MP3 / FLAC to WMA


Till recently, I was using only MP3's and FLACs; with tags in ID3v2.3 UTF-16. And I was using tag fields not in a "standard" way, with a bunch of signs different than just letters and numbers, but had not problems with them whatsoever

But now it seems I have found a bug

If the value in the TRACK tag field starts with a dot sign

.I simply cannot copy such value to a WMA format. But if that dot was behind I number, then there would be no problem. Also if I have a letter or letters in the TRACK field, such value cannot be copy. But if letters are following a number, then there is no such problem

So the bug is: it can be copied, but to MP3 and FLAC; but such an attempt on a WMA file will spit out an error saying, that it cannot be opened for writing

[I haven't tested all the fields with all the signs that I'm using- so maybe there are more cases like that?]

REQUEST: Tag Panel new Size Of Field - micro
Mapping of tag fields - is it really needed at all?
[X] .wav cannot be opened for writing replicable bug
Add missing ID3 styles (genres) types support

Why should it be a bug if you try to use tag-fields against their official definition:

The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9"."

There is nothing mentioned of dots and letters.


So why does MP3 and FLAC have no issues with it and WMA does? Why are those two treated better [at least in MP3tag], in a more universal way?

Why should I limit myself to what a value should be, in terms of meaning / characters? With that logic I should not put in the TITLE tag all those non-letter signs used on this album tracklist https://en.wikipedia.org/wiki/Reanimation#Track_listing. And by extending that logic, I should only put one predefined genre in GENRE tag, and not my own [sometimes multiple] descriptions [number codes meaning various activities like running or falling asleep]. WHY?


This is not a bug, but the result of an Mp3tag feature.

WMA files use ASF (Advanced Systems Format) tags.
see here:

My understanding is this:

ASF tags support both Track and TrackNumber.
Track is 0-based and included for legacy reasons. (ie back-wards support)
TrackNumber is 1-based.
Mp3tag writes both.

You may ask, "How does Mp3tag write those tags?"

Only the developer knows for sure, but my observations suggest this:
Whatever number is entered by the user becomes TrackNumber.
Track is calculated by substracting 1 from the integer portion (the part before the decimal) of TrackNumber.

This means that you may only enter any decimal number greater than greater than or equal to 1. [EDIT]
Anything else will cause the warning you have seen.
This allows the feature of writing both Track and TrackNumber.

For example:
If you enter 1, then TrackNumber = 1 and Track = 0
If you enter 1.12345, then TrackNumber = 1.12345 and Track = 0
If you enter 1.9, then TrackNumber = 1.9 and Track = 0
If you enter +1.9, then TrackNumber = +1.9 and Track = 0
If you enter +300.9, then TrackNumber = +300.9 and Track = 299

Mapping of tag fields - is it really needed at all?

You mean developer of Mp3tag: Florian?

Or developers of WMA container format?

I took a shoot at another format [because I'm looking for another lossless format to use aside from FLAC]: WavPack

WV files seem to behave the same as MP3s and FLACs. There is no problem with unusual data that I use in the TRACK field. And I've also tested to same extend other fields in that format, with different signs

But the TRACK field WVA bug question remains: should or shouldn't it behave the same as MP3 / FLAC / WV in Mp3tag?

APE files problem
Mapping of tag fields - is it really needed at all?

This is not a bug. This is merely behaviour you don't like.
Mp3tag should continue to maintain back-wards compatibility by writing both TRACK and TRACKNUMBER for WMA files.


Presumably Mp3tag does nothing else than the function $num() to verify and to get clean values for the tracknumber from user input.
At last the target filetype decides which datatype can be accepted.
Note: a dot character is not a number.

The Windows Media Format 11 SDK defines ...
WM/TrackNumber g_wszWMTrackNumber WMT_TYPE_STRING
... and therefore it seems to be allowed, to store non numerical values into a WMA tag.



Does this mean some other tag software will also have the same "problem" with WMA?

I'm not planning to switch, WavPacks in Mp3tag seem to work the way I need; I'm just curious


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.