Maybe only 998 suns. But it’s definitely a lot, especially since my working windows are dark grey and the surprise import window is somehow brighter than those 998 suns of my hatred).
And ctrl/cmd+i is how I prefer to import. My thought is, “if I want to import, I’ll tell you, Adobe, thank you very much.” So while I’m perfectly fine importing with the tidy and controlled way of ctrl/cmd+i (vs this reckless abandon of double clicking everywhere), I still can’t figure out how to turn off this annoying “feature” of double clicking opens the import window over the top of my work making me have to trundle my cursor over to cancel it.
Last update, then I’m moving on with this unless I find the illusive definitive answer.
Today I was able to output one of the 2 files that had multicams (the suspected culprit) with absolutely no issue. I did change from exporting h264s to QT 422 HQ, so I thought perhaps that was the fix (it’s what I successfully exported from AE in desperation in my first post).
So I moved on to the second video, and nope. Not working. It hated all the different ways I tried to export it. After 23-27% completion, the whole machine just locked up. I could force quit after a few attempts, and I never had to hard power off. But if I tried to do anything without first shutting down and restarting completely, the whole system was just too mad to function.
After trying a variety of export settings, I created a new comp, unlinked my audio, and flattened my multicams. Still no good. 23-27% and then we just sat waiting until I couldn’t take it anymore and went through the whole force quit, shut down, restart rigamarole.
So I sent it on to AE, spit out a beautiful QT 422 HQ, brought it back into PP, slapped it on top of my audio cut, and BOOM! Export. And a speedy one at that. I looked away and when I looked back, we were done.
So maybe it’s the MXFs, maybe it’s the multicams, maybe it’s Adobe is cruel and awful and just loves to torment me, I don’t know. But I do know that AE is my friend and PP can eat a turd (today. Who knows what fresh hell tomorrow will bring).
But actually, I spit it out of AE, brought the mov of the edit into PP, dropped it on top of the disabled video and used the multicam audio (because when I flattened it, it chose whatever audio was attached to the visible clip rather than the good audio on the main camera), and voila, everything exported beautifully. So the multicam audio wasn’t an issue there.
Based on all my workaround attempts, I think you’re right that it’s the multicams vs the MXFs. The multicams were janking my audio levels too, and just being all around not friendly, but they seemed less irritated by the .movs and .mp4s. The multicam video was disabled at the sticking point, and we were seeing straight MXF b-roll (hearing multicam audio), so I was thrown off the scent. My error reports kept listing specific files and timecodes, making it :40ish seconds into a 3 minute edit, and I foolishly believed them, wasting 2 hours removing and replacing clips, trying to find the secret formula before flattening the multicams and sending everything through AE. The flattening was probably the fix, and the AE was probably unnecessary.
Ya know, I thought about doing that, but each video is hours of interview footage at 4k, and my fancy new baby has just been plugging away doing her thing, so I got cocky. And now I’m paying for it.
Also, the lav audio is baked into the cam 1 footage, and when I transcoded it straight from the Finder through ME, it blew out the audio (like the multicam issue I describe in the next paragraph), which was part of my hesitation as well. No matter what settings I chose, it was like “let’s turn this baby up to 15. Fuzz is where it’s at!”
But back to this issue. It’s definitely something to do with the multicams (which is funny that those aren’t the clips the error messages are fussing about). The 2 videos with 1 camera set ups exported just fine. Before sending to AE, I flattened the multicams since AE doesn’t seem to know what to do with them, and AE exported without issue. And when I was building the multicams, it was blowing out the main audio. I would have to move my audio then delete the top audio tracks because it was something baked into those tracks themselves.
I think the moral of the story is MXFs are the devils codec.
Cool. I’ll look into that just as soon as my next video that is ALSO doing this super fun thing that I am definitely enjoying finishes outputting from AE. That little box is definitely checked. I mean, it should also be checked in the first one which worked, but if memory serves that one didn’t have any multicams. Hmmm… The plot thickens (or perhaps thins).
Yes, but when the client’s specs are an odd number mp4, you try your best to provide an odd number mp4. Their specs are based on the Jumbotron specs they were given by the stadium which clearly states that it is an odd number of pixels wide but also that delivery needs to be an mp4. I’m not sure the Jumbotron folks and the machine that runs the images on the Jumbotron folks have ever had a conversation about what’s possible which is how we get this kind of issue.
And the PC vs Mac thing appears to be HOW they each handle it. PC adds a weird line of some super bright color as if to say, “hey, I don’t like this, and I’m going to make sure you know it.” Mac just shaves it off like, “well, surely they didn’t mean it, so let’s just tidy this up for them.” I use both and generally don’t have a preference, but when I was trying to trouble shoot export issue, I couldn’t replicate the problem on my Mac. Neither of them were willing to give me an odd numbered width mp4, but the Mac version could just get sent on with fingers crossed, while the PC one needed a bit of attention first.