It's time for an update on the next software release.

First, it's not going to be called 1.1 after all - it will be release 2.0. There are a number of reasons for this, including there being a lot of new functionality, and avoiding potential confusion with the 1.0x branch.

Although Alpha testers have had the new software for several months, we have not been fully focussed on it for much of that time. This has been due to settling in as a division of a new company, and to a greater extent because of our comittments to the development of other products. You'll hear about those other projects soon, but I do apologise for the delay in car player development.

The good news is that from early August thru Q2 2002 we will be working almost exclusively on the car player software. The first priority is to finalise the spec for 2.0, complete alpha testing, and get a public beta released as soon as possible. In practice we believe that beta will become available at the end of September - I'll refine the date as the alpha phase progresses.

At the same time - and independently of the 2.0 schedule - we are reopening the voice recognition project. You may recall that we recently recruited John Graley, who joined us from the application team at ARM, and his priority is to progress this area of functionality. We'll update on this from time to time.

After 2.0 we have a number of exciting ideas including a revisit of the UI, but I'm going to hold back the teasers for another time

Rob

How nice that you are sharing your development schedule with us, it is indeed very good news!
I guess you will not release the v1.1 alpha (out for a while) as a pre-beta 2.0 then, will you? However, I would love to install it for just the extra visuals only!

Edwin de Vaan
mk2 rev.7 # 080000263 (queue 1232) 6+20Gb blue/red

Make that two of us.
Maybe you guys could release alpha releases as well after one would sign an online waiver or something stating no liability.
That way we could see how the softwares progressing and you guys wouldn't be hounded with "when is it coming", "where are you in development", etc, etc.

Steve

> Maybe you guys could release alpha releases as well after one would sign an online waiver

That's not going to happen. As soon as a build is considered "safe" then a public beta is released. If we get through 4 or 5 betas before a consumer release - and if you guys want to download them - then we're happy to let you have them.

We're not happy to let you have Alphas, for a number of reasons, primarily that during intensive testing periods there are new releases almost daily (and we don't have the bandwidth for 1000 people to get them every day, even if you were willing to do so) and those releases sometimes have serious bugs.

As an example, earlier in the alpha phase of 2.0 we discovered a bug which would scrap all of your music after synchronising a certain number of times. Luckily we caught it after the first couple of reports - alpha testers are well aware of the risks, but others may not be.

Finally, alpha testers get to see things which have not been announced. They are under NDA for this purpose. Sometimes the code they test (new CODECs for example) is under a development licence and cannot be distributed more widely.

So, sorry folks, but most of you will have to wait for 2.0-beta1.

Rob

As an example, earlier in the alpha phase of 2.0 we discovered a bug which would scrap all of your music after synchronising a certain number of times.

Yeah, wasn't I one of the ones who got bitten by this one?

Heh, you guys oughta be glad Empeg doesn't do publc alphas.

Finally, alpha testers get to see things which have not been announced. They are under NDA for this purpose.

And, of course, there's the painful initiation rituals, too.

________________________________
Thank you sir, may I have another!

In reply to:

---

And, of course, there's the painful initiation rituals, too

---

Personally speaking, I'm more than familiar with bizarre initiation rituals, painful or otherwise but I bet that isn't enough

So I guess I'll wait....
...Hugo's hint about the tuner availability cheered me up no end though

Geoff
---- -------
Got one of the first Mark 2 empegs...

Well it was just a thought. I'm sure their are a few of us out here that would like to be a part of alpha testing, but I guess I'll wait since I don't really have any other choice.

Greetings!

Trust me, I can wait. It has taken me almost 4 days at 24 hours a day in order to reload the empeg after the disk upgrade. I would queue up about 10 GB worth, the most space I can scrounge on my local hard drives, and set it up to run overnight. The last thing I would want is something to blow away the music partitions. But I would like a nice, easy to use, built in backup system as part of emplode...

Paul G.
SN# 090000587 (96GB Smoke)

So would I. Believe me, the more I use empeg, the more I love it. And the more I miss such a backup feature. Anything that can save the files AND the database in the empeg in case of failure of the empeg hdd would just be great. I am spending so much time in entering all the info in all my mp3s, and the empeg is slowly becoming a extraordinaru music database. Year, genre, Comments, Version... Just amazing. Now, the simple idea of a hdd crash a nightmare for me...


Taym
_________________________
MK II BLUE/RED 12GB #923

But I would like a nice, easy to use, built in backup system as part of emplode...

My absolute #1 priority on the Wish List. It need be no more sophisticated than an icon I can click on in Emplode that will creat a single large TAR file on my PC's hard drive or a network drive. This file need not be readable, editable, playable, or usable in any fashion whatsoever other than to have the capability of being copied back into the same empeg that created it (serial number check?) to do a full restoration after a hard drive crash. This restricted backup capability should alleviate any fears of Rio enabling music piracy.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

I'm astounded that it has taken so long for someone to start working on what should be a relatively simple project to accommodate certain requirements that Rio are unable to satisfy for reasons of their own. It looks like somebody has finally begun such a project.

Of course I couldn't possibily approve, but it's open source so what can we do eh?

Rob

Right right right!
The single large TAR file is simple and great., That's what I suggested as soon as I entered this crazy great BBS, and, as I said before, the backup does not have to be readable, playable, etc. (Again, some smart immoral hacker may find a way to turn the TAR/RAR/ZIP archive in anything he/she wants, but that's another story, right? ;))
But we need the backup!

Taym
_________________________
MK II BLUE/RED 12GB #923

You guys don't seem to take a hint. I don't think Empeg can write that backup utility for various reasons.

There's a project in the programming forum that allows you to grab files off the unit via Ethernet, and EmpegTaxi does the same thing, except via USB.

In both cases, they do their work one file at a time. But with a small bit of work, they could both be made into full-fledged backup utilities that don't require modification of the installed software.

The only thing is that I would like them to back up the database information, too. I think that's pretty do-able, too.

So, guys, wanna modify your utilities into backup programs?

___________
Tony Fabris

Part of the changes to the Alpha 7 version of empegTaxi were to add multiple file download support. (It's not enabled in the UI yet, as it needs more testing)

However before making it a full backup utility, I need a checksum routine on the empeg to ensure the files transfered correctly.

Watch this space....

(anyone recommend a good c++ book?)

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

Regarding checksums:

One thing that has come up in Alpha testing is that the empeg guys sometimes ask me if I have the correct file based on an MD5 checksum of a given file. There is open-source stuff on how to generate an MD5 checksum on PC files. If the empeg itself came with an MD5er built-in to the developer software, that would solve your problem.

Is there an MD5 checksum generator on the developer image?

___________
Tony Fabris

I can't find any MD5 program on my empeg... =(

However, that's the sort of idea I had in mind...

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

you mean the one like they would be sued by the horrible recording companies of america

would someone unrelated to sonic blue writing a backup utility prevent that from happening in this society of too many lawyers and not enough logic I doubt it

32Gig MK2 In 2001 VW Golf TDI

Hi.

I'm not sure wether the md5sum binary is part of the developer image, but a binary can be found in the tools-binary-empeg-1.0.3.tgz file on my homepage (preview).

cu,
sven

proud MkII owner (12GB blue/green/smoked, #080000113)

If it's not included in the default developer image, it's probably not what Jazzwire's interested in. I think the idea of EmpegTaxi is for it to work without adding software to the player.

What other options are there for generating a checksum at the command line on the player?

___________
Tony Fabris

Tony, sure we didn't? Of course we took the hint. I think we all read the legal issues involved in the backup thing, and we all understand Rob's point of view ;) The reason why I said we need a backup, leavig my joke about the evil hacker apart :), is exaclty what you pointed out, that is: no current project of feature or third party sw allows a real backup. The empeg info database is left out. So I am doing exactly what you're doing: encourage anyone of the great people in here who has time and capability to make a good complete backup sw for the empeg. :) And of course to them goes my thank you! :)

Taym
_________________________
MK II BLUE/RED 12GB #923

Of course I couldn't possibily approve...

Really, seriously... would piracy be an issue if the software were written as I described: produce a single large file, unreadable, uneditable, unplayable, flagged so it could only restore to the same empeg that wrote it? You could encrypt the file header, using the empeg's serial number as the decryption key. (Is that serial number hard-wired in the empeg?)

From my position of invincible ignorance, it seems like this should be an easy hurdle to cross.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

Really, seriously... would piracy be an issue if the software were written as I described?

Maybe, or maybe not. But mainly, I think that the Rio folks aren't interested in becoming a "test case".

Here's my take on it (correct me if I'm wrong):

Making a copy of the music files is what would make the RIAA angry. Whether or not those files are stored in an encrypted format probably has nothing to do with it. The fact is, a backup is a copy. And although there are some rules regarding allowable backups of computer software, there are no such rules protecting digital copies of music CDs.

The only rules about copying music CDs are those outlined by the AHRA. If it's a digital copy, it has to implement SCMS. And SCMS has a very specific set of standards-- an encrypted tarball isn't part of the SCMS spec.

The only reason you can get away with doing the same thing on your PC is because PC's are specifically protected by the AHRA. The RIAA would probably like to see that changed very much, but here's my point: By the letter of the AHRA law, Rio can't allow the Empeg Car to make backup copies unless they specifically and exactly implement SCMS. It's this same "letter of the law" that allows audio-extracting CD-ROM drives to exist at all. So you can't have your cake and eat it, too.

I'm sure the Rio people have thought this through very carefully. They know how to implement SCMS, but trust me, you don't WANT them to have to implement it on the car player.

___________
Tony Fabris

This functionality is already in displayserver. There's a 'System Backup' link on its homepage which when clicked produces one huge tar file of the entire contents of the empeg. One could use wget or some such utility to automatically download the file without having to use a browser.

The only reason you can get away with doing the same thing on your PC is because PC's are specifically protected by the AHRA.

But that's the point -- the backup copy would be made to and kept on the PC. Or am I misunderstanding something here?

tanstaafl.



"There Ain't No Such Thing As A Free Lunch"

This functionality is already in displayserver.

Call me a wimp and a weenie... but I don't want to deal with the hassles involved with a non-standard kernal.

I'm not sure, but I think displayserver does not save the database file. Correct me if I'm wrong, please.

Also, displayserver requires some hoop jumping -- export to a csv file, use that as an "index" for retrieving the song files, something like that. I just want to hook up my USB cable, click an icon on my desktop, and walk away and leave it running overnight and come back the next morning and know that my data files and song files are safe.

Finally, I think the "4 GB bug" is still unresolved -- where the transfer stalls after about 4 GB.

I don't need to extract songs from my empeg (Jazzwire's EmpegTaxi will do that). I just want the ability to create a disaster-recovery file that will leave me "whole" when (not if) my hard drive finally craters.

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

Am I correct in assuming the AHRA is an American law?

If so, then someone outside the US could write a nifty empeg backup utility, and providing they don't travel to, say, Florida to give a talk on, say, 'empeg backups: Theory and practice', then there's no chance of them being thrown in the slammer for it.

Is that about right?

Geoff
---- -------
Got one of the first Mark 2 empegs...

Hi,

Untill only a few month back, it was restricted by law in Denmark to copy any digital media. E.g. I couldn't legally make a spare copy of my audio cd, or copy my cd onto a tape to play it in the car (yes, currectly - i only have a tape player in my car, because i still like to listen to radio.) Atleast now they changed to law so that digital copying is legal for private use. But what i'm saying is that there is probably a lot of local rules that requires a great deal of work for the rio/empeg guys to read into, or deny selling in some contries.

Regards,
Kaare

Regards,
Kaare.

Mark II - S/N: 702

Copies of software and audio files for private purposes are legal in Germany, too. You are just not allowed to sell them or make them available to foreigners. Sharing with friends for private purposes is ok, though.

Also, copying _any_ data for backup purposes is legal in Germany. So creating such a tool here (or in any other European country, I think they're trying to align the laws now) should be safe.

Till

I'm not sure, but I think displayserver does not save the database file. Correct me if I'm wrong, please.

The database files are created from the *1 files and contain no extra information -- they serve only to speed up access. An emplode sync causes them to be rebuilt from scratch.

Peter

If it's not included in the default developer image, it's probably not what Jazzwire's interested in. I think the idea of EmpegTaxi is for it to work without adding software to the player.

What other options are there for generating a checksum at the command line on the player?

sum, cksum... none of which is there by default. If idea is to command the player to send a FID, then I don't see what can we do (except to rely on heavy error checking transfer routine is supposedly doing). If, however, we can execute a script on empeg, then perhaps tar with one of compression options could do.

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green