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...