![]() We'll just have to agree to disagree on this one Neil. But yea, it can be frustrating when the user & engineer viewpoints are polar opposites. We users do get some things changed over time. And this is one of the issues I'll be arguing with the engineers about. The engineers don't see that usage as necessary, as they have the process they intended for us to use. And that's where the disconnect comes in. Because as far as they can see, they already have a good, working process for Y.įrom our user standpoint, there are things about the interpret footage that work better for the work you're doing than a time/duration change. The user is essentially saying "But when I do Y with X, it breaks at times!" to which the engineer simply says "Don't use Y to do X." And, as far as they're concerned. Because again, to them, that is something it was never designed nor intended to do. And as the "proper" designed process (as they can see it) works as expected, they don't see a reason to "fix X" because it doesn't always do "Y" well. Both processes are working correctly (to the engineers) for what they are designed to do.Īnd if some user chooses to use X tool to do Y, and it works at times, great.īut as that use is not what they designed it for. Which they see as very different processes from an engineering viewpoint. odd.Īnd I think this an issue where as far as the engineers are concerned, they built a process for "X" and a process for "Y". ![]() ![]() We users often do something with a tool that it was never designed to do, but does in many cases cool stuff for us. Their opinions can be quite different than ours, but it isn't from a lack of caring.Īnd I'm sure the engineers would take exception to your calling this a "workaround" when as far as they can see, things are functioning exactly as expected and designed, when used for what they were designed for. As, having spent hours with quite a few of the engineers, they actually care quite a bit about the program. And it doesn't have anything whatever to do with not caring. "I come back to my original point - interpret footage should work for all workflows and Adobe just doesn't seem to care if there is a so called "workaround"."Įasy enough as another user to see your viewpoint. I've already lodged a bug/whatever request on this and of course the bug is still present 6 months later. And we probably have to do that before creating proxies.Īnd none of this explains why ordinary 25fps footage when slowed down on the timeline gives glitchy jumpy results when rendered via hardware on the M1 processor. So if Adobe uses interpret footage - shouldn't it actually work properly? For footage like that, we now have to undo the interpret footage and then redo it as a speed clip. Plus Adobe themselves do this automatically for metadata flagged slo mo like A7SIII, RED etc. Basically it allows you to work in whole frames without Adobe trying to invent in between frames. Interpret footage is actually a much better tool (if it worked) than working off some random percentage speed. I would argue the opposite to what the video proposes. But for argument's sake let's say Adobe compensates for that by using a 23.98 timebase for your sequence and rounding it down to whole frames (I don't know if they do or not). I still have reservations because it doesn't answer my question - it's not frame for frame. Kevin, thaks for pointing me to that video - it's super helpful. and if I'm not being clear enough, just ask me to describe this workflow in more detail. If you need help figuring out how to test this workflow, post back. But I'd do a test to make sure this workaround wil function correctly with your camera generated proxies. Of the 8 channels of audio, I only needed the first 2 channels (actuallly there was no audio in tracks 3 - 8_).Although I could generate proxies within premiere, they wouldn't stay attached to the camera original clips. I spent several days tearing my hear out trying to generating proxies from a sony camera (maybe the FS7 - can't remember but can dig down to figure it out if you want) that had 8 tracks of audio generated in camera. When you lock picture, unlink the proxies and relink to the full quality camera original. And here's the trick, rather than "attaching" the camera generated proxies, unlink the full quality camera original and relink to the camera generated proxies in Premiere. First, as Kevin suggested, do not interpret the clips to adjust speed but use the adjust speed dialog.
0 Comments
Leave a Reply. |