Dan Bricklin on becoming a Happy Caster

The Conversations Network is embarking on a new phase in which it will expand its ambition to capture, publish, and curate spoken-word audio from a wide range of sources. One of the challenges will be to help more people effectively capture audio to a reasonable standard of quality. Dan Bricklin, my guest for this week’s ITConversations show, has ascended that learning curve in recent years. In this conversation he explains why he’s become interested in audio recording, and what he has learned about equipment, and techniques, which can be readily transferred to individuals and organizations wanting to make decent recordings of their own events.

When I embarked on my personal audio adventure a few years ago, I naively thought that our fancy new digital technologies would make the whole process very simple. Boy, was I wrong about that. Yes, we’ve made digital photography accessible to the masses, but there was vast demand for enabling the so-called Happy Snapper to point, shoot, and take a decent photo. There’s been comparatively little demand for enabling the Happy Caster to plunk down a microphone, punch record, and capture a decent sound track.

Over the last few years I’ve slowly and painfully assimilated just a fraction of the audio lore possessed by domain experts like the Conversations Network’s founder Doug Kaye, and its senior audio engineer Paul Figgiani. So it was refreshing to hear from Dan Bricklin that it has also been a struggle for him to become competent in this domain.

I guess the demand for point-and-shoot photography will always outstrip, by orders of magnitude, the demand for plunk-and-punch audio recording. But the latter demand is growing, and in this conversation we speculate a bit on what the Happy Caster solution might be.

Mainly, though, Dan focuses on two things. First, the new opportunity to capture spoken-word events that would otherwise be lost, and publish them for audiences that didn’t attend, or couldn’t have attended, in person.

Second, the minimal setup that will enable folks who are not audio experts to accomplish that capture and publication.

PS: A bit of backstory on this recording illustrates some of the challenges of the audio domain. In my FAQ for interviewees, I invite remote interviewees to record themselves locally, then send me the track which I combine with my own locally-recorded track. Why? If you’re sending voice over the network, whether it’s POTS (plain old telephone service) or Skype, there’s a lot that can and often does go wrong. Eliminate the network and you avoid all those problems.

In principle, combining local tracks recorded separately is a great solution. In practice, it has almost never worked out, and this case was no exception.

Usually the problem is that interviewees lack the gear or knowledge required to make a decent local track. Attempts to record directly into a computer always end badly. Most people don’t own standalone digital audio recorders. In one case, a musician who routinely records his music through a mixer nevertheless produced an unusable track because he’s not used to recording his voice and overshot the limits.

In this case, Dan was quite capable of making a good recording, and he did, but things went wrong on my end. What Dan recorded was an MP3 file. What I was expecting was a WAV file, because I was going to edit the combined recording and it’s dicey to uncompress an MP3, edit, and then recompress.

Now, Dan had recorded the MP3 at a bit rate — 192kbps — that he judged would be high enough to survive an edit. But would our discriminating audio engineer Paul Figgiani agree? We weren’t sure, so I sent Paul samples of Dan’s MP3 track and the WAV file I made from the telephone track I’d recorded using the Telos. Paul’s verdict: “I think we can make the 192 kbps mp3 version work. The bit rate is high enough … lets go with it.”

So far, so good. But when I loaded up my local track and Dan’s remote track into Audition, things didn’t line up. My WAV track was slightly longer (or shorter, I can’t remember) than Dan’s MP3 track. The difference was only about 1.5 seconds over an hour-long recording, but still, it had to be dealt with.

Audition has a time-stretch feature that can be used to solve this problem. And I could swear that I’ve used it successfully before in these circumstances. But this time, I couldn’t make it work. Every time I tried to stretch the shorter clip, it snapped back to its original position. I fiddled with every approach I could think of, or could discover by searching, and finally threw up my hands and just used the original recording that had both halves of the conversation in sync. If this Audition behaviour rings a bell with anyone, I’d love to know what went wrong and how to avoid it next time.

The moral, anyway, is that if a reasonably technical guy like me is struggling to keep his head above water in this domain, it’s clear that non-geeky civilians will just drown. I’m quite curious to know when, or perhaps whether, those civilians will constitute a market that technology providers want to serve.