I'd be interested to see what the skip protection was like when playing a vanilla audio CD in the laptop CD drive they are using though - I suspect it's almost non-existent.

Unless, of course, they're using realtime DAE on the drive and streaming cached wave data. But that's probably expecting a little too much, then, isn't it?

___________
Tony Fabris

If the architecture is like I suspect it is, then yes this is expecting too much. The audio path is connected only via the MP3 decoder (I guess they've added an analog mixer to mix in the audio outputs from the laptop CDROM) - at no point does the CPU actually deal with uncompressed audio. This is only going by what their other products are capable of though, I could be wrong. We'll see...

Hugo

Unless, of course, they're using realtime DAE on the drive and streaming cached wave data. But that's probably expecting a little too much, then, isn't it?

Actually, I'd be pretty upset if they do that yet claim to "play audio CDs". I have several CDs that play just fine in most players but are impossible to rip with any drive/ripper combination I've tried. I can't even return those to the store since they play just fine on their demo system. OK, I have to admit that some of those are of questionable origin...

Borislav

Try Exact Audio Copy. It copied out a hugely scratched maxi single CD of Concrete Blonde (Caroline) with no pops/errors whatsoever. It's slow but Wow. The download link is:

http://www.exactaudiocopy.de/eac6.html

-Zeke

just say you weren't paying much attention...

I don´t see how you could realize the current functionality of storing only one playlist/song no matter how often it is referenced by other playlists.

Quite simple really, a file copy from the empeg to the empeg would create a reference to the file or folder (additional database entry) rather than a copy just like it does with emplode.

This seems simple from the users view, but detecting such a "local" (to the USB drive) copy is not easy. While local moves are usually handled by just moving/renaming the link to the beginning of the file, local copies are usually handled the same way that non-local copies are: The OS reads the originating file and writes the destination file. There is no way for the device to know wether a write access is for a copy or a new file, except for accepting the whole new file and comparing it to existing ones after it got closed. Then again, the device has no really convenient way to know even when a file gets closed, it might just as well only be a file being flushed.
To get to the point of this all: A USB hard drive does not see any file opens, file writes or anything similar. It only sees sector/block reads/writes.

cu,
sven
(MkII 12GB blue now green, #080000113)

To get to the point of this all: A USB hard drive does not see any file opens, file writes or anything similar. It only sees sector/block reads/writes.

OK, nobody is agreeing with me and I guess no one got my point so I am going to stop bothering soon. I was suggesting the the empeg emulate a USB drive, not that the computer would be talking directly to the drive within the empeg. Since the empeg would be emulating a hardware device it could keep track of reads and writes and deal with making links instead of copies. I.e. if the OS reads x number of bytes from a certain location and then writes the same number of bytes to a new location and both files have the same name assume that they are the same file.

Actually for me at least this problem would be irrelivant as I only have one reference to each song on my empeg and I never really got the point to having multiple references (I prefer to create playlists dynamically using the search functionality).

-Mike

I think we know what you're suggesting, but at the same time it seems you don't quite realise how filesystems work under Windows (and most other OS's). To make something work like a standard Windows storage device isn't too hard - to make something work mostly like a standard Windows storage device, but with bells and whistles, is a lot harder.

Rob

my bad.. well.. last i remember, it was stated that the mk2 was not really a second model, only a revision of the first. that's why i said empeg2, not empeg mk3.

12gig red mk2 -- 080000125

I never said it was easy and I think I have a pretty decent understanding of what would be required. I just have high expectations! Designing an in car computer with the functionality of the empeg that will fit in a standard DIN slot is not exactly easy either.

-Mike

I never said it was easy and I think I have a pretty decent understanding of what would be required. I just have high expectations! Designing an in car computer with the functionality of the empeg that will fit in a standard DIN slot is not exactly easy either.

Its not just "not easy", it is outright impossible using todays hardware. There are two reasons for this:

1. The operating system (Win/MacOS) is a multitasking system, so writes to different destinations on the same drive might mix with each other. This becomes even more likely with caching systems that accumulate writes before flushing them, ordered not by file but by physical location of the file.
   
2. Because you might have multiple copies of the same file on the device (virtually), you can´t give a correct value of the (virtual) drives size, because the OS really sees say, 10 copies of a file (not knowing that they are copies), but they only take the space of 1 copy. What if you decide to add one more copy of(reference to) that file, but only half the space needed for the file is actually free on the drive? Using emplode, this won´t be a problem, but using the file interface you suggest?

There are even more things. Because of the first point above, the software on the empeg would have to accept the file writes, than search the whole drive for possible dupes (probably using content comparison rather than mp3 tag comparison), remove the dupes and replace them by links to the first copy.
A legal issue is also important to consider: Currently, the empeg is a "write only" device, you can´t get the files back from the empeg without fiddling with the developer image etc. This keeps empeg´s back free from legal issues, as discussed several times before. But if you were emulating a USB drive, you would be able to retrieve the files back (if you weren´t, the whole reason for implementing the file interface would be defeated, I think).
The issue would be completely different, if:

1. the legal issue about fetching files back from the empeg would get solved, and
   
2. one used the same fid-structure on the local disc as on the empeg (which would be just great if players for Windows/MacOS etc. existed that were able to use this layout).

cu,
sven
(MkII 12GB blue now green, #080000113)

I also wondered about an interface to the empeg over USB and had a much simpler approach : run a service on the win32 machine which listens on some TCP-ports which get forwarded over the USB link to the empeg. Suppose I had port 21 forwarded to the empeg, where an FTP-daemon is listening; an ftp to localhost would result in ftp-ing the empeg. It would probably also be possible to do the same for a samba server, which brings me to the point of linking files. AFAIK the CIFS protocol does smart copying; if a file on a remote server is copied to a location on the same server, the data isn't transferred to the client machine, but the server copies the data internally. This scheme could be used to automatically link copies to the actual data.
I allready had a connection to the empeg over USB, with the use of windriver software.
Empeg Guys, would it be possible to give us a small example of how to connect to the empeg over USB on win32 using the empeg VXD's ? I've tried the CreateFile call, but what should device.c_str() be?

Frank van Gestel

I've tried the CreateFile call, but what should device.c_str() be?


Never mind, I've got it working...



Frank van Gestel

It looks like you couldn't take this device out and hook it up to a home stereo or a set of speakers... that's an advantage the empeg has.

I have a cd-playing headunit anyways, so I would see no reason to upgrade to this...