Home ›

Podcast Recording Shootout

Issue 169

From Issue #169
May 2008

May 01, 2008  By Dan Sawyer
 in
So many VoIP programs, so little time. What's a podcaster to do?

Do you have a podcast? Okay, dumb question. Of course you do—podcasting is the blogging of tomorrow. It's quick, it's easy, it's not tied to a computer screen, and your audience members can take you with them anywhere on their iPod-ish devices. Best of all, you don't have to worry about actually learning to spell in order to inflict your opinions on others. So long as you can speak clearly and have fun doing it, you too can have a podcast. So who wouldn't want to do it?

I mean, you have an opinion you want to express, right? Or you have a story you want to tell. Or you simply have a desire to see what will happen if you gradually fade the volume out on your podcast until it's near zero, encouraging your listeners to turn their headphones up, before you blast them with a channel-saturating guitar riff to wake them up. The point is, you have a podcast, or you want one.

One thing you begin to notice when you get into podcasting is that listening to your own voice is boring—really boring. It's cathartic to rant into a microphone for half an hour and then put it on iTunes for the world to hear, but after a while, it's really nice to have listeners call in, or have guests, or pick up a cohost in another state.

How can you do it? Telephony, naturally.

Now, I must emphasize that not just any telephony client will work. Ekiga and Skype are not created equal. Neither are Gizmo and Twinkie. That doesn't mean they aren't all good for something, but good for something isn't the issue here. We need good for podcasting, which is a whole other spool of fiber-optic cable.

In my podcasting and production career, I've run into a lot of remote conferencing, and I've found that pretty much any remote conferencing is done for one reason: you can't get the talent into your recording studio (humble as it may be).

A Note on Production

Your podcast will sound only as good as the production technique. Good equipment is important, and good doesn't always mean most expensive. More important is good engineering—proper EQ and compressor settings, a low noise floor and proper mic technique will make or break your production sound. The software you use is a small component in the podcasting battle. Production and publicity are the other two parts of the holy trinity. If you want to survive in the new media world, get to know them all.

Why this can happen is a bit of another matter. For one of my podcasts, The Polyschizmatic Reprobates Hour (don't ask), my sometime-cohost lives halfway across the country, and to have any kind of intelligible real-time conversation, we needed a good telephony setup. This went double for when we needed to bring in guests for interviews. The basic requirements list is as follows:

  1. Good sound quality: this show is already going to be compressed to MP3; we don't want to start off with crappy sound in the first place.

  2. Ease of installation: most people still are fairly technophobic or tech-ignorant, and most people still run Windows. That means whatever telephony software you're using for your podcast conferencing, it has to be one that you can get guests up on in a few minutes. Longer or more troublesome than that, and you're going to hear the words of death: “Maybe we should do this another time.”

  3. Ease of dial-out/dial-in: sometimes, your guests just aren't going to be able to get on your VoIP network, and when that happens, you have to call them on a phone. In that case, you want the experience to go quickly and smoothly—there's nothing worse for your street cred than making a guest, who has carved out an hour for you, wait by the phone. Chances are you'll need to do this at some point. When you do, will it be quick and painless? Will the price be right?

  4. Ease of recording: of course, the best-sounding protocols on the slickest software in the world aren't going to get you anywhere if you can't record your conversations, and on this score, VoIP software is justly infamous. Because of the way most conference calls grab your sound ins and outs, it often kills the hardware duplexing your otherwise bright-and-shiny ALSA drivers usually support. But, a lot of people podcast over telephony, so there has to be a way.

  5. Carts: this is something from the old days when those of us who took broadcasting training at college radio stations actually had to juggle tapes. A cart was a tape cartridge on a continuous loop that contained station ID, sound effects, music beds or anything else we wanted to punch in to the broadcast. Nowadays with podcasting, most people just lay this stuff down in the final mix, but sometimes it's nice to be able to play things while the show is being recorded—sound effects, quotes from sources upon which you're commenting and so on. This is one of those nice-to-have-but-not-essential features, which does make life a lot easier.

Now, looking back over that list, the vast field of SIP clients narrows substantially. Instead of a couple dozen to pick from, there are only two that will fit the bill, and neither of them are open source.

______________________

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions