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?]
Why should it be a bug if you try to use tag-fields against their official definition:
"TRCK
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"."
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?
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
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?
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/Track g_wszWMTrack WMT_TYPE_STRING
WM/TrackNumber g_wszWMTrackNumber WMT_TYPE_STRING
... and therefore it seems to be allowed, to store non numerical values into a WMA tag.