3 ms·

80% of people mean this: I don't want to hear the same song too soon after hearing it before. How soon is "too soon"? Probably anywhere from 50 to 200 songs. E

80% of people mean this: I don't want to hear the same song too soon after hearing it before. How soon is "too soon"? Probably anywhere from 50 to 200 songs. Easiest solution that gets you 99% there would be to make a shuffled list, run through the whole thing, then shuffle again. The only reason why this wasn't done in the past was lack of RAM, which isn't an issue anymore. Or if RAM really actually is an issue on your embedded device, use a Debruijn sequence.

ilikehurdles 7y ago
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.
- kstenerud 7y ago
  So... what you're saying is that you don't want to hear the same song too soon after hearing it before?
  - ilikehurdles 7y ago
    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.
    - kstenerud 7y ago
      So... You'd say that my summary gets you 80% of the way there?
    - iforgotpassword 7y ago
      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-random-I-keep-hearing-the-same-songs-in-my-library-too-often-for-it-to-be-a-mere-coincidence-Does-Spotify-use-some-kind-of-special-algorithm-to-determine-what-song-plays-If-so-why/answer/Mattias-Petter-Johansson https://www.quora.com/Is-Spotifys-shuffle-feature-truly-rand...
      - IanCal 7y ago
        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.
  - deleted 7y ago
    [deleted]
- shados 7y ago
  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.
craftinator 7y ago
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...
- kstenerud 7y ago
  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.
  - BoiledCabbage 7y ago
    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.
    - kstenerud 7y ago
      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.
  - magicalhippo 7y ago
    > 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#Some_polynomials_for_maximal_LFSRs https://en.wikipedia.org/wiki/Linear-feedback_shift_register...
Franciscouzo 7y ago
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.

ilikehurdles 7y ago

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.

kstenerud 7y ago
So... what you're saying is that you don't want to hear the same song too soon after hearing it before?
- ilikehurdles 7y ago
  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.
  - kstenerud 7y ago
    So... You'd say that my summary gets you 80% of the way there?
  - iforgotpassword 7y ago
    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-random-I-keep-hearing-the-same-songs-in-my-library-too-often-for-it-to-be-a-mere-coincidence-Does-Spotify-use-some-kind-of-special-algorithm-to-determine-what-song-plays-If-so-why/answer/Mattias-Petter-Johansson https://www.quora.com/Is-Spotifys-shuffle-feature-truly-rand...
    - IanCal 7y ago
      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.
- deleted 7y ago
  [deleted]
shados 7y ago
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.

craftinator 7y ago

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

kstenerud 7y ago
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.
- BoiledCabbage 7y ago
  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.
  - kstenerud 7y ago
    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.
- magicalhippo 7y ago
  > 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#Some_polynomials_for_maximal_LFSRs https://en.wikipedia.org/wiki/Linear-feedback_shift_register...

Franciscouzo 7y ago

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.