This is not advice, and it’s not advocacy. I’m not going to try to convince you of anything. This is just me writing down what’s in my head, talking about a decision I’ve come to on my own for my own reasons.
So no more hate mail, please. Seriously.
A couple days ago I wrote at some length about a very serious problem I ran into with Adobe Premiere. Short version? Premiere incorrectly computes 24p timecode under certain conditions. Certain not-ubiquitous-but-incredibly-common conditions, it’s worth pointing out.
I got some surprising responses to that little blahg.
First, the “community” — hate that word, but I don’t have a better one — of post professionals who use Premiere apparently went kinda apeshit. It is my understanding, through secondhand knowledge, that the timecode bug became a very hot topic on the Premiere CS 6 beta mailing list, with opinions of all sorts being flung about, and an eventual consensus emerging that took the form “For the love of all that’s good and holy in this world, fix this fucking thing.”
I’m paraphrasing, of course.
Second, I got a larger-than-I-would’ve-expected number of emails asking me why anybody should care about an antiquated concept like timecode in the modern era of digital cinematography anyway. I said some things about that yesterday, and I won’t repeat myself here.
The third response I got from my little blahg was this: I got a call from a senior Adobe Premiere developer. We had a nice chat on Tuesday night about the problem. As I sat here on my system, he sat there on his, and we reproduced the problem together. His initial reaction was, in short, “Huh. That’s weird. Lemme call you back.”
Now, to be fair, I shouldn’t have been surprised by this. Adobe has cultivated a reputation over the past year or so for being a company that does stuff like that. Stuff like call up random Internet weirdoes who gripe about their products to chat with them in a friendly and helpful way. That’s apparently a thing Adobe does now, and I’m all for it.
So when that guy — I’m not naming names or being specific about job titles out of respect for people’s privacy — called me, my reaction was less “Woah, wow, this is unprecedented!” and more “Yup, that’s par for the course for these guys, let’s see what happens next.”
Cause see … openness is neat. Being transparent with your customers is neat. Establishing a culture of two-way communication between customer and vendor is neat. But in the end, it’s really just all talk unless that openness and transparency and two-way communication results in products that actually work.
So the big question for me was whether this apparent glitch I’d found, first of all, was actually a glitch and not just me being stupid (that turned out to be a yes), and second just exactly how Adobe would end up fixing it.
The best-case scenario, of course, was that the developers hammered out a super-quick fix they thought would work okay, then threw a build with that fix up on the FTP site for me to download and try. That’s what I … okay, expected is too strong a word there, but that seemed like the natural outcome for me. According to an email I got shortly after our phone call, such a build actually existed internally at Adobe within hours of my posting my rant to the Internet. So like … halfway there, y’know?
Except that didn’t happen. Okay, fine, I’m sure the software guys have these elaborate regression-test rigs they use internally, and there’s a good chance the quick-and-dirty build this guy made to test the fix wouldn’t run outside that environment anyway, for dependency reasons. That tends to happen in these kinds of situations, so that’s okay.
But of course, that just leads naturally to the next question. Clearly the fix for this is going in version 6. That’s just obvious. Version 6 is in beta right now, and this is what the beta-testing process is for: identifying huge, show-stopping flaws and fixing them before the product is released. So … yeah. Duh. So that wasn’t in doubt. What was in doubt was how long it would take Adobe to release a patch for version 5.5 that fixes this critical bug.
And, more selfishly, whether that patch would drop this week so I could take advantage of it on the project that started this whole big mess.
Well, yesterday afternoon I got the answer.
And that answer was “no.”
Again, I will not name names or give direct quotes. But I’ll paraphrase as succinctly as I can: This bug, according to my new friend at Adobe, will not be fixed in version 5.5 or any earlier version. Did you see the big press release Adobe sent out announcing that CS 5.5 and all prior versions had been retroactively end-of-lifed and were now out of support? Yeah, me neither. We both must’ve missed it, because that’s what’s happened: If you are an existing Adobe Premiere user of any stripe, you are currently — whether you’ve had to be aware of it or not — working around at least one absolutely critical show-stopping flaw in the program … and that flaw will not be fixed. Adobe has the fix, they know how to fix it, they’ve even fixed it internally. They’re just not going to release that fix to anybody. Ever.
This, I think we can all agree, sucks. It sucks if you’re a Premiere user who’s had to deal with this bug, and it also sucks (though less empirically and more philosophically) if you’re a Premiere user who hasn’t yet encountered this bug.
But if we’re really unreasonably generous, we can step back and say … okay. With a heavy sigh. Ours is not a perfect world. There are ten software guys who work on Premiere — a number I made up just now for illustration purposes — and all ten of them are working overtime on version 6 which is to be released imminently. Taking them off of 6 and putting them on patch duty for versions 5 and 5.5 would push back the release date of the new version, and since the bug’s fixed in that version anyway, and since market research shows that every last one of their customers is going to upgrade on day one, rushing a patch out for software versions that are only going to be used for another two days doesn’t make any sense, economically speaking. Right?
Except there are some problems with that line of reasoning. First, version 6 is not two days away. I don’t know if anybody knows how far out it is, but it’s not shipping on Saturday, that’s for sure. It’s probably most reasonable to guess that it’s months away. They’ll probably show it off publicly at NAB, then ship it in July or September or something, would be my guess. So that’s anywhere from weeks to months (depending on whether you’re in the beta program) of having to live with this same critical bug.
Next, versions 5 and 5.5 aren’t going to evaporate like morning dew in the swift sunrise of version 6. Will some people upgrade immediately? Doubtless! Will others upgrade later? Of course. And some — many, I think it’s safe to say — won’t upgrade at all until a good reason to arises.
A good reason like a critical bug existing in the version they’re currently using, and the version 6 upgrade being offered at a discount for a limited time so you better act now have your credit card ready?
Perish the thought.
Point is, “It’s fixed in the paid upgrade” only applies to people who buy the paid upgrade. As much as I’m sure Adobe wants that to be everybody, it’s not going to be. Hell, one of my housemates still uses CS 3! Why? Because he hasn’t run into any critical, show-stopping bugs.
So I’m understandably unsatisfied, I think. Here’s a really bad bug. Here are simple steps to reproduce it. Here’s me on the phone with you walking you through it. Here’s you fixing it within hours. And now here’s you saying you won’t release that fix except as part of a paid upgrade that isn’t available yet.
In other words, Adobe is essentially saying “We’re very sorry you had a horrible experience with our product. Please give us $600 now.”
Not a great sales pitch, guys.
But of course, the story does not end here. Because you see, I held something back. Something I’m probably not supposed to say publicly, but I never signed an NDA, so I’m throwing caution to the wind on this one. I think it’s that important.
The thing I’m holding back is this: They’re not fixing it in version 6 either.
Yeah. That’s right. Not only do they currently have a fix for the current version in house, according to what I was told, which they will never release, but they also won’t apply that fix to version 6 before it ships. Instead, they may — this was not a commitment, but merely a statement about what is possible — include the fix in some future, unspecified, currently unplanned patch release to a version of the software that hasn’t even shipped yet.
Critical bug. In a foundational part of the software. Makes the software completely unusable in many common workflows. And they’re just not gonna bother to fix it now, and they’re just not gonna bother to fix it next time around, but they might choose to fix it by Christmas. If you buy the paid upgrade. Which you already fucking know will still be broken.
I said up front this is not an attempt at advocacy. I’m not trying to convince you of anything. I’m just telling you what I think.
And I think I’d be ashamed.
I’ve never walked a mile in the shoes of any of the Adobe guys, fair to say. But I’ve walked plenty of miles in shoes that look and feel awfully similar to theirs if you squint a little. And I sincerely think I’d be ashamed if I were in their position.
But there’s no sense crying over it. It is what it is, and now it’s up to me to decide what to do about it. And while it’s still all very new, my tentative decision is this:
I’m just not going to use Premiere any more. Period.
I was emailing back and forth with a good friend recently — hi, K., awkward and dorky wave — and she really put it perfectly. She said it’s about trust. Neither of us trusts Premiere. If we drop a piece of footage into Premiere, we cannot trust that Premiere is giving us the right timecode, or the right frames for the timecode. Maybe it is and maybe it isn’t, because we know for a fact that sometimes it doesn’t. And at least for me, that’s as good as never getting it right, because the seed of doubt has been planted.
Yes, Premiere has some neat things going for it. But you know what? We lived without real-time playback of compressed media for decades. We can live without it again. And After Effects integration on the timeline? Sure, it’s kind of neat, kind of a time saver, but it’s not like it’s the best thing ever. Especially considering the overwhelming majority of working editors out there often ship their After Effects work over to another guy so they can focus on editing anyway. It’s handy to be able to bounce a shot over to AE with a couple clicks, but it’s not like that’s the only way to do compositing or whatever.
So the bottom line is that all the neato-whiz-bang features in the world can’t make up for a basic, fundamental lack of trust. I don’t trust Premiere. My friend K. doesn’t trust Premiere.
I don’t think you should trust Premiere.
But like I said, I’m not trying to convince you of anything. I’m just telling you what I think.
The blahg I blahged yesterday was really intended for an audience of one. So I didn’t go out of my way, when writing it, to explain a lot of the rationale behind the various givens that went into it.
Since I posted it, I’ve gotten some entirely reasonable and sensible questions about some of those givens. So lemme share a few thoughts not about the problem I ran into yesterday, but rather the rationale for doing things the way I do them that led me to that problem in the first place.
Let’s start by talking about film. You remember film, right? Probably read about it in books. It used to be this way of recording moving pictures.
Film workflow is fairly standardized, even in this day and age. Unexposed film negative comes on reels which get inserted into a special piece of camera gear called a magazine. This magazine gets attached to the camera, the film runs through it to be exposed, then the exposed (but still undeveloped, and thus light-sensitive) negative gets taken up on another reel inside the same magazine.
A film magazine, therefore, can be thought of as a contiguous length of film negative, including (in most cases) many takes of the same scene. Due to the nature of how film cameras work, each take buts right up against the take before it and the take after it; there’s no “blank space,” as it were, between takes on the same reel.
Thus we have our basic terminology: mags, rolls and reels are all essentially the same thing. They’re contiguous pieces of footage straight out of the camera.
When shooting on videotape — remember videotapes? — the same basic principle applies. You put a blank tape in the camera, roll a few seconds or minutes, stop the camera, reset to one or whatever, then restart the camera and roll a bit more. At the end of the day, you have a tape with multiple takes on it, one right after the other. Thus, you often find that in editorial the terms mags, rolls, reels and tapes are used interchangeably.
But let’s go back to film for a second, because clearly something has to happen between the part where the images are on film and the part where they’re in your computer being edited. Film reels — mags, rolls, whatever — are typically transferred to videotape all in one go. We said earlier that each reel has multiple takes on it; these takes are transferred to tape in one long pass. But here’s the cool part: The timecode on the tapes is linked to the reel number of the film being transferred.
For instance, reel one gets put on a tape that starts at 01:00:00:00. Reel two gets put on a tape that starts at 02:00:00:00. And so on, right on up to 23 (or 24 if you really want; that would be 00:00:00:00, which most people are disinclined to use for a wide variety of reasons).
Why do it that way? Because if you’re dealing with 23 or fewer camera reels, then every single frame of raw, unedited footage you’re working with gets a unique timecode number. All the stuff from reel six has timecode that starts with 06; all the stuff from real 13 has timecode that starts with 13. No two frames in the entire project have the same timecode.
Okay, but why is that important? Because it eliminates ambiguity entirely. In a setup like that, you’ll never find two frames numbered 03:22:57:06. There’s only gonna be one frame with that number, period, end of paragraph. That means when your EDL (or whatever your end product is) refers to frame 03:22:57:06 there’s no chance of getting that wrong — well, I mean aside from all the obvious technical and human-error problems that can come up, but we’re pretending both we and our tools are perfect for purposes of this discussion.
Of course, in the real world there are plenty of shows that don’t have 23 or fewer reels. In those cases, you need to track things like reel number, tape number and all that separately. NLEs typically use a combination of reel number and timecode to uniquely identify frames; you might have more than one frame with timecode 03:22:57:06, but only one of those frames is gonna be on reel 27. The others are on reels 81, 136 and 2,768 respectively. So in those cases, it’s the combination of reel number and timecode that uniquely identifies a frame … and if you’re a database geek, you’re probably thinking in terms of compound primary keys right now, and that’s good, because under the hood that’s really what we’re talking about.
But once again you ask, why go to all this trouble? What’s the big deal?
The big deal is this: Fundamentally being an editor is about communication. I don’t mean in the corp-speak “synergize our core competencies” sense of the word. I mean it literally: It’s about communicating a list of pictures. At the end of the day, the editor’s job is to say, “Gather round and attend, for here is the list of pictures that make up our show: From the reel of our Lord 37: picture the fifteenth, picture the sixteenth, picture the seventeenth, picture the nineteenth (for we removeth one frame to make the punch land harder), picture the twentieth” … and so on and so on and oh my god kill me now.
That’d be a valid way of communicating a list of pictures. It’d also be a completely stupid way of communicating a list of pictures, because it’d take so long we’d all be dead by the start of the second act. So instead we use shorthand. Shorthand like this:
001 8 AA/V C 08:21:19:00 08:21:19:09 01:00:00:00 01:00:00:09
002 4 AA/V C 04:00:15:00 04:00:16:02 01:00:00:09 01:00:01:11
003 7 AA/V C 07:01:00:13 07:01:01:07 01:00:01:11 01:00:02:05
You may or may not know what you’re looking at there; depends on whether you got into editorial before or after, say, 2005. That there is an EDL: an edit-decision list. It’s a very simple way of communicating a list of frames. It breaks down into columns like this:
Source timecode in
Source timecode out
Record timecode in
Record timecode out
Remember how we talked about the combination of reel and timecode uniquely identifies a frame? That’s why we can say “8 08:21:19:00” instead of “that shot of that girl looking squinty, no, not quite that squinty.” The reel-plus-timecode points to exactly one frame in the entire job, so we know once we’ve found a frame with those identifiers on it, we’re looking at the correct frame.
"Okay, fine, whatever, old man. All this talk of film cans and EDLs … it’s like we’re back in the dark ages. What does this have to do with me, a hip young editor with a 7D and a dream?"
It’s just this: Some cameras, the 7D being chief among them, do not record either reel numbers nor timecode while they’re running. In that example above, the first event in the EDL refers to reel 8, timecode 08:21:19:00. That identifies a unique frame; no other frame in the whole project has those identifiers on it. But those identifiers are only there because I put them there by hand. When that frame came out of the camera, it was reel 0, timecode 00:00:00:00. And since there are about 400 shots in this show, I had 400 different frames on my computer that were all called reel 0, timecode 00:00:00:00. They were all in different QuickTime movies — MVI_2237 or whatever — but they all had the same timecode and reel numbers. So if you said to me “reel 0, timecode 00:00:00:00,” I’d have to go “Which one?” Cause I had hundreds of those exact frame.
Remember: Being an editor is about communicating. And communicating is about being unambiguous. Two frames called “0 00:00:00:00” is bad enough; four hundred of them is absolutely intolerable.
So I grouped the QuickTimes into folders by scene — the scenes and shots fortunately having been coded for me in the shooting script — and then named them by scene, shot and take. So the QuickTime corresponding to scene 8, shot 8C, take 3 on the A camera would end up being in a folder called “8” and named “8C-3-A.”
Why code the takes this way? Because it makes it possible for me to sort them in alphabetical order and stripe them. That’s where QTchange comes in. Point it to a folder of QuickTimes and it’ll put reel numbers on them, first of all, but it also puts timecode on each shot. As I wrote previously, you can use time-of-day (or “free-run”) timecode, but I’m now even more inclined than I was before to use rec-run timecode instead. So you start with a list that looks like this:
Name Reel Start End
8A-1-A.MOV 0 00:00:00:00 00:01:26:15
8A-2-A.MOV 0 00:00:00:00 00:01:59:03
8A-3-A.MOV 0 00:00:00:00 00:01:03:12
And you end up with a list that looks like this:
Name Reel Start End
8A-1-A.MOV 8 08:00:00:00 08:01:26:15
8A-2-A.MOV 8 08:01:26:16 08:03:25:18
8A-3-A.MOV 8 08:03:25:19 08:04:28:13
(Note: I did that timecode math in my head just now, so odds are it’s all wonky. Take it as an illustration rather than a real example, kay?)
The first list should make any editor with any experience under his belt feel like throwing up. The second list, by contrast, looks totally normal: The timecode hour is the reel number, and the timecode is sequential and monotonic. Every frame is uniquely identified by reel number plus timecode for that frame. All is well. We can communicate.
Now, given the number of people who’ve asked me what this whole deal is about since yesterday, I can only assume that by doing things this way — a way we could charitably, think, call anal-retentive — I’m a weirdo. I dunno what to tell you, man. I’m not that experienced as a professional editor, but I’ve been editing in various non-professional and on-the-fringe-of-professional capacities for more than a decade now. In that time, I’ve had maybe three experiences (not counting yesterday) where a timecode or reel-numbering screwup caused me serious headaches. But those headaches were so serious and so painful that I now have a deep-seated Pavlovian response to this kind of thing. Seeing “00:00:00:00” anywhere gives me an immediate tummyache. Not having sensible timecode everywhere makes me feel like throwing up. Because I know if anything does go wrong — and fair point, it might well not — it’s gonna be a fucking catastrophe that probably involves my staying up all night three days in a row to redo a whole lot of work that I could’ve just taken a little extra time to do correctly in the first place.
So … yeah. My take on this stuff is somewhere between the voice of experience and the paranoia of the truly mentally ill. I make no implications about where along that spectrum it falls.
After my previous blahg I received, through a variety of channels, a significant number of comments of the form “Dude, QTchange? What the hell is that? Clearly that’s your problem right there, some weirdo third-party utility thing.”
To which I have three things to say: First, you guys aren’t wrong. Whenever a problem arises, the weirdo third-party utilities are the prime fucking suspects. You’re absolutely right to go there first.
Second, however, QTchange isn’t some weirdo bit of freeware nobody’s ever heard of. It’s absolutely standard kit for striping timecode-less QuickTimes — such as those that come out of DSLRs — to make them more useful in NLEs. If you’ve never had to use it, great, that’s awesome for you, really. But it’s not some obscure bit of whatever, either.
And third, I reproduced the problem without using QTchange at all … or in fact using any footage whatsoever. Here’s whatcha do:
Open up Avid Media Composer. I’m using 5.5.3 here, but it shouldn’t matter.
Create a new project: 1080p23.976.
Create a new sequence in your default bin. Do nothing to it. Don’t edit anything into it at all; just leave it completely blank.
Export that sequence — yeah, the one with literally nothing in it — as an AAF.
Open up Premiere. I’m using 5.5.2 here, which I believe is the latest version. At least it better be, since I just ran Adobe’s updatemonster thing on Friday.
Create a new project. Settings shouldn’t matter here, but for the record I went with whatever the defaults are for everything.
You’ll be prompted to create a new sequence. What you pick here doesn’t matter at all, because see next step.
Delete that first sequence Premiere made you create. You should have a completely empty bin.
Import the AAF you exported in step 4 above. It will come in just as it should: A new folder in the bin, and inside that folder a new sequence, and nothing else. Duh, because you didn’t edit anything into that new sequence; it’s just an empty timeline.
Double-click that newly imported sequence.
Observe that the start timecode of the new sequence, rather than being 01:00:00:00 like it should’ve been — like it was in Media Composer — is now 00:59:56:09.
Refer back to my previous blahg in which I made note of the fact that a QuickTime striped with QTchange to have timecode starting at 01:00:00:00 comes in — according to Premiere — starting at 00:59:56:09.
Bemoan the fact that, at least as far as 24p timecode goes, Premiere apparently can’t count.
Somebody who’s less tired than I am should feel free to do the math to figure out exactly why Premiere thinks 01:00:00:00 = 00:59:56:09 and email me the results. I don’t care that much, unless it points to an easy workaround, but I admit to being idly curious nevertheless.
So this friend of mine promised one of his friends he’d cut her short film for her. Life intervened and he found himself without the free time, so I volunteered to take over, since I don’t have anything else going on right now anyway.
Now, by “short film” here I mean short film. The script is only 17 pages, and it reads long, so it’s just not that big a deal. All shot on 7D mostly MOS, with just a handful of sync-sound scenes, and the deliverable is just a QuickTime. No biggie, right?
Well, naturally I wanted to cut it in Avid. Because Avid is my girlfriend. But see, the right workflow to do this job in Avid involves AMAing all the takes, then batch-transcoding them to DNx 36 to cut, then relinking back to the AMA media once the edit’s finished. Transcoding takes a long time on my humble laptop, and I didn’t want to waste a whole day just doing that. So I decided to save myself a day by doing the job in Premiere Pro CS 5.5 instead.
Now, this job should be right in Premiere Pro’s wheelhouse. Native DSLR media, not a lot of fancy stuff, no real compelling need to collaborate with anybody else … easy, right?
Yeah, not as much as you might hope.
I started the job like you always start DSLR jobs: By using QTchange to lay timecode tracks onto the media files the camera spits out. See, DSLRs like the 7D don’t record a timecode track at all, which makes editing a bit tricky later on down the line. This is easy to work around, though, because QTchange gives you the option of quickly and easily adding a timecode track to all your media files. You can either use the timestamp the camera recorded to be the timecode of your first frame, or you can ignore that and use incrementing timecode instead. It’s basically analogous to the difference between free-run and rec-run on your camera; you can let the camera’s internal clock set the timecode (free-run) or you can say mag 1 starts at 01:00:00:00 and counts up, mag 2 starts at 02:00:00:00 and counts up, and so on (rec-run). Totally doesn’t matter which you pick (as long as the free-run method doesn’t cross the midnight line), as long as you pick something and stick with it.
Me, I picked the free-run method, because why not, it’s easy. Couple clicks and it was done. Easy peasy. This turns out to have been an error, for reasons I’ll get to in a sec.
The next step was to import all my takes into Premiere Pro. Now, if you’re an Avid person I might need to clarify this: “Importing” into Premiere is not like “importing” into Avid. It’s more like “importing” into Final Cut Pro, in the sense that you just tell the program “Hey, use these files here,” and it does. It doesn’t actually move any data around or transcode anything. It just refers to the files already on whatever hard drive you’re using. So it’s a quick process, generally speaking.
What I should have done next is to double-check that Premiere was reading the timecode from my QuickTimes correctly. That’s what a fastidious and careful editor would’ve done. Cause the relationship between NLE timecode and source-media timecode is the heart and soul of editing; screw that up, and … well, you’ll see shortly.
Anyway, I loaded all my shots into Premiere (in the Premiere sense of “loading”) and started working. It was going okay, I got the first minute or so cut, then hit my first scene with sync sound. For reasons I won’t go into detail on here — involving Premiere Pro 5.5’s completely fucking stupid “Merge Clips” feature and the general impossibility of dealing sanely with sync sound in that program — I decided it was time to rethink my choice and consider cutting the project in Avid instead.
That’s where yesterday ended. Bad news: I had serious doubts about my ability to do the project in Premiere and stay sane at the same time, because of the sync-sound issue. Good news: I had a solid minute on my timeline, and moving that over to Avid should be fairly easy, with either an AAF or an EDL. So I slept well and soundly last night.
This morning, though … goddamn.
First thing: If you use the “Merge Clips” feature in Premiere — comparable-sort-of-but-turns-out-not-really to AutoSync in Avid — you can no longer export an AAF. Period. It’s right there in the manual and everything: No AAF or XML exports with merged clips. Well, shit.
That’s not that big a deal, though, because I’d only cut in about four sync-sound shots in one scene. I could redo those edits easily by hand in Avid. What I did want to bring over was the minute of shots before that scene that I’d spent most of my time on the day before. Surely I can just lop off the offending sync-sound scene and export the rest as an AAF, right?
Turns out … no. Not really. I can export an AAF all right, once I remove the merged clips, but that turns out to be way more complicated than it should be, because of a variety of things I won’t bother going into here because you’ll probably just say “Oh, you fix that by doing bonk” for each one, and you’ll have missed the point that by this time I just didn’t care any more, so rather than working the problem I just punted and went back to the stone age. I used an EDL.
God bless EDLs. They’re the most brain-dead, stupid interchange format in existence. Ever looked at one? There’s like no information in there. And that’s awesome because it means they’re so simple they’re damn near impossible to screw up. Right? Right?
You know how this goes. Do major amputations on your timeline: no dissolves, no V2, no none of that. Hell, just to keep life simple, strip off all the audio, because I can just replace that later with a couple quick edits. Next: export an EDL of the timeline. Take that EDL into EDL Manager, sanity-check it, then hit “send sequence.” Pick a bin, and poof, there’s the timeline, along with one 24-hour-long offline clip for each source reel that was referenced in the EDL.
Now for each source reel, use the “Modify” function to change its source to the tape name of your choice; this should match the tape name in the media you want to relink to. Click click, done, now hit “relink” and hope for the best.
Yay! Everything relinked correctly! That’s awesome! Except … erm … no, it’s not. Because it turns out these are the wrong fucking frames.
First frame of first shot in Premiere:
First frame of first shot in Avid:
I’m looking at entirely different pieces of my shots, not the pieces I selected in Premiere when I edited this sequence the first time. Totally different frames.
And if you look real close at those two images, I bet you can figure out why. Have you spotted it yet? Give up? I’ll tell you, but brace yourself. Cause this is where it gets good. I mean really good. You ready for this?
Premiere Pro CS 5.5 cannot fucking count.
Uh-huh. You heard me. Look close at those screen shots. See how the two both show the same timecode? Like, judging by the timecode alone, you’d expect to be looking at the same frame. Same clip plus same timecode equals same frame, right?
Only nope. Because the timecode you’re seeing in the Avid screenshot is right, and the timecode you’re seeing in the Premiere screenshot is just plain wrong.
Remember up yonder when I said that using free-run timecode, based on the camera clock, was a mistake on this job? Here’s why: If I’d chosen rec-run instead, wherein the first shot on the first mag starts at 01:00:00:00, I’d have spotted the problem immediately. But I didn’t, because I didn’t care what the timecode actually was; I just needed sane timecode. So I threw some random time-of-day on there and forgot about it … which meant I completely missed the fact that Premiere was showing me — the whole time, and on every single shot in the show — the wrong timecode for every last mother-lovin’ frame.
First mag, first take, shot 1A-1-B, first frame:
As you can see here, in big friendly yellow numbers, Premiere thinks the timecode of the first frame is 01:48:51:11. But here’s the first mag, first take, shot 1A-1-B, first frame in Avid:
Observe: Same frame. Like literally the same image recorded by the camera. Only Avid thinks the timecode for this frame is 01:48:58:00. Which it is. That’s the timecode QTchange put on that frame (I went back and checked). That’s the timecode QuickTime Player 7 displays (when you select the timecode track, which is not selected by default). As seen here, it’s the timecode Avid reads. It’s the timecode Final Cut Pro 7 reads — yes, I blew the dust off my FCP 7 icon just to check this. That’s the correct timecode. That’s the timecode in the file. It’s right there in big numbers, staring up at you: 01:48:58:00. No ambiguity, no complexity, no confusion. Just 01:48:58:00.
Only Premiere is all “LOL nope, 01:48:51:11.”
To try to make some kind of sense of this, I restriped that same shot with rec-run timecode instead, in QTchange. (Yes, I have a backup of the media files, what do you think I am, some kind of barbarian?) Now the timecode on that shot starts right where you’d think it’d start for mag one, take one: 01:00:00:00.
Premiere: “LOL nope, 00:59:56:09.”
What. I’m sorry, but what.
It’s probably some kind of bizarro fucked-up drop-frame thing. It’s 24-frame non-drop timecode on 23.976 media; totally normal. But Premiere is probably trying to be clever and show me drop-frame timecode instead … or some goddamn thing. If I weren’t so fed-up right now, I’d do some math to try to figure this out … but fuck it. I’m just not going to. I’m putting my foot down, Premiere. I don’t expect a lot of an NLE. I want a lot, I desire a lot, but if wishes were horses none of us would have to walk, so I take great pains to distinguish between what I hope for and what I expect. And you know what? I expect my NLE to be able to count. That’s all, that’s the absolute bare minimum. At the lowest level, editing is nothing more than counting: Count in this many frames, make a cut. Count this many more frames, make another cut. All the rest is just scotch tape and stuff. If you can count, you can edit.
But as best I can tell, Premiere couldn’t fucking count to eleven if it took its pants off.
I’m not a happy person right this minute. If you work for Adobe and you happen to read this — because you know, Internet and shit — then please accept my apology for saying in no uncertain terms that your NLE is a fucking abomination that should be pulled down brick by brick, and that we should salt the Earth beneath it so nothing ever grows there again. Later, when I’ve spent two fucking days starting over and getting back to the point where I thought I was last night, I’ll probably have calmed down enough to express myself more diplomatically. But for right now, no. For right now, I’m just pissed.
I’m pissed particularly because at this point I have a choice to make. I can either throw all the work I did yesterday, plus all the time I spent today trying to figure out where things went wrong yesterday, in the garbage and start completely over, just eating the fact that Avid will make me transcode all these takes to DNx before I can work with them in real time …
… or I can just go back to yesterday’s save of the project file and finish the fucking job in Premiere. Knowing that Premiere can’t fucking count, knowing that I’ll never be able to get any useful machine-readable representation of my timeline out of Premiere, knowing that if my friend or his friend wants to take the timeline I create and do something else with it — like ship it off for a high-quality finish for submission to festivals or whatever — then we’re all just fucked in the ear, because Premiere cannot fucking count.
And I don’t know what I’m gonna do yet. But one way or the other, I’m gonna be in a bad mood for a while.