Avid Behaving Badly #13: Changing Tape Source in NTSC 23.976 Changes Clip TC to 29.97 Pulldown.
There's no error message for this, because Avid doesn't like to admit when it's just fucking wrong. Also, this is almost certainly related to the issue with autosequencing that I raised in my Avid Behaving Badly #12 post below.
Here's the bullshit workflow we have to use because stupid fucking Avid can't play back proxy MPEG-4 video in 9 camera split without stuttering (I know, it's not an every-frame-keyframe codec, but jesus christ, maybe if you used more than 2 fucking cores of my SIXTEEN CORE system, you'd get, I don't know, more fucking processing power!! Seriously). First, we capture using AI direct because Avid can't be bothered to implement their own tapeless fucking workflow. Then we have to transcode everything to 8:1m because that's the only codec that works cleanly in 9 cam multicam split playback. Transcoding, by the way, takes for goddamn ever. I'm sure you knew that.
In order to transcode to 8:1m, for some reason that makes no sense whatsoever, you have to be in an NTSC 23.976 project. Nevermind that Avid's entire workflow is based around digitizing all of your footage in low res and then uprezzing later to HD. No, Avid doesn't give a fuck. So it forces you to use what it calls a standard def "23.976" project. But there's one problem with that: There is no such thing, according to Avid, as a standard def 23.976 project! What? That's right. Once you go to standard def, even though Avid displays that you're in a 23.976 project, you're actually in a 29.97 project where the timecode is being pulled down to 23.976. Which means timecodes get fucked up all the goddamn time.
And that, dear reader, brings me to this issue. Let's say that you realize, while in this "standard def" project for your transcode, that one of your tapes was accidentally mislabeled when you digitized it. Maybe you fat-fingered it to have an extra 0 in the name or something. Happens all the time; honest mistake. So you go to modify the clip and change the source to the correct tape name. Except, after you do that, your clip changes in duration from 1:14:05 to 1:30:12. WHAT THE FUCK? And then if you load that clip and go frame by frame, the frames will count like this:
.1
.2
.3
.5
.6
.7
.9
HOLY WHAT? God damn, Avid, WHY DID YOU DECIDE TO FUCK ME TODAY???
And here's the best part: Your clip is now fucked for good. You have delete the clip, delete the media, and re-ingest. All because Avid insists that standard def 23.976 is somehow different from a low res version of a 1080P 23.976 project.
Fuck you, Avid.
Here's the bullshit workflow we have to use because stupid fucking Avid can't play back proxy MPEG-4 video in 9 camera split without stuttering (I know, it's not an every-frame-keyframe codec, but jesus christ, maybe if you used more than 2 fucking cores of my SIXTEEN CORE system, you'd get, I don't know, more fucking processing power!! Seriously). First, we capture using AI direct because Avid can't be bothered to implement their own tapeless fucking workflow. Then we have to transcode everything to 8:1m because that's the only codec that works cleanly in 9 cam multicam split playback. Transcoding, by the way, takes for goddamn ever. I'm sure you knew that.
In order to transcode to 8:1m, for some reason that makes no sense whatsoever, you have to be in an NTSC 23.976 project. Nevermind that Avid's entire workflow is based around digitizing all of your footage in low res and then uprezzing later to HD. No, Avid doesn't give a fuck. So it forces you to use what it calls a standard def "23.976" project. But there's one problem with that: There is no such thing, according to Avid, as a standard def 23.976 project! What? That's right. Once you go to standard def, even though Avid displays that you're in a 23.976 project, you're actually in a 29.97 project where the timecode is being pulled down to 23.976. Which means timecodes get fucked up all the goddamn time.
And that, dear reader, brings me to this issue. Let's say that you realize, while in this "standard def" project for your transcode, that one of your tapes was accidentally mislabeled when you digitized it. Maybe you fat-fingered it to have an extra 0 in the name or something. Happens all the time; honest mistake. So you go to modify the clip and change the source to the correct tape name. Except, after you do that, your clip changes in duration from 1:14:05 to 1:30:12. WHAT THE FUCK? And then if you load that clip and go frame by frame, the frames will count like this:
.1
.2
.3
.5
.6
.7
.9
HOLY WHAT? God damn, Avid, WHY DID YOU DECIDE TO FUCK ME TODAY???
And here's the best part: Your clip is now fucked for good. You have delete the clip, delete the media, and re-ingest. All because Avid insists that standard def 23.976 is somehow different from a low res version of a 1080P 23.976 project.
Fuck you, Avid.
In short like I said in my post I am multigrouping. I have done this before no problem when I am multigrouping dnx36 in a HD format but for this new project since there is going to be a lot of footage I have to multigroup 14:1 or 8:1m and when I do the video jumps around the source monitor I filmed it here
ReplyDeletehttps://www.youtube.com/watch?v=C4D0uACqRvQ
and the audio jumps too. I am completely confused by this. I dont if its a setting that I am doing wrong or what. but I also even when I bring in the footage in a NTCS project as 8:1. Dinner and drink on me if you can help
This is normal behavior, actually. Say you have cameras A and B both running. Initially, you'll see A cam is camera slot 1 and B cam in camera slot 2 in the multigroup split view. If A Cam stops rolling, but there's no add-edit in your multigroup, you'll then see nothing in slot 1 and B cam in slot 2. If there's then an add-edit (say, iso audio comes in or a C cam or something), B cam will move up to slot 1 because there's no A cam yet. Then, later when A cam comes back, you'll have another Add-edit. At that point, B cam moves back to slot 2, and A cam is back in slot 1.
ReplyDeleteYou can make it slightly less confusing by putting add-edits at the heads and tails of every clip, which will not prevent cameras jumping slots but will prevent any sections of your group from having filler before or after a camera actually starts rolling. I personally hate this method, as it tends to make the multigroups HUGE (meaning you more frequently run into "too many items in a bin" errors), as well as full of add-edits. That takes much longer to sub out and also takes your editors an eternity to change audio tracks on if they need to.
One more thing to note: Before multigrouping, alway sort your clips by AuxTC first, and then by name. That will keep them in order in your multigroup. If you only sort by AuxTC, you'll get B cam appearing before A cam or audio appearing ahead of video (which will then shuffle all your "audio follows video" tracks down 1). This could be your problem, too - I can't really tell from your video if the cameras are in alphabetical order the whole time.
Please let me know if this helped.