Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save Domon/389a3b997b31bea71ebbd0244eee497d to your computer and use it in GitHub Desktop.
Save Domon/389a3b997b31bea71ebbd0244eee497d to your computer and use it in GitHub Desktop.
Gary Bernhardt on Screencasting

I'm planning on either writing this up in detail or maybe doing a screencast about screencasting, but I'll give a short version here.

On sound quality:

This matters a lot. In decreasing order of importance:

  1. Remove echo. You have to hear this to understand. Set up a mic in front of your mouth and record a sentence. Then, put a thick comforter over you and the mic and say it again at the same distance. Listen to the two using headphones; you'll understand. Google for solutions.

  2. Remove noise. Disable the HVAC and flip the breaker for your fridge. Lawn mowers and car horns are harder to deal with.

  3. Get a decent mic. I use a Rode Podcaster ($230) on a boom arm (about $70 for one that clamps to your desk). I got it because of Dan Benjamin's guide, linked in this thread.

  4. Remove vibration. Before I used a professional studio, I'd put a folded dish towel between my keyboard and the desk. Otherwise, your typing vibrations go through the desk, up the clamped-on boom arm, through the shock mount (!), and into the mic.

If you're not using a pro studio, your best bet is a walk-in closet with no external walls. The clothes along the walls will dampen echoes; the lack of external walls will insulate you from outside noise. Nowadays, I have a deal with a studio where I rent time without an engineer for $25 an hour. I'm normally there when a producer is using the control room anyway, so it's a pure win for them.

On speaking quality:

You want the mic close to your mouth. In recent Destroy All Software screencasts, the mic is about four inches from my mouth, angled about 15 degrees up, and 45 degrees to the right of my mouth. Putting it to the side isn't optimal, but I have to be able to see my laptop screen since I record live.

Controlling your mouth properly also matters, but I don't really have anything useful to say there. I haven't consciously focused on this, although I've definitely gotten better. I still really mess up an S sometimes. Fortunately, Ps aren't a problem since my mic is 45 degrees off-axis.

Standing is significantly better than sitting. Nowadays I sit because my studio doesn't have a standing desk. It's a concession I made to stop having takes ruined by lawn mowers, leaf blowers, and ambulances.

On video quality:

This one's pretty easy. Record at the resolution you'll publish at. I use 1440x900 with a 14pt font. Better too many pixels than too few. I export with h.264, "best" quality, multi-pass. These are the maximum settings possible. My exports tend to be about 60-100 MB for a 10-15 minute screencast.

I've tried very hard to never alter the appearance of a DAS screencast. It's the same color scheme, font, font size, resolution, etc. as on the day I started.

On flow:

DAS screencasts are recorded live. I don't know how to do this in any other way (I haven't tried). Everyone tells me that they can't record live; I'm skeptical that this is true. It was hard at first and I'd need 12 takes to get a decent result. Now, my second take is usually pretty reasonable (though the one that's published is usually around 6 or 8).

In every DAS screencast, you're seeing my actual thoughts, as they occurred. I don't make an outline and rearrange thing. My first step is to sit down and hack around for 15-30 minutes, figuring out what I'll demonstrate. Then I revert, go back at the beginning, and do it again while explaining what I'm doing. After a few iterations of that, I start recording. But even in the final screencast that flows nicely, you're still seeing my thoughts in the order they originally occurred, and I'm still ad-libbing the entire thing. I've just done it enough times that I don't have to think about what comes next.

In any case, if you're saying "uhh" or "umm" or backtracking or saying long sentences, it's not ready and you should practice more.

Examples:

  1. das-comparison.mp3, attached. This is a small clip of DAS #1 and DAS #84 (the second-most-recent one). In #1 the mic was a couple feet from my mouth and I was standing at my breakfast bar, facing into the kitchen (pretty much the most terrible, reflective thing to face). In #84 I'm in my current professional studio.

  2. home-vs-studio.mp3, attached. This is me saying the same sentence with the same hardware, the same mic positioning, and the same voice (my "I'm-trying-to-record-a-final-take" voice). The only difference is where I'm recording. The first clip is in the last iteration of my home studio. There's a lot of foam on the walls and a thick sheet separating the recording nook from the hallway, so there are fewer reflections than you'll get in most untreated rooms. This is more effort than most people put into a podcasting/screencasting home studio, I think. The second clip is in a professional studio. It's night-and-day even compared to my best efforts at home.

I guess that wasn't so short. :/

http://link.olivierlacan.com/PLoq http://link.olivierlacan.com/PKKb

Oh, I forgot to mention: in das-comparison.mp3, you hear mistakes in both clips; I chose those intentionally. The mistake from DAS #1 is an error of flow: my mind blanked for a second and couldn't keep up with the pace of the screencast, so there's a pause. This is what happens when you haven't practiced enough (or just aren't good enough at live performance, as was the case for me back then). When this stops happening, or at least mostly stops, it's a good indication that a screencast is ready.

In the clip from #84, I stumble over the words "on the left". (It actually sounds like an edit to me, which is weird; it's not.) I allow small numbers of these mistakes to exist in my final screencasts. This is partly because it would be a lot of work to ship without any little mistakes at all, but also partly because they betray the reality of the recording: it really is me sitting there, talking to you live, and I like for it to feel that way.

OK, now I'm done. ;)

On Mon, Jan 21, 2013 at 5:17 PM, James Gray [email protected] wrote:

I really don't mean this to be insulting and I definitely appreciate the effort you put into your craft, but can you clarify how it matters? I don't consciously know of anytime I've ever had thoughts about the sound quality with regard to screencasts. Did you see better feedback or increased submissions or anything as you improved your sound quality over time?

Well, let me deconstruct my statement because there's a lot of context wrapped up in it.

  • Quality matters to me, personally. I care about the quality of the work that I do. I don't think that a human can say "I am going to obsess over content quality but not care about delivery quality". These things, and our perception of them, are deeply entangled. When I say that audio quality matters, I'm expressing this belief about humans (which I clearly think is a well-justified belief).

  • DAS has density as a goal, and even as a motivation for existing. To give a simplified history: when DAS started in early 2011, there was PeepCode, which was presentation-style, and there were lots of one-off amateur screencasts (including mine) that were slow and full of mistakes. I wanted to show that a screencast could be a live demonstration of actual programming but still be dense and engaging. Audio quality is relevant to this because you have to be able to understand me as a speak quickly and make mistakes, which are unavoidable in a live screencast. The relatively minor difference between my home studio and the professional studio probably doesn't matter here, but I think that the difference between DAS #1 and DAS #84 does matter. The clarity difference there is huge. There are going to be slurred words in a screencast that some viewers will understand with the higher-quality audio, but not the lower-quality.

  • A lot of people have commented on the quality of DAS screencasts. They don't usually mention audio quality specifically, but they're also not going to be experts in that. Humans encountering an artifact can't dispassionately evaluate different parts of it; that's not how our brains work. A story: I just bought a Pioneer SX-780 receiver manufactured in the late 70s. I love it not just because of the sound it makes, but because it's of such high quality. You could dump it in a bath tub or throw it down the stairs and it would probably be fine. It weighs enough that I can barely get it out of the back seat of a car. You can just look at the thing and say "that is an object of high quality". I can't add weight and physical ruggedness to my screencasts, but I've added whatever I think I can, which mostly means audio quality, video quality, and clarity of speech.

I don't want to go all Robert Pirsig on you, but there's clearly a recurring theme here: we can't disentangle the quality of individual components of an object. A receiver that sounds great and survives a bath tub will be perceived as higher quality; the same words spoken in a screencast with higher quality audio will be perceived as higher quality. I want the experience of watching my screencasts to be of the highest quality that I can achieve. I think that there are business gains there up to a certain point, but I've also gone beyond that point because my goal isn't just to make money; it's to make the best thing that I can make: quality for its own sake.

That may be way more than you bargained for. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment