BTW, the original motivation to write that code was a bug in an early version of the DSP chip, it would produce a loud "click" each time the MP3 data stream stopped or started. so instead of stopping the stream I would either play a file (processed as per above) or if stopped or paused repeately insert a frame of "silence" that I encoded for every possible sampling frequency. luckily total silence is a really short frame to store
MPEG layer 3 (MP3) differs from layers 1 and 2 in the fact that the frame data for a given audio frame can be spread out over several consecutive MP3 frames, that makes the stream effectively VBR (variable bitrate) even if the total bitrate is fixed at e.g. 128kbit/s. due to that you cannot simply cut at MP3 frame boundaries.
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.
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 :)
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...
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...
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 :)
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 :)
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
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 :)