Auto-numbering, track 32 and the Rename Master app

This maybe an edge case but if there's something underlying actually happening I thought I'd at least let you look at it. I found while I was worked with a powerful app named Rename Master. The developer of the app said the issue was not in his product (in my professional opinion I think it is), so let the dart tossing begin! :wink:

I'm using build v2.90a and have used many earlier versions throughout the years. It's always worked fantastically well (as always). I recently decided to take multiple live music discs and combine them into a single folder. mp3tag makes it extremely easy although the leading track numbers for the file names didn't change (thus the need for Rename Master. In this case, I added MP3s from a single Pearl Jam concert on three (3) discs to a new folder named simply "2016/04/16 Greenville, SC" The tracks were named as follows:


There are 35 tracks total. I used the Auto-numbering Wizard, so all the tracks tags were 1/35 through 35/35. I then renamed the Album tag (removing Disc 1, Disc 2, and Disc 3) so they all were simply "2016/04/16 Greenville, SC" and changed the discnumber tag to Save. All is good. I started Rename Master, which I downloaded from, and first used the app to remove the leading pj160416d3_ from each MP3 file name. I then sorted by track tag. For some reason the 32 track tag did not appear at all (it was blank), so it was at the top of the list. The developer said that is NOT a bug on his side. I did this for again for 8 other concert and 32 failed to appear every time. Is it possible that mp3tag isn't properly writing 32 as track tag? I've got screen captures.

FWIW, There's a workaround in Rename Master that let me move the empty track number file down to the 32nd position, so I could rename the files 01, 02, ... 31, 32, 33, 34 and 35.

Thanks for the detailed explanation. I don't want to go into dart fighting here and checked, whether Mp3tag is writing the track number correctly. The Rename Master seems to only support ID3v1, not ID3v2, so my test file was an ID3v1.1 tagged file.

It's written at position 126 in the ID3v1.1 tag and from looking at it in a hex editor, it's correctly encoded as 0x20 (which is 32 in its hexadecimal representation). Other apps I use for cross-checking (e.g., foobar2000) are also reporting the track number as 32.

This makes me think, that maybe the Rename Master developer can have a look again. 0x20 is also the space character if the data is encoded as ASCII, so this might be an idea for starting.

Let me know how it goes.

1 Like