Padding Track Num, Scrambled.

Does padding of the track numbers affect how explorer and mp3 players reads the track number?(Padding being the prefixing with zeros to have a specific number of characters.)

I used 'Bulk Rename Utility' ver 2.7.1.2 to rename a series of 150 mp3s that were named with the suffix of 'title disk_track'; 01_01 through 15_10 to their sequential counterparts 001 through 150.
The conversion worked and everything was fine. I then attempted to use mp3tag to cleanup the file attributes and set the track as the last three characters of the filename.
Using Action with a sort by filename: Format value "TRACK":$right(%_filename%, 3)
This worked fine within mp3tag, when refreshing, reloading the directory, reloading the program, rebooting. It all appears fine within the program. Looking at the file attributes in explorer they are scattered hitter and yon, and less than 1/2 of the filename suffixes appear to match the track number. (Is this clear enough or would an image help clarification?)

I feel safer with 01 than 1 in the case of alphabetical sorts but is this my problem?

Any suggestions?
Thank You.


There was a post from March of 2010; don't remember much but he had his tracks padded to 2 characters. He didn't find a satisfactory answer in that post but I think his problem was related, messed up track number read in explorer.

More recently, LifesSweetDrug asked for a method of stripping the leading zero from tracks and dano answered.

Action type: Format value
Field: TRACK
Formatstring: [$num(%track%,1)]

and a varient for 10-99

But this leaded to the discovery of the tool autonumber wizard... and it's option of Leading zeros for tracknumbers.

It turns out explorer doesn't like padding of the track number field, discovered by experimentation.

Thank You.

This answers the problem.

But why does explorer reject the padding?

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 explanation for this phenomenon, but I tend to say that the property handler has a bug when reading the TRACK tag field's number string and the string looks like an octal coded number.

But that such an error, before software deployment, at least in the final inspection, has not be noticed to anyone of the programmers, that would be unbelievable.

Better you check the tag type of your files.
For compatibility with Windows they should have tag type ID3v2.3 UTF-16.

DD.20110318.0540.CET

While trying to get my head around the concept I ran a few statistics that might be of interest.

Tracks Doubled in Explorer with Leading Zero
8,9,18,19,28,29,38,39,48,49,58,59
(24 Tracks Doubled)

Tracks 64-67 and 71-77 (inclusive) are Missing
(12 Tracks Missing)

Tracks above 78 (inclusive) are intact.
(73 tracks at high end)

The first grouping only files ending in 8 or 9 are doubled. There is definitely a pattern.

Track #'s are sequential with the insertion of the duplicates at there correct location, the tracks will continue counting until the next filename ending in 8 or 9 where another duplicate will be inserted.

REM edit: strike duplicate(s) and insert octal-pair, duplicate implies that it is the second or was copied from something that came before whereas octal-pair is just trying to describe numbers ending in 8 and 9. Numbers that have no place in an octal system. Although this description works up to 63, I haven't managed to fit the missing numbers into the system of numbers, nor why tracks in the ten's place (eight's in octal?) are unaffected.

Either mp3tager reads an writes tracks in a unique way or there is a problem with explorer of Win7 32 or MSWin ver6.1.7601. (I will compare this with a win7 64bit machine tomorrow, as it is late.)

Thank You DetlevD.

Just because this post needs one more concept to be confused about:
Nonary is a base- numeral system, typically using the digits 0-8, but not the digit 9.

Managed to track down that post, thanks for the pointer.

herby-t posted it on March 13,2011 (in german)
/t/11709/1

somenick and dano were discussing UTF-8 and unicode support which might be related, I'll try and unravel that latter.

If you are refering to mp3tag Options > Tags >
it looks right to me. I'll do some reading on ID3 and related to gain a better understanding.

Thank You and Good Night.

I greatly thank all involved for looking into this problem. Last Friday I changed from Windows XP to Win 7 and have been having nothing but headaches with this same track numbering issue. For years I have been using the defunct original ID3 and inserting leading zeros as they were needed by earlier Windows Explorer & Media Player to properly set the tracks. They are also useful in track naming for proper sorting.

Now I find that the leading zeros cause problems with Windows 7 Explorer (at least in my Win 7 Pro 64-bit version). Renumbering the tracks without any leading zeros appears to have solved the problem completely.

Previous to finding this solution, I had tried repeatedly to fix the track numbering, using my old standard ID3, NCH's StampID3, and your Mp3tag, all without success. Renumbering 2 different audiobook folders (180 files and 173 files) without leading zeros fixed both immediately upon saving the changes.

So far as I can tell, this site is the only one to address this problem directly, much less to have offered a working solution. Again, THANK YOU!!