MP3 metadata oddity. Bug or feature?

CB · March 2016

Take a look at this:

When I work on an audiobook, I export the final tracks (from Audacity, BTW) with a standardized (for me, not for the industry) production code in the file name, the track name, and the track number (I enter them all exactly the same: two digit chapter # followed by two-digit section #) This keeps them well organized no matter where or how they are being alphabetized or sorted.

The oddity is that the track numbers below 0801 do not retain as I entered them. They are changed every time. The change is predictable (0401 always becomes 257, for example) and (in my experience) they are always still in order (later tracks always still have higher numbers than earlier tracks), although this last property can't possibly be sustainable across all numbers (since there are simply not enough numbers between (for example) 194 and 257 to hold all the numbers between 0302 and 0401). Yet: The sequentially numbered tracks always remain sequentially numbered (again: in my experience (chapters rarely have more than five segments, and almost never more than a dozen, so I haven't tested much further than that). The phenomenon always stops with Chapter 7. From 0801 on, the track numbers start to match the entered numbers as I would expect (with just the leading zero removed) and there is a huge jump from the Chapter 7 track numbers to the Chapter 8 track numbers.

This isn't a problem. (if it was, I could easily fix it by just omitting the leading zero when entering track numbers.)

It doesn't seem to hurt anything, so I don't really need a fix or a solution, but I think it's odd, and thought I would share. If someone know why it happens, it would be interesting to know.

sgstair · March 2016

Unclear; You could try a more recent version of Audacity - I took a look into the current sources and it seems to store tracks as strings using ID3v2.3. However, the first revision of the ID3 metadata format stored the track as a byte (0-255), so maybe the tools were doing something strange and only partly correct. I didn't see evidence of that in the history, but at some point the code was reorganized so it's hard to be sure.

Strikes · March 2016

It's actually a programmer decision on Windows' side. When you put in '0401' instead of '401', Windows music folder viewer interprets the leading 0 as a hint to use Octal (0-7) instead of Decimal (0-9). It displays Decimal to you, though, so it converts Octal(401) into Decimal(257). You can verify this by using the little radio buttons on Windows' Calculator on Programmer view

This also explains why the issue stops happening at 0801: 8 is an impossible digit in Octal, so it assumes Decimal instead.

So, nothing's wrong, nothings being changed or damaged, and it's just an unexplained, very opaque feature.