Comment by codeulike | Hacker News Reader

Comment by codeulike | Hacker News Reader

Parent Full thread

Haha. Hello, I had an Archos Jukebox 6000, in 2001 or so. From what I remember it was pretty awesome. The first MP3 player with a decent hard drive (available for some years before the iPod). I think my main niggle was that it was missing a 'play randomly from my whole collection' feature if I remember correctly. And I think there was a limitation to the length of a playlist so you couldn't just make a huge playlist and randomise that.

Before rockbox there was some PC utility that would read the whole Jukebox file list and then generate a series of randomised playlists numbered 01 to 99 which covered everything. As such, a roundabout way of getting a global shuffle.

In a way I think this is quite interesting, these days the idea of shuffling songs from your entire collection is very commonplace, but before large-capacity mp3 players people hadn't really thought of doing that before, so perhaps it never made it onto 'features people want' lists. Its obvious now, maybe it wasn't obvious then.

Was there any thought given to a global shuffle feature?

the problem with global shuffle was that you could have a LOT of music on the device, thus for a global shuffle you would need to hold an index of ALL the music in memory, and I did not like that.

Also, I was never a SHUFFLE ALL type of person myself since that would mix way too different styles of music for my taste - even today, I mostly listen to an album at a time

It doesn’t require much memory to shuffle, essentially just an integer permutation generator and possibly an index of block pointers. You could store the latter in the NV storage. This assumes no storable “playlist” at all. If you have playlists then shuffle is trivial.

true, but as said below, I was a bit green at that time.

what we did have was that we would remember a song not by its full path which could be like 256 bytes long, but by only 8 bytes, so when we read in an playlist, we would convert each file path into these 8 bytes and use them to retrieve the tracks later. that made parsing playlists "slow". Rockbox did access the playlist as a file, so they would only resolve the path when the next song was needed, but then they had the time and leasure to write a Posix like file API whereas we moved in a hurry and used a much more primitive block based approach. this was also born out of the fact that our design initially had only 128k of RAM and a larger SDRAM for buffering while the drive is off was only added later...

Probably today I would use a bloom filter to avoid duplicate plays. You could even produce a transition matrix between albums with similar code and memory complexity.

That's why we need an album shuffle function.

Reply on news.ycombinator.com