The iTunes Random Test

Introduction

Some days when I'm sitting at my desk listening to my iTunes music library on shuffle mode (which is how I always listen to it), I could swear that my iTunes loves to play me the worst music on my playlist, or is in some way plotting against me. Other times, iTunes will play nothing but METAL. Yes! \m/

So, is iTunes really random? <nerd_time>Well, obviously it can't be truly random, since that's impossible</nerd_time>, but does it approximate randomness, or does it really plot to play nothing but bad mashups and Ace of Base when you leave your desk, and your boss is looking for you? Well, there's only one way to find out.

To see just how sneaky iTunes is, I wrote a little Ruby program to test it out. It uses RubyOSA to communicate with iTunes through the Apple Event Manager, just like Applescript, and ActiveRecord to easily communicate to a MySQL database keeping track of the whole thing.

Update: My friend Ben is getting cranky because I didn't mention that this was his original idea.

Database

I stored the songs played, and the play counts in a MySQL database with one table named 'tracks'.

CREATE TABLE `tracks` (
  `id` int(11) NOT NULL default '0',
  `artist` varchar(255) default NULL,
  `name` varchar(255) default NULL,
  `play_count` int(11) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

The two interesting things to note here are that primary key is the iTunes Database ID, a unique value iTunes gives to every song in its library, and that we are keeping track of the play count ourselves. iTunes does keep track of the play count, but their definition of "play count" is your pressing the play button while a certain song is selected. iTunes does not seem to increment the play count when a song is played during shuffle play, so we keep track of it ourselves.

Test Application

I wrote the test application in Ruby because I like it, and because it has a nice integration with the Apple Event Manager/Applescript called RubyOSA, which makes communicating with other OS X applications a breeze. The source code is available for your reading pleasure. Like all good Ruby programs, it's not very long.

If you want to run it, make sure to change the database connection settings to reflect your system.

The algorithm is stone simple:

  1. Programmatically click the "Next" button in iTunes
  2. Get the track it selected
  3. If the track already exists in our database, increment its play count; otherwise, create a new record for this track, initializing the play count to 1
  4. Sleep for 1 second to avoid chewing up all my CPU
  5. Repeat Step 1

Procedure

Running the test is easy.

  1. Create the database
  2. Install RubyOSA and ActiveRecord if you haven't already sudo gem install rbosa --include-dependencies
    sudo gem install rails --include-dependencies
  3. Open iTunes, make sure your Music library playlist is selected, shuffle mode is on, and iTunes is Paused
  4. Turn off Synergy, SizzlingKeys, or whatever else crap you've got running
  5. Run it! ruby iTunes_random_tester.rb

I let mine run for 24 hours. Totally unnecessary, but 24 hours sounds way cooler than if I said I let it run for an afternoon.

Results

After 24 hours of my application clicking the "Next" button in iTunes every second, I thought my computer was going to be totally hosed. Actually, it didn't use up hardly any CPU at all. Good thing I added in that 1-second sleep.

Guess how many songs it chewed through?? 56,951! Daaaaaang!!

SO WHAT HAPPENED? Did iTunes play nothing but Unholy Grave alternating with Rod Stewart?? No! In fact, the results were INCREDIBLY BORING! iTunes' shuffle mode really does work, unfortunately.

SELECT play_count, COUNT(id) FROM tracks GROUP BY play_count

Boring Results
Play Count Number of Songs
241229
251293
26310

Boooring.

If you'd like to look at it on a track-by-track basis, you can view a dump of the database table in a nice HTML table or straight up XML.

If you're curious about order, you can view the Terminal dump of the program as it was running. The full 24 hours weren't captured, but quite a bit was.

Back to my home page.