at times it was one of the rather large open source SW projects in terms of users, developers, testers, translators, doc writers. I'm kinda proud to have caused that :)
AMA
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?
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
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...
I was never angry about the fact that people preferred the alternative, given that with Archos we were running at breakneck speed to release a new product every year, constantly piling on more features for better or worse. there was little time to look back and reflect :)
It was my first USB 2.0 storage device I owned too. Soooo fast!
But ya I ran rockbox..
I wrote code to on-the-fly and in-memory convert a fixed bitrate MP3 stream into a variable bitrate one with differing frame length for each frame, adding padding data if needed to adhere to the allowed standard frame sizes. Once I had that I could drop or repeat MP3 frames, thus making the music play faster or slower. Since the reconstruction filters in MP3 decoder where already working across frame boundaries, they would also help to smooth over the artificial transitions introduced by this.
This works nicely up to a speed change of +/- 10%, going much slower would e.g. noticeably double snare drum hits or other percussive sounds.
of course you can also reassemble the frames in reverse order, I have a prototype MP3 "DJ" player where you can use a jog wheel to scrub forwards and backwards through an MP3 file without decoding it.
there, my secret is out :)