Search the Community
Showing results for tags 'drift'.
Found 4 results
I couldnt see a specific thread about Pluraleyes but I could see a lot of very sceptical posts about the softwares ability from around 2111/2012. I have worked with a lot of people (editors) who absolutely swear by it and when I do 5D work I can just give them the audio files and nothing else (it helps if times of day matches a bit) and I've not had wines or gripes. I did do one job here in ZA for an American company who insisted I got a big ass SD mixer (as well as top of the range everything which was hired at great expense) and we shot on some bigger Cannon cameras and the time code kept drifting and there is always the framerate issue. Now enough time has gone by for people to know. if you have a scratch track on the camera are you soundies and editors happy with Pluraleyes results or are there still sceptics out there and if so why?
Hello all, my question is this. Can a digital tc camera, let's pick Red Dragon, or Weapon, tc drift after the record button has been pushed and before the stop button is pushed? So if you are on 25fps, for easier math, then frame 1 gets stamped 0, is there any way for frame 3 to get stamped something other than 74? And yes, I have searched this. If you know of a link that answers this question, please post it. Thank you. If you need to increase the roll time to an hour for discussion purposes, that's fine.
I have a hypothetical/theoretical question about timecode. I am not asking for any practical reason, and I have no timecode enabled equipment to test this on myself. Just a curiosity. I'm pretty sure I understand the differences between timecode and genlock/sync, namely, that timecode alone does not force synchronised recording speeds between devices, it only stamps synchronised time numbers over the top of the recordings. EG, I am aware that if one jam-syncs the timecode of multiple devices at the start of shooting, then disconnects the timecode cables, after a while, the timecodes (and thus, the recordings themselves) can/will drift out of sync. But what happens when the timecode (NO genlock) is constantly being fed, not a single jam-sync? Say, for example, you have a single audio recorder and a single camera. The audio recorder is sending timecode to the camera constantly via cable. What happens when the camera 'tries' to drift out of sync? The timecodes cannot drift out of sync (as they would if only jam-synced at the start of shooting), as that is the whole point of having constantly connected timecode cables, right? But at the same time, timecode alone will not force the recordings to sync? So...? I have been reading up online about this, and different websites seem to imply two different possibilities: A) the recording of the slave device (the single camera, in my above scenario) will simply drift out of sync from the master (the single audio recorder, in my above scenario), even though the timecodes remain the same throughout the recordings. Or as the slave recording 'tries' to go out of sync by a full frame, it 'tries' to take the timecode with it, but it cannot, so it 'jump' corrects itself. EG, as the camera 'tries' to run 1 frame slower than the timecode it is being fed, it forcibly corrects itself by adding a frame (and/or the opposite, of course). I have come across references to 'green flashes' in footage as a result of a slave camera 'trying' to drift from its incoming timecode. I guess these green flashes are the result of the camera 'adding' a frame (of green?) to force correct itself to match the incoming timecode? Or something else entirely?
Hello My rig is adrift and I cant figure it out! I have a S/D 788t running timecode through my mackie 1220i onyx into metacorder on my macbook pro Leopard. 15 minute take resulted in a ridiculous drift. Timecode was intact but drift was miserable and inconsistent. Used my 788 files and no problem. Any help would be GREATLY appreciated. Thanks Trent