Sunday, 5 September 2010

Editing the Full Circle Podcast #3: The Edit Environment

I have a confession: this may NOT be the best tool for this job. It is certainly not fool-proof or bomb-proof. It can occasionally crash but it has the best crash-recovery routines of any software I know (except in the extreme circumstances where it has deleted or orphaned segments of a recording. See filenaming, versioning and backing up.)

Audacity works, I like it, I'm used to it. Now I've got it stable in Lucid, I'm going to stick with it.

Audacity In Practice
First-pass edit: I will edit each recorded segment separately. This means cutting up master recordings and saving as separate projects.

Import audio: I save the new project imediately so Audacity creates its working folders. Have plenty of disk space free, Audacity stores its working files as uncompressed audio.

My general rules from here:
  • Save projects often.
  • Don't do more than a handful of edits without saving.
  • Re-work is my enemy.
To compress or not compress?
If you make edits in compressed formats, then start cutting and pasting together, mix and render then export as compressed, your audio quality will be shot to hell by the end.

So I take the original file and convert to an uncompressed format such as f.lac BEFORE I begin editing. Yes, the file size is larger, but de-compression and re-compression eats CPU cycles and Audacity's working files and folders are uncompressed anyway, so save some electricity.

Unless you're using GIT or another version-control framework, you're going to have to institute your own tracking and versioning.

My working projects/files follow;
episode - edit date - qualifiers
I take an unedited file:

and convert to an uncompressed version to edit.

Once I have an edited version - just length and content, this saves to:

Then moving on to filters, effects and general post-processing, save it out to

Intermediate versions
I will periodically export my edits to an interim file.
and so on. I delete all the excess files at completion of project.

I can go as far as I want. It gives me some 'safe' copies and a macro-level of undo should anything go wrong.

Back up
For extended editing projects, always back up your .aup projects and interim files at the end of each session, preferably to external media off-machine. I delete all the excess files at completion of project and just keep final copies.

Source tracks
I don't need Stereo for a podcast. I'm not Kraftwerk panning left to right and through surround sound.

Through Skype call recorder, I get a low sample-rate mono ogg file.

For non-skype recordings - titles, trailers, music - I go for 44.1KHz stereo. I can downgrade the sample rate and quality in the edit, I can't put in what wasn't there.

I import into Audacity converting stereo to mono when needed. Remember you can't paste stereo into mono, two tracks into one won't go.

Resample! I always work with the same sample frequency for all tracks (44.1KHz).

Technical Edits
The editing workspace in Audacity works well if you can expand, collapse, resize and zoom at will. Undo is my friend.

Effects menu; Filters
Clean up starts with Noise Reduction. Select a it of blank recording where no one is speaking. What you'll be listening to is the background hiss or line noise.
Run once using Get Noise Profile, select the whole track then repeat  the filter (control+R) to run Noise Reduction with the same settings.

To enhance the audio, I'll run more or less of:
  • Bass boost
  • Pitch shift
  • EQ
to make up for the Skype quality and low sample rate. It artifically fills in the signal and warms up the sound.

Tempo changes are usually reserved for Dave Wilkins, to slow him down to an intelligible words-per-minute count.

I may selectively apply these for segments of audio or across the whole track.

The Leveller boosts the low amplitude parts of the signal to get a more 'level' waveform.

Amplify and Normalise
All our recording have low signal levels. This is deliberate. I can fix levels with Amplify and normalise, I can't fix clipping of a signal that booms past 0db - when it bounces off the red end of the scale.

I will Level the finished track to -0.3, leaving some 'headroom'.

Automatic 'errm' remover
Sadly there isn't one. Normal speech is littered with pauses, stutters, repetition and 400 varieties of errm, aah, err, eh, and other verbal ticks. 'Sorta', 'kinda', 'like.'

A few occurrences you can tolerate, but too many ruin the listening experience. The human ear tunes in to imperfections making each instance more and more of an irritant. Continuous, coherent speech, however, is a learned skill.

So I zoom into the wave form and cut them. I don't take out every single instance, that's a lot of work. We're only human.

This was hard at first, but having edited the same person's speech, I can 'read' the wave form and spot the verbal glitches. My 'errms' have a distinct shape in the waveform for me.

Editorial Policy
Being family friendly has its issues. We are pretty good, but sometimes unintentionally cross the boundary with a throwaway line. I hate the modern obsession we call "political correctness gone mad" and in my private humour I reserve the right to offend anybody at any time. And I do. But not for the podcast.

Out go:
  • Swearing
  • Blue jokes
  • Race jokes
  • Religious jokes
  • Minority jokes
  • Disability jokes
Also I try to minimise:
  • Apple bashing
  • Microsoft bashing
  • Other Linux Distro bashing
Not because its disriminatory, but they're such easy targets it like kicking a tramp when he's already down.

So I have to listen as an outsider and take out any references which push the boundaries of acceptable taste and decency.

Content Edits: Deep Thought
Here's the difficult bit; making three British guys sound like intelligent experts. Or even functioning human beings. You have my sympathy if you have to talk to us face to face.

The best radio sounds like a well-formed stream of conciousness. We don't. It's worse than that, we are unscripted. Most people have a very weak internal-edit button.

Half lines, incomplete thoughts, halts, restarts. All have to go.

Dead Air
Almost the last step is to cut all the dead air. I hate dead air. For one thing, it wastes air time. For another, when a speaker pauses for too long, it makes the listener uncomfortable. Thirdly, in audio only, listeners think its broken down and start checking the media player. Do this twice in one show, they've given up and gone.

Edit for Length
All the way through this I'm listening back to make cuts for final length.

I know how many segments we have for the episode and a rough timing (or precise timing for the pre-records). There are two criteria:
  • relevant to the topic
  • entertaining and relevant to topic, or at least not too far off it.
The 'live' discussion segments are unscripted and even whilst recording I am on the lookout for rat-holes and dead-ends in the content. Some of the amusing 'banter' also has to go. See editorial policy.

I will note (mentally or on a scrap-pad) some outtakes.

The Quality-o-meter also kicks in. If the comments are not intelligent enough, are too obvious, vaccuous or add no value (cliche and duck-billed-platitudes) they're gone.

Trouble is a lot of our material is technical. Some of it - i.e. gaming - I know nothing about. Editing is difficult. Are we saying anything useful or entertaining and any given point in the show? We are pitching to the broad church that is the Full Circle readership, from expert developers, through sys-admins to new desktop users. I know we can't please everyone most of the time.

Bearing in mind we are an opinion-driven show and banter is quite important to keep things lively. That means giving all the participants a share of air time, not letting my natural sarcasm run riot and not rat-holing the show in exclusively British humour, in-jokes or tedious personal anecdotes.

Oops. See also Editorial policy.  RC


  1. Hi

    A fantastic amount of work to be done for the pleasure of others !!!

    Keep up the great podcast as I now look forward to listening to your different approach, alongside my other regular linux podcasts (you know who they are )

    Thanks again

    Clive (UKtux)

  2. This is far far too much work!

    Also, is this prep for me and Dave, when you decide you have had enough with this mess-of-a-podcast, and its then up to me and Dave to edit.

  3. Robin,
    Very informative and easy to listen to. Side-pod must be an order of magnitude less work than the full podcast.

    You are just too good to your co-hosts. I know I don't have that degree of patience or generosity.

    the answer is 'yes' because mediocrity sucks!


At least try to be nice, it won't kill you...