I need to thank Saron Yitbarek. She posted a tweet that had me laughing last night, as she was talking about how she needed to edit a podcast, but that she was procrastinating the editing, and she wanted to write a blog post about podcasting instead.
Please forgive me misspelling #TheTestingShow in my reply. I was a little tired. Still, her Tweet has been rattling around in my head all day. What if someone who listens to The Testing Show wanted to start their own podcast. What would I tell them? How should they start? What should they do? How do you actually produce a show? Could I put this all into one post?
I decided the answer to that was “probably not”, but I could do a series of posts about what I do as a quick and dirty tutorial about my approach as to how I edit and produce The Testing Show, so if you will indulge me, that is exactly what I am going to do.
First, you need a show, and to have a show, you need a topic. It helps if the topic is something you are nerdy about, has a direct connection to your professional life, or is otherwise something you would climb a mountain of people to do and, thus, talk about it with a passion. Hyperbole much? Maybe, but seriously, if you dig the topic in question, you will be motivated to make many installments, and that tends to encourage the commitment to keep making episodes.
Second, you need to decide how you want to present your show. Do you want to be a first person podcast, where you do all the talking? Don’t dismiss this, as several of my favorite podcasts are exactly this. Dan Carlin’s shows Hardcore History and Common Sense, Stephen West’s Philosophize This, most of the podcasts on QuickandDirtyTips.com, and a new one that I am currently enjoying called The Ends, all of these shows have a single speaker/narrator and work well in this format. Upside: you can produce shows anytime you want to. Downside: it’s all on you, and that means you have to provide all of the research, commentary, and thoughts. An interview or panel show add the elements of additional speakers and commentary. Upside: you get a variety of viewpoints. Downside: your ability to schedule everyone to record can be a logistical challenge, and the more people you want on the call, the greater the challenge. For The Testing Show, we have a rotating recurring cast. The general rule is that three of us together meet the minimum requirements to record a podcast on a topic, or two of us and a guest also meet that requirement. In a pinch, if we are remote or at an event, we will do a one on one interview with someone, but we strive to get three people into the conversation so there’s some give and take.
Third, how do you want to capture your audio? For the time being, I will leave video out of the mix. I will also leave in person recording out (though the Voice Recorder apps on iPhone and Android are actually quite good, and I have used them in live settings to great effect). We’re talking just an audio recording done with remote participants. If you’d like an inexpensive, but quite reliable, recording method, I recommend using Skype and the ecamm Skype Call Recorder. There are numerous recording options, but for now, focus on the voice-only option. The calls are saved as .mov files, and each file can be imported into your audio editor of choice.
Fourth, you need an audio editor. Which one you use is up to you. For the past seven years, I’ve used Audacity. It’s got a lot going for it, and once you get a handle on how to use it, it can be very fast to work with. Truth be told, there’s a lot of features that will feel like overkill, and if you want to record a podcast, 90% of the features will remain untouched, but I promise, the 10% that you do use you will use all the time, and they will become second nature to you (and as soon as they do, don’t be surprised to find out that the number of “essential features” starts to creep up 😉 ). Whatever you use, make sure that you can import the file types you save. Yes, I’m using a Mac, so I’m using Mac vernacular here. Once I’ve imported the Skype call as a .mov file, I am presented with a stereo track that has two channels. The first is the channel with just my dialog or the dialog of the person that recorded the call. The second channel is the dialog of everyone else on the call. If you want to go very clean and are willing to spend the time to do it, you can have everyone record their own version of the call, send you their .mov files, and you can import them all together.
GEEK TRICK: If you want to go this route, and you want to be a little cheap on the sync-up options, record a “beep series” at the start of the recording, and occasionally, during silences, insert the beep series again, as a standalone audio spot. Also, run the beep series at the end of the recording. Why? This series of beeps will be a visual cue when you import the audio files to help you line everything up. One you do that, split all of the stereo tracks into mono, then mute the secondary tracks that have multiple voices together. If you do this, you will get multiple first person recordings, made local to their systems, and the odds of removing drop outs and clicks/audio artifacts are much higher.
If you can’t get a native recording from everyone, or if you are the only one able to do the recording (common if you ask a guest to be on the show; it’s rude to ask them to shell out for software they may never use again), then you can import a single .mov file, split it into two mono tracks, and sync-lock the tracks together. This way you can select sections in each track to mute, and if you cut out sections of audio from one track, you will also be cutting the same time period in the other track.
GEEK TRICK: One of the easiest ways to do a fast condensing of a recording is to use the “Truncate Silence” feature. You enter in a minimal time limit that you want to search for (usually anything longer than a second), and you truncate all of that down to individual silences of one-half second. Why? This is a typical time space in average conversations. By reducing all silences to anything less than a second, you can take out several minutes from a podcast recording easily, with very little chance of cutting off something important. Along with this, if you listen to tracks and decide you want to cut sections, I suggest selecting the section and muting it first (meaning silence everything in that selected space, which on the Mac is Command-L, and Ctrl-L on the PC). By doing this, you can do a rough cut of your show, chop out the bits you know you’re not going to use, then run Truncate Silence to squeeze everything together.
Another consideration; this is important when you decide to publish… do you want to have show notes? Do you want to have a Transcript? Do you want to have both? The Testing Show provides both show notes and a full transcript of the audio. I have tried a number of methods for this, and truth be told, I keep returning to this approach. Fire up whatever word processor you want to use in one window, and your editor in another. As you do your fine editing, type out your transcript in time with the second by second audio scrubbing you are doing. If you are not providing a full transcript, this will be overkill. If you are not doing what I refer to as “grammatical audio editing” (that’s removing the “um’s”, ah’s”, like’s”, “you know’s”, and other vocal tics we all use when we speak) then again, this is overkill. If, however, you decide to provide both a grammatical audio edit and a full transcript, you might as well do them both simultaneously. You may incur a 15-20% overhead by doing both at the same time, but that’s not bad, really.
GEEK TRICK: If you come across a comment that you think might need referencing in the show notes, either highlight it or insert an end-note and type a reminder text about that entry. Later, when you review the end notes, fill in the actual reference values or URL’s to resource links. If you are online and can do it right then and there, all the better. Seriously, do this, and you will have produced 75% of your show notes. As to the pithy commentary to add as your “selling paragraph”, that’s an everyday struggle, but you will get better the more you do it. Seriously, though, I think I spend more time trying to get the introductory paragraph together at times as compiling all of the reference materials, and yes, I frequently feel like I’m an idiot as I review the text I’ve written, but over time, you just learn to roll with it. Sometimes, it works. Sometimes, it falls flat. So it goes.
Finally, you may want to spice up your podcast with music, inserted comments (bumpers) and some intro and outro comments. You may decide to do this differently each time, or you may want to standardize what I call “audio beds” that include these. For The Testing Show, our intro and outro music is provided by my band, Ensign Red. If you can make your own music, that will provide you with the ability to customize it as you need for your intros and outros or other uses. If you are not musically inclined, there are numerous sources of Creative Commons free use music samples that you can download and use. If you’d like to take the plunge, start with CreativeCommons.org and see what sounds interesting to you. It’s good protocol to give credit to the artists whose music you choose to use in your podcast. Mention them in your show notes and in the podcast itself. It encourages discovery of their music and thus, makes them more willing to keep creating Creative Commons content.
So there you have it, a whirlwind look at creating a podcast. Have I left a lot of stuff out? Most certainly. Would you like to know more? I’m happy to share what I know and how I do it, partly because I know the challenges of getting started and how large a mountain that is. Also, I have a slightly selfish ulterior motive. My hope is that, by sharing these posts, and giving people a peek into my world of producing these shows, someone might comment back and say “you know, you could do this sequence of steps so much more efficiently if you just [fill in the blank].” Hey, it happens with code review all the time, so why not with podcast production review as well :)?
Oh, and Saron, if you do publish that blog post, please let me know. I’d love to read it.