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 pic.twitter.com/9DNvsBVbG6” – @insomaniac
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… twitpic.com/7t3byf ” – @lobbyshifter
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
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.
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.
WHY IT MAY SEEM LIKE A DIFFERENT 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.
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.
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.
Few Tweeters inspire me like Khris Brown. If you like game audio, voice acting, and joy — follow her. So when she came to Southern California recently, I invited Khris to meet in person.
If I haven’t previously met someone, I like to offer a beverage because it’s pretty simple and open… maybe we meet at a bar, maybe we meet at a coffee shop. Khris replied, “Let’s have hot chocolate.” It was the first of many unexpected answers.
A GOOD RECORDIST
I asked Khris what she looked for in a recording engineer for her game dialog sessions. A top qualification tends to be speed, since the voice director and actor usually put a premium on being able to keep a quick pace. But Khris put more worth in empathy. She gave an example of an actor being late for a recording session because there was bad traffic. If the engineer is focused on time, s/he might hurry that person in to the booth and get the actor on mic as quickly as possible. But a recording engineer who values the human element might instead offer her/him a cup of tea, or find other ways to help the actor transition out of traffic and into a mindset for interpreting a script on mic. I like Khris’ perspective on this because I know the first set of takes could be a waste of time if the actor isn’t mentally and emotionally ready to perform. Either you retake that first set, or you keep some potentially mediocre, even bad performances.
Khris also used the term Invisible Engineer, which really resonated with me. When the engineer’s role is given center stage it can take focus away from capturing a great performance. But when the engineer seamlessly blends technology into the activities of performers and producers, the engineer seems invisible. I have long believed that technology should serve the creative pursuits of the people who come to the studio, and that the engineer guides the guests to the best results technology provides. When it’s done well, the good engineer goes unnoticed.
Later, Khris told me one of the best metaphors I’ve heard in a long time. She referred to the voice director as the lead dog of a dog sled team. Every dog’s effort is important for pulling that sled, and they must work together to reach the destination, but the front dog bears an important responsibility. Apparently good sled dogs can smell thin ice. Yes, smell it. The lead dog needs to detect trouble before it arrives to keep itself and everyone else on solid footing. The director, like the front sled dog, must be able and willing to guide the journey through the dialog script — instinctively — for the safe travel of the whole team.
My thanks to Khris for the insights and I look forward to the next episode of hot chocolate.