Wil Renczes
Forum Replies Created
-
The double-click is intentional – we found too many people would click to set the focus to the program monitor & inadvertently start panning footage because the direct manipulation mode would engage. By requiring a double-click, those accidents don’t happen anymore.
-
The blue alpha tint thing sounds like a bug – most likely a BGRA image is being composited as ARGB (or vice versa), so the alpha & blue channels are being swapped. It’s probably specific to the clip with the Animation codec + alpha, I’d expect that it would bake in the blue tint into whatever it’s layered over.
If you can share one of those Anim + alpha clips somewhere, we can check it out.
Cheers
-
I don’t know if AJA testers are free to talk yet about the state of the CS6 drivers as it’s still in beta, but to give you an idea, at the AJA booth, they were demonstrating 4K realtime (sic) output on one of their stations.
-
Correct, interpret footage acts on the master clip & applies to all instances of that clip on your timeline. If you want to have the same footage behave differently, you can import the same clip as two distinct master clips.
I don’t think you’ll need to mess with the interpret footage options, unless a clip is coming in with the wrong PAR / framerate, or alternatively if you’re trying to force a PAR on a clip. (Usually, this is more likely if you’re bringing in a still – Premiere will try to guess what the PAR of the image might be, but it’s a crapshoot whether it’ll be standard vs widescreen, since stills typically don’t contain additional metadata that indicate this.)
Video footage should be correctly letterboxed / pillarboxed as appropriate when it doesn’t match the PAR of the project in question.
Cheers
-
That sounds like a painful way to do it. If you prefer to spot correct individual jpgs, one way to force an update to the clip in Premiere is to offline the clip in the project window, then relink back to the first frame.
There’s also an option (I believe in the sequence menu) that will allow you to delete preview files if you want to flush your timeline renders.
-
The 3.1.0 update is going live today via the Adobe Update Manager. Enjoy…
Wil
-
Tim, your concept of dropping the hours from the TC conversion from non-drop to drop is interesting. I won’t debate whether it’s technically wrong or not – it’s moot, since it comes down to how you stripe your tapes. The problem is that Premiere can’t assume what the starting TC of the tape is, since it’s arbitrary. It has no choice but to go with the assumption that zero is the starting TC.
The real issue though is the fact that your non-drop material is being displayed as drop. You’ve found the (annoyingly subtle) preference to change it; I think you’ll find that the option will be removed entirely going forward. Bottom line is that the app should always show the native TC & dropness of any clip in the project window. As you pointed out, it doesn’t make sense to convert the TC to the project settings, since it’s meaningless when you go back & look at your source tape.
Ironically, I think you would have found that if you had gone ahead & attempted to capture your footage without that switch on, it probably would have worked anyway. The issue you’re hitting is simply how Premiere ‘displays’ the TC, not necessarily whether it’s actually messed it up…
-
Hard to say. It would depend on the original duration of the clip that has the speed change applied.
-
Hmm… sounds like your DV encoder is corrupting frames while rendering. (I think the decoder’s okay, since you only seem to see this on things that have some sort of effect/filter applied.) Quick test to confirm: try creating a new PAL project, and right-click in the project window- new clip – color bars or universal counting leader, drop that on the timeline & drop the opacity slightly. Hit enter to render preview the timeline – if it renders messed up, we know it’s the encoder.
Assuming the above, now, the next question – how does the encoder get corrupted? This has me a little stumped. Premiere uses the Main Concept codec for DV – do you have a separate installed version of it on your system? Or possibly another 3rd-party codec that could be trumping the default?