PhillipWestbrook Posted April 13, 2013 Report Share Posted April 13, 2013 Hey! So I just got a call from our editor and he said the audio recorded on the 664 isn't matching up with the video. All the cameras (Vericams) were jam synced with a Timecode slate to 29.97ndf and were checked at the end of each hour long take and were still in perfect sync. The video from both cameras matches up perfectly for the whole hour but the audio starts in sync drifts way out by the end. We also used a clap from the slate as a back up. Has anyone else had this problem or have any ideas what might have gone wrong Quote Link to comment Share on other sites More sharing options...
Rhys Posted April 13, 2013 Report Share Posted April 13, 2013 In your Time Code menu, Do you have your TC set to one of the "Internal"? (The blue light TC should flash when the mixer is off if you are internal) If its on one of the "External" settings then the mixer isn't making use of all of its Timecode holding prowess... Quote Link to comment Share on other sites More sharing options...
Wandering Ear Posted April 13, 2013 Report Share Posted April 13, 2013 The video from both cameras matches up perfectly for the whole hour but the audio starts in sync drifts way out by the end. This doesn't sound like a TC issue, but a sample rate or clock issue. Did they tell you how far out it is by the end? Maybe something it's being pulled up or down. Maybe your clocks are tuned differently and genlock should've been used. Maybe ..... I would recommend asking the editor for more information so you can help them to troubleshoot the issues. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted April 13, 2013 Report Share Posted April 13, 2013 How do you mean "jam synced with a TC slate"? You mean they shot a slate, or they shot a slate that had been jam synced to the Varicam TC? Were the cameras genlocked to each other? I was never able to get Varicams to stay in sync with my audio recorders w/o Lockits--the cameras would drift off a jam sync pretty fast. philp Quote Link to comment Share on other sites More sharing options...
Marc Wielage Posted April 13, 2013 Report Share Posted April 13, 2013 Drifting "way out" is traditionally a 29.97/30.00-frame issue (or, god help you, a drop/non-drop issue). My advice would be to shoot a 5-minute test, clap at the beginning, clap at the end, and see which way it's drifting and then try different settings. And be sure to look at the visible timecode during the 5-minute test and see if it matches audio or matches camera(s). I agree with Phil above: the Varicams are known to drift, and I believe they work better when you put lockboxes on them (Ambient or Denecke). Quote Link to comment Share on other sites More sharing options...
macrecorder Posted April 13, 2013 Report Share Posted April 13, 2013 It's potentially an edit issue, particularly if on FCP 7 - you should check that. Quote Link to comment Share on other sites More sharing options...
pindrop Posted April 13, 2013 Report Share Posted April 13, 2013 On the 788T and the 744T if you feed timecode in to the machine and there is a mismatch between the internal timecode setting and the incoming (from external source) timecode, the timecode rate displayed on the screen flashes until the two agree. I've found this quite useful on occasions. Not sure if the 664 offers the same ability, but might be worth doing as a quick check, as I've also found that Varicams can to do unexpected things with timecode like be set for 25fps picture but output 30fps timecode from the timecode BNC out socket. Quote Link to comment Share on other sites More sharing options...
pvanstry Posted April 13, 2013 Report Share Posted April 13, 2013 I had an similar issue in the past. Here are the specs: Camera at 23.98 Sound at 23.98 All synced using Denecke SB3 Editing software FCP at 29.97ndf Editor was a really savy guy. When importing camera files in FCP, all stayed fine. When Importing sounf files in FCP, files started in Sync with Image but accelerated over the course of the same file ( or decelerated can't remember ). After searching we found out that when importing an sound file in FCP, if it is not the same frame rate then the FCP session, FCP does a Pull up or Pull down on the audio and basically alters the sampling rate thus slowing or increasing the speed of the file, hence the change in speed. Fix was simply to import the original sound files in Wave Agent, change the Frame rate Metadata for all files and reimport in FCP. All was fine from there. Hope this helps. Thanks Quote Link to comment Share on other sites More sharing options...
macruth Posted April 13, 2013 Report Share Posted April 13, 2013 Drifting "way out" is traditionally a 29.97/30.00-frame issue (or, god help you, a drop/non-drop issue). My advice would be to shoot a 5-minute test, clap at the beginning, clap at the end, and see which way it's drifting and then try different settings. And be sure to look at the visible timecode during the 5-minute test and see if it matches audio or matches camera(s). I agree with Phil above: the Varicams are known to drift, and I believe they work better when you put lockboxes on them (Ambient or Denecke). A shot in the dark, but last time we used Varicams (in 2006), seem to remember that somehow the Varicam "internal math" works at ONLY 30fps or 60fps, hinting that what Marc mentioned above might be the case, We ended up using Lockit boxes and solved the issue Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted April 13, 2013 Report Share Posted April 13, 2013 Pascal's issue pertains also--that famous FCP bug that demands that your session setup match all the media imported or it will gearbox nopn-setup spec media to match its setup. Big landmine. philp Quote Link to comment Share on other sites More sharing options...
PhillipWestbrook Posted April 13, 2013 Author Report Share Posted April 13, 2013 Thank you everyone for sharing your experiences and the solutions you've found. We used C300's on a different day of shooting and had no problems so we know it was a Vericam issue. We will make sure to have lock-it boxes in the future. I passed the information on to the editor and hopefully reimporting the audio will solve the drift issue. Thank you again everyone! Quote Link to comment Share on other sites More sharing options...
Robert Li Posted April 13, 2013 Report Share Posted April 13, 2013 This might sound stupid, but as part of the workflow test could you set the internal tc of the 664, jam the varicam to it (always been super iffy about using varicams anyway), do the 5 minute test that marc suggested then tether the 664 for the varicam and check it against the internal tc with the built in checker? Or is that pointless and the drifting has to do with the ingestion into fcp? edit: nvm lol Quote Link to comment Share on other sites More sharing options...
Mark Orusa Posted April 13, 2013 Report Share Posted April 13, 2013 I came across this page on Sound Devices' website: http://www.sounddevices.com/notes/recorders/file-formats/panasonic-varicam-tc/ It may be of some use. Mark O. Quote Link to comment Share on other sites More sharing options...
PhillipWestbrook Posted April 15, 2013 Author Report Share Posted April 15, 2013 The answer to our problem ended up being reimporting the audio with a different sample rate (44.1k) and everything lined up. Additional relevant information also includes that the FCP session started as 24 frames. Quote Link to comment Share on other sites More sharing options...
Derek H Posted April 15, 2013 Report Share Posted April 15, 2013 I love how the sound mixer is often the first one under the bus for sync issues. Quote Link to comment Share on other sites More sharing options...
Solid Goldberger Posted April 15, 2013 Report Share Posted April 15, 2013 I love how the sound mixer is often the first one under the bus for sync issues. Seems like this is the case EVERY TIME Also every time, it seems that I hear about these problems from a frantic producer, rather then just a phone call or email directly from post. sigh. e. Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted April 15, 2013 Report Share Posted April 15, 2013 The answer to our problem ended up being reimporting the audio with a different sample rate (44.1k) and everything lined up. Additional relevant information also includes that the FCP session started as 24 frames. Why is 44.1 being used in a video project? philp Quote Link to comment Share on other sites More sharing options...
Jeff Wexler Posted April 15, 2013 Report Share Posted April 15, 2013 Why is 44.1 being used in a video project? philp For the same reason they have probably made several other mistakes that they will blame on the sound mixer. Quote Link to comment Share on other sites More sharing options...
studiomprd Posted April 15, 2013 Report Share Posted April 15, 2013 Hi, and welcome... " he said the audio recorded on the 664 isn't matching up with the video. " you are going to need something much more specific... " the audio starts in sync drifts way out by the end. " that's better... " Has anyone else had this problem or have any ideas what might have gone wrong " yes, and yes. " This doesn't sound like a TC issue, but a sample rate or clock issue. " well, maybe sample rate but not WC...even with such limited information, it sounds a lot like a TC issue to me, and probably a pull-up/down issue between integer TC and non-integer TC...which it appears to have been (induced by FCsP.) Thus it is and was not a SD 664 Timecode sync issue at all... but the important thing is the apparent lack of a workflow test before the shoot... Quote Link to comment Share on other sites More sharing options...
Robert Li Posted April 19, 2013 Report Share Posted April 19, 2013 I just literally then did a workflow test of my 664 with a red one mx we are going to use tomorrow on an ad + ambient master slate. Camera is continuously jamming to a lockit box, It is consistently out by 1 frame, no drifting after 5 minutes... hmmm... rejammed it twice and ran through work flow each time (ingest into edit). Wierd... edit: nvm did it with a dumb slate as well and it's bang on, just the display on the 664 is out by a frame oooooo display latency Quote Link to comment Share on other sites More sharing options...
TomBoisseau Posted April 19, 2013 Report Share Posted April 19, 2013 I seem to be in the minority here, but I often use my G3's to send timecode. I'll put the transmitter on the camera and a receiver on my 664, slate, etc. This usually seems to be preferable. This way when the camera rolls, I have the 664 set to "auto record". Makes life easy! Sometimes Ill make the 664 the master, but that can be a problem if camera breaks away. Obviously not a real answer to your problem, but it's a method that has "usually" worked quite well for me. Tom Quote Link to comment Share on other sites More sharing options...
macrecorder Posted April 19, 2013 Report Share Posted April 19, 2013 So it sounds like the FCP issue was the culprit, even if you found an unconventional way to fix it. Quote Link to comment Share on other sites More sharing options...
soundslikejustin Posted April 19, 2013 Report Share Posted April 19, 2013 I just literally then did a workflow test of my 664 with a red one mx we are going to use tomorrow on an ad + ambient master slate. Camera is continuously jamming to a lockit box, It is consistently out by 1 frame, no drifting after 5 minutes... hmmm... rejammed it twice and ran through work flow each time (ingest into edit). Wierd... edit: nvm did it with a dumb slate as well and it's bang on, just the display on the 664 is out by a frame oooooo display latency Alexa's display TC is out by a second, the RED display TC is out by a few frames, but display drifts back and forth - refresh speed is limited, apparently. Quote Link to comment Share on other sites More sharing options...
studiomprd Posted April 20, 2013 Report Share Posted April 20, 2013 " Wierd... " no it isn't... and why do so many folks keep saying that. " It is consistently out by 1 frame, no drifting after 5 minutes... " we call that an offset. quite common, actually, and not at all "weird"... Quote Link to comment Share on other sites More sharing options...
Philip Perkins Posted April 20, 2013 Report Share Posted April 20, 2013 Nearly all TC readers take a frame to refresh, so they appear to be a frame late. However this diff is only visible if you take a still pic of the readers--my eyes at least are not good enough to see a single frame of diff between two readers! philp Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.