[av500]

I "caused" Rockbox, being the original firmware developer for the Archos Jukebox 6000. apparently the firmware I wrote was so bad around playlist handling and our CEO unwilling to open source the code so that the boys and girls wrote their own.

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

[codeulike]

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?

[av500]

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

[braindeath]

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.

[av500]

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

[microcolonel]

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.

[ruvis]

That's why we need an album shuffle function.

[foldor]

Very interesting. What was the development like for you? How much time did you have to do this? How experienced were you at the time? Were you ever upset to hear it wasn't loved by users, or was it something you were upset at having to release in it's state due to a fixed deadline?

[av500]

basically the "mp3 player engine" that was used by Archos (and a few other companies at that time, TerraTex M3PO, SSI NEO25/NEO35) was our first project out of high school, so the code is pretty bad looking at it today :)

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 :)

[av500]

I was more upset that Archos took our original design with a 4 line LCD and a rotary encoder and reduced it to a single line and U/D/L/R buttons - missing the whole point of "all" your music with you, thus needing a way to browse it fast...

[dsr_]

No questions, just a sincere thank you. Also, rec.audio.high-end thanks you.

[av500]

thanks :)

[nrclark]

Just a note - I had a Jukebox 6000 and I loved it! So at least one person didn't think the firmware was bad.

[cowmix]

I loved it and I loved Rockbox too.

It was my first USB 2.0 storage device I owned too. Soooo fast!

[av500]

actually JB6000 was still USB 1.1 I think, only the JB Recorder would add USB2.0 speed

[abacadaba]

Still have it and still love it! Not that I've fired it up recently.

But ya I ran rockbox..

[av500]

hey, that makes two of us :)

[codeulike]

Did you ever contribute to rockbox? : )

[av500]

not in code, but I think I answered a few questions. there was also the fact that another MP3 player I was involved in, the Terratec M3PO had a feature to change the MP3 playback speed and the Rockbox people wondered for years how we did that on the limited DSP that it had (same as on Archos products) - took them a long time and some hints to figure out :)

[saghm]

Can you tell us how you managed this now, or are you not technically allowed to even today?

[rasz]

probably custom code for the MAS DSP.

[av500]

nope, the MAS had MP3 decode fixed in ROM and while you could upload your own algo into the RAM and run it, that meant no MP3 decode at the same time :)

[big_chungus]

So how exactly did you do it? You can't leave me hanging now.