I am a huge fan of mp3tag, so first off many thanks!
I think I have found a bug in the renumbering of a large set of tracks. I attempted to renumber a set of 121 tracks (from 001 to 121) and it appeared to have worked fine in mp3tag. However, when I closed mp3tag and looked at the files in File Explorer (Windows 11) I found that the track number field (shown as #) in Explorer had the wrong track numbers, i.e. they did not seem to have been set correctly even though mp3tag showed that they had been. I worked around this by only selecting 99 tracks at a time for renumbering, and this enabled me to do what I wanted. I chose to do 99 at a time arbitrarily so I do not know of an actual limit for successful renumbering.
I don't think the problem is in Explorer, because when I renumber only 99 tracks in mp3tag they do appear correctly in Explorer. Therefore I suspect that when I renumbered all 121 in a single pass the new numbers (001 to 121) were not being written correctly to the mp3 files even though they appeared to be correct inside mp3tag.
Apparently, you did not go through the linked thread as that already describes your observation and the cause for it: WIndows Explorers interpretation of values with 3 digits and leading zeros as octal values.
If you take care that there are not 3-digit numbers with leading zeros in the field TRACK then the Windows explorer will sort correctly
The CD Redbook stipulates that no disc can have more than 99 distinct tracks. So the idea of going beyond that when recognizing track numbers shouldn't typically be a problem.
But as far as creating digital albums of some sort, this could be an issue for some interfaces. Windows has a documented issue of looking at tracks with three or more digits as octal format. But most other players and devices do not have this problem.
Bottom line - don't depend on Win Explorer to display tag information other than for a quick reference. Let the metadata do the talking in media players and library managers and your songs should appear correctly.
That is not the issue. The track numbers reported by Explorer appear to be simply wrong. If I create track numbers from 001 to 121 in batches then they come out correct, but if I try to create them in a single operation they are wrong.
This cannot surely be an issue to do with octal representation: even with 99 tracks in a batch there are 9s involved so octal issues would fail. So I think the track numbers written to the mp3 files are not the ones displayed in mp3tag.
Do you have any proof execpt the display in the Windows Explorer?
Have you checked a file that appears out of order with a hex editor to see what is stored in TRCK?
A simple test:
and the same files with 3-digit-numbers and leading zeros,
where the second dump shows 2x8 and 2x9
Maybe this is too complex for me to understand, but I would point out that I don't think this is to do with sorting - the track numbers shown by Explorer are not the same as those shown in mp3tag. I simply want to be able to select all my 131 tracks in mp3tag and give them track numbers 001 to 131, and this appears to work while I am in mp3tag but not if I use Explorer to examine the files. If I do this by only selecting batches of 99 (my choice and I have not researched to see whether this is a critical number) it works: I can use mp3tag several times on multiple batches (twice in this case) and by doing so I can get tracks 001 to 121 in mp3tag and also in Explorer. However if I try to do them all in a single batch, then the track numbers in Explorer are wrong.
If I can't do this then I accept it, but I should be interested to know the limit on how many tracks can be renumbered in a single batch: is there a known limit?
I stress again that this is nothing to do with sorting - it's the actual track numbers which simply do not match in mp3tag and Explorer, and it's not the sort order.
Thanks, I'll try that but I'm definitely baffled as to why there is a problem. I always use leading zeros in my track numbers and have never had a problem before, but in fairness I've never had more than 100 tracks before. And it does work fine with 99 tracks, so I'm baffled!
Please address your astonishment at Microsoft. What you see is a Microsoft problem, no MP3tag problem.
You do not need leading zeros in a decent player - if you want to create filenames with leading zeros, you can use $num(%track%,3) instead of the plain %track%. The Windows Explorer has not problems with leading zeros in filenames.
