MOTUnation.com

Just to muddle the issues, FYI, QT 7.1 has been a problem with some graphics applications as well. So much so, that reverting to 7.0.4 is the recommended short term fix from the "conventional wisdom" crowd.

Okay I now this horse may be long dead, but I want to try one more time to see if I can get some info on what it is I think rpm is referring to:

I know there is a long standing issue with qt audio sync in dp. My understanding of the issue was that it is either always out of sync, or would get increasingly out of sync the deeper into the film you went. I've always extracted audio to avoid the known problem. pencillina posted that qt audio was never in sync for him so he would extract. rpm's post seems to focus on something different.

rpm's initial post said that in his test, he had started with sync'd up audio and the playback was fine. He starts from a point where qt and extacted audio are in perfect sync. Extracted audio and qt audio would stay sync'd up for him regardless of location UNTIL he did a spacebar stop followed by an immediate re-start.

Now audio flams, the qt source audio being heard later than the extracted audio. Stop DP and re-start a few seconds later, things are back in sync, no flams. Quick stop/start and flams again. I can recreate this as well.


Okay, so you can get around this by extracting your audio. Fine.

But I think rpm's point was about the qt video: when you do a quick stop/start and the flammming begins, is the video also slipping late (under the theory that the qt video is always in sync with itself).

Or to ask the question differently: why isn't the video as likely to have slipped as the audio? I ask that question quite honestly as I don't have a huge in depth knowledge as to how qt or DP may handle things so I hope an expert can explain it properly.

So if I've followed the initial point correctly, let's ignore the audio workarounds as these are well known. Anyone got a good handle on why we can be certain the video is not slipping under these specific quick stop/start circumstances? If you're scoring to qt, you don't want to be worried that you may have hit the space bar too quickly in succession...

Just trying to get to the nub of this... thanks in advance for the patience

Andrew

cmm wrote:Anyone got a good handle on why we can be certain the video is not slipping under these specific quick stop/start circumstances...
Andrew

Easy. If you record a performance to QT in DP (at least on my system...) playback is rock solid with the recorded tracks and DP generated audio. I am scoring three silent films for large orchestra currently and the sync has to be perfect for the conductor's DVDs. All playback and bounce to disks are exactly as recorded. The only QT issue is if I try to switch around too many windows during playback, the QT movie will stop(music continues). But that is only when i really push the CPU and hard drive for data.

QT playback sent to an external monitor (TV) via FireWire video (Canopus 100) is also perfect as is full screen (dual 19" ViewSonic's). So I would say, based on my system, it is rock solid once the audio is extracted. I don't any issues with that and prefer the have control of the video track anyway...

FWIW the spacebar-delay problem described above is fixed in 5.01

Jim wrote:Just to muddle the issues, FYI, QT 7.1 has been a problem with some graphics applications as well. So much so, that reverting to 7.0.4 is the recommended short term fix from the "conventional wisdom" crowd.

I've had trouble creating movies in 7.1. It quits unexpectedly very often. I eventually get things done, but it usually requires a couple of reboots of Quicktime to get it working. I'd go back to 7.0.4, but I don't have my installer.

Shooshie

There is an updater to QT 7.1.1 that has been out for a week or so.There's a lot of info at Apple/Forums/Discussions/Quicktime. Apparently OS 10.4.7 is about ready as well.

Well, if you search the UnicorNation web site regarding this problem, there are numerous threads, with varying topic titles, but they are all really addressing the same problem. It is a shame somebody cannot pull all these threads that relate to the same problem into one single chain.

Anyway, here is my understanding and experience of the problem. QT movies, when opened up in DP, have a problem with the audio staying in sync with the video. The known work around for this, which I also have found to be rock solid, is to import the QT movie's audio into the sequence, and then mute the audio coming directly from the QT movie. I have not found anybody that believes that the QT movie video itself slips out of sync with the set start time, it is specifically the audio portion that has been an issue. While using the trick of setting the DP countoff to 0 bars seemed to lessen the amount of offset between the imported audio from the QT movie and the audio coming directly from the QT movie, it was not a consistent fix for me, and yes, stopping the sequence anywhere past the start point, and then hitting play again, always yielded more of an offset problem than starting the sequence from the very beginning. Again, the masses seem to agree that the best solution is to import the QT movie audio into an audio track in DP, and then MUTE the QT audio. There seem to be a few postings in other threads on this site that indicate these problems have been fixed in DP 5.01 and/or QT 7 point something, but I would like to see more submissions confirming this.

Lastly, I just started using a Canopus ADVC 110 to send the QT movies I am working on to a Sony 27-inch TV monitor set up for client viewing, via firewire. I am new to this, and have not had much time to tweak the problem, but there is definitely a seperate sync issue with the video display being out of sync with the audio from DP (and the video running on the computer monitor). I think the problem goes away when you turn the QT movie "Echo movie" command (or something like that) OFF, so that the video is output only to the external TV monitor, and not the computer monitor simultaneously. I am sorry I cannot be more accurate about this, but I am using my home computer right now, and am not at my studio. I will do a follow up posting after I check this out at my studio. Again, this is a different issue than the issue of QT movie audio being out of sync when played in DP. With this Canopus problem, it is a case of the video being out of sync with the audio, not the audio being out of sync with the video. This might seem like playing with words here, but I am referring to whether the audio or video component is the one not starting correctly from a referenced start point. A friend in the biz had mentioned to me that he had heard that many people find it necessary to use a 5 frame offset when using a Canopus box to send firewire video to a TV monitor, and I did read one other posting on this site describing the same problem and the 5 frame offset work-around.

rsherm wrote:Lastly, I just started using a Canopus ADVC 110 to send the QT movies I am working on to a Sony 27-inch TV monitor set up for client viewing, via firewire. I am new to this, and have not had much time to tweak the problem, but there is definitely a seperate sync issue with the video display being out of sync with the audio from DP (and the video running on the computer monitor).

External DV-Analogue video converters always induce a delay. Which has to be compensated for in the video settings (I assume DP has them somewhere). It happens on all systems. The good news is that once you set it for your particular hardware, you shouldn't have to touch it again.