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.