Ok, so I love V2b of emplode, it has allowed me to fully sort out all of the database information and get everything in tip top order. Now there is a problem in that the original files on my PC do not have all of the correct tag info. So back to the yet unresolved subject of backup.

I can create an app which will trawl through the FIDS and update the tag information as required, but to do this I need to get all the FIDS back onto my PC.

I am looking for the simplest most basic way to get the contents of the empeg onto the PC. Serial is too slow so USB or TCP seems to be the way forward.

What do you chaps recommend, I have no problem sending the app to the empeg and running it but I do not want to do any other configuration/load distributions etc.

Has anyone else done an ID3 app which sends the FIDs back to thier original MP3 state (with updated tags) to save me some work?

I may be misunderstanding what you're asking for here... But couldn't you just update the tags with a command line tagger residing on your Empeg? Just mount your music drive RW and do something like this pseudo-code:

foreach fid file ending in 1 (ascii "tag" files)
do
grab fields from fid (title, artist, comment, year, genre, etc)
pass them onto command-line tagger, passing the corresponding *0 FID's filename
done

If I knew of such a command-line tagger (I'm CERTAIN they exist) I would recommend one. Maybe others do... I know the shell script to do this couldn't possibly exceed 10 or 15 lines.

Any problem with this strategy? The MP3's would be edited in-place on the Empeg, saving the long and difficult journey from Empeg to PC and then back to the Empeg.

You are not fully misunderstanding.

Your method is not without merit but the fact is I know what I am doing in VB but have no idea with Linux and don't want to change the content of the player without knowing it is going to work perfectly. My main goal is to put all the files back on the PC with the correct filenames and tags from the versions I have edited in emplode. This way if the worst happens, I can send it all back to a new empeg without doing the 6+ hours of tag maniplation again.

I have around 250 CDs which were ripped with audiograbber/lame. not all of the CDDB info is the way I want it in the discs.txt file so I have done some tag editing on the PC before sending to the empeg. I have then done some more to iron out inconsitencies on the empeg with emplode. I want the whole lot back on my PC again.

Thanks for your idea anyway.

Hi,

I found stupid FTPd at SMUs site (thanks SMU!) and it seems to do what I want, I now just need to write the VB bit but I got a good ID3 OCX that I plan to use.

So it basically sounds like you just want to install a FTP daemon, leech the contents of /drive[01]/fids, and work on them on your PC, right?

Sounds great. Share the wealth when you're done, for people who don't mind sucking down the entire FIDS directory, this would be a good backup solution.

So I'd expect there are more of us out here than just yourself who'd like the very same functionality. Any chance you'd share you final tool for the rest?

Thanks.

I'd really appreciate it if someone with more linux experience than me could throw something like this together. Even if it wasn't perfect, just having the tag editor compiled for the StrongArm and the basic workings of a script would be enough to customize it and make it work for everyone. On my 10G player, this couldn't take more than about 5 hours, assuming 10 seconds/track.
Is anyone else interested in this?

Good idea. How about someone with crosscompiling toolchain in place port some of a myriad of command-line taggers, for example this one based on id3lib. (Actually, id3lib used to come with a decent sample command-line util, but I am not sure it still does. My copy went with the smoke from my Linux laptop.)

I'll see if I can give it a quick try later tonight. If things go well I'll try to throw a script together.

In the thought pattern of all this.... i have a question about emplode for the empeg guys...

How hard would it be to modify emplode to be able to do what it does on the empeg database (as far as modifying tags) to files on the hard drive?

I know the song info is kept seperate on the empeg and all that, and that you guys aren't in the game to make a tag editor... but the functionality you've built into emplode for tag manipulation is kick ass and it would make sense to be able to modify all the tags on your hard drive before uploading them to the player. Then we wouldn't have the situation that a lot of people seem to be in where they made a ton of tag changes on the empeg and don't wanna have to do it again should they loose their data on the empeg. I know there are other taggers and all the other goodies i'm sure i'll be told negate the need for such a thing, but i'm just purely curious what it would take to get emplode to be able to tag files before uploading. Any ideas?

This has already been discussed. They would like to turn Emplode into a full-featured tag editor, especially since the new 2.0 features have made it a pretty darn good tag editor.

However, writing that data back to the PC is tricky because Emplode currently does not keep track of where it got the files from your hard disk.

They would like to turn Emplode into a full-featured tag editor,..... However, writing that data back to the PC is tricky because Emplode currently does not keep track of where it got the files from your hard disk

that's all i wanted to know. Thanks =]

"This has already been discussed" and "they would like to..." doesn't equal a wish list entry, does it? Is this formally on the list, and if so, do they really want to do it, or is it just a "would be nice" feature? Can we think about it for the version 2.1 timeframe, maybe?

It really would make emplode a killer app wouldn't it?! =]

How about this idea for Emplode 2 then.

Instead of Emplode doing everything itself in this area, why not leverage the current feature set in emplode [e.g. the manipulating and working with MP3 'file sets' and associated ID3 tags and 'resyncing'] and leaving the implementation of the 'reading/writing/updating' of MP3 files and associated ID3 tags to a [yet to be developed] COM object [aka a Windows plugin] that someone else other than the empeg/Rio guys (i.e. one or several people on this board) can write for emplode.

All we need from the Empeg folks is for them to publish a standard COM interface supported by emplode that we can use for this purpose.

We can't do this without this interface and we need the Empeg guys to come up with [or at least agree to our proposed interface and then implement it in emplode].

I would envisage a very simple interface with only a few methods. I'm thinking like a very focussed and stripped down 'plug-in' interface here, a bit like the Winamp plugin SDK only much less work all round - I don't see we need a vast array of methods etc - just enough to let emplode be able to get and save the tag information from files we read/write/update for it.

The 'read' method on this interface would allow the emplode program to request a 'set' of MP3 files and associated tag properties [similar to connecting in emplode to your player now, except you'd connect to your 'hard drive' via the COM interface - there may be UI issues here in that the COM interface may have to ask the user for the directories etc to 'read in' ]. For that purpose we may need to implement a 'initialise' method also to let us obtai nthis information from the user and/or from configuration information from somewhere (e.g. the Windows Registry)

The 'save' method would let the emplode program save this [possibly changed/rearranged] set of MP3 files and associated tag properties back to the files where the ID3 information is actually stored.

The interface COM object would be responsible for the implemention of the actual file/directory reading, remembering which file, which ID3 Tag info came from, then when it gets the set of MP3 tags back from emplode, working out the updates needed to the on disk MP3 files that have had their information changed within the emplode UI. Then updating these files with the new ID3 tag information.

While its not a simple task to do such a interface it would free the empeg guys up to do their regular jobs and/or improve the player software. The only work the empeg guys need to do is to spec/agree to the interface and produce a emplode that can invoke the the interface - we can then build the COM object seperately and glue them together.

Think of this idea as a Windows equivalent to the 'userland' break out menus hack that others are working now to allow 3rd party developers to use the Empeg menus from 'user' [as opposed to] Kernel level apps in the empeg/rio car player.

I am putting my hand up as someone who is willing to write such a COM add on for emplode [I don't mind if we open source the plugin object - but its really up to the Rio guys to decide if they want to open emplode up in this way but as emplode is the property of Rio and is not GPL'ed they do not have to do any of this].

The only problem for me is that I don't do C++ only VB6 - but for Windows thats not such a issue if the emplode guys design the COM interface to emplode so that they are 'language neutral'. There are enough Windows ID3 tag libraries around that we can use for the ID3 stuff, or we can write our own/ use a GPL'ed version already out there for windows now.


I envisage that the 'installation' process add-on would be pretty seamless as the current emplode installation is - the installation could be done as a seperate download which during the installation informs emplode that its available so emplode will now be able to work with disk based MP3 files for tagging/renaming purposes, or it could even be bundled with the next version of emplode on the installation image - depending on how the software is licensed etc (e.g. under GPL or not).

Thats my suggestion. So, any takers out there for this idea?

Or has someone got a better idea?
Personally I find the new emplode UI fantastic and I would prefer it as my mp3 tag editor - even if I had to pay to do so - most of the other tag editors out there are not as good.

The major benefit for Empeg/Rio owners is one place to update/wrestle with your MP3 tags from - whether on your PC's hard disk or on your car player.

It's on my personal wishlist. This means:
a) It's not formally on the list.
b) It's definitely a "would be nice" feature.
c) It's not going to be scheduled.
d) It'll get done in my copious free time.

Of course I will be happy to share "when its finished" (am I allowed to use this saying or is it tradmarked by empeg Ltd ?)

I intend to put it on Riocar.org when done.

Thats it, I want to get the *0s and *1s, get the info from the *1s, apply it to a V2 tag in the *0s and then store them in a folder for each Source. This will pretty much recreate a flat folder full of albums, of course it would be better if I could enhance it so that it also stored them in playlists but I dont know how to handle duplicates across playlists. On that note, I seem to have accidentally dropped an M3U onto emplode a while ago and it added all of the tunes it contained! I didn't know it did this !! This means I could in theory, create a directory structure on the PC which resembled my playlist structure on the empeg, populate it with m3us then just drag the whole structure to emplode in case of loss on the empeg.


However (and this is a big one) Stupid FTP does live up to its name and will not transfer more than 200odd tunes at the moment. It seems to take ages to do a dir and is altogether flakey. Any ideas ???

Hi.

However (and this is a big one) Stupid FTP does live up to its name and will not transfer more than 200odd tunes at the moment. It seems to take ages to do a dir and is altogether flakey. Any ideas ???

Hmm, I had no trouble transfering my 1200+ songs including their accompanying FID info files. I do have other problems with it though.
I will probably strip stupidFTP (or another simple FTP server) down to a single-threaded, single-connection (at a time) server that remounts the /drive[01] mounts as needed to allow for PUT operations without prior commandline remounts. This is extremely tricky with multi-threaded, multi-connection servers, and I don't have the time to do that (remember, I am supposedly working on the nav'em project).

If anyone of the hackers in here would create a specialized empeg-FTP server, I will volunteer to create the installation procedure for it (probably a hacked .upgrade file including displayserver and other software, if I get the authors' permissions).

Is there any interest in patched .upgrade files that include additional software?
Are the guys@empeg (resp. @sonicblue) allowing me to include the player binary in such upgrades? If so, I would do that and incorporate the additional software to the original root partition. If not, I will simply tell the kernel to use /dev/hda2 instead of that partition and add some scripts there to start all that software followed by the original init/empeg software from its original partition.

Also, I need some beta testers for my upgrade files, at least one of each of the following configs:

• MkI
  
  • single drive
  
  
  • dual drive


• MkII accordingly


• MkIIa accordingly

cu,
sven

Well My VB stuff is now working properly on the FIDs that I have managed to get onto the PC but I would like to test it on the whole lot before releasing it into the wild.

I still cannot manage to get all of the FIDs onto my PC with Stupid FTPd.

I would be happy to offer a MK2 Dual drive for the FTP .upgrade test.

Can anyone else give me an FTPd which works 100% ?