random($foo)

Being landlocked by the marathon for most of the day, I ended up mostly hacking around with JpGraph instead of doing the countless other things I should have been doing.

That being said, I don’t think it was a total waste of time. My goal was to try to replicate the floater/sinker graphs that EatWatch creates, and I more or less succeeded. I’m using a simple moving average rather than a full blown exponentially smoothed moving average (I think it’s pretty straightforward to implement, TODO) and I don’t know how (or if) the first values are dealt with in EatWatch.

The above is fake data, but it gives an idea (I don’t have enough data points yet for the SMA to kick in). Here’s a look at the source, and also the patch for the floater/sinker enabled scatterplot (against JpGraph 1.17)

I spent a couple hours today messing around with parsing the iPod iTunesDB.

Ostensibly, this is for the purpose of writing an Audioscrobbler plugin for syncing the songs played. (iScrobbler does this, but not if you don’t have autosyncing on – since my iPod is pruned from a much larger collection, I have manually manage my songs).

At first glance, there seem to be many options, but neither Mac::iPod::DB nor Mac::iPod::GNUpod support the ‘lastplay’ fields. libitunesdb and Sam Wood’s iPodDB.cpp are out of the running because my C/C++ skills have now faded to nothing.

Anyway, it turns out that GNUpod does support the lastplay field, and after you install the scripts, it also installs the GNUpod::iTunesDB package. Using the tunes2pod.pl as a base, it was pretty straightforward to pull the tracks from the “Recently Played” list and sort by lastplay date.

That’s about as far as I got, so I get output like this:

2005-03-05 18:55:14 - Bloc Party - Plans
2005-03-05 18:47:34 - Bloc Party - Banquet
2005-03-05 18:42:32 - Doves - Black And White Town
2005-03-05 16:29:53 - daft_punk - on_off
2005-03-05 16:22:26 - Bloc Party - Compliments
2005-03-05 16:18:05 - daft_punk - emotion
2005-03-04 21:54:48 - Four Tet - Tangle
...

I’m also calculating percent played based on the next played item to try to insure that it’s over 240s/50%, although I’m not sure exactly how skipped songs are counted, so I’ll have to experiment a bit w/ that.

What’s left to make this actually functional:

• cron/daemon to check for songs when iPod is newly attached
• md5sum + date check if iTunesDB should be read (reads are expensive, my 2400 song DB takes about 20s of full CPU usage)
• queing submissions
• submitting to Audioscrobbler (I’ll need to get a client id)

I’m probably not going to have time to get to finishing this anytime soon, but in case anyone is working on something similar, here’s what I hacked together today.

Some misc notes:

• The iPodLinux site has a very comprehensive page on the iTunesDB format (see the discussion as well)
• A pair of perl scripts that weren’t directly applicable to what I want to do, but are worth mentioning: tunes2html and tunesxml2html that convert iTunesDB and the iTunes Library XML to HTML listings
• One of the peculiarities of the date format is that its stored in Mac epoch time, which starts at January 1, 1904 instead of January 1, 1970. I couldn’t find the second offset anywhere online (it’s 2082844800 seconds) and I ended up calculating it in JavaScript after not being able to figure out an easy way to do it with Date::Calc:

  var d1 = new Date("January 1, 1904")
  var d2 = new Date("January 1, 1970")
  diff = d2.getTime() - d1.getTime();
  document.write(diff/1000);
  

Over the weekend I wrote some import processing scripts to dump in all my old random($foo) archives. That would be 3822 entries over the past 5 years. No matter which way you slice it, that’s a lot of text.

I’m working to do imports from my ’98-’99 stuff and miscellaneous other posts. I suppose having a better way to view archives would probably be a good idea. And then some graphs…

This command will disable autoplay for audio CDs:

defaults write com.apple.finder AutoplayAudioCD '0'

There’s a fun utility called drutil that is quite useful. It has a poll command which will run and output status/state changes (you could also manually poll with status, both are quite useful for scripting as you can imagine). It also has all kinds of related information dumps and of course, allows controlling of the tray and ejection.

Lastly, all the tools that you’d want for ripping/making CDs are available via Fink, although cdrdao requires compiling, and cd-discid and abcde are only available in the unstable branch.

Now that I have to suffer through frequent Tomcat restarts and other interminable waitstates, I figure I will have lots of time to pop CDs in and out at work. If I do 20 a day, I could be done in less than a month.

I just spotted this, and posted it on Upcoming.org, but thought I’d post about it as well to show my complete and utter excitement. Great flyer.

If you’re in town, sounds like lots of fun. (turns out I’ll be going to the Bright Eyes show on the 13th, so it all works out. sweet.)

With a crunch mostly over at the beginning of the week, I don’t have much of an excuse not to be posting anymore, especially considering this new layout was supposed to highlight my content production, not my conspicious lack thereof.

I spent some time tonight doing some cleanup/sorting. For example, filing and closing out about 30 unsaved OmniOutliner files that have been precariously sitting in my dock. I’ve upgraded to OmniOutliner 3 Pro, which among other features, has the ability to select and restrict views of sections. This eases on mental clutter, and is a great idea:

Also, over the past week, I’ve been much more diligent in scheduling the upcoming day in iCal. This works out well for two reasons. I already track my billable hours in iCal (I have a server-side script that processes the iCalendar file after it gets transferred via WebDAV that automatically updates our billing system as well as generates reports) and the additional scheduling only helps me keep on top of that, and also at the end of the day, I’m able to push off the things I haven’t gotten to and have half the next day scheduled. It’s one of those virtuous cycles, or something like that.

Here’s a direct quote from Evan Cornog’s Slate article, Portable Audio for Snobs:

Even using lossless files, none of the players sounded quite as good to me as the same music on CD played on a $50 Discman. But portable audio has to involve trade-offs, after all. Given the limited disk space of all these players, a lossless format is a reasonable compromise between low-quality, small MP3s and uncompressed files. If you value sound quality over convenience, buy a $50 CD player and take the money you saved to buy better headphones and a headphone amp.

Lets have a laugh and read that again: Given the limited disk space of all these players, a lossless format is a reasonable compromise between low-quality, small MP3s and uncompressed files. So, how are the bits different between an uncompressed file and a losslessly compressed file? (But the quads, man. It needs more quads.)

s/&(?!#?[xX]?(?:[0-9a-fA-F]+|\w{1,8});)/&/g

I’m glad to be helping DHB with their distribution of Eyes on the Prize. For infoporn, here are the tracker stats.

I stopped by Tom Jennings’ lecture on computer hardware at Machine yesterday, which was worthwhile not so much for the description on assembly (sort of muddled), but for the tangents and historical bits.

For example, I had no idea that core memory was manufactured primarily by Filipino seamstresses… (actually, all the early memory types are pretty interesting. Like acoustic delay line memory. Crazy.)

Some things that I’ll have to follow up on myself: assembly programming in relation to advanced features (handling out-of-order execution, pipelining, parallel processing), and the historical development of synchronously clocked architectures.