Whenever I upload a directory of music (either by dropping the folder or the individual files), I lose the track information from the 8th and 9th tracks.

When I go to properties, the track numbers are no longer there, but on the "details" track listing they appear but don't seem to work. What I mean is, if I re-organize the tracks based on them, they both go before the first track, which reflects the track listing of nil.

If I add then in and sync up, everything works fine.

Also, when I download any files, the 8th and 9th tracks never include the track numbers in the naming, but the ID3 tags both still contain the track information.

It just seems like emplode or the players doesn't read in the #8 or #9 tracks.

Any ideas? Anyone else seeing the same problem? I've reinstalled and seen this problem repeatedly. Hijacked v251, 10 gig player, one drive.

Are these freshly ripped and tagged files from MusicMatch by any chance?

Nope, ripped from various programs. EAC, Audiograbber, etc. Some modified by Tag Studio, some fresh from encoding.

The reason that I asked is because I had a similar problem with MusicMatch. Basically, when I would drag a folder in to MM to edit the tags, it would start playing the first file. I would hit "Stop" and then touch up the tags (adding year, etc). After making the changes, I would then drag the folder into emplode. It often would have the OLD tag info for Track #1. This is because MM didn't update track 1 yet. It was still thinking the track was inuse. So, sometimes I had to actually kill the MM program and THEN drag into emplode.

Do you happen to have the explorer "preview pane" on the left-hand side of the window, showing the Media player with the current MP3 selected?

Looks suspiciously like you're importing id3v2 tags with leading zeroes in the track number fields.

You may be able to confirm it by making two short tracks and tagging one with "id3v2 -T 08 file1" and the other with "id3v2 -T 8 file2", verifying that the two tags differ in the track number tag, then uploading. I expect that the one without the leading zero will work as expected and that the one with will fail as you've experienced. (Can't test this myself, as emplode only runs on Windows platforms)

If that's the case, post it as an emplode bug in the Bugs forum. Roger will know what to do about it (read the value as a decimal integer, rather than as a C-style implicit-base integer).

In playing around, that seems like it is the issue. Files that are normally giving problems work properly after I go in and re-save the numbers in Tag Studio (making sure to re-save the info to the files).

The files now show up as 1, 2, 3.. 8, 9, 10 instead of 01, 02, 03.. 08, 09, 10. The 8 and 9 tracks are in the right order, whereas with the leading zeros, the 8th and 9th tracks had no track listings in their properties.

Interpreting them as octal or something?

Empeg guys, you see this? Is this one already on the internal bug list?

Assuming that this is the "leading zeroes get treated as octal" bug, then this one is on the internal bug list, it's marked as "fixed" in February. When was beta 11 released? Anyone?

In reply to:

---

When was beta 11 released? Anyone?

---

8th February. HTH.

Okay, the fix listed in the internal bugbase post-dates the release of Beta 11. So I think the bug described in this thread can be classified as "known bug FITNR".