Skip to content
April 8, 2014 / Randy Coppinger

Rob Bridgett on Sound for Pre-School Games

Veteran game audio director Rob Bridget inspired me with his post-mortem on Zorbit’s Math Adventure for iOS and Android. These were my eight take aways…

1. Even among the few quality developers making compelling experiences for young ones, there are significant opportunities to improve the quality of the audio. More importantly, “the overall integration of sound and design seemed like huge missed opportunities in this genre.” Audio should be integral — not an afterthought — because sound plays a key role for a younger audience, especially dialog for pre-readers.

2. Rob suggests we owe pre-schoolers an especially safe loudness landscape in mobile games so as not to damage their hearing. From early concepting through audio implementation, sonic loudness was carefully managed. They even implemented an audio reduction (pad) scheme when headphones were inserted to help protect young ears.

3. Thinking about loudness early in production helped the team work more effectively toward that goal, but also helped simplify audio production in general.

4. Instead of simply ducking music anytime dialog plays, they decided to map the experience in two zones: player listens, player interacts. The music becomes more subdued (while keeping the same basic song structure) whenever dialog plays. This not only makes it easier to understand the dialog, it guides the player through the zones with an audible prompt. The subtle music tells the youngster it’s time to stop and listen. The return to the more active version of the music is the prompt to interact again. It’s an elegant audio design for user experience.

5. Some mobile users are going to wear headphones. Others are not. The audio presentation must work in mono on a tiny speaker. And on headphones.

6. Media made for kids should actually consider two audiences:
(1) The experience the child has, and
(2) The direct experience the parent may have, or indirect experience while the child interacts.
So the content — including audio — should engage the child, but also feel safe and fun for a parent.

7. “Consistent dialogue levels, clarity and performance were especially important for our design in terms of communicating the educational and instructional aspects of the experience so audibility and intelligibility at all times were critical.” But without sacrificing the fun! Balancing learning with entertainment rings true with my experiences in all educational media for kids. Sesame Street is so much better than a character shouting curriculum at the fourth wall.

8. In iterative build reviews they subtracted any dialog that was neither educational nor fun. This helped remove audio clutter, for a more focused user experience.

Throughout the post-mortem, Rob’s focus on possibility and opportunity — rather than limitations and problems — was the single most inspiring aspect of the entire article. Moving quickly from adversity to opportunity is more than just a positive way to view a situation. It’s a recipe for adding value to almost any situation, individually and as a team. So here’s to better audio as we anticipate opportunities to use these lessons from Rob.

Be inspired for yourself. Read the entire article.

February 19, 2014 / Randy Coppinger

Nasty ProTools Errors

It’s interesting to know what limits and problems other people are having with the same tools I use. Here’s a collection of responses from Twitter and Facebook when folks were asked what ProTools errors they found especially troubling:

“Pro Tools did not shut down properly. You must restart your computer.” – @grhufnagl
“ProTools has quit unexpectedly…” – Preston Shepard
“that would probably be this one” – @insomaniac
ProTools error dialog box with no text
ProTools 11 is “a vast improvement in many ways (not video!).” – @JamieMusicNYC
“For no reason PT sometimes just come up with def prefs. Even daily.” – @tamasdragon
“Check this crash bud….It didnt come with an error number….lol… ” – @lobbyshifter
ProTools error with code superimposed on left side of screen

A few weeks ago my colleague @SwiftyMorgan told me about this one: Neo Assertion in [volume name], line 164

An error that has haunted me for years: ProTools Sync: The Short Video Problem

See also- ProTools and H.264 Video, ProTools + H.264 video = Problem, ProTools: Bounce to Quicktime Movie with Full Options, Conflict: ProTools and Spotlight Indexing

February 17, 2014 / Randy Coppinger

ProTools Sync: The Short Video Problem

I mistakenly assumed this issue was fixed several versions ago, but I’ve seen it again recently in ProTools 10. It could be caused by code deep in the video playback core of the software. It could even be caused by some quirk with Quicktime, which ProTools uses for the video decode heavy lifting. I’m documenting it here in case anyone else encounters it — it can be difficult to diagnose and sometimes isn’t simple to solve.

This error occurs when the video file is shorter than the audio. In other words, audio extends past the end of the video. Then audio is highlighted in the Edit window and a Bounce to Quicktime command is issued. For whatever reason, sometimes the video is stretched — frames are added or lengthened — so that the length of the video and audio are the same.

Video clip shorter than audio causes error

This is a huge problem for several reasons:
The audio and video drift out of sync getting worse toward the end.
The video may look strange, or in extreme cases, terrible.
There is no error message or indication during the Bounce. You have to review the video outside of ProTools to find the problem.

Video sync can tricky, both in terms of the mistakes we can make because we’re human, and because ProTools is an audio-centric tool that also allows video. The plethora of video codecs makes testing every permutation a challenge for software developers too. Given the number of other things that can go wrong, the short video problem feels especially insidious.

1. Don’t combine the video and audio using ProTools; don’t bounce to Quicktime.
2. Pad the video at the end.
3. Cut the audio to end as soon or sooner than the video.

See also- ProTools + H.264 video = Problem, ProTools: Bounce to Quicktime Movie with Full Options, Conflict: ProTools and Spotlight Indexing

January 24, 2014 / Randy Coppinger


A good social media feed should bring inspiration, good things to read, and a bit of fun. But too often a stream can get crowded with irrelevant posts, marketing, and drivel. Facebook likes to filter for us (no thanks), but it takes some discipline to prune an overgrown Twitter or Google Plus feed. Once committed to some cleanup, who should be cut and who kept?

I like to read about professional audio, game design, voice acting, and other topics related to my profession. I’m not opposed to personal posts now and then, but I primarily want social media to feed my brain and help keep me enthused. The curated feed of Women’s Audio Mission is amazing in this regard (on Twitter and Facebook). All of the posts are audio related. I’d miss so much good stuff if I didn’t follow WAM.

I adore the work of science fiction writer William Gibson and was elated to find him on Twitter. But he posted so much stuff I couldn’t keep up. I held on for months out of respect for his Cyberpunk novels, but eventually had to admit that his Twitter profile just wasn’t a good fit for my social media personality and habits. I seem to prefer people who post occasionally, and when they do post, it’s good stuff that gets right to the heart of things.

The difference between social media and broadcast media is the willingness for conversation. If I’m following someone who is just blasting out promotional material about their projects, but doesn’t engage in conversation, I might as well be watching TV or listening to radio. I’m looking for people who want to help each other find solutions. I’m interested in folks who are building community. For example, guru of #GameAudio Lost Chocolate Lab nurtures our community with his posts.

I don’t tend to watch video or listen to much audio on my mobile. When posts are predominantly text and pics I can catch up while waiting for coffee or food. That’s not to say I don’t enjoy watching or listening, but I’m not prone to do that mobile – where I typically engage with social media. (If something high bandwidth seems really good, I save to Evernote and check it later on a good screen and better audio reproduction).

Who do you follow and why?

December 30, 2013 / Randy Coppinger

Good Names, Bad Names…

… you know I had my share. Previously we explored ways to let people know more about a media file using metadata, a ReadMe doc, a posting notification, folder name, and file name. Here are a few more tips for creating good file names and avoiding bad ones.

At the time you name a folder or file, the word “new<" may be accurate and descriptive. But after some time passes, the content will no longer be new. Worse yet, if another version is needed after that, “new” in a previous file name is downright confusing. Because there may be more than one version of an audio file, using the word “new” should be avoided.

For the same reason “final” is a terrible choice for a folder or file name. Using “final” is like a curse on your file, inviting someone to request another change. To prevent names that are ambiguous — and especially wrong — be sure to avoid using “new” or “final” in folder and asset names.

A simple and common way to distinguish files for version control is to use an incrementing number. For example: SmRoomAmbLoop_Stereo_vers1, SmRoomAmbLoop_Stereo_vers2, etc. If you are creating every version, or you administer the naming, then a simple incrementing version number can be a great way to keep track of everything.

When large teams are working simultaneously on a project, it may be difficult to know the current version number. Using the date may be helpful especially if many iterations are anticipated.

Workflow Milestones

It’s often useful to know how far along an asset is in the process. Inserting words like scratch, raw, edit, master, and the like identify where the asset relates to major milestones in the workflow. This is valuable during production when there are fixes, and also if someone wants to revisit a project (think sequel) months or years after the initial project has been completed.

There are often major categories of audio file types such as dialog, music, and effects. These can be important file groups to call out by including right in the name. When assets are organized into folders by these categories, the folder name is an obvious place to use these words. But when files seem likely separated from your folders, the categories may better be used in each asset name. An abbreviation may be helpful for adding category to a file name.

Don’t overlook combined use of version number, date, milestone, and category in a file name. For example: fx_SmRoomAmbLoop_v3_2014-01Jan-02_edit.wav may help any number of people downstream quickly recognize and make effective use of the audio.

Still to come: sound for picture file name tips

December 25, 2013 / Randy Coppinger

Frozen Storybook Deluxe

We had so much fun making the Frozen Storybook Deluxe app. Editor Vickie Saxon placed a special challenge before narrator Kari Wahlgren: tell the story from the perspectives of both sisters Elsa and Anna. Not only did she give a phenomenal performance, I grinned all session long as Kari wove nuance and subtext into this telling of the story. At various points during the narrative readers can choose to rotate the device for the other sister’s viewpoint, keeping the experience fresh and unique.

Kudos to producer Ashley (Kaye) Bravo for marshaling the efforts of our design, animation, and audio teams in coordination with the developer to make this beautiful app.

Ashley (Kaye) Bravo, Kari Wahlgren, Vickie Saxon, and Randy Coppinger at recording session for Frozen Storybook Deluxe

See also Kari Wahlgren Rocks for additional recording session details, and this app won the Editor’s Choice Award from Children’s Technology Review!

December 3, 2013 / Randy Coppinger

Qu’est-ce Que C’est?

This article includes some specifics for audio professionals, but the underlying principles should be useful to anyone who uses digital files.

An immediate tip off that someone is a ProTools rookie: an audio file named Audio_01.wav. The less experienced may ask, “If you can simply listen to the file to know what it is, why does describing it matter?” The same reason a book has a cover, a film has a title sequence, and a video game has a splash screen… we want to know what we’ve got. A good label can help introduce the audio, and differentiate it from other files. Most of us have more than one file on our machine right? The title helps us find and verify the one we seek. While everyone may not appreciate a well crafted moniker, few enjoy a generic one.

Whereas consumers may be slightly annoyed by a poorly identified audio file, professionals lose time and money overcoming ambiguity. We can work far more effectively with descriptive information. In Music Production, Sound for Picture and Game Audio the there may be hundreds of thousands of individual assets for a project. Finding, sorting, producing with, and implementing sound is more efficient with a well organized audio file system.

Displaying metadata with itunes

Metadata is cool, because the info about the file is contained in the file. It isn’t likely to be separated from the audio unless someone deliberately strips it out. ID3 tags are extensive and the fields are standardized, making it easier to find and report the information whether it’s iTunes, Soundminer, or some home-brew in-house solution.

But if someone downstream isn’t using software that displays the metadata, it will likely go unnoticed and unused. That’s pretty worthless. I’m not opposed to metadata, in fact I’d like to see it more widely used. But I haven’t found usage common enough to count on it alone for providing details about an audio asset. As I see it, some additional forms of information are important.

A quick, descriptive text file is pretty well accepted in audio production and computing in general. I like to use ReadMe docs for detailed technical information about a file set such as channel configuration, codec, data rate, synchronization standards, asset categories, etc.

But a separate document may not stay with the sound files through a work flow. Because it can be separated from the audio, we risk losing important details at later stages of production. A ReadMe document seems most effective for conveying information to those immediately next in line, but we shouldn’t rely on a ReadMe further along.

When files are moved from one networked machine to another, some message about that transfer is typically sent. That notification could be as simple as, “Your files are here,” followed by a link. But I like to take the opportunity to describe assets for the recipient(s). In this form, the details are probably more ephemeral than a ReadMe, because once recipients get the audio they tend to leave the posting notification behind. But these descriptions may be useful in the future if they take the form of email or a descriptive field on a delivery site that doesn’t auto-delete the data. I especially appreciate being able to refer back to date sent, and the recipient list from posting correspondence. Connecting the date and recipients with the file set requires enough description to differentiate a particular file delivery from others — some of the same information that may be used in metadata and/or a ReadMe.

By convention I deliver audio in a folder. Even if I only deliver one sound file, I like to wrap it in a folder. Folks downstream sometimes store my audio in a folder on their systems. If they keep my folder name — or even part of it — I can potentially convey useful details to audio people working at later stages of the project. I like to include information such as bit depth, sample rate, and file type in a folder name (assuming all of the files in that folder share the same specification).

It’s difficult to open a folder without reading the folder name. That means there is a very good chance information in the name will be noticed. There is a much better chance of sharing information in a folder name than separate correspondence or a document.

But like the ReadMe file, a folder and it’s name can be separated from the audio assets. Despite my claim that a folder name stands a better chance of carrying useful information, it too may be lost.

I put a high value on the actual name of a file. Why?

First, the file name is attached to the audio. Unless someone renames it (which should generally be avoided) the file name travels with the recording. It’s like Metadata, except it won’t be missed by those unable or unaware they should see it; everyone who accesses the audio as a file can see the name.

Which brings us to the second reason file name is important. Like a folder, someone using a file tends to notice the name simply by selecting and using that audio.

Because it lives with the asset, and is difficult for others to ignore — file name is huge. From my perspective, the file name is the ultimate metadata!

But let’s face it, file names and folder names shouldn’t be too long. If we try to cram too much detail into a file or folder name, folks downstream may just skim for the part they need, and consider a verbose title annoying. So if everyone on a project can agree on some abbreviations for file and folder names, that can be very helpful. Yes, if you have anything absolutely critical to share with everyone about an audio asset, find a way to include it in the file name.

See also: file naming conventions to avoid/embrace.
Still to come: naming for audio post production.


Get every new post delivered to your Inbox.

Join 44 other followers