In the middle of 2004 I purchased a Creative Nomad Zen Xtra portable MP3 player. “MP3 player” was not quite a commonplace concept yet but the word “iPod” was beginning to catch on. When describing this new toy to people, I usually described it as “about the same as an iPod but about 1/2 the price” which was absolutely true when I purchased it.

Here is my Nomad compared to a 1st generation Apple iPod Touch, my current MP3 player (and more):

The Nomad Zen Xtra served me well for 3 solid years until I finally got a proper iPod in summer of 2007. I have kept the unit around since then for no particular reason. I decided to disassemble and photograph it before I send the battery and electronics off to their respective recycling destinations.

The Nomad Zen Xtra was highly user-servicable and upgradeable. At the time I put it out of service, the battery could barely run for 5 hours (whereas, 10-12 hours was no problem when it was new). A replacement battery would be easy enough to order from assorted battery shops on the internet.

Have more than 40 GB of songs? Take off the back of the unit, remove the 2.5″ 40 GB IDE HD and replace with a larger one. That never proved to be necessary for me; in fact, I soon realized after I bought it that the lower-end 30 GB model would have been well more than enough.

The 40 GB HD from the unit is still perfectly good. I decided to hook it up to a Linux computer and see if there is anything I could work out about the filesystem. Before I got too far into it, a little Googling led me to a Python utility called zenrecover.py. Works famously:

$ python zenrecover.py /dev/sdc songs /home/melanson/mnt/zen
0% 3.6MB/s "Bizet_Intermezzo_from_Carmen.mp3" (6.8MB)

Just for fun, I dumped all the songs from the unit. I discovered a few things I had long forgotten and had never made the transition into my iPod. Curiously, the very first items that the utility dumped (likely because they occupied the first parts of the filesystem) were a selection of classical tunes as played by the “Beijing Central Phil Orchestra”. These songs came with the unit. It’s notable that the software transferred them off because the packaged software did not allow the user to do so (I’m pretty sure it allowed all music that was downloaded to be transferred off).

Ugh, that packaged software had to be the worst part about the Nomad Zen Xtra. I know lots of users like to chastise iTunes over a range of pet peeves. I think such people have simply never been exposed to anything worse, like this software.

Someone recently updated a link in the MultimediaWiki page for mirrored documents. Naturally, that doesn’t automatically update the mirrored copy @ multimedia.cx (having me poll the page history and manually update the mirrored copy hardly counts as an automated process). I suddenly thought that it would be desirable to have a content management system that allows authorized users to upload and organize documents, particularly PDF documents which comprise many of these mirrored documents. Sort of a… document management system.

“Document Management System.” Sounds enterprise-y. Here’s what I want:

• Free, open source solution in which I do not have to modify a single line of code
• Allows me to create a list of users who have permissions to upload or delete PDF documents
• Allows authorized users to upload or delete PDF documents
• Manages at least a minimum of metadata

The key thing here is to allow authenticated users to upload and manage these mirrored documents. I know many will say, “Drupal/WordPress/MyFaveCMS can be coerced to do just that!” And I don’t dispute any such claims. It’s also true that nearly any program you need to write can be written in straight C, eschewing any higher level languages. I was just hoping for a more turnkey solution that doesn’t require me to learn a lot or do my own coding or customization.

I guess the problem here is that no one sets out to just write such a simple CMS. A CMS might start out simple but eventually grows into the next Drupal. I probably need to come to terms with that fact that there is no prepackaged solution that exactly fits this simple need without at least some tinkering.

The IETF has recently put out a request for an audio codec. This may strike some of you as remarkable that anyone would need another audio codec since, at the time of this writing, we have cataloged 137 audio codecs via the MultimediaWiki. You have to give the request some attention, though– it acknowledges that there are already lots and lots of audio codecs in existence and explains why each category is unsuitable to the goals of the request. I’m not going to be the one to audit every one of those 137 codecs and identify why each is unsuitable for the outlined goals.

I am a bit concerned about some of their stated goals, such as the very first one: “Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance).” Generally, one of those examples is not like the others (unless, perhaps, “live music performance” refers to a cappella singing. Then again, the request later states that optimizing for very low bitrates (2.4 kbps and lower) is out of scope.

I accidentally used the main ‘ffmpeg’ binary as an input to itself. Its best guess is that it’s an MP3 container with MPEG-1, layer 1 audio data:

[NULL @ 0x1002600]Format detected only with low score of 25, misdetection possible!
[mp1 @ 0x1003600]Header missing
    Last message repeated 35 times
[mp3 @ 0x1002600]max_analyze_duration reached
[mp3 @ 0x1002600]Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'ffmpeg_g':
  Duration: 00:03:20.29, start: 0.000000, bitrate: 256 kb/s
    Stream #0.0: Audio: mp1, 32000 Hz, 2 channels, s16, 256 kb/s
At least one output file must be specified

What an Easter egg it would be if the compiled binary could actually decode to something — anything — valid.