# Tag %track% incorrectly includes %\_total%
**URL:** https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874
**Category:** No Bugs
**Created:** [August 10, 2020, 9:25am UTC](https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874 "2020-08-10T09:25:56Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@kruipolie](https://community.mp3tag.de/u/kruipolie)
#### Post date: [August 10, 2020, 9:25am UTC](https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874/1 "2020-08-10T09:25:56Z")
When converting tags to file names, MP3tag includes the total number of tracks into the track number. This was not the case in previous releases, although I've read that the problem has also occurred in releases as far back as 2016.
In other words: %track% now is 01/27, 02/27, 03/27 etc which will be converted, in a filename, to 0127, 0227, 0327 etc.
However, I would prefer %track% to be just the number of the track: 01, 02, 03 etc.
The total number of tracks can be used through %\_total% anyway.
Thanks for reading this and thanks in advance for any follow-up.
(BTW: I know that there is a workaround: use $num(%track%,2) instead of %track%. But it would be more logical and consistent if it would be as requested above.)
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 10, 2020, 9:35am UTC](https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874/2 "2020-08-10T09:35:57Z")
> [@kruipolie](#):
>
> This was not the case in previous releases
The function was there as you describe since way back when. So I doubt that your allegation is correct.
> [@kruipolie](#):
>
> The total number of tracks can be used through %\_total% anyway
In which tag version do you find that?
Or: have a look at the supported tag fields in the help:
> **[Tag Field Mappings – Mp3tag Documentation](https://docs.mp3tag.de/mapping/)**
>
> Overview of all available tag fields, their names in Mp3tag, and how they are mapped to the internal structures of the different tag formats. Mp3tag is the universal Tag Editor.
where you don't find a field called \_TOTAL.
So it looks a lot like a user-defined field to me.
> [@kruipolie](#):
>
> However, I would prefer %track% to be just the number of the track: 01, 02, 03 etc.
This would then not be according to the MP3 standard, which states
"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". "
(see [https://id3.org/id3v2.3.0](https://id3.org/id3v2.3.0), search for TRCK)
I don't see a bug. On the contrary: I see most of the changes that you demand as a step towards a non-compliant non-standard handling of the field TRACK.
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [August 10, 2020, 4:00pm UTC](https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874/3 "2020-08-10T16:00:10Z")
> [@kruipolie](#):
>
> When converting tags to file names, MP3tag includes the total number of tracks into the track number.
I am using MP3Tag since 2009 and Mp3Tag always included all information of the tagfield TRACK.
For naming files you always had to use `$num(%track%,2)` if the total number of tracks was included in the track-field.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:19pm UTC](https://community.mp3tag.de/t/tag-track-incorrectly-includes-total/49874/4 "2026-02-09T12:19:08Z")