# Auto-numbering different values in MP3Tag and Windows

**URL:** https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738
**Category:** Support
**Tags:** player
**Created:** [February 21, 2026, 8:44pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738 "2026-02-21T20:44:34Z")
**Posts on this page:** 14
**Page:** 1

<div class="post-metadata">

### Author: ![Harm10](https://community.mp3tag.de/user_avatar/community.mp3tag.de/harm10/32/16198_2.png) [@Harm10](https://community.mp3tag.de/u/Harm10)
#### Post date: [February 21, 2026, 8:44pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/1 "2026-02-21T20:44:34Z")

</div>

I mostly do not check whether the numbering created by MP3Tag also shows correctly in the Windows folder but accidently I stumbled on a difference.  
First I thought just clear the numbers and redo them but the problem persists.

The numbering set by MP3Tag displays correct in the tool itself but when looking at the folder content the Number is sometimes different. They are all MP3.

 ![Schermafbeelding 2026-02-21 214054](https://community.mp3tag.de/uploads/default/original/3X/9/e/9ed672250c3729b59ebb8802f5fd7b191174698e.png)

 ![Schermafbeelding 2026-02-21 214136](https://community.mp3tag.de/uploads/default/original/3X/8/b/8bebeaaedd210bf433b7d22fbaacded63999d2d0.png)

I added screen prints of it. Any idea what is happening here?

I use version 3.33.1

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 21, 2026, 8:48pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/2 "2026-02-21T20:48:04Z")

</div>

> [@Harm10](#):
>
> Any idea what is happening here?

Yes: it is the leading zeros that upset the WIndows explorer which interpret the numbers now as octal values - a problem that has not been corrected for ages, see e.g. here:

> [@Padding Track Num, Scrambled.](https://community.mp3tag.de/t/padding-track-num-scrambled/11740/3):
>
> Maybe. Hmm, few days ago there was a rather similar request like yours now. Looking at your pictures all looks fine with focus to the filenames. When looking at the property sheet of a file resp. at the property column titled "#" there are the quirks. For me ... it looks like ... if numbers with one leading zero will be interpreted as "octal numbers". So that the octal number "010" will be displayed as decimal "8" or octal number "011" will be displayed as decimal "9". I have no definite …

---

<div class="post-metadata">

### Author: ![Harm10](https://community.mp3tag.de/user_avatar/community.mp3tag.de/harm10/32/16198_2.png) [@Harm10](https://community.mp3tag.de/u/Harm10)
#### Post date: [February 22, 2026, 12:11am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/3 "2026-02-22T00:11:18Z")

</div>

So you are saying this is a Windows problem?

In this folder there are 2000 mp3s so that is why it becomes four digits when using Auto-numbering option with leading zeros switched on.

Is there a way to get around this?

---

<div class="post-metadata">

### Author: ![arb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/41988e/32.png) [@arb](https://community.mp3tag.de/u/arb)
#### Post date: [February 22, 2026, 12:23am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/4 "2026-02-22T00:23:30Z")

</div>

I’ve tested it too and it’s definitely a Windows problem, basically unavoidable for any official releases with 100 tracks or more.

Only other way around it is sub-dividing releases into other folders, like CD’s or Part 1-10 or for folders with less organisation, more folders with specific genres, artists etc.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [February 22, 2026, 3:22am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/5 "2026-02-22T03:22:03Z")

</div>

> [@Harm10](#):
>
> In this folder there are 2000 mp3s so that is why it becomes four digits when using Auto-numbering option with leading zeros switched on.

Keep in mind the CD Redbook standard limits the number of separate tracks on a CD to 99. So in theory the 3+ digits that Windows interprets as Octal should not typically occur in a typical album folder.

Ultimately it is only a Windows display issue. If that doesn't affect your library or player software then just ignore it.

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [February 22, 2026, 7:10am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/6 "2026-02-22T07:10:40Z")

</div>

> [@Harm10](#):
>
> Is there a way to get around this?

Yes. You have to omit leading zeros.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 22, 2026, 7:22am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/7 "2026-02-22T07:22:26Z")

</div>

> [@Harm10](#):
>
> Is there a way to get around this?

Do not use leading zeros at all.  
The TRACk field is supposed to be numeric anyway (with the exception of the separating slash) so any decent player should sort TRACK as a number.  
If you like to see the leading numbers in the filename, then use $num(%track%,4) instead of a simple %track% when writing new filenames with Convert\>Tag-Filename.

---

<div class="post-metadata">

### Author: ![Harm10](https://community.mp3tag.de/user_avatar/community.mp3tag.de/harm10/32/16198_2.png) [@Harm10](https://community.mp3tag.de/u/Harm10)
#### Post date: [February 22, 2026, 11:05am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/8 "2026-02-22T11:05:46Z")

</div>

Using $num(%track%,4) is a good suggestion! In that way I will still get a proper file name/

Windows having this problem you wonder why the option of leading zeros is there?

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 22, 2026, 11:32am UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/9 "2026-02-22T11:32:09Z")

</div>

> [@Harm10](#):
>
> Windows having this problem you wonder why the option of leading zeros is there?

Because Windows is not the navel of the world?  
BTW: MP4 tags do not accept leading zeros at all.

---

<div class="post-metadata">

### Author: ![Harm10](https://community.mp3tag.de/user_avatar/community.mp3tag.de/harm10/32/16198_2.png) [@Harm10](https://community.mp3tag.de/u/Harm10)
#### Post date: [February 22, 2026, 12:04pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/10 "2026-02-22T12:04:10Z")

</div>

No I meant why MP3tag has this option? If you can set the track number in the file name in the $num(%track%,4) way I do not see why MP3tag offers this option? Just out of curiosity.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [February 22, 2026, 12:16pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/11 "2026-02-22T12:16:36Z")

</div>

> [@Harm10](#):
>
> I do not see why MP3tag offers this option?

Many do not care what Windows shows as it doesn't affect how their library manager or player programs work.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 22, 2026, 12:31pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/12 "2026-02-22T12:31:32Z")

</div>

> [@Harm10](#):
>
> No I meant why MP3tag has this option?

A feature request?, See e.g. here:

> [@Numbering Wizard sometimes fails to add leading zero](https://community.mp3tag.de/t/numbering-wizard-sometimes-fails-to-add-leading-zero/12104):
>
> Hello, I use the auto-numbering wizard and I have it setup to add a leading zero when needed. I have noticed that in some cases it fails to add the zero, it happens rarely and I can't see anything different about the files. I will greatly appreciate your response and I apologize if this has been covered before; I searched for numbering, wizard, etc. and could not find any reference to this.

and as it is not forbidden and most other players can cope with it and only Microsoft has refused to iron out the strange interpretation of track numbers being octal values, I see no harm.

---

<div class="post-metadata">

### Author: ![Harm10](https://community.mp3tag.de/user_avatar/community.mp3tag.de/harm10/32/16198_2.png) [@Harm10](https://community.mp3tag.de/u/Harm10)
#### Post date: [February 22, 2026, 4:21pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/13 "2026-02-22T16:21:41Z")

</div>

Yes MS has a mind of its own……… 🙂

I have switched the option off and now everything displays fine.

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [March 1, 2026, 4:22pm UTC](https://community.mp3tag.de/t/auto-numbering-different-values-in-mp3tag-and-windows/70738/14 "2026-03-01T16:22:12Z")

</div>

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