You're correct about 08 not being valid in octal, and that is in fact the reason the problem exists. The problem was only on the Rio Central, and it went like this:

- If your ID3V2 tags had the track number padded to two digits so that everything sorts properly when you rename your songs based on tags (something you can only do in V2 tags, since the track number is ASCII, unlike V1 which is just a byte)...

- And, you add an album's worth of songs to the Central, with track numbers of 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12...

- The internal-to-the-Central C function that they're using to convert the ASCII track number field into a database number, by an accidental choice of the function that they chose to do the job, interprets a number with a leading zero as an octal value instead of a decimal value.

- So, track numbers 01, 02, 03, 04, 05, 06, 07 are all fine because those numbers are the same in both decimal and octal.

- Track numbers 10, 11, 12 are also fine because they don't have leading zeroes and therefore the function interprets them as decimal instead of octal.

- Track number 08 and 09 have leading zeroes so they are interpreted as octal.

- Unfortunately 8 and 9 are not valid octal numbers (as you said).

- So the function returns 0, and those tracks get tagged as 0 in the Central.

The work around would be for Jemplode to strip leading zeroes off of all track numbers before sending them to the Central.