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.