I'm running a similar system to yours on Vista 64 and have the same problem. It seems to be that the processor is struggling to keep up with the camera changes and the delay gets longer as you work along the timeline.
I improved the situation by reducing the project into timelines that are about 30 minutes long.
The problem only shows up at preview and the changes are actually being made at the moment you select each camera.
The problem with both of your posts is that it is lacking in basic info to help you.
It is somewhat akin to "Help, my car does not start".
Well, did you have the car keys, was there petrol in the tank, was the battery charged, was the car stolen, etc.
Chris, I have replied to you before with this link:
If you can't give us more info, we can't either.
Harm, I have replied to JD's question making the wild assumption that he knows where his car keys are and has, as I do, a good working knowledge of Prem pro CS4.
I have given him the benefit of my experience without attempting to talk down to him.
You should try the same.
making the wild assumption that he knows where his car keys are
In these forums, that is a pretty wild assumption. Would that only pros came here...
I've discovered the same issue with two recent multicam edits. One was a 3-cam DVCPROHD 720/24pN shoot, and the other was a 2-cam DV 24p shoot; both exhibited the problem, though the DV edit to a somewhat lesser extent. Oddly, it wasn't always reproduceable. For instance, the HD project would lag pretty seriously (it got up to 4-5 seconds at times) and I guess this would be expected, but occasionally I'd leave and then come back to the project and it would work perfectly fine for a length of time. Of course, as soon as I thought "It's fixed!" it would start acting up again. The DV project did it too, to a lesser degree, which was surprising considering I've done similar and even larger projects on earlier iterations of the software without the issue.
I tried every combination of turning various features on and off, but nothing seemed to make a major difference. Wish I had a solution, as "something" is quite obviously amiss, but it's really difficult to pinpoint where this problem lies. I'm submitting a bug report to Adobe, but am not holding my breath for a fix in CS4.
Thanks Chris for the reply. At least we (you and I) believe there is a problem somewhere.
Eddie posted a link to optimizing your workstation, which I read, but those tips seem very basic, much like the tips that have always accompanied apps that push the limits of a system. I don't know if I'm a Premiere "pro", but I been using Premiere since version 4.0 (not Premiere Pro, just plain Premiere) back in the mid 90's. Man, talk about a history... let me see.., ver.4.0, 4.5, 5.0, 6.5. Premiere Pro, Pro 1.5, CS2, CS3 and now CS4....hmmmm.... that seems to be a bunch. :-) This is the only time I've run into this particular issue; of course MultiCam editing only came into existence with CS2?..can't really remember. Not trying to bash Adobe, gosh if I didn't like the product I would have changed to a different vender years ago, but CS4, even with the 4.1.0 update has some issues. I hoping Adobe will come out with a 4.2 or something that will fix some of the problems.
BTW, I deleted the 'target' sequence and created a new 'target sequence' and it's running as I think it should (no delays for now), but I haven't quite reached the mid-point in the first part of the performance which is 42 minutes. Then I've got the second part (post intermission) that is over an hour .. that's going to be fun!!
Thanks Colin. You hit mynail right on the head ... your description of the issue is spot on!! My experience is exactly the same as what you describe, however, I only shoot DV. Funny thing though; I just finished two weddings, each a 3 camera ceremony around 35-45 minutes and neither had this problem.
Obviously, it's far from conclusive, but this certainly smacks of a software issue and not something to do with hardware. Wish I had a solution, but "hope/wait/deal with it" seems to be the only course of action for now
I will offer up one suggestion that seemed to have some positive effect, and that's getting rid of the audio portion of your sync sequence when you nest it in your edit sequence. Let me explain a little more:
I create my original sync sequence that holds all my various angles, and I call it "MC_SYNC"... no relation to MC Hammer. I trim the heads and tails of each angle so that clips all begin at one time point, and end at another time point--you'll see why this is important later, beyond the fact that it just makes things neat and tidy. Per the multicam procedure in PPro, this sequence is nested into a fresh, empty sequence which is dubbed "MC_EDIT". Now, what PPro will usually do is render/conform the audio portion of the nested sequence, though in my recent multicam edits, sometimes this did not happen right away. This can be a rather large, ungainly file and might be thrown hither, thither and yon depending on the media cache settings. Most of the time, I never use the "multicam mixed" audio track because I do my own mix in a new sequence (or in an external application) before finalizing the sequence. So what I do now is immediately delete the audio portion of the nested sequence (ie. MC_SYNC once it's placed inside of MC_EDIT) and replace that with a good, clean, workable track from one of my camera angles.
To do this, I go back to MC_SYNC and find the camera angle that has the best sound from which to edit. I Alt+click the audio track I want and copy it (you can also use Match Frame to load the source clip into the source monitor, if you want), and then switch back to MC_EDIT where I paste it into the sequence with the CTI placed at the beginning of the sequence. This is why I trim up everything in MC_SYNC before nesting: so that there is no chance of having the pasted audio out of sync with the multicam video clip. Now, the program will be referencing a single source file for audio in your multicam edit, which has seemed to me to have a positive impact on the editing experience.
Give that a shot, and see if it works for you.
I've applied your suggestion on the audio .. and I think you may have
something there. It does seem to help....so far, a LOT!! I also got
frustrated because I needed to do some 'repair' to the original footage,
color correction, etc. so I just applied the necessary filters and
adjustments to the original footage and exported a 'new' avi file, then took
those 3 avi files to my 'MC_Sync" sequence timeline. I also, did as you
suggested and selected my 'best' audio track, copied it and placed it on my
audio track in my "MC_Edit" sequence timeline. As I said, so far so good.
Thanks again ...
I have the same problem with Multi Cam since I updated my Premiere Pro from 4.0.1 to 4.1, before that It was OK, I Install new Windows Vista (x86) and just update my Premiere from 4.0.0 to 4.0.1, and the Multi Cam Is fine!
I'm not sure you gonna have the same result, so I just share my experience.
Thanks. I did find in one of the Knowledge Base docs a reference to MultiCam
editing. It 'suggested' there was a known bug and to use .MOV files rather
than .AVI for the source material. So, for most of us, I would think that
would mean a capture to .AVI (from the camera tape), then a AME conversion
from .AVI to .MOV, then import and edit using the .MOV files. Seems like a
lot of hassle. I have not yet tried that, but will be doing so in the next
week or so.
For MAC's that may make sense, but it does not apply to PC's. Qui(R)ktime MOV's cause too much trouble on PC's. Further it is better on a MAC to just change the wrapper before import, but leave the AVI codec in place. It avoids a generation loss. BTW, do you have a link to the KB article?
No I didn't make note of it .. it was a while back and I'm sure I could have
Sorry, I meant to say the DV codec, not the AVI codec, because AVI is not a codec. Changing the wrapper means the codec remains the same, no generation loss, but the wrapper is changed from AVI to MOV.