Auto-Numbering Wizard works incorrectly by using leading zeros

Hi together,
I came across an issue today with the latest official release (and also the dev release 3.12a).
I like to use the auto numbering wizard with leading zeros for around 170 tracks. Doing this in Mp3tag the values got displayed correctly like 001, 002, 003, ... 172. When checking the files in the directory the sequence is mixed up like 1,2 ... 8, 9, 8, 9 or missing numbers inbetween. When I do not use the leading zeros option the numbering is fine in Mp3tag and the directory but of course the leading zeros are missing. I don't remember the previous release but it has worked fine before.

Thanks for your help.

KR
Lutz

see this thread

and look for the explanation on "octal numbers".
It's a bug in the Windows explorer.

Further to this, the original Redbook definition for CD has a track limit of 99. So in those cases, up to track 99/99 this issue would not come up. Of course these days with digital downloads of some compilations numbering well into the hundreds or more tracks, there are going to be possible problems like this.

You could try breaking them into subsets using the %discnumber% field combined with %track% and separated by a dash or similar. This would break up the three digit anomaly causing the octal conversion. [i.e. %discnumber%-%track% %title%]

Edit: Or another thought - if your track numbers all have three digits, save them using the first digit, insert the dash or dot or similar, then the second and third digits. Again breaking the octal conversion from taking over. Only apply this logic to 3-digit track numbers, as single and 2-digit numbers shouldn't be affected.

Hi togehter,

Thanks for your thoughts on that. Strangely it does not occur for every folder with tracks. When displaying it in windows explorer it is column title number. I have cleared the field content for all tracks before writing them with Mp3tag so it should not make a differenceif there were other numbers in before, shouldn't it? From my feeling it shouldn't behave different when using leading zeros or when not using them.

Some background regarding the numbers: I like to listen to Perry Rhodan audio books and they usually consist of 12 to 15 CDs. The tags on a CD are in most cases either not existent at all or completely rubbish so that the titles get completely out of order on my mobile through unneeded or inconsisten tags. Therefore I use first the auto numbering and then change the title and filename to Titel_%track%. I don't need the chapter name there but just a short name to remember where I had to stop listening.

I never cam across this issue in previous versions hence I feel this is something new.

So these tracks are coming from CD - limited to 99 tracks per disc. If you have the disc and track numbers tagged in your files, then use the suggestion I mentioned first to build your filenames. This avoids the three digit issue altogether.
%discnumber%-%track% %title%

Does MP3tag show the files as they should be ordered?
Does your player show the files in the correct order (except it is the Windows Media Player which has the same bug)?
If that is so - it is your display that does not work, not MP3tag.
This whole topic has been handled before, as you can see.
I think we can close this now.

Hi MotleyG,

I use only titel, track, interpret and album. I remove everything else like CD, year and so on.

I mostly use VLC player on the PC and it shows the right order same as MP3tag does but it takes only the title number into consideration and this is in the right order.

On the mobile especially Apple devices they often use the track number internally which messes up the order of tracks.

One general question regarding this topic:
How do you explain the different behavior when using leding zeros and when not using them. The tag is written by Mp3tag, isn't it so shoulnd't write different numbers into the field.

MP3tag write the correct numbers into the field. Decimal numbers.
It is the Windows explorer that takes 3 digit-numbers with leading numbers as octal values.So the decimal number 8 appears twice - once for the decimal value 8 and once as the decimal-transformed-into-octal number 10
Why Microsoft has not corrected this bug since it was discovered in W7 is beyond my grasp.

Ok, thx. Think we can close this thread.

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