(J)em(peg/tool/plode)

There's a confusing plethora of tools to manipulate one's empeg music and I'm struggling to find one that I consider the best (acceptable even). I'm having some problems and hoped for some advice. I have about 1000 albums sorted into an Artist/Album directory structure, all mp3s with correct ID3 v2.3 tag info.

Emplode2 (Windows XP)
Dragging an artist's directory onto the playlists folder creates appropriate playlist entries, but for one of the artists (of the 3 I'm testing with) the soup data is entirely missing (well, all shown as 'None' in fact) and that's 100% repeatable. I could not correct that or see any reason why that artist's music files were any different.

Emptool (RedHat 8)
'Upload'ing the same artists had no such trouble, but then it apparently doesn't show any soup data and I've no idea whether what it does display is taken from the ID3 tags or the directory structure. However, it sync'd perfectly, even sending some spurious files (Mac's .DS_Store) up to the empeg which is NOT clever.

Jempeg/Jemplode2 (MacOSX 10.3)
First version I tried couldn't even find the same empeg using broadcast over ethernet. Direct entry of the IP address worked, but other things didn't once it had downloaded the database, like it couldn't delete tunes/songs.

Tried a later release of Jemplode2 and that seemed to cure the above problems. But having downloaded the database (after the upload from emptool above) there is NO soup data. The playlists are there, but the soup folders are empty.

When downloading the database from the empeg, where does the soup data come from?

I deleted everything and dragged the same artist directories onto the playlist folder I wanted and all is apparently well, with the correct data (well almost) showing in both the playlist folder and the soup folders.

Am I correct that the playlist data is created from the directory structure and the soup data is from the ID3 tags?

Why are 75% of the songs in the genre named '17' and not 'Rock' where they should be and indeed are ID3 tagged as such. 'Open'ing these entries and simply OKing the dialog box (the correct 'Rock' genre is already displayed) seems to fix it as this entire genre then disappears and they all correctly appear in the 'Rock' genre.

I then removed all the playlists, so only the soup data was there and sync'd. Ages later and all the music has apparently been uploaded to the empeg, but I'm buggered if I can find it there. The playlist section is simply empty.

So what's the point of all the soup data then?

How come music I'd uploaded with emptool had NO soup data when downloaded to Jemplode, yet when the same music is uploaded via Jemplode and the database later downloaded back again, the soup data IS there? Where is it stored differently by those 2 programs and why on earth would they do it differently.

Maybe there's a way through this maze, all I want is to take the data structure I've painstakingly created on my hard disk and put it down onto the empeg - not such a tough request I would have thought, but I've really no idea what is going on here.

Why doesn't someone (sorry, beyond my capabilities) write an interface to iTunes? Let that be the front end for manipulating playlists, maintaining the tags etc and then some form of plug-in to simply sync that down to the empeg. Adding anything that isn't there, replacing anything that's changed and deleting anything that should no longer be there - just like for the iPod. Now that WOULD be GREAT.

I responded to your email to most of these, but I maybe wasn't clear on one part:

In reply to:

---

How come music I'd uploaded with emptool had NO soup data when downloaded to Jemplode, yet when the same music is uploaded via Jemplode and the database later downloaded back again, the soup data IS there? Where is it stored differently by those 2 programs and why on earth would they do it differently.

---

There are two types of soups in jEmplode -- in-jEmplode and on-device. The in-jEmplode soups will ONLY appear in jEmplode and are not stored on your Empeg. The on-device soups are stored on your Empeg as playlists with a special tag that jEmplode understands. I'm assuming this is the kind you're referring to. The reason the programs do it differently is because Emptool doesn't do it at all. Soups on the Empeg are not actually supported. What you're seeing is some trickery by jEmplode to magically create playlists for your tunes that look like soups. One notable difference in the newest versions is that the old version supported going back and forth between jEmplode and Emplode (or emptool I suppose) and it would keep the soup playlists up to date. The newest version removed that and it will only keep soups up to date for tunes that were actually uploaded w/ jEmplode (it /may/ get new files, but it won't remove old ones).

ms

So, how could I bulk upload with emptool and then create all that 'virtual soup' data afterwards within Jemplode?

It would be useful to have that since it enables easy creation of new playlists based on the info in the soup data, such as year, genre etc. Ideally I just want to be able to organise by the ID3 tag data, but that seems to be under-utilised in these empeg tools.

If you made a new soup after your import with emptool it woulld work ... If you had an existing one, in the new version, it might not autoupdate for you, but you could delete and readd the soup and it would do it. Out of curiosity, why would you not use jEmplode (assuming you get it to work eventually ) to do the import also?

By the way, it's funny that you say you just want to organize by ID3 tag data, because the newer Rio products don't have all the cool nested playlists and people are complaining that they DON'T want to just organize by ID3 tag data . No point this, just interesting is all.

I found that after having the auto playlists (soup views) on the karma and central that it is easier to just do it the empeg way with the nested playlists. The soup views are limiting sometimes and if the tags aren't right it is easy to get messed up.

I didn't mean not able to have other playlists. But a lot of effort has gone into correctly tagging my mp3s and to have to re-create all that in order for basic artist/album type playlists is a non starter.

Basically I want it like iTunes. Drag songs into iTunes and they get displayed according to the tag data and you can then add other groupings as your own playlists - ideal. If you want, it will even keep the directory structure up to date as well.

Not that its perfect. Right now I can't get it to work with symbolic links. It won't import a directory of symlinks to real mp3s, but it WILL do it if the symlinks point to AAC files. But in that case it doesn't get their ID3 tag data, so it is not correctly resolving symlinks, which quite frankly is pants. I'll try it with Mac aliases and see.

As for why I want to use emptool, I want to bulk upload directly from the linux machine which stores the mp3s directly to the empeg. Firstly to avoid the double hop upload if I do it via (J)Emplode on the Mac or Wintel and also it's less likely to go wrong. There's 1000 albums of mp3s and I'd rather it all went in one go and no problems half way through. Also I have 2 empegs, so I will need to do it all twice.

For later updates though I'll undoubtedly use Jemplode.

Dragging an artist's directory onto the playlists folder creates appropriate playlist entries, but for one of the artists (of the 3 I'm testing with) the soup data is entirely missing

I'm wondering if this is due to this problem?

I had read that, but I cannot see that it's bad tag data. iTunes and MP3 Rage both report that there are 2.3 tags only and also both emptool and JEmplode import the same album with all the data intact, so I'm inclined to believe it's an Emplode problem.

Someone else reported problems with itunes-tagged files because of the tagging format in question, it uses a slightly newer standard than Emplode expects. I forget the root of the problem or its symptoms, but I just remember that it was itunes-tagged files that were the problem.

But I didn't tag them in iTunes. The tags were created by the LAME encoder.

Have you inspected the files with a binary editor to see if the data is actually correct?

No, but then I wouldn't know what I was looking for. Since emptool and JEmplode don't seem to exhibit this beavious, I guess I'll stick to them.

beavious

I'm going to figure out how to use this word more often. I like it.

mp3tool (Linux) can be used to examine (or nuke) the tags.

beavious

Not familiar with this term, but Google suggested beavis as a replacement...

I don't know what it means, either, but it's a great word nonetheless.

In reply to:

---

beavious

---

I just hate it when my fingers do that.

That should obviously have been 'behaviour'.

I'm digging the originaly word as well ... So I gather it is:

beavious: (n) a strange and annoying trait

I'm going to try and use this at work today ...

Hm, how is that pronounciated [sic]?

You said Sick! heh. heh. heh. Sick!

I need teepee for my buuung hole!

oh man. it begins.

In reply to:

---

Since emptool and JEmplode don't seem to exhibit this behaviour

---

I stand corrected.

Uploading more mp3s using emptool reveals that for some albums the 'tag' data is simply missing. But, I have discovered a common thread.

Since I had a lot of albums to encode I employed LameBrain on my Mac G4 and CDex on my Wintel to run in parallel and speed things up. The former program is based on the latter and I set both to use LAME -alt preset standard. I now find that the mp3s created by CDex give trouble whereas the LameBrain encoded ones are perfect.

Unfortunately I made some changes part way through and added the -V2 tags only option to LAME - those already encoded I stripped off the v2 tags with MP3 Rage and changed any v2.4 tags back to v2.3 using iTunes. So it's kinda tricky establishing what was done to what tags on which mp3s, but the common factor seems to be those encoded by CDex cause the trouble.

Can anyone suggest what is going on here and how I might be able to 'fix' those mp3s with the problem? Currently everything I have tried shows the tags exactly as I want them, so the problem is obviously a bit deeper. Is there an mp3 tag fixing program?

There's more...

I now find that the CDex created files lose their tags when being 'uploaded' by emptool, i.e. before any sync'ing is done. So it's emptool (and also exhibited by emplode) that is simply not 'seeing' the ID3 tag data. It's not the sync'ing that's the problem.

Just to confuse things further, JEmplode on the Mac manages to find the tag data corectly, on these same files.

Confused, I certainly am and would like to get to the bottom of this and get emptool's tag reading fixed.

Any ideas, clues etc?

jEmplode's tag parser is ported off of the same branch of Rio development as Rio Music Manager. I'm pretty sure there have been changes between tag parsing in the 2.x Empeg codebase and RMM's codebase. What you're most likely seeing is just old code with bugs that have been fixed in later Rio releases.

What are the chances that emptool will get updated to fix this?

I'd still like to know what it is that causes it to miss the tag data. If I could find that out, I might be able to modify the mp3 files.

I suppose you could try the emptool in the 3.0 alphas, but that comes with all the usual caveats ...

Worth a try. Where would I find that?

http://empeg.comms.net/php/showflat.php?Cat=&Board=empeg_general&Number=203091