Do you have a source for that claim?

For me, random means: "I want to hear every song in this selection exactly once, chosen randomly". Random should mean uniformly distributed and I don't care whether the same artist or album is played back-to-back. I feel like this is exactly what "shuffle" has meant for decades before some UX quack at Spotify headquarters decided they knew better.

Thats why the feature is usually called "shuffle" rather than "random". Then if you stop to think about it a bit, the expected meaning is reasonably clear.

So... what you're saying is that you don't want to hear the same song too soon after hearing it before?

No, I’m saying I want to hear every song in the list exactly once before any is repeated. Your summary is more generous than my definition.

That's shuffle, not random. Maybe randomized. With random, every song should have the same chance of being picked, which would technically allow the same song to play twice. If you'd let the player run for a decade, every song should have played about the same number of times.

But this usually leads to people perceiving the feature as not being random enough.

See Spotify for example: https://www.quora.com/Is-Spotifys-shuffle-feature-truly-rand...

Random has a lot of meanings, and you are picking a very specific one. It doesn't have to be uniformly distributed, for example, but relevant here is I don't think there's a problem describing a random shuffle as "random". It is playing a list in a random order.

So... You'd say that my summary gets you 80% of the way there?

Lack of RAM? Make an array of pointers or ints or whatever corresponding to the current order of songs, then lookup each new song as the current song ends. Maybe 1kB RAM...

Yes, lack of RAM. First mp3 player I ever worked on consisted of a PIC driving an IDE hard drive over I/O pins, and an mp3 chip over I2C, with 2k RAM for the whole shebang. If you want to support more than 256 songs, you'll need 2 bytes per index value, so 2k RAM just for the shuffle table if you have 1000 songs. Then there's the hard drive controller, the FS driver and file I/O interface, the LCD driver, the send buffer to the mp3 chip, etc, etc.

Mp3 players have had more than 2k of RAM for way longer than two decades.

The hardware restrictions of the earliest IDE HD based MP3 players really have nothing to do with any limitations on modern shuffle ability.

IPod in 2001 had 32MB of RAM. 2k RAM is not relevant to this discussion. You getting close to discussing 3 decade old technology.

It's very relevant. The early technological restrictions become the standard practice, which fail to change after the original restrictions no longer apply.

Using random number generators for shuffle mode was a stopgap measure that everyone else cargo culted because it's easier than critical thought.

> Yes, lack of RAM

So how about using a maximal linear feedback shift register of smallest size greater than the number of songs, skipping entries that are beyond the end of the list?

Either keep the polynomials[1] in a small list, or implement them as separate functions, invoking the one you need via a function pointer. Both approaches take just a wee bit of extra FLASH/ROM, and just a few bytes of RAM.

https://en.wikipedia.org/wiki/Linear-feedback_shift_register...

So a permutation? There's no need to store the whole shuffled array in RAM, a big 64-bit co-prime number is enough, you don't care about cryptographically secure numbers, so even 32 bits could work.

For example for a 1000 songs playlist, you choose n to be 2416648531, start with i = 0, you then get the following permutation: 0, 531, 62, 593, 124, 655, 186, 717, 248.