Okay, I'm at an interesting point here, and I'm wondering if anyone can help me out.

I've decided that it's time for me to get a USB-capable high-capacity file taxi. Something to take huge files back and forth between home and work. I'm looking at a 20gb LaCie drive that runs about $199 if I remember correctly. This is a good option, and I might go with it.

But something I've had in the back of my mind for a long time is the idea that the Empeg is already perfectly equipped for this task, hardware-wise. I'm going to be replacing the failed hard disk pretty soon, and I'll have gobs of extra disk space. Since I've got this hardware sitting here already, why should I cart the Empeg and a LaCie drive back and forth, when, with a little software, I could just carry the Empeg (in its nice fasionable carrying case).

I don't have the cash for a Mark2, so I don't have ethernet. USB is what my Mark1 uses for its file transfers. The only problem is that all the FTP stuff I'm seeing on the BBS is meant for Ethernet. I don't think that stuff will run over USB (although correct me if I'm wrong).

So what are my options for turning the Empeg into a USB file taxi?

Note that I do not care about copying the music files at all. I'm just interested in making a little folder somewhere on one of the disk drives that I can call my own. I have no need for access to the FIDs.

I actually have this idea that this could be leveraged into an installable piece of custom software. For example, if someone good at Linux coding wanted to work with me, I could make the Windows user interface half while they worked on the Linux end. Imagine this: A custom kernel that includes new routines to handle the file I/O so that the developer image isn't required to install it. Then the Windows program fires up and talks to it via the USB port. When the Windows program starts, the Empeg quits the player software, mounts the hard disk R-W, and handshakes with the Windows software. Then the Windows software presents a little drag-drop folder screen so you can drag files back and forth from explorer. When you exit the Windows software, the Empeg remounts the drives R-O and goes back into the player.

This software could even make sure not to give access to the music files. That way, we could distribute it without fear of turning the Empeg into an AHRA-taxable item.

So am I dreaming or is this do-able?

___________
Tony Fabris

It all sounds great, I think the problem part is going to be talking to the USB driver at the Windows end. Any idea how to do that in VB ?

__
Unit serial number 47 (was 330 in the queue)...

If I remember rightly, back in the days before the MkII existed some of the guys on this board got TCP/IP running over USB (PPP?). Have a look back through the old posts - would be a good starting point for a project like this. I also reckon an empeg would make a much better zip/jaz/whatever drive

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 6GB blue)

I've thought about this for a while (although when I needed to use the empeg as a file taxi, I was able to dump a zip down via emplode then use the serial port to recover it), mainly because I have a spare MK1 sitting around the place =)

(Disclaimer: I haven't looked into the technical issues in any detail, so I might be spouting rubbish... =)

The emeg USB driver has to support 2 way transfers (it's how the playlists are retrieved after all), and we have the source to emptool, so we should be able to figure out how to push files backwards and forwards using the player software on the empeg talking to a PC program via the USB driver (If we can work out how to talk to the PC USB driver, I assume it won't have a com/corba interface?)

However, it's possible that the USB from the empeg to the PC would be slow (as it's unlikely to be optimised for large files going back to the PC).
It's also very likely that the player wouldn't be able to write the files into a "Taxi" subdirectory, so the they would be mixed up with the music, and there is the risk of it appearing in a playlist (although it won't actually play it) or being overritten.
Finally, if the Sync protocol changes, the Taxi program would need modification.

Just some random thoughts...
I'll have a poke at the USB driver at some point to see if it's willing to talk to me... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

I think the problem part is going to be talking to the USB driver at the Windows end.

Jazzwire also said this. Why would that be a problem? Doesn't the Emptool source give us some clues as to how to go about it?

Or for that matter, don't we have currently-compiled versions of the Emptool source that can use USB in a windows environment? Perhaps we don't even need to talk to the Empeg USB driver and can create our own based on the Emptool sources.

___________
Tony Fabris

If we can work out how to talk to the PC USB driver, I assume it won't have a com/corba interface?

We wouldn't necessarily need to talk to Empeg's installed USB driver if it's somehow proprietary. Then again, if we could, it'd probably make our lives easier. But talking directly to the Windows USB interface (skipping Empeg's driver) should have a lot of supporting example code in the MSDN literature so it wouldn't be an impossible task.

However, it's possible that the USB from the empeg to the PC would be slow (as it's unlikely to be optimised for large files going back to the PC).

Even if this were true, it would still be faster than a serial port, I'd think.

It's also very likely that the player wouldn't be able to write the files into a "Taxi" subdirectory,

Sure it would. You can create whatever folders you want at the Linux end. Right on the music partition. I'm pretty sure that the Emplode "free space" count would be correct, too.

You have to mount the music partition R-W, but that can be done programatically. We'd make sure the software handled the necessary stuff for this.

Finally, if the Sync protocol changes, the Taxi program would need modification.

No, not if we wrote our own programs to do the work at both ends. If it's our own code doing the file transfers, then we're not dependent upon Empeg's synch code at all.

Then again, if we talk through Empeg's drivers, the coding would probably be simpler. I'm guessing that their high-level "send a file" and "receive a file" functions in their drivers wouldn't be changing much over time. The stuff that would tend to change a lot would be the functions related to the player software and the database, stuff we wouldn't be touching.

___________
Tony Fabris

What would be possible is if there is a 'network' driver for USB on the Windows
platform, then one could install PPP on the Empeg, then you could use SAMBA, or ftp or something.

TommyE

Or for that matter, don't we have currently-compiled versions of the Emptool source that can use USB in a windows environment? Perhaps we don't even need to talk to the Empeg USB driver and can create our own based on the Emptool sources.

I thought that the Windows version of Emptool hadn't been compilable for a while ?
If you are going to create your own driver for USB for empeg then you are going to need a C++ developer who is up to speed on windows device drivers.

I can imagine having two drivers in place for the same USB device isn't likely to work.

Sorry to be so negative, but it sounds like hard work.

__
Unit serial number 47 (was 330 in the queue)...

You would need some code on the PC side to pretend to be a RAS connection and pass the data via USB to the empeg, so much the same problem.

Unfortunately unlike Linux you can't just treat any device much like another on Windows.

__
Unit serial number 47 (was 330 in the queue)...

It would be a grand undertaking and, although I'm not an expert on the hardware or software that's running the empeg, I think I can explain a little bit.

The main issue is that, while the emptool source does have code for talking to the empeg over serial, ethernet or USB, it's specifically about talking to the player software that's listening on one of those interfaces. It's documented (in source form) how to talk to the empeg over the wire, but the code is all built around talking to the player software to transfer music files back and forth. If you wanted to use the same codebase to transfer arbitrary files, you'd only be able to use the lowest-level code there was for physically communicating over the USB interface and then re-implement your own protocol on both the PC and the empeg side of things for actually doing the data transfer. (i.e. you'd have to write an ftp server that understood how to talk to the usb device on the empeg.)

It certainly should be do-able on both sides, but it would be quite a hack-job at trying to write an FTP client for Windows and server for the empeg that knew how to talk across the USB devices instead of sockets. (Probably much easier on the empeg side of things since Linux presents its devices is a much more consistent fashion, I believe.)

I don't run Windows to talk to my empeg, so I don't know for sure, but it also could be that the Windows USB empeg driver is specifically designed to talk to the player software and even if you could code your own client from the emptool source, you still might not be able to actually talk to anything on the empeg unless the player software was running, in which case the whole project would be moot unless you also wrote your own USB driver for the empeg for Windows that knew how to talk to your "server."

If you were lucky enough to be running Linux on your client, there is a relatively recent driver that someone has written that will treat an arbitrary USB device as a network device, which makes it butt-simple to establish a PPP session across USB. Some of the iPAQ guys are doing this. It's supposed to work great. You'd have to rebuild the kernel on your empeg to include this driver.

Other alternatives that I see are to a) get a Mk 2 with ethernet and reconfigure your empeg to run inetd and an ftp server or b) install the developer image on your Mk 1 and, using Hyperterm, get a shell prompt on your empeg and establish a ppp session to somewhere to transfer your files. a) works great but is expensive :( and b) would work with your Mk 1 but would be pretty slow.

...but the code is all built around talking to the player software to transfer music files back and forth. If you wanted to use the same codebase to transfer arbitrary files, you'd only be able to use the lowest-level code there was for physically communicating over the USB...

Unless there are already built-in functions for transferring arbitrary files in the player software. Odds on that?...

___________
Tony Fabris

Sorry if I didn't make it clear, but I was basing my comments on using the empeg player software on the empeg side... =)
I'm quite aware that you can create files and directories on the music partition... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

The USB driver provides a file interface actually, much like a unix device. I suspect there is stuff in the connection classes we released which will talk to this driver, though I can't check at the moment. We have had command line emptool running over USB on windows in the past.

Hugo

Thanks for the hints, Hugo!

Wow, sounds like it's do-able. Guess we ought to be looking more closely at the released Emptool sources, then.

If I understand you correctly, this might even be something where we'd only need to write a windows client? If we talked to the existing file interface on the player, we wouldn't even need any software running on the player. Now that would be suh-weet.

___________
Tony Fabris

Which is what I was thinking in my post above... =)

I've had a bit of a peek at the Emptool sources, and I haven't yet found a magic direct-file interface. I know so little about the Emptool sources that I don't really know what to look for. So far I've only seen stuff that assumes each file is a genuine FID. Maybe there's a way to extend the FID spec so that we can add FIDs of our own that the player will ignore (for instance, maybe the FID filename could have a 2 in place of the of the current 1 or 0), and then we could index the files ourselves in our client software. A daunting undertaking, of course...

___________
Tony Fabris

You'd have to make it use FIDs for file storage, and understand the static database format (all this is in the emptool sources) but if you added files with the 'type' field set to something apart from 'tune' or 'playlist' (eg, 'file'?) then the player would ignore them & you could deal with them as you saw fit.

In theory, the easiest way to do it would be to modify emptool (or the java version) to be able to download files from the empeg, and to support files which weren't ".mp3" (no tags, etc) - then you don't have to write a while new app.

Hugo

Thanks, Hugo. I think I'd come to that conclusion, too.

Who's working on the Java version, and would like to take a stab at adding this kind of functionality? And does the Java version support USB?

Personally, if I could have just one single .ZIP file with a single hard-coded FID on the player that I could call my own, then I'd be happy. I could manage the zip's contents myself on the PC's hard disk and just store/retrieve it from the Empeg as I hop back and forth between home and work.

___________
Tony Fabris

mschrag is the primary (maybe only) guy working on the java version. AFAIK java (the language) does not support USB however. There may be extensions to support it on some platforms, but it is not part of Sun's spec as I understand it.

-Mike

To expand upon Hugo's response:

FID suffixes are reserved by empeg. Currently, we're using 0 and 1.

Don't rely on them being unused forever.

Currently, as Hugo says, the correct thing to do would be to set the type to something other than 'tune' or 'playlist', which should cause the player to ignore the item.


Roger - not necessarily speaking for empeg

FID suffixes are reserved by empeg. Currently, we're using 0 and 1.

And, in 1.1, F (the dynamic data).

Peter

I thought the FID suffixes and the file types had a 1:1 correspondence in the code.

If I set the file type to something different, but I don't change the suffix, won't that confuse the player?

___________
Tony Fabris

I thought the FID suffixes and the file types had a 1:1 correspondence in the code..

No, it's like this:

The *0 file stores the data for the particular item. In the case of tunes, it's the MP3 data. In the case of playlists, it's a list of the FIDs contained within that playlist. The FIDs are stored as a simple sequence of unsigned 4-byte quantities (little-endian). They also store the low 4 bits (one hex digit) of the child FIDs, although these are always set to zero.

The *1 file stores the tags for an item. This is the stuff that you edit in emplode. It's a simple tag=value format. One of the important tags is 'type'. Currently, we use 'playlist' and 'tune'.

The root playlist is stored in FID 0x100, i.e. /driveN/fids/100. Its tags are in /driveN/fids/101.

If you change the type to something other than 'tune' or 'playlist', the player should ignore it.

So, to summarise: Put your data in the *0 file, and then describe it in the *1 file, making sure to set type to something other than 'tune' or 'playlist'.


Roger - not necessarily speaking for empeg

Thanks for that information, that is very helpful.

___________
Tony Fabris

Blimey, this sounds as if FID 100h is a single-point-of-failure for the whole playlist structure. What happens if you develop a bad disk sector right in the middle of this file?

One of the few remaining Mk1 owners... #00015

> What happens if you develop a bad disk sector right in the middle of this file?
I suppose all files go to "unattached items"

Frank van Gestel

Blimey, this sounds as if FID 100h is a single-point-of-failure for the whole playlist structure. What happens if you develop a bad disk sector right in the middle of this file?

Blimey, it sounds as if main() is a single-point-of-failure for the entire of the player program. What would happen, I wonder, if I developed a bad disk sector right in the middle of the player program?

I don't think modern winchesters just develop bad sectors just like that. The only time I've seen a disk develop a bad sector, was immediately prior to the whole thing catastrophically failing.

Thus, the answer is, if you develop a bad disk sector anywhere your empeg is probably going to be hosed quite soon. So it's a good thing this almost never happens.

And anyway, if just fid 0x100 was wrecked (perhaps by a power outage during sync), then the database rebuild code in emplode would notice that there were a lot of orphaned playlists and tunes, and they'd pop up in Unattached Items, from where you could move them back to the right place.

Peter

So can anyone tell me how I might write a script to read this file, and translate this "simple sequence of unsigned 4-byte quantities (little-endian)" into fids that i can work with?

I have an mp3 server i wrote so I can get to my collection from wherever. I copy all the fids directories onto my webserver, and then I dump the database using emplode to CSV, import to a MySQL database, and use aPHP script to serve the files from there. I'd like to kick out that MySQL database step, and script it to use the *1 files instead.

I'm looking at fid 100 to get the contents of the root playlist, though I'm not sure what I'm looking at or how to use it..or change it to something I can use.

The Hijack source code, in the file "kftpd.c", knows how to parse and interpret the various files from the FIDS directories. But due to space constraints in the kernel/flash, the code is rather "tight".. But if you can figure it out, it does provide a demo of how to use the tags and playlists.

Cheers

So can anyone tell me how I might write a script to read this file, and translate this "simple sequence of unsigned 4-byte quantities (little-endian)" into fids that i can work with?

In C, just load them into an int array. In a script, try "od -An -t x4 -w4 < fids/100".

Peter