The current 2.0 beta has added several new shuffle modes including:

- Least recently played
- Least often played

I would like to see added:

- Most recently played
- Most often played

These would offer a way of hearing your current favorite tracks without having to constantly build new playlists reflecting what's hot in your world of music.

In an earlier alpha, it was possible to add your own custom shuffle modes to config.ini. The ones you listed would have been pretty easily possible, as I recall.

I assume this functionality is still there, I just don't remember how to do it. Darn, I wish I would have saved that message.

Perhaps someone from the development team can give us a clue here? I'll document it in the FAQ if you do.

Perhaps someone from the development team can give us a clue here? I'll document it in the FAQ if you do.

Boy, am I good, or what?!

(from an e-mail exchange dated april 6, 2001)


From: "Peter Hartley"

Douglas Burnside wrote:
> And on a peripherally related topic... how about adding one more
> shuffle mode, "Most Often Played". This would be an easy way to
> dynamically generate a "favorites" playlist on the fly.

The 1.1 player software allows for user-defined shuffles. The UI for
creating them probably won't get added to Emplode in time for 1.1final, but
if you don't mind grubbing about on the player, you can add a section to the
config.ini file as follows:

[custom]
shuffle0=Favourites,-PLAYS=32000,RANDOM=1

Make sure you spell "Favourites" in UK English ;-)

This sets up a shuffle where the number of plays largely defines the order
(the minus sign means large numbers come first), but there's also a random
element so that if there are five tracks you've all heard, say, 20 times
each, those five get shuffled each time.

You can use any number of tags (Emplode column headings) in the shuffle --
as long as each one has numeric values, of course. You can also use the tags
"PLAYS", and (on Mk2) "TIME", which is a measure from 0-32000 of how long
it's been since you last heard it. The built-in shuffles are defined as:

Random,RANDOM=1
Least often played,PLAYS=1,RANDOM=2
Least recently played,TIME=32000,RANDOM=2000
By year,-YEAR=32768,RANDOM=1



Is this what you were looking for, Tony?

tanstaafl.

Yes, that's it, Doug.

Can you do me a favor and e-mail that to me as well? I'm away from home at a Con and don't have time to dump that into the FAQ right now. If it's in my email box when I get home, I'll remember to do it.

Also... Has anyone had a chance to actually TRY this in 2.0? Does it work? Note that these notes were from one of the 1.1 alphas...

Has anyone had a chance to actually TRY this in 2.0? Does it work?

It should work, as it's still (more or less) how the built-in parametric shuffles work.

Peter

It certainly appears on the menu, but I am listening in random shuffle mode too much (i.e. more or less all tunes have been played 2-3 times since 2.0b3) to say with certainty whether it really works.

Peter, what is the meaning of numeric parameter to RANDOM and PLAYS? I didn't quite understand from that mail Doug quoted. Are the mode label (shuffle0) and menu name (Favourites) arbitrary? How does one specify other tags, if at all (like in searches?) (for example, 'play randomly, but prefer tunes Wendy-tagged as not being suitable for mother-in-law's ears)? I guess one cannot combine parameters (e.g. maximize(plays-2*skips))...

Peter, what is the meaning of numeric parameter to RANDOM and PLAYS? I didn't quite understand from that mail Doug quoted.

They are the weightings given to each factor in determining the track's "soonness factor".

Suppose the shuffle we're doing is "PLAYS=32000,RANDOM=1". Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1. The resulting number is the "soonness factor" for that track. Tracks with lower soonnesses play sooner.

Are the mode label (shuffle0) and menu name (Favourites) arbitrary?

The labels (shuffle0, shuffle1) are not arbitrary and must be consecutive and starting at 0. The menu name ("Favourites") is arbitrary.

How does one specify other tags, if at all (like in searches?) (for example, 'play randomly, but prefer tunes Wendy-tagged as not being suitable for mother-in-law's ears)?

You can use TIME, PLAYS and RANDOM as described in the Big Yellow Email, plus any numeric database tag -- of which there aren't many; YEAR is about the only useful one. (A future release might add MTIME, so you could shuffle favouring tracks recently added to your player.)

(A far-future release might include the original intention of being able to add custom numeric tags in emplode/emptool. So you could assign a numeric "cheese factor" to Britney Spears, Steps etc. and then shuffle favouring cheesiness -- or suitability for fast driving, or for dancing on the back seats, or whatever.)

I guess one cannot combine parameters (e.g. maximize(plays-2*skips))...

No, that's exactly what one can do. One is only prevented from specifying that particular shuffle, by the fact that keeping count of skips isn't yet implemented.

Peter

The current release already has "mtime" and "ctime", so as long as you put the tracks on with emplode v2.0, you can already do this -- they're numeric tags (Unix time_t).

Okay, I'm dense. I admit it. I still don't understand how it works.

I don't understand why some of the examples shown her have a minus sign in front of the field name.

I also don't understand why RANDOM looks like a field name.

And why one of the examples have RANDOM only and others have other fields. Why do some require more parameters than others?

Can you really do math expressions on the line as was suggested?

Why 32000 and 2000? Isn't that the same as 32 and 2?

And this statement...

Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1.

... confuses me becuase the word "is" gets used twice in the same breath. Is the number multiplied or added?

I would really like to understand it before I try to write a FAQ on it.

I'm not sure which is more amusing -- the fact that a guy on the alpha team just found out about a new feature and can't figure it out, or the fact that one Empeg guy just informed another Empeg guy that a feature is already in the current release.

The only thing that could be more amusing would be having this kind of access to, say, Microsoft's engineers.

Hiya. Here's my understanding. Please tell us if this is wrong, empeg guys.

Each track gets a number (the soonness factor). This number is the sum of all the fields specified in the config file. The value of the field in the database is multiplied by the factor specified in the config file for that field. If there is a minus sign preceding the field name in the config file, then the value for this field is multiplied by -1. RANDOM is not actually a database field, but it acts like one, with a random value between 1 and 32000 that will change every time.

Tracks with smaller soonness factors are played first.

I think you're right that if the list of numbers on any one line has any common factors, then that adds no extra information.
i.e. TIME=32000,RANDOM=2000 is the same as TIME=16,RANDOM=1

Lets assume we have three tracks, A:plays=5,time=30 B:plays=10,time=40 C:plays=20,time=20

So:

-PLAYS=1 gives soonness factors of A:-5, B:-10, C:-20 so the order of the tracks will always be C,B,A

TIME=1 gives soonness factors of A:30,B:40,C:20 so the order of the tracks will always be C,A,B

PLAYS=4,-TIME=2 gives soonness factors of A:20-60=-40, B:40-80=-40, C:80-40=40 so the order of the tracks will be either B,A,C or A,B,C.

-PLAYS=32000,RANDOM=20 gives soonness factors of A:-160000+R1, B:-320000+R2, C:-640000+R3 where Rx are random numbers between 20 and 640000. So, if you want roughly even weighting between number of plays and randomness, you should give each a multiplier related to the expected value of the other number. But, as said above, this is the same as -PLAYS=1600,RANDOM=1

Have I got it right? Or have I just confused the issue more?

Richard.

Excellent! Thanks.

No chance of treating Wendy flags as numeric values (0/1)?

I don't understand why some of the examples shown her have a minus sign in front of the field name.

Because in a shuffle-by-year you want LOW numbers (years) first; in a shuffle-by-most-often-played you want HIGH numbers (play counts) first.

I also don't understand why RANDOM looks like a field name.

Because it acts just like a field name -- one with a different random value each time it's evaluated.

And why one of the examples have RANDOM only and others have other fields. Why do some require more parameters than others?

The one with RANDOM only, will shuffle the songs in completely random order. The ones with other parameters, take those factors into account too when shuffling the songs.

Can you really do math expressions on the line as was suggested?

No. But Bonzi's suggested math expression, maximize(plays-2*skips)), is the same as a shuffle "PLAYS=1,-SKIPS=2".

Why 32000 and 2000? Isn't that the same as 32 and 2?

Yes, it is.

And this statement...

Then, for each track, the number of plays is multiplied by 32000 and added to a random number (1-32000) is multiplied by 1.

... confuses me becuase the word "is" gets used twice in the same breath.

Sorry, the second "is" shouldn't be there.

Is the number multiplied or added?

Looking at it now, it would have been clearer to use "*" instead of "=", and "+" instead of comma. So instead of

-YEAR=32768,RANDOM=1

please read it as

-YEAR*32768 + RANDOM*1

Hope this clears things up a bit...

Peter

Have I got it right?

Yes, bang on.

Peter

I have a little problem with this mail:

"TIME", which is a measure from 0-32000 of how long
it's been since you last heard it.
And the definition of the least recently played random mode:
Least recently played,TIME=32000,RANDOM=2000
Which I will simplify to:

Least recently played,TIME=16,RANDOM=1

If the statement about the content is understood correctly by me, TIME is higher the longer a song is unplayed. But if this is correct, the "Least recently played" random mode would actually be a "most recently played" one.
So, am I correct with my assumption that the TIME measurement is actually more like a Unix time of the last playing date of a song, scaled down to the 0-32000 range, and therefore higher for more recently played songs, and lower for songs that were not played for a longer time?
If so, yould you give an estimation for the actual rang of TIME one should expect? If a song was not played for a week, what will TIME be approximately?

cu,
sven

I don't understand why some of the examples shown her have a minus sign in front of the field name.

Because in a shuffle-by-year you want LOW numbers (years) first; in a shuffle-by-most-often-played you want HIGH numbers (play counts) first.

Why don't you simply allow negative factors? This would result in:

shuffle0=Most recently played,TIME=-16,RANDOM=1

or similar lines instead of the (at least for me) less readable

shuffle0=Most recently played,-TIME=16,RANDOM=1

cu,
sven

If the statement about the content is understood correctly by me, TIME is higher the longer a song is unplayed. But if this is correct, the "Least recently played" random mode would actually be a "most recently played" one.

TIME is higher the longer a song is unplayed. It's 1/32 of the elapsed seconds since last play: 0 immediately a song is played; 18900 after a week; and 32767 after about twelve days, at which point it's clipped. (So anything you haven't heard for twelve days counts as "ages ago".)

As TIME is higher for a long-unplayed song, that song's "soonness factor" is higher, so it gets played sooner. It is the right way round.

The "soonness factor" sort is a descending sort. That's why you have to use -YEAR to get a shuffle in ascending order of year.

Peter

No chance of treating Wendy flags as numeric values (0/1)?

I wouldn't say "no" chance, but it doesn't work like that at the moment. All wendy flags are combined into a single 32-bit flagword, so, unless you only have one flag, there's no point trying to do a custom shuffle on it.

Peter

Why don't you simply allow negative factors?

Bear in mind that this stuff in config.ini was never expected to be user-visible. We were intending to put a nice, simple, sensible UI in emplode.

Peter

Thanks, everyone, for the replies.

I've printed out this entire thread and I'm going to read through it carefully a few times and see if I can figure out how it works.

I think it's been adequately explained, now I just need to make it sink into my crack-addled skull. The only other thing I could possibly wish for is a set of examples showing how to do some interesting shuffle mode...

Just so you know, we do still intend to implement the nice front end in emplode..

Rob

Just so you know, we do still intend to implement the nice front end in emplode.

Oh.

How soon? Will it be in Peter's Copious Spare Time, or sometime before 2.0 final?

I'm just wondering if I'd waste my time by making a FAQ entry on it. One of the things I try to avoid is making FAQ entries that will become obsolete with the next software release.

I'd hold off for the moment Tony. I think there would be far too much confusion even for a FAQ. I had to stop several times while reading this thread and make another cup of brownian stimulants to cope. In the end my brain filled up.

Heh. Actually, I figured it out, and even figured out a way to explain it clearly in the FAQ.

The only problem is that when I actually TRY it on my player it doesn't produce the desired results.

For instance, I know that there are a handful of tracks on my player that have a "plays" count of 20 or so. Everything else is in the 0-5 plays neighborhood. But when I create a "favorites" shuffle as the example, those tracks are not at the top of the shuffle when I hit it. They're not at the bottom of the shuffle when I wrap around backwards, either.

This counts even if I remove the "random" item from the list. In that case, I would assume I'd get a straight count-up or count-down by Plays. I don't. In fact, the resulting song list doesn't seem to be related to the plays count at all.

Hmm.

I think for some, a simple "1" if any Wendy tag is set, "0" otherwise flag would be of a lot of help. Sure, that might filter too many songs out (resp. to the end/start of the playlist), but still, that would be better than nothing.

cu,
sven

Why don't you simply allow negative factors?

Bear in mind that this stuff in config.ini was never expected to be user-visible. We were intending to put a nice, simple, sensible UI in emplode.

Sure, but wouldn't it be easier to write from emplode, too? I mean a

printf(",%s=%d",tag,value);

is easier than the way you would be writing it now, right?
Also, it would be easier to read for you, too, when debugging.

cu,
sven

That's not what Wendy filters are designed for. What you want is custom tags (e.g. "cheesiness").

Hi Tony.

I'm still trying to figure this stuff out because I also want to document it on riocar.org (speak of redundancy).
Ok, let's leave the definition of the various counts aside, I still have problems with the basics. Is the following definition for the line format correct (Peter)?

shuffle#=< menutag >,{-}< tag >=< factor >{,{-}< tag >=< factor >{,...}}

Where the different shuffle modes are number in an ascending order, starting at 0 ("#"). The menutag is a simple string, the possible tags are defined seperately, the minus sign before the tag denotes that the associated tag's value
(multiplied by its associated factor) is substracted from the sum instead of being added.
The list of tags is seen as the definition of a sum, first multiplying each tag's value by its associated factor, then by "-1", if a minus sign was seen before the tags name, finally all those products are summed up. The sum (soonness factor) is then used as the key in the following sort (inappropriately named "shuffle" ). The sort is descending, so the larger the soonness factor, the earlier a song is played.
Is this correct?

cu,
sven

Hi Peter.

TIME is higher the longer a song is unplayed. It's 1/32 of the elapsed seconds since last play: 0 immediately a song is played; 18900 after a week; and 32767 after about twelve days, at which point it's clipped. (So anything you haven't heard for twelve days counts as "ages ago".)

Well, not trying to criticize your decision on choosing 1/32rd of the seconds elapsed since the last play, but IMO, this divisor is choosen tooooooo low. Even if I let my empeg play 24h/day, it would need 2-3 weeks to play my complete collection (due to the large number of low-bitrate audiobooks). So basically, half of my collection would always show as "never played/last played ages ago". Couldn't you either
a) make the divisor user selectable, or
b) increase it to at least 128 (which is about half of a song)
PLEASE.

cu,
sven

Some mathematics, which may (or may not) make it clearer. All Fn are normalised to between zero and 32767.

So basically, half of my collection would always show as "never played/last played ages ago".

Is this actually a problem? Do you ever find yourself thinking, "Here, my empeg is playing Napoleon's Piano again, I only heard that two weeks ago"?

If Q103 -- or Radio 1 for that matter -- went twelve days without repeating a song I'd be ecstatic

Peter

Is this correct?

Yes.

Peter

So basically, half of my collection would always show as "never played/last played ages ago".

Is this actually a problem? Do you ever find yourself thinking, "Here, my empeg is playing Napoleon's Piano again, I only heard that two weeks ago"?

Though I only have _very_ few piano pieces on my empeg, let alone "Napoleon's Piano", and as odd as this might sound to you: Yes, that is a problem for me.

cu,
sven

I think I agree with Sven here, but for different reasons.

If the oldest possible date is twelve days ago, then okay, sure, maybe I don't care if I've heard a song in the last twelve days or not.

But here's the real problem in my opinion: At any given time, MOST of my collection will still be equally randomized when I'm using the time-based randomizer. In other words, the feature doesn't really work as intended if it's only got a 12-day memory.

This thread really does confuse me i'll come back when hey start talking english again

Well, I finally got around to trying to setup these custom shuffle modes on my unit and discovered some interesting things...

The examples given here in this message thread do not work correctly with 2.0-beta3. For example, the following entry...

[custom]
shuffle0=Most often played,-PLAYS=1

causes a bizzare shuffling of songs that doesn't make sense. Even worse, if you attempt to apply this shuffle to a huge playlist your player may hang with an hourglass on the screen forever (kind of reminds me of good old Windows 3.1!)

However, the following entry works exactly as expected...

[custom]
shuffle0=Most often played,PLAYS=-1

Perhaps this odd -PLAYS / -TIME syntax only applies to older alpha/beta versions, while the newer releases simply use negative numbers? Anyone from empeg care to comment?

Hi.

Bringing up an old thread here again, but anyway:

Regarding "custom" shuffle modes in 2.0b3, we were discussing the factor by which the time since the last play of a song is devided by, just before feeding the value to the shuffle calculation.

Peter wrote:
TIME is higher the longer a song is unplayed. It's 1/32 of the elapsed seconds since last play: 0 immediately a song is played; 18900 after a week; and 32767 after about twelve days, at which point it's clipped. (So anything you haven't heard for twelve days counts as "ages ago".)

Tony Fabris and myself agreed that the factor of 1/32 is a bit too low, because typically the biggest part of any empeg owner's collection will be at 32767 after the conversion above, which obsoletes the "least recently played" mode somehow.

Was this changed since beta3? Nothing regarding this problem is mentioned in the beta7 release notes.

cu,
sven

Hi Tony.

I'm just wondering if I'd waste my time by making a FAQ entry on it.

Did you add an entry for custom shuffle modes to the FAQ? I did add it to the developer info, but the way I wrote it, it is probably still incorrect. I couldn't find your FAQ entry for it, even if it existed.

cu,
sven

I didn't add a FAQ entry for it because I tried to make it work on my player the way I understood it to work, and it didn't behave as I expected it to.

I tried creating a shuffle mode based on the number of "plays". I did it without the random factor, so in theory I should have gotten a list of songs in order of "plays". But I didn't get that, I got something that seemed random-- the "plays" field seemed to go up and down randomly as I cycled through the songs.

So until I can get something that works, I won't write a FAQ entry on it.

Also...

The Empeg guys said that they intend to create a user interface for the feature in Emplode. So if they do that, there's no need for a FAQ entry.

When will skip-counts be implemented? I'd love a shuffle mode : "least skipped".


Geert

Empeg 6Gb Red

Reviving an old thread here, because an idea popped into my head at the weekend.

In reply to:

---

Bringing up an old thread here again, but anyway:

Regarding "custom" shuffle modes in 2.0b3, we were discussing the factor by which the time since the last play of a song is devided by, just before feeding the value to the shuffle calculation.

Peter wrote:
TIME is higher the longer a song is unplayed. It's 1/32 of the elapsed seconds since last play: 0 immediately a song is played; 18900 after a week; and 32767 after about twelve days, at which point it's clipped. (So anything you haven't heard for twelve days counts as "ages ago".)

Tony Fabris and myself agreed that the factor of 1/32 is a bit too low, because typically the biggest part of any empeg owner's collection will be at 32767 after the conversion above, which obsoletes the "least recently played" mode somehow.

Was this changed since beta3? Nothing regarding this problem is mentioned in the beta7 release notes.

---

A suggestion: implement a non-linear curve by scaling values from a certain point.

Replace the "divide by 32 seconds to get a number" by the following procedure, then continue with the calculation as before:

• Keep the initial divison by 32 seconds.
• Values up to 16383 remain the same as they are now.
• Values from 16384 to 4210687 are divided by 256 and added to 16320.
• Values over 4210687 are forced to 32767 (so the values are limited, as before).
  

This means that we squash 4210687 seconds (1559 days or so - more than 4 years) into our 15-bit value, as opposed to the current 12 days, by using less precision (two hours instead of half a minute) for things played more than 6 days ago.

By fiddling with the constants above, you can get different ranges; it's also possible to break up the domain into more than two ranges (to get less discontinuity between recent and less-recent).

Hi Toby.

Nice suggestion. I like that one alot.

cu,
sven

There is a bug in the current software with regard to the most-recently-played values, and it will be corrected in the next release.... Dunno about PLAYS but I was never able to get this to work right...

Emplode getting the feature soon?

No. Unfortunately.

The bug with "most recent" is that if you're not in the GMT time zone (for instance, I'm off by eight hours), then the calculations get all messed up, and re-shuffling considers anything you've heard within the last 8 hours to be "ages ago".

The bug with "most recent" is that if you're not in the GMT time zone

Actually I think that bug was in beta 12 only. Beta 11 et pre have a much wider variety of much worse bugs with that feature.

Peter

Here's an old one, brought back, what's the be all end all on this, does it work ?

Has anyone implemented a good (worthwild) custom shuffle mode ?
Perhaps someone might post a few config.ini string with their associated "plain english" meanings.

GeorgeLSJr did a great job with these:

shuffle0=Favorites,PLAYS=-32000
...you'll get a shuffle of your playlist in sequence of number of plays, highest # of plays to lowest # of plays. Keep the player paused and keep reshuffling the playlist and you'll keep getting the exact same sequence of songs.

shuffle0=Favorites,PLAYS=-32000,RANDOM=1
...and you'll get the same as the above, but songs which have the same # of plays will be re-shuffled amongst themselves each time.

Anyone Else ?

More on This Old Thread:

In reply to:

---

A suggestion: implement a non-linear curve by scaling values from a certain point.

Replace the "divide by 32 seconds to get a number" by the following procedure, then continue with the calculation as before:

Keep the initial divison by 32 seconds.
Values up to 16383 remain the same as they are now.
Values from 16384 to 4210687 are divided by 256 and added to 16320.
Values over 4210687 are forced to 32767 (so the values are limited, as before).

This means that we squash 4210687 seconds (1559 days or so - more than 4 years) into our 15-bit value, as opposed to the current 12 days, by using less precision (two hours instead of half a minute) for things played more than 6 days ago.

---

Blert: Insufficient generality, 10 yard penalty.

How about this:

TIME should be the log(base 2) of the actual time difference, with as many bits of precision as are possible at any given time (if you're messing with unix time_t's, the largest log base 2 will take 4 bits of integer, leaving the other 11 for the fractional part).

Note that this scales kind of self-correctingly: if you've played everything recently you get an extra couple bits in the fraction to differentiate them with. Also, this completely gets rid of the 'ages ago' category, though of course songs can still 'collide' by having the same 'TIME'

--pj

TIME should be the log(base 2) of the actual time difference, with as many bits of precision as are possible at any given time (if you're messing with unix time_t's, the largest log base 2 will take 4 bits of integer, leaving the other 11 for the fractional part).

<tommyboy> You can get a good look at a T-Bone by sticking your head up a Bull's arse, but most people just take the butcher's word for it. </tommyboy>

So I'll take your word for it...
I mean, it sounds good but I imagine I speak for may users on this board when I say:
"I have no idea what to do with such information."

Perhaps you may have added a few "Custom Shuffle Modes" to your empeg that us "simpletons" might find handy, convenient and usable.

Something like these:

shuffle0=Favorites,PLAYS=-32000
...you'll get a shuffle of your playlist in sequence of number of plays, highest # of plays to lowest # of plays. Keep the player paused and keep reshuffling the playlist and you'll keep getting the exact same sequence of songs.

shuffle0=Favorites,PLAYS=-32000,RANDOM=1
...and you'll get the same as the above, but songs which have the same # of plays will be re-shuffled amongst themselves each time.

take 4 bits of integer, leaving the other 11 for the fractional part

All that kind of stuff got way too complicated. In beta 13 it's done in 32-bit quantities (and 64-bit total), not 15 (and 32).

Peter

A-Ha !!
So now me goes to install beta 13,
is there some kind of interface for adding shufflemodes ?

So now me goes to install beta 13,

Custom shuffles still have some bugs in beta 13, FITNR. It's a lot better than beta 12 though.

is there some kind of interface for adding shufflemodes ?

No, you still have to illicitly furtle with config.ini as previously.

Peter

No, you still have to illicitly furtle with config.ini as previously.

Is the syntax for illicitly furtling config.ini still the same as above?
Are strings I mention above still applicable?

Custom shuffles still have some bugs in beta 13, FITNR.

Interesting. I was wondering about that. In b13, I'm still doing least-recently-played shuffles and it's sometimes playing stuff I just heard in the prior shuffle. Not as much as in beta 11, but sometimes. Would the FITNR stuff account for that?

In reply to:

---

So I'll take your word for it...
I mean, it sounds good but I imagine I speak for may users on this board when I say:
"I have no idea what to do with such information."

---

Well, the intent was to compress the time-since-last-played, which is a 32 bit quantity, down into 14 bits, 1) without sacrificing ordering (ie. small numbers should still be small, larger numbers should still be larger) and 2) without having too large of an 'ages ago' category (which was the problem with the previous method).

I guess the point is, it doesn't matter what the numbers really *are* as long as you know that things you haven't listened to in a long time have higher numbers than things you've listened to recently. That's all you care about anyway.

Of course, all this is moot if they've now moved to carrying the whole 32 bits around.

--pj

Of course, all this is moot if they've now moved to carrying the whole 32 bits around.

...of course.

I love all the new features in 2.0 beta. I have also noticed randomization problems. I don't know if its bugs or a feature oversight though. When I use SHUFFLE mode..things seem to do more or less what they are supposed to. However, I very infrequently use shuffle mode per say. What I wish is that the playlist randomization (without shuffle) was smarter like shuffle mode is supposed to be. For example...

I have all my stuff organized by artist/album as many others have also done. The idea is that folders are randomly selected but then the album folder playlist is set to "ordered" so that the album plays in correct order. The idea is that I can randomly hear complete albums. All that works fine. However...it repeatedly brings up the same albums at the front of the list and ignores many others. its generally easier if an album comes up I don't like to just start over with a new random playlist...but it seems that there is a small subset of albums that always seem to be at the top of the list.. Can the randomization algorithms that are used for playlist order (not the shuffle mode) be improved to use some of the new algorithms that are used in shuffle mode..such as least recently played, etc.. ???

it repeatedly brings up the same albums at the front of the list and ignores many others.

You could be describing something that's just an interesting statistical coincidence.

However, the more time I spend with this car player, the more I think that its randomization routines aren't all that random. The notes in this thread (and others), combined with my experience, are leading me to be increasingly suspicious.

This article, although not related to the compiler that's used to make the empeg software, gives some insight into how the randomizers built-in to a language might not be right, and how a programmer might work around the problem.

I tend to agree. I hear alot of the same stuff. Also get groupings of the same artist more than randomness allows for. (ie...MANY of my artists only have a couple tracks on the player, yet they end up with playing with only one song between them all the time)

There is no question in my mind that the randomization routines need to be improved. I only have 500 albums in my player. That isn't so many. when randomly choosing one of the albums(ie, folders ) from a list of 500 or less...it should not be difficult after months of using this thing to hear just about any of the albums in there. However there are definitely certain ones that have NEVER come up near the front of the list...and others that repeatedly come up at the front of the list. Over and over...

I understand that they improved the shuffle mode to keep track of most often played, most recently played, etc..in order to sort those to the bottom of the list....which is great..but from what I can tell that only applies when using Shuffle mode. When I'm using the player with Shuffle-mode off...and I have the top level playlist set with the Randomized order attribute....I definitely get the not-so-random playlists coming up time and time again....no matter how many times I've heard that damn album that keeps coming up at the front. Its gotten to the point where I now find the random feature useless because I'm sick of hearing the same albums it always sorts to the front. So I'm back to just manually trying to think of albums and then choosing them manually. But I much preferred the notion of having my player just randomly pick an album for me....and the first item in the list should always be completely random...not repeatedly the same one.... There should be absolutely equal chance of any one of my 500 albums coming up as the first one in the list. At right now..that is DEFINITELY not the case.

I defninitely agree with you.

On my 10GB, I would put the thing into shuffle and get the same damn songs within the first 100 or so in the playlist. Yet I'd NEVER get other songs.

I find it particularly interesting that I had one song that accidentally got a Plays=33 on it (while others were below 10). From then on, it never came up in any of my shuffles again (at least not anywhere near the beginning).