This does not work. When married, all your and his/her accounts are locked, as they are considered shared property, no matter the name on the account. The legal proces after death is to decide who owns what as this decides what share the state gets.
Also not advocating for crypto, just saying you should be able to live a while without access to a bank.
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 :)
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.
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?
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 :)
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...
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 :)
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 :)
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.
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
a cheap dumbphone that retails for less than $20 has a BOM of around $5 and has CPU, battery and screen. so $20 retail for your cartridge is achievable in volume
