Any setup where the music is a file by itself will work with squash. You just can't put all the files in one big file (ewwww).

The playlist format of the old player seems to be just a list of numbers (representing filenames). That's fairly useless for me. So I just added a master list that is autogenerated and then used for ever other load of squash. Load time is about 5 seconds.

Right now squash is writing statistics to disk

So you're leaving the filesystem mounted read/write? What happens when you pull the power? A thirty-minute fsck?

This screams for ext3

Well, actually not. I would just point you to my code on this (it's the stat.c file in the squash tar ball) but I guess we are all terminally lazy so I'll try to give you a brief overview.

First you calculate the rating for each song. This is based on the plays and skips. Currently it is r = (p-s)/(p+s+1) . So r is constrained within -1 and 1. Second you calculate the average and standard deviation of the ratings.

Now to add a new song to the queue of songs to play you do this: pick a song at random. Calculate it's Z score based off of the rating. (That is z = (r - r_mean) / r_stddev)). Now use the normal curve to determine a probability. (That is 50% for a Z score of 0, 2.5% for a Z score of -2, and 97.5% for +2 ).

Take this probability and roll the dice. If the song passes it is added to the queue.

Now the only problem with this scheme is that this is an improvement on -randomized- play, not -shuffle play-. So to make it like a shuffle play, after it passes all these tests it must then pass the countdown test.

That is all songs start at 0. So they will pass the test the first time. Their counter then gets set to 10. Next time the song gets to the countdown test it will fail, but the counter is decreased by one. This repeats until the song is again at 0.

This gives you a shuffle play that is biased towards good songs.

Now for your concern about the snake eating its tail.

Here are some numbers I came up with:

A) One song with r=1 and 100 songs with r=-1 (what you describe that might eventually happen). In this situation the good song would have a 100% chance of passing the first test. And the bad songs would have a 46.6% chance (approaching 50% if you have more than 100 bad songs).

So the good song is picked with a frequency twice that of a bad song. But still there are 100 bad songs. Now, if we were using just a regular unbiased shuffle we would pick that good song just as often as any one bad song. So that's 0.99% of the time (1 out of 101).

But with the biased shuffle, we pick the song twice more frequently, this means we hear it 2.1% of the time.

So a marginal improvement, but definately the opposite of what you describe. In fact, you may now ask why doesn't it increase more? Well that's because you have so many bad songs that bad is normal, so they will in fact be played. But at least the one good song is still played -more- often.

B) One song with r=-1 and 100 songs with r=1 (the opposite of situation A). This gives a 53.4% chance for the good songs but a 0% chance for the one bad song. That means instead of hearing 99.01% of the time good songs, you hear good songs 100% of the time. So here the player would mute that one atrocious song.

C) 50 songs at r=-1 and 50 songs at r=1. Here the bad songs have a 16% chance of play and the good songs have a 84% chance. This means that instead of playing good songs 50% of the time you would play them 84% of the time.

The thing to keep in mind is that this is sort like the adage of why good needs evil. Because if you don't have evil you can't compare. But similarly if you have -lots- of evil, well that makes evil look "ok". Anyway, if you think these are "bad" cases, realize that you can use the statistics gathered to cull out the bad songs and not download them to the empeg.

Thanks for the question, I hope that helps answer it.

Actually you only need three files to find everything on the player, without reading any *0 or *1 file.
These files are "database" "playlists" and "tags". If you search this BBS you'll find examples how to parse these files.

You can differentiate mp3 's from ogg files by the "codec" tag in the database.
These are the possible values:

mp3
wave
wma
vorbis
flac

Pim

mp3tofid is a lifesaver (assuming you have to live with the database thingamabob that the current player uses). I was using 3.00 with rsync and a few other custom tools to put new music on the empeg.

There were two things I would improve on mp3tofid. Both are really related. One is, can you please support symlinks, so one can make a symlink farm instead of an actual copy of all the music (copying 12 gig can take awhile -- and yes hard links do work but I'd rather symlinks). Second is how about just a list of files, and you can just use the directory structure therein. I don't mind the directory structure I currently use at home, but I don't think my 12 gig harddrive will appreciate me trying to stuff 40gig of music on it.

Otherwise, it's essential to using the empeg. The little tool that ships empeg is just worthless for automatic updating. (pardon for the plain truth).

can you please support symlinks

I don't understand. mp3tofid is all about symlinks.

It creates symlinks from your real tunes to a directory structure
supported by the player. symlinks inside the mp3 tree are used
to create playlists.

Pim

Will either this new player or the upcoming v3 player software be able to play Real Audio (RAM, RM) files?

I would like to be able to do this, because there are radio programs that I download from the net in Real Audio format, and I would love to be able to just drop them into my empeg.

I can't see that this would be a big deal to implement.

Will either this new player or the upcoming v3 player software be able to play Real Audio (RAM, RM) files?

Not a chance in Hell, as I see it.

I can't see that this would be a big deal to implement.

Easy to say when you're not the one implementing it.

Seriously though, name another audio player other than RealPlayer that has RealAudio support. And then subtract out all the ones that pay enormous licensing fees to Real, Inc. What's left?

If any player is to support the proprietary Real Audio formats, they have to pay fees to Real. I can't see that happening with either the empeg player or this 3rd party project.

Sorry to dash your hopes, but you're probably going to have to convert those RealAudio files with Total Recorder or something.

Seriously though, name another audio player other than RealPlayer that has RealAudio support.

mplayer

And then subtract out all the ones that pay enormous licensing fees to Real, Inc. What's left?

mplayer

Sorry, couldn't resist. Still, I think you're right. Empeg would have to license the format, just as they did for WMA. I don't think the demand for the Real format would justify that.

Pim

My current fix for getting hijack to read the config.ini file is to do a "source config.ini" inside of the shell script that runs squash.

Not the best, but "cat < config.ini > /dev/null" didn't work. And, I don't want to patch hijack as that puts an even higher bar for people to try out squash.

I still do not know what is causing the problems with llseek. My current theory is there is something wrong with my toolchain. I followed this guide:

http://people.debian.org/~debacle/cross.html

Is there something else I should be adding to get better empeg support? The reason I suspect it is the toolchain is that I got the same error message after compiling pump (a dhcp client).

I would like to update the skipping I have experience with squash. Currently it does not skip at all during play -- it did before because if the config.ini does not get read the kernel brings the load average up to 2!

It does skip for a little while during load (which is in the background). It is not really that heavy of an operation, and is only one other thread -- so it would seem that I shouldn't be skipping. Right now I'm not worried about it and I will be looking at other issues.

No fsck, since nobody will run one. (That was something I thing the original player ran). But right now there are issues concerning this. First is that I do not know how to power down the empeg. The second is should I move to a journalling filesystem? Right now all that can get blown up is the statistics files. That's not really that major.

In fact I hadn't noticed these files (thanks ). But they don't really help too much as having a separate masterlist that squash creates is probably more convenient.

Thanks!

Pim,

mp3tofid does infact create a symlink farm from the target directory. But my concern is that I have to first (outside fo mp3tofid) build this target directory -- then I can have mp3tofid run on it.

Well the problem is that the target directory cannot be built using symlinks -- they must either be hard links or symlinks. Also, why even require the building of the target directory, just read a file list instead?

Those where my main two concerns. Otherwise it is truely a lifesaver when trying to use the original player.

(And the fact you need such a program is annoying, and one of the reasons I like my player, squash -- because you can name the files whatever, and the database is automatically handled. That means you can use ftp or rsync, etc. to get the files there -- and you can name them whatever too).

I do not know how to power down the empeg.

You pull the power from it. That's the only way. If you look in the kernel code, you'll see that it tries to do some things in the milliseconds after power is removed and power is gone.

There's no nice way to shut it down. Since power can be removed from it at any point, and usually is, there's no point in trying to define a nice shutdown. It has to do the right, most transparent thing in the worst case, which is the most common case, so there's no nicer way to shut down.

The only time this fails is when power gets removed while uploading data. But it should then be on AC, not in the car, so the changes of power going away happening are fairly slim.

So is shutting off the display sufficient? Is that what the original player does? I would think (from the comments I read about the PIC power controller) that this is not true. Afterall, what is the point of having a PIC power controller that can turn you on ever 15 minutes, if you can't turn your self off?

Also, power is not lost (at least not in my car). Instead there -is- an accessory line that tells the unit to turn off. But the power will remain even if you choose not to. Honest.

What I need is code/docs/etc. that let me power the unit down (or I should say, the 1ma state described in arch/arm/special/empeg_power.c).

I'm not very familiar or good at munging with the linux kernel.

It's got that timeout value, where it will fully power itself down after the timeout in config.ini. So saying that software can't shut it down completely might not be 100 percent accurate. I don't know if that shutdown procedure is entirely controlled in the PIC or in the player code or in the kernel or some combination of the above...

The thing is, since it's a car-based device, Bitt's point is that it's gotta be able to gracefully deal with sudden catastrophic loss of power in order to be truly useful.

So is shutting off the display sufficient?

Oh, forgot to answer this main question.

The way the player works is that the display and the Amp Remote wire are tied together functionally. If the display is on, the amp remote wire is on. If the display is off, the amp remote wire is off. Any time that you want the player not to "pop" through the amplifiers, you must shut off the display so that the amp remote wire goes low and mutes the amps.

Is that what the original player does?

The player does a few more things than just shut off the display. Complete details of everything it does are listed here.

But the power will remain even if you choose not to. Honest.

And a thief will be there, too. Or a battery waiting to die.

Eventually, at some point, you'll be pulling the empeg from the dash, and there's no warning when that will happen. You don't select a ``I'm getting ready to pull the plug'' menu option anywhere. You just do it. And, at that point, the player sees the power go away and it does its best to save whatever state it can. And it usually does.

I suppose you could have a menu option (or whatever) that the user selects before pulling the unit, or you could have it shut down cleanly when the accessory line is turned off. But that doesn't help in those situations where the user forgets or the car dies for some reason. You might as well make the program robust enough to cope with whatever might come its way, in which case, there's not much point in worrying about how to shut down more cleanly. In addition, there's nothing there right now that tells the empeg to shut down; you'd have to come up with that yourself, if it's possible. (It may be or it may not; I have no idea.)

(General reply to thread - not at Bitt specifically!)

I haven't noticed anything said here that is wrong. You're all correct;

If the Accessory line is high or the empeg is on AC power then it is impossible to get a complete shutdown. Muting, spinning down the disks and blanking the screen is it. (ie Standby)
On DC power, once the accessory line goes low, then it is up to the software to complete the shutdown, using the power_ioctl in empeg_power.c. State should be saved first.
The standard player binary writes state to the scratch partition on a regular basis, thus minimising the amount of data that it needs to save during powerfail. AFAIK, the only data saved during powerfail is to flash - there wouldn't be enough power or time to spin up the disks.
Check empeg_state.c

AFAIK, the only data saved during powerfail is to flash - there wouldn't be enough power or time to spin up the disks.

Correct. The stuff saved to the scratch partition is done at the moment you perform the relevant action. For instance, toggling shuffle, or saving a bookmark, or selecting/inserting a song or playlist, those cause a scratch partition write at that moment. Then the current position within that songlist is saved into flash at the time of the next powerfail.