Audiobooks 2.0: Listening at double speed and beyond

I'm a huge fan of audiobooks, and I listen to them almost exclusively in the car. I currently commute around 60-70 minutes a day total, and instead of being frustrated by traffic, I often arrive at work or home excited and invigorated by a new idea that I picked up in my classroom on wheels. However, one thing that I do that often surprises people is that I listen to nearly all my audiobooks at double speed or faster. Fortunately (or perhaps as a consequence), I commute alone!

The San Jose public library system has a huge selection of audio books available for download in MP3 and WMA format, as well as a number of books on CD that can be ripped to MP3, and I have recently begun to purchase more books from Audible.com now that I am not completed blocked by their DRM. I use my Android phone as my portable media center, but I was turned on to the idea of high-speed listening by an iPhone user because Apple has variable-speed playback built in. I use an Android app called Astro Player Nova (the paid version, although they have a free version that also does speedups) that allows me to increase (or decrease) the playback speed, while providing pitch correction so the speaker doesn't sound like a chipmunk. Most audiobooks are recorded at a comfortable speaking pace (~150 words per minute),  but most people are able to easily process spoken language at at least 2 times that rate. It is a little daunting at first, but I started out at 25% faster, then gradually increased it until I now start most books at double speed and move up or down according to the book. Although in theory I can probably go even faster, I find that the software begins to clip words together. Yes, I know, blaming the software, not the "wetware"... At that rate, I enjoy a new (unabridged) book nearly every week, and I also find that the faster pace keeps me more alert.

Prior to getting a smartphone, I used a rather cumbersome pipeline (tools glued together with perl) that would convert CDs or MP3s into WAV files, then run these through mplayer to do the speedup, resize them into 2 minute chunks for easier indexing (my old CD player would only start at the beginning of the song, not exactly where I was when the engine stopped), and then finally re-encoding them as MP3s before burning them onto CDs for playback in my CD player. Variable speed playback of audiobooks was actually the deciding factor that pushed me over the edge to a smartphone! DRM protection on the audiobooks is still a nuisance for both WMA files and audible.com files, but tunebite helps.

Trying out Evernote for my note collection

Since 2005, I've been keeping my collection of notes in a text file. It is part journal, part idea book, and part todo list. I tried a few different tools and techniques, but kept coming back to the simplicity and ease of a single file edited in vim. I wrote a few supporting perl scripts to make it a little easier, including a template for new notes, timestamps, backups, and some very basic search capabilities. Despite also using version control (RCS), I managed to delete a significant portion of my notes when upgrading my server at one point, and so the system remained a little fragile. However, when I got a smartphone about a year ago, things changed and I began to need a way to add notes on the go as well as from my computer. I created a simple web application wrapper for my notes file, and then I could post to my notes file from the web. Unfortunately, this system was very much optimized for writing notes, and much less useful for searching or browsing through related items. I was intrigued by the idea of a commonplace book as described in the outstanding book Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson. A commonplace book is a cross between a scrapbook, a journal and and idea book, and rose to popularity nearly 500 years ago in Europe. One of the most interesting characteristics of a commonplace book was the cross-indexing of topics to enable me to pick up threads of earlier ideas and combine them together serendipitously. I wanted to have better searching capability than I was willing to write or wire in, and I wanted to be able to combine notes gathered from other sources (like audio transcriptions, documents, images and web pages) into a "common place".

Enter Evernote. I tried their free online note service a few years back when I was looking for an online Getting Things Done (GTD) application, but it didn't stick. However, this time around I was excited to be able to upload audio notes from my phone straight into Evernote, and then transcribe them at my leisure. I record voice memos when listening to audio books on my android phone, or any other time when I have a phone but not a keyboard. I also like Evernote's synchronization feature, which stores notes in the cloud, and also locally on one or more computers/devices, and will automatically synchronize them. (Cloud + local storage is the best sort of backup). What finally tipped me over to giving it another try was the text (XML) import/export format. I'm concerned about vendor lock-in, and wouldn't want to put my notes into a cloud-based application without a clear path to getting my data back out in the event that I was unhappy with the system. So, with a bit of perl hackery, I wrote a script that would parse my existing notes file (350+ notes), massage dates, extract tags, and covert it into an XML document that could be imported directly into Evernote. Evernote has a number of companion products and services made possible through their API, and that is a big plus. The one feature that caught my eye is service that will transcribe up to 30 seconds of audio for free. I'm going to give Evernote another go, and see if I can improve on notes.txt + vim.

Tasksets in Gearman

Here's a little tidbit about using the Gearman Perl Client:

Gearman is a powerful yet simple job queuing and distribution framework with clients in a variety of languages,  written by the Djanga folks (who also wrote memcached).

For a recent project, I needed to be able to queue up a potentially large number of jobs during one phase of execution, and begin processing them  went out to find more work to queue. At some point, we would know that we had no more jobs to add to the queue, and would be ready to move on to the next stage when all the jobs had completed. Gearman::Client provides a synchronous "do_task()" method that waits for a task to return its result, and a "dispatch_background()" method that runs jobs in the background. The limitation of background jobs is that it does not return results: you are merely able to monitor the status of the job to see when it completes. Task sets to the rescue!

Task sets allow you to group a number of jobs together, begin executing them immediately in the background, but with full access to the return values, errors and retries via event handlers. Furthermore, task sets provide a wait() method that will wait until all jobs have finished (either succeeded or failed), which was exactly what we needed.

Here's some sample client code that I used to verify this functionality:

1:  #!/usr/bin/env perl  
2:  use strict;  
3:  use warnings;  
4:  use Gearman::Client;  
5:  my $client = Gearman::Client->new();  
6:  $client->job_servers("localhost:4730");  
7:  my $tasks = $client->new_task_set();  
8:  for my $count ( 1 .. 10 ) {  
9:    $tasks->add_task(  
10:      echo => $count,  
11:      {  
12:        on_complete =>  
13:         sub { my $result = shift; warn "from job $count got " . $$result; },  
14:        on_fail => sub { warn "ERROR from job $count"; }  
15:      }  
16:    );  
17:  }  
18:  warn "done adding tasks";  
19:  sleep 5;  
20:  warn "waiting";  
21:  $tasks->wait;  
22:  warn "bye";  

The critical part of this prototype was to verify that jobs began to be processed by workers when the job was added to the taskset on line 9, and not only at the call to wait() on line 21. 

And here is the trivial echo worker that returns whatever you send to it:

1:  #!/usr/bin/env perl  
2:  use strict;  
3:  use warnings;  
4:  use Gearman::Worker;  
5:  sub echo_worker {  
6:    my $job = shift;  
7:    my $arg = $job->arg;  
8:    warn "ARG: $arg";  
9:    return $arg ;  
10:  }  
11:  my $w = Gearman::Worker->new();  
12:  $w->job_servers( "localhost:4730" );  
13:  $w->register_function( echo => \&echo_worker );  
14:  $w->work while 1;  

Without tasksets, it would have been substantially trickier to