One thing I've noticed since I've gotten the player, is that just about always one particular group in general is always grouped extremely close together on random play. "Verve Pipe". I don't know if something with the random seed creates it, but in just about every instance fo playing all songs in the play list puts all 7 or 8 songs I have of them very close. Typically playing 3 in a row, having a random song, 2 more of their songs, a few random sonds and then the last couple after that. Is there anything that would cause this? I haven't noticed it with any other artists, pretty much just with this one, and it's happened ever since I got the player way back in version 1.01 software.

Just thought I would mention the quirk to see if anyone else has noticed something similar to this.

EVERYONE has reported this, and the empeg guys keep insisting that it's ordinary statistical clustering and there's nothing wrong with the randomization code.

I see it happen so often that I'm convinced there's some kind of a bug or weakness in the randomization code that no one's caught yet.

There are two bands that I notice the empeg plays more than any others. Collective Soul and Verve Pipe.

Collective Soul used to be a lot bigger problem, but since 2.00b13, it seems to have become more random. For only having one Verve Pipe CD on the empeg, they do get an awful lot of play though. I usually only get 200 tracks into a "full suffle" playlist.

I would have to say you're on to something.

Ok, I touched on this in another thread but here's my take: I'm betting this is totally random. I admit that I had doubts in the beginning before I took over the program I work with now. I can’t get into specifics, but it basically does randomly picks from a fixed list of available items. Every time it selects it does a completely isolated selection, but I get calls every day from users complaining that it isn’t random (that it “favors” certain items). I have tested the program, examined the random number generator, and written lengthy papers to explain the behavior, and yet I still get the calls. The truth is that I can plug all of the numbers into an excel spreadsheet and every time the numbers that the users report are well within expectations. The problem is the perception of non-randomness, not the program. True randomness does not yield an even distribution, though that’s what we expect. If it did, however, that would be an indication that it isn’t in fact random.

Now my program is a little different than the Empeg and I can’t say for sure that the randomizer on the Empeg is accurate. All I know is that I still get calls at least once a week complaining, and during some parts of the month (when program usage is high) I’ll get them every day. So Empeg guys, I feel your pain.

One example I remember from this community is the same song title coming up three times in a row (3 different version of the same song). I don’t remember if this was alleging a problem or not, but I know we discussed the randomizer in that thread. If you think about it much, this clearly wasn’t the randomizer at fault. The reason? The randomizer certainly isn’t taking song title into account; in fact I believe that if the randomizer were broken the only information that would affect how often a song was selected would be the song “position” (ie where it resides in the “list” of songs). Since I believe this particular song was three cuts off of three different albums, clearly the randomizer wasn’t at fault, as the songs were not located right next to each other. The only correlation between the three songs was incidental to the randomizer, but we perceived a correlation.

The only thing I can say is that perhaps the randomizer could be “de-randomize” since it seems that’s the behavior we all want. I think, though, that that’s what the parameterized shuffles are for.

I agree that this is a red herring, and is basically a result of peoples' distorted perceptions of what randomness is. In order to give people what they want, the shuffle algorithm would have to go through on a second pass and "de-cluster" any songs from same artists/albums/whatever.

Just tell yourself it's a feature and the empeg has artificial intelligence.

Today I was playing all my punk stuff and it would play three songs from each artist it picked it was pretty cool.

the shuffle algorithm would have to go through on a second pass and "de-cluster" any songs from same artists/albums/whatever.

The first post I ever made here was to request this feature. In the end I "beat the system" by setting up a complex series of playlists that achieves this. (which only goes to show how flexable the playlist system is on the Empeg). One thing the Empeg guys may want to think about is how average consumers will react to this "pure" radomization in their other products. I'd guess that most aren't going to care whether the process is totally random or not, they'll want something closer to what you just described.

Well, the main thing I'm noticing seems to defy even the statistical normals that you'd expect in a true random shuffle.

I'm not talking about a few songs by the same band coming close together.

I'm also not talking about a few variations of the same song coming close together.

I'm not talking about a certain band who dominate my playlist with sheer numbers (say, Rush) coming up excessive amounts.

All of the above I would expect from a random shuffle, and pretty frequently.

No, I'm talking about a consistent and regular "comb" of a LARGE NUMBER of closely-grouped FIDs coming up on EVERY SINGLE RESHUFFLE, usually noticeable within the first couple dozen tracks or so.

Case in point:

- My player has about 3000 songs on it now, of which 2759 are not ignored-as-child on a "down down down" shuffle.

- Of those songs, there are exactly 13 by Madonna. The album "Ray of Light" is the only album of hers I own.

- I do a down-down-down shuffle in purely Random mode.

- The beginning of the playlist looks like this:

Some song
Some song
Some song
A song from Ray of Light
Some song
A song from Ray of Light
Some song
A song from Ray of Light
Some song
Some song
Some song
Some song
Some song
Some song
A song from Ray of Light
Some song
Some song
A song from Ray of Light
Some song
A song from Ray of Light
Some song
A song from Ray of Light
Some song
Some song
Some song
A song from Ray of Light
Some song
Some song
Some song
Some song
A song from Ray of Light
Some song
Some song
Some song
Some song
Some song
Some song
(etc...)


Now, I could imagine this once in a while. But I see this happening at least once somewhere in every single full-player-shuffle.

I will admit that each time it's not "Ray of light" but it's something, some album or artist who I don't have a lot of compared to the rest of my collection.

Are you saying that in a truly random shuffle, that this behavior is still within the realm of statistical distribution?

I totally agree with you Tony. I'm not much complainging, but I have noticed it specifically with Virve Pipe, and always with all of the songs on a "down-down-down" shuffle. Typically Verve Pipe comes up somewhere in the middle, but it's always every single one of the songs they have within a block of about 20 songs, with multiple ones next to each other. Currently I have 2161 songs, and it varys between 1300 and 2600 depending on my current "playlist" mood and what I have on it. But in every case, Verve Pipe always comes up in almost the exact same "pattern".

Of course, there is no such thing as true randomization, just a close aproximation to it. At least it isn't like WinAMP. On more than one Occasion I can start guessing the next few songs based on the previous few. I also have to agree that the randomization has gotten "better" as time has gone on. In the 1.x version of the software it was also pretty predictable depending on the seed the down-down-down shuffle got. Now it just happens to be with the few Verve Pipe songs I have that I always notice it on.

Sorry to bring up such a heated topic!

Sorry to bring up such a heated topic!

Heh, didn't mean to get defensive. It really isn't a heated topic for me, at least not where the Empeg is concerned. It is heated when it comes to my application though, cause I'm so tired of wasting development time trying to answer the same question over and over again (and yes, it's in our FAQ). For all I know the Empeg randomizer could be messed up, I'm just trying to offer a defense because I know how tiring this battle can be for the developer!

Are you saying that in a truly random shuffle, that this behavior is still within the realm of statistical distribution?

I was going to say that it was, but I decided to write a program to try and prove it. Anyway, the program generates a random list of "songs" grouped by tens into albums. You can set the total number of tracks. It will then tell you how much "combing" it found within the sample by looking for songs on the same album that are 1 apart, 2 apart, 3 apart, etc. I also chopped the stats at the first 30, as this is where you'd normally perceive the problem. What I found is that the combing effect seems to be relatively low. Much lower than what I've seen on the Empeg.

As I conceived this test and coded it in under a half hour I'm not sure how accurate it is (or bug free). I'll have to take the weekend to think it over. Anyway, the program is attached if you care to look at it.

And here is the Delphi source (if anyone can still read Pascal) in case anyone wants to point out an error I made. Remember, be nice. I coded this in thirty mins.

Are you saying that in a truly random shuffle, that this behavior is still within the realm of statistical distribution?

Of course it is. If you got _exactly_ the same running order from a ddd shuffle as one that you'd had before then _that_ wouldn't be within the realm. (Unless you'd shuffled somewhere in the order of n! times before).

But you have to remember that in a _purely_ random shuffle, there exists a chance that the resulting order is exactly the same as the unshuffled order. As there is also the chance that the resulting order is the same but with only the last 2 tracks swapped. Or only the first 2. Or only _any_ 2 tracks.
None of those would be considered as 'shuffled', but are totally valid in a _purely_ random shuffle.
What about when we consider the huge number of other running orders that are also similar to the unshuffled playlist? Starting with a playlist of 2000 tracks, I would suggest that if in the resulting running order the first 1000 tracks were exactly the same, and only the last 1000 tracks got moved around, everyone would cry foul. Yet there are 1000! ways that this could happen. Sure, the odds of it happening are still only approximately 1 in (2000!/1000!), but those 4x10^2567 possible results are still valid in a _purely_ random shuffle.

What I found is that the combing effect seems to be relatively low. Much lower than what I've seen on the Empeg.

Actually, if I'm reading the output of this program correctly, it's kind of showing me that a certain amount of combing is to be expected.

I didn't catch how it decides what an "album" is, I assume it's 10-15 sequential numbers? If so, does your algorithm count any number close to ANY 15th-or-less neighbor without considering album boundaries, or does it split the list up into discrete album segments and then decide from that list?

For example: If it sees two guys from the list "A B C D E F G H I " close together, say D and G close together, it counts that as a "hit", but what if the album boundary was between E and F? Then it shouldn't be considered a hit.

I know that from the point of view of a statistical sample, the album boundary is irrelevant. But from our perception of whether or not D and G are unnaturally paired, it's critical. And that's what we're testing: Is it normal for us to perceive that kind of clustering and combing in a random shuffle?

This discussion has been VERY enlightening so far! In fact, if we can fancy-up that Delphi program a bit more (make it more obvious what it's measuring), I'll do a FAQ entry on this topic and link the EXE from the FAQ.

Jeff,

Other than being a bit inefficient (you're using an O(n^2) shuffle algorithm where a simple O(n) algorithm could be substituted), the code looks good. You might post an example output for those of us who don't run Windows (or have Kylix), though.

More to the point, it has long been my expert opinion that there is something broken in the Empeg's shuffle code. I've seen too many cases like the one Tony described to chalk it up to the normal pockets of order in truly random data.

--John

I get exactly the same behavior as Tony. Many songs from the same artist that only has a few songs on the player with a song or two intersperced between them. This behavior is reproduceable nearly every time my empeg is played in shuffle. For instance, I'm in Richmond VA on business right now. I have one album from REO Speedwagon on my player... The Hits. In a two hour drive here from the airport in Raleigh-Durham, I easily heard 8 or 9 songs from that album, with one or two seemingly random tracks between each of them. This happens constantly.

Two hours from RDU to Richmond huh. Boy, I am glad you did not get pulled by the NC Patrols.

Anyway. Drove from RDU airport area to Greensboro, NC this afternoon and the same thing happened with Collective Soul (v2.0f on the empeg) I have five Collective soul albums and 9500 songs on the empeg. I think i heard at least 5 Collective Soul songs in that drive... This is typical. Pick any band. Moby, Alison Krauss (AKUS), Zappa, Ween... This happens occasionally. I found the player loves to group Travis or Pink Floyd (or any member solo project). Is the shuffle/random slighted toward the british music???

Usually if I do not like the shuffle, shuffle again...

Actually, if I'm reading the output of this program correctly, it's kind of showing me that a certain amount of combing is to be expected.

What is very strange is that you always get about 80 or 90 "combed" songs no matter how many total tracks you have (unless you got down to 50 or less, duh!), which made me question the output, but I couldn't find any bugs at first glance.

I didn't catch how it decides what an "album" is, I assume it's 10-15 sequential numbers? If so, does your algorithm count any number close to ANY 15th-or-less neighbor without considering album boundaries, or does it split the list up into discrete album segments and then decide from that list?

It does discrete album segments, assuming 10 "songs" for every "album", except perhaps the last (if you have an odd number). Put another way, it does consider "boundries" of albums.

This discussion has been VERY enlightening so far! In fact, if we can fancy-up that Delphi program a bit more (make it more obvious what it's measuring), I'll do a FAQ entry on this topic and link the EXE from the FAQ.

I'll see what I can do. I've been very bored at work recently so I should be able to mess with it in my down time on Monday. I also want to give my brain some time to think this through, as I didn't expect the results I got at all (though I guess that might be a good thing).

Other than being a bit inefficient

Yes, well I wrote it in a hurry and I've never done a shuffle algorithm before (my other program does random "selections", which is slightly different), so that was a brute force attempt!

the code looks good

Excellent! Thanks for the sanity check.

You might post an example output for those of us who don't run Windows (or have Kylix), though.

I'll do that tomorrow (and I'll have to use my wife's machine as this is Linux I'm typing on right now).

In reply to:

---

What is very strange is that you always get about 80 or 90 "combed" songs no matter how many total tracks you have (unless you got down to 50 or less, duh!), which made me question the output, but I couldn't find any bugs at first glance.

---

I don't find that strange. As you have more total tracks you have more places for "combed" songs to occur but the probability of a "combed" song at any one spot decreases. I could probably work out the math, but it's not surprising that these would cancel out.

--John

Yes, well I wrote it in a hurry and I've never done a shuffle algorithm before (my other program does random "selections", which is slightly different), so that was a brute force attempt!

Hey, at least your code was correct! That's a lot better than many attempts. Just for reference, a good shuffle algorithm looks something like this:

/* Shuffle x[1..n] in place */

for i=n downto 2

        let j be uniform random from range [1..i]

        swap x[i] and x[j]

--John

Wine runs it fine.

Just tell yourself it's a feature and the empeg has artificial intelligence.

Well tonight (after about six hours of uneventfull shuffling today) my empeg played Rocky Horror's Rose Tint My World followed directly by Arlo Guthrie's I'm Going Home. For those of you familiar with Rocky Horror, I'm Going Home is the following track in the musical. Arlo Guthrie's song by the same name shares no relation. I was impressed that my empeg was emulating the kind of jokes I make when I make mix CDs.

I do notice what people are pointing out however, that my empeg does seem to group songs by an artist together. For instance, I hadn't heard Aimee Mann in at least a month, when today I got three songs within an hour of driving. Probably just random coincidence.

Matthew

a good shuffle algorithm looks something like this:

Thanks, I was going to ask! I suppose the fact that I was a CIS major not a computer science major is showing (since CIS was the closest thing my college offered). I never had a solid class that taught alogrithms.

What is very strange is that you always get about 80 or 90 "combed" songs no matter how many total tracks you have

Actually I meant 60-90, just for accuracy's sake.

Here's an image for the non-window folks. I should point out it doesn't as much detect "combing" as it does songs off the same album close together. In the test run I just did, only 86 pairs (in 3000) were close together, and many of these might have been couples rather than full-blow "combing". I should add that since each pair is only noted once, the number of actual songs involved is higher than 86 (172 if all songs were couples and not triples, etc.) In addition, in the first thirty songs (where I determined you'd probably most notice the effect) only two songs from the same album were close together. Clearly this program is limited in what it tells us, but my first feeling is that we are seeing more "combing" on the Empeg than we should.

The changes I'm planning to make are

1. Fix my stupid misspelling in the caption! Actually, I might just change it to something else entirely. Maybe I should also check the font . . . (sorry, deja vu from my last project!)

2. Allow the user to set range for album sizes (ex: 10-15 tracks).

3. Allow the user to set maximum gap for considering a pair of songs to be "combed" (Ex: 10 or less).

4. Get rid of the current statistics and replace them with:

5. An actual display of the sorted tracks (AlbumID/ Track No.) with "combed" songs marked. A "find next" will allow the user to jump to the next "combed" song so all patterns can be observed.

Anybody have any other information they'd like to see?

So FerretBoy, what you're saying is that the program is only reporting numbers of individual close pairs, rather than clustered groups.

I expect to hear pairs rather often. It's clustered groups that I'm interested in.

Here's another idea. Something I've toyed with the idea of making myself. A program that shows, by color graph, the distribution of a given album in the shuffle:



(Pictures are a 60x60 grid=3600 songs. Images doubled in size so you could see the red dots.)

What I'm interested in seeing is... in a truly random shuffle, how often the second thing actually should happen. Not just what we think we perceive if we happen to hear three Madonna songs on the same trip.

So FerretBoy, what you're saying is that the program is only reporting numbers of individual close pairs, rather than clustered groups

Yeah, but with such a small number of pairs (80 or so) you have to think there's not much clustering, which was what I felt the program was revealing. However, the modifications I have in mind will point out exactly what you want, though I hadn't thought of putting a graph in the program. I might do it, depending on how bored I get at work.

Anybody have any other information they'd like to see?

How about this...

Allow the user to set the total number of songs on the player (default about 3600), how many songs per album (default about 12), and how many albums per band (default about 4).

Then, graph the results, allowing you to quickly scroll through a list of band1, band2, band3, etc., and as you scroll, show the dots on the graph. Each album within a band could be a different color, so you could see if there's any clustering effect of band X along with the album effect. You could also scroll through individual albums (band 7, album 3) and show only that album on the graph, like in my illustration.

Then we'd have a very clear picture of just how clustered a truly random distribution should look.