# Padding Track Num, Scrambled.

**URL:** https://community.mp3tag.de/t/padding-track-num-scrambled/11740
**Category:** Support
**Created:** [March 18, 2011, 3:01am UTC](https://community.mp3tag.de/t/padding-track-num-scrambled/11740 "2011-03-18T03:01:52Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![greyDrifter](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/g/90db22/32.png) [@greyDrifter](https://community.mp3tag.de/u/greyDrifter)
#### Post date: [March 18, 2011, 3:01am UTC](https://community.mp3tag.de/t/padding-track-num-scrambled/11740/1 "2011-03-18T03:01:52Z")

</div>

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.

 ![](https://community.mp3tag.de/uploads/default/original/2X/a/a35fb30a5db3e80834cb0c408afed15d999bd619.png)

---

_[View the full topic](https://community.mp3tag.de/t/padding-track-num-scrambled/11740)._