MP3 metadata oddity. Bug or feature?

CBCB Ƹ̵̡Ӝ̵̨̄ƷDer Millionendorf-
edited March 2016 in Internet & Media

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. :)

Comments

  • sgstairsgstair Reverse Engineer Redmond, WA

    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.

    Garg
  • sgstairsgstair Reverse Engineer Redmond, WA

    Nice catch; I didn't consider that.

  • primesuspectprimesuspect Beepin n' Boopin Detroit, MI

    Whoa

    BobbyDigiRyder
  • CBCB Ƹ̵̡Ӝ̵̨̄Ʒ Der Millionendorf-

    Neat!

Sign In or Register to comment.