%tracknumber% works in some places but not others

Anyone else find that %tracknumber% works in some places e.g. Convert, Text file - Tag but not others e.g. Convert, Tag - Filename ? Testing with WMA.

I find no mention of %tracknumber% in http://help.mp3tag.de/main_tags.html or elsewhere in Help.

Thanks.

I see the same thing as you describe.
Maybe it has something to do with the 2 fields normally found in the ASF tag: TRACKNUMBER and TRACK.
It seems that TRACKNUMBER can be written but not read.

I couldn't see the same behaviour with MP3's.

TRACKNUMBER must be a user-defined field. As that field that contains the number of a track is simply called TRACK.
So, of course, you can write data to a user-defined field - not much good, though, if your player does not support it.
And: the contents of a field TRACKNUMBER will only appear if it has been filled before.
I would use TRACK instead.

What I see is this: When a user writes to %track% for a WMA file, Mp3Tag writes the user entered value to TRACKNUMBER and also writes the value minus 1 to the TRACK field.

For example, the tag panel displays 1, TRACKNUMBER is 1, and TRACK is 0.

I assume that TRACKNUMBER and TRACK are both written to ASF tags according to the Microsoft/Windows specification.
If so, then for ASF tags in WMA files, TRACKNUMBER is not really user-defined.

I cannot reproduce this behaviour: if I open a WMA file with MP3tag and enter a number in TRACK then this number is presented just as I entered it.
If you import data with the converter to a user-defined field called TRACKNUMBER then, of course, TRACK will remain empty. I doubt that any subtraction is carried out.
(What happens if you enter 3 in TRACKNUMBER - does TRACK show 2?)

Thanks both. Ohren, yes, I would use TRACK instead of TRACKNUMBER - I am trying to debug a received script that uses TRACKNUMBER.

I just did these tests, using a hex editor to view the WMA's WM/Track and WM/TrackNumber, and using the Tag Panel with TRACKNUMBER added under Options (assuming this panel's Track: maps to TRACK) to make changes and view.

I started with a file with no tag (showing TRACK and TRACKNUMBER blank).

  1. changing TRACK and clicking Save changes TRACK, WM/Track and WM/TrackNumber
  2. changing TRACKNUMBER and clicking Save changes Track:, blanks TRACKNUMBER, does not change WM/Track and changes WM/TrackNumber. Note: Track: and WM/Track now fail to accord.
  3. Clicking Save again changes WM/Track to the value expected at 2)! Further changes shows WM/Track lags by one Save.

(The value in WM/Track is always the value entered/shows in Track: or entered in TRACKNUMBER or shows in WM/Tracknumber, minus 1.)

This certainly suggests that TRACKNUMBER should not be used. I'g guess its availability is unintentional.

Florian, I suggest the Mp3tag docs http://help.mp3tag.de/main_tags.html:

be amended to show that TRACK maps to WM/Track additionally to WM/TrackNumber, and that TRACKNUMBER has undefined behaviour and should not be used.

Yes, that is true. But when writing "Track", two fields are written to the file. See the screenshot.
When reading a file, the tag panel shows whatever is in TRACKNUMBER, not TRACK.
TRACK as a raw tag field is not the same as "Track" in the tag panel.

I assume Mp3Tag does this to conform to the format specification.
We see only an interpretation for "Track", not the raw tag data.

Here is another discussion.
http://www.mediamonkey.com/forum/viewtopic...?f=3&t=1723

No.
If you write directly to TRACKNUMBER, then TRACK is not written. The value for TRACK remains the same and it is not created if it was absent.
Earlier, I said that TRACKNUMBER is not really a user-defined field. But it is more accurate to say that it is a bad choice to use TRACKNUMBER as a user-defined field because of the specified relationship between TRACK and TRACKNUMBER in ASF tags.
Writing TRACKNUMBER alone, as a user-defined field, might cause unexpected results in some players.