Jump to content

Deva Timecode is gonna get me sacked


HOPKIN

Recommended Posts

  • Replies 146
  • Created
  • Last Reply

Top Posters In This Topic

One other thing to consider is that DEVA (at least the last time I examined the files) used a different tag than everyone else in the bext metadata to indicate Time Code Frame Rate. It could be that whatever edit software or other plugin that was being used in post couldn't detect the correct frame rate from the bext data so fell back to whatever default it was last set to. This could explain the difference in interpretation from the Deva files and the 788t files.even if they were both being driven from the same Time Code Clock. Frame rate may be represented the same way in the iXML chunk but a lot of software still pulls the Time Code data from the BEXT chunk first.

I sure would like to know what edit system/version etc was being used here. Given normal healthy Devas what happened to the OP could happen to anyone working with that system. My old school brain keeps thinking about fussy overly-narrow-speced analog CTTC playback machines in telecine, and wondering if some digital/software version of that sort of "too small a tolerance window" situation was in effect.

phil p

Link to comment
Share on other sites

One other thing to consider is that DEVA (at least the last time I examined the files) used a different tag than everyone else in the bext metadata to indicate Time Code Frame Rate. It could be that whatever edit software or other plugin that was being used in post couldn't detect the correct frame rate from the bext data so fell back to whatever default it was last set to.

What Courtney is suggesting here seems to backup my feeling that something is happening AFTER the Deva in post that is "causing" the problem.

Link to comment
Share on other sites

I would be curious what method is being used to sync up the Deva files in post as well. The key difference between this project and hundreds of similar non-linear dailies projects I worked on over the last 10 years:

1) no timecode slate

2) tuning the internal camera TC generator instead of ext. TC and genlock

3) a post crew insistent on absolute perfect TC matches between camera and sound.

#1 makes me nervous, #2 frightens me, and #3 is just silly. Strictly my opinion. It's strange how some post people just love to whine and complain, while others quietly sweep all the problems (however minor) under the rug and just fix it. I have definitely seen the "sometimes 1 frame off, sometimes perfect" syndrome before, and it can be maddening -- but not a deal breaker.

I concede that many, many major A-list films routinely shoot with just dumb sticks, and there does exist several good post-syncing tools that rely on actually finding clap sync automatically -- and they work well, with some human intervention. MTI Control Dailies is one, and I believe Bones Dailies (now discontinued) did this, too. Fotokem invented their own system, and I believe eFilm has one as well.

Link to comment
Share on other sites

I believe that HOPKIN tried to do the offset on burning wav trick that Fusion can do. From memory I believe he went for 40 ms.

I am on mental arithmetic atm, and post pint in the pub... but isnt a frame at 24fps about 40ms long, so are we not taling about a third of that, (0.3) so about 15ms of difference? So - if HOPKIN tried the 40ms offset it might have been rather too much to put things into about the right ballark?

sb

Hi Simon,

I read your post just before Friday wrap and as I was heading out for for a couple of glasses of wine, I naturally didn't give it much consideration until today.

Hopkin used a 60ms delay or about 1.4 frames and you are correct that the delay that I observed is about 15ms. Some of that 15ms delay will be A/D conversion of the timecode going into the audio input.

I have followed this thread since the outset and it's been difficult to add anything to the discussion that would help resolve Hopkins problems. Some interesting theories though.

Link to comment
Share on other sites

I would be curious what method is being used to sync up the Deva files in post as well. The key difference between this project and hundreds of similar non-linear dailies projects I worked on over the last 10 years:

1) no timecode slate

2) tuning the internal camera TC generator instead of ext. TC and genlock

3) a post crew insistent on absolute perfect TC matches between camera and sound.

#1 makes me nervous, #2 frightens me, and #3 is just silly. Strictly my opinion. \

I'm a proponent of auto syncing and (as near possible) perfect TC matches between camera and sound.

Auto syncing with the appropriately specified cameras, audio recorders and timecode / sync generators provides for synch accuracy to a 1/10th of a frame or better and assuming all the vision from any number of cameras and sound is in a non linear format and loaded into Avid or FCP bins, syncing of a days rushes can take 10" or so. On the basis of sync accuracy and efficiency the process is the "state of the art" and has been in use since the mid 1990's

The principle is that the alignment of camera frame starts and the TC stamp in the audio can be created accurately in the original field recordings and that when imported into a frame based editing system, that accuracy is maintained until someone in the post chain moves it around or as been noted earlier in this thread, you just happen to be sitting near the back of a cinema and sound is delayed a frame or two due to the laws of physics.

By comparison, syncing using traditional slates or timecode slates on frame based editing systems where there is no alignment of camera frame starts and the TC stamp in the audio results in sync variations of between 0.00 and 0.99 fames. No one knows within the duration of the vision frame exactly when the slate occurred.

It can be argued that sync accuracy of between 0 and 1 frame is just fine and decades of productions have successfully been made with this level of resolution.

In reality, if a production is using Lockit's on the cameras, chances are they are auto syncing in an Avid. There's an expectation of near as perfect sync between camera and sound and this is achieved everyday worldwide.

When the wheels fall off the bus, as Hopkin and others have discovered, it's a problem figuring out what's going wrong and the sound mixer always gets the blame. With offset bugs and frame based syncing the simple solution might be bumping a frame here or there without any analysis of cause of the problem. With buggy auto syncing, there's just a lot work fixing sync and quite possibly, a disgruntled production and post team and still no methodical analysis of the problem.

My first ever Lockit shoot was in 1995. My new StellaDat and couple of Sony Digital Betacams. For the first 2 or 3 weeks there were numerous random frame errors. Much angst and memos flying all over the place inferring the Lockits weren't working Suddenly everything went quiet. It transpired that post had a basic Digidesign interface which wasn't frame accurate. They then acquired a Digidesign Slave Driver and the frame error evaporated. To this day that post faciltity specialises in auto syncing rushes.

Getting back to the essence of the thread, here's some comments on Alexa's. As Simon Bishop and others have noted, it's said that the Alexa won't hold a new Tune value when fully powered down and defaults back to the factory reference. I only ever seem to do short term shoots with Alexa's and haven't had the opportunity to verify this but it does present a dilemma for accurate sync. On the other hand, every Alexa I have checked with an ACC501 hasn't been far off Ambients GPS reference standard.

Sebastian Fell at Ambient commented in an email last year about a variation of the Ambient technology that Arri had implemented some time ago in the SR3 timecode system and more recently in the Alexa that provides for accurate sync with an external Lockit.

"It can also (which is the mod of the Clockit) auto-tune to an incoming time code, which it does when it is in EXT. TC / REGEN mode. It then generates TC, but follows the incoming code closely, a kind of "sync & lock", as we called in in the old days in the recording studio... As the whole camera is clocked from the tunable crystal, this means that the camera is then indeed synced to the external TC, meaning that the picture sensor will not drift against the TC"

So if anyone is feeding a tuned Lockit into an Alexa in EXT TC / REGEN Mode, it would seem that's as good as it gets. It's tweaking the Alexa's master sync generator so don't feed just any old flavour of timecode or Mark Wielage might justifiably have heart palpation's.

Link to comment
Share on other sites

So if the OP did what most other posters here seem to do with Deva+Alexa shoots: ext clock to the Deva, jam lockits to it, Lockits to the Alexa in Ext TC Regen, then all should be well, given that the rest of the apparatus is working correctly. Right?

This is a bummer. The Alexa was one of the bright spots in our little world--decent sound recording, (supposedly) able to take a jam and hold it as well as another camera with a Lockit. So now we've decided that that workflow isn't accurate enough, I guess? And I'm to understand that a project doing Avid autosync will require dead-on frame accurate TC sync all the time or my phone will ring? But that the vastly larger post world that is Final Cut based doesn't care so much about this?

phil p

Link to comment
Share on other sites

David Madigan writes:

<By comparison, syncing using traditional slates or timecode slates on frame based editing systems where there is no alignment of camera frame starts and the TC stamp in the audio results in sync variations of between 0.00 and 0.99 fames. No one knows within the duration of the vision frame exactly when the slate occurred.

It can be argued that sync accuracy of between 0 and 1 frame is just fine and decades of productions have successfully been made with this level of resolution.>

If the boom mic is moved into the set to pick up the slate (which i guess any decent boom op would do as matter of course), assuming the mic was even 6 feet away from the slate, it would still result in a 18 ms delay, which is far less than timecode at 1/24 or 1/25 of a second.

I wonder of what importance such accuracy is helping achieve.

I KNOW using timecode boxes on digital cameras has been the way for many years, why would companies like Denecke and Ambient put out these boxes otherwise... I am asking a fundamental question here.

Is it really imperative to have uniform timecode between picture and sound? What is the real purpose this serves? Saves time in post?

If it was a multi-cam shoot, camera department may need to synchronise their 2 or 3 or more cameras so that the image clips line up on the time-line on their edit workstations one below the other in sync with each other.

Is post thinking about saving time to sync picture and audio? If they have the same TC it would save them time? How much really, in the case of file-based TC stamped audio that anyways lines up automatically and chronologically on any non-linear picture edit workstation nowadays?

Link to comment
Share on other sites

In reality, if a production is using Lockit's on the cameras, chances are they are auto syncing in an Avid. There's an expectation of near as perfect sync between camera and sound and this is achieved everyday worldwide.

I believe The Senator has an expression about producers who have to "lower their expectations."

Seriously, if you auto-sync an entire day's worth of dailies, it takes less than :30 seconds per take to just check it. If it's off 1 frame, slip it, and move on to the next take. Not a big deal in the real world. 200 takes = 100 minutes, roughly 90 minutes. And if the sync is exactly perfect already, that takes 10 seconds to jump to the next shot, which is even faster. In truth, the whole process takes well under an hour.

And yet I have seen external timecode and genlock work perfectly on many cameras. I have never seen a picture editor worry about sub-frame accuracy, so if something is 18ms out (as Vin describes above), they aren't gonna notice it. Bear in mind that a lot of editors are using LCD monitors that may have a frame of delay built into the monitor...

Link to comment
Share on other sites

  • 2 weeks later...
  • 4 weeks later...

For what it's worth, I've done a few shows that used auto sync. Our setup was extremely simple. Deva was

the tc master (23.98), feeding the IFB xtr. We set the cameras to external TC and fed them with Zaxcom ERX

receivers (also set to 23.98). We also jam the slates with the ERX. Works flawlessly. On the first day of the first job (Season 1 of The Big C) we discovered a glitch in the way the ERX would bounce between receiving tc and resyncing itself to the received code which would lead to a glitch every 30 minutes or so. Howy quickly re-wrote the software and from then on it's been golden. Very accurate, very simple,very lightweight and very fast to set up.

Billy Sarokin

Link to comment
Share on other sites

same here,

Deva V - Ifb100 - ERXtcd - 2 Alexa EXT tc, regen + audio scratchtrack

I asked the editor to compare the audio recorded as a guide on the alexa against the sync of the Deva files, and it was (apart of a consistent Phase from Different AD) rock solid on 2 camera's for 35 day's in a row

I really like this option a lot, very lightweight, and accurate. No need to tune lockits, and put one on the Deva itself.

Jan Deca

Link to comment
Share on other sites

It is interesting that this topic (mis-named from the very beginning because I don't think anybody got "sacked") continues with lots and lots of people chiming in with success stories that counter the amazingly long winded and complex HOPKIN saga. The fact remains that the majority of us have had little or no difficulty syncing (even un-attended auto-syncing) our Deva tracks providing proper timecode protocols have been followed. For me, there has never been a problem and this is with several thousand sound rolls over 15 years. That said, it is obvious that the HOPKIN problem could only be solved by using a different recorder. I still cannot understand this but I'm pleased that he did not get sacked and the problem got solved.

Link to comment
Share on other sites

As a distant observer what I seem to be seeing is that at least some of the successful Deva shoots (Avid auto-sync TC wise) used Zax IFB+TC devices receiving a TC signal transmitted from the Deva, while the SD shoots (where my experience is, and where Mr. Hopkin ended up) jammed TC generators like Lockits to the SD recorder, and then put those on the camera. There are still many unexplained factors (like post house workflow). I don't doubt that many of us have been doing recordings for years that might not be 1/10th frame TC accurate, since there are a whole lot of workflows in which that doesn't matter much. We may have just collectively re-discovered one in which it DOES matter, or (perhaps), PEOPLE to whom it matters.

philp

Link to comment
Share on other sites

1/10th of a frame probably won't matter, but if that error accumulates over time, then the numbers are eventually going to "flip over" to the next frame. This is what I suspect is going on, in terms of time code phase and/or jitter.

I can recall problematic jobs where we wound up using a Destripalizer to stabilize timecode sync, especially in analog situations where the tape was dropping out or there was stretching or some other problem affecting the timecode track. Timecode analyzers exist, and it would be a simple matter to compare Ambient, Deva, and Denecke signals to see if any issues are there and how they can be resolved (no pun intended).

I agree with Phil that post house flakiness can be a wild card issue as well. We occasionally had complex post projects in the 1990s and 2000s where engineering had to be called in to do the preliminary check and set up for the incoming sound rolls, and once we established a reliable workflow, we'd make an effort to write it down so that if somebody else wound up doing the job, they'd be prepared. God help you if you got the part-time late night guy who had 6 months experience, instead of the regular operator.

Link to comment
Share on other sites

1/10th of a frame probably won't matter, but if that error accumulates over time, then the numbers are eventually going to "flip over" to the next frame. This is what I suspect is going on, in terms of time code phase and/or jitter.

I can recall problematic jobs where we wound up using a Destripalizer to stabilize timecode sync, especially in analog situations where the tape was dropping out or there was stretching or some other problem affecting the timecode track. Timecode analyzers exist, and it would be a simple matter to compare Ambient, Deva, and Denecke signals to see if any issues are there and how they can be resolved (no pun intended).

I agree with Phil that post house flakiness can be a wild card issue as well. We occasionally had complex post projects in the 1990s and 2000s where engineering had to be called in to do the preliminary check and set up for the incoming sound rolls, and once we established a reliable workflow, we'd make an effort to write it down so that if somebody else wound up doing the job, they'd be prepared. God help you if you got the part-time late night guy who had 6 months experience, instead of the regular operator.

This last I remember vividly, and had an instructional label I would put on EVERY 7 inch tape box re: this for a few years--phone numbers, what had helped in which situations in the past etc etc, because most of my jobs were the ones done on the graveyard shift by newby freelancers, not the staff day-shift guys doing the movies and episodics. Bad times--don't miss those late night phone calls. I had a minor side business transferring problem TC tapes for awhile because the local post houses had so many problems with 1/4 CTTC recordings. In any case, I think the policies or habits of the post house have more to do with issues now, or I hope that's the case.

philp

Link to comment
Share on other sites

Yes, I agree -- we have used those phone numbers on the DAT boxes, DVD-RAM boxes, and the Nagra boxes in the old days. (I won't mention the name, but there was one modest-budgeted film a few years ago where the DVD-RAM disk we received was blank! Luckily, we had a backup DAT, and it was fine. We called the mixer, told him not to worry, and he replied that he had allowed his 3rd to format the Deva that morning, and had suspected it was bad but was too rushed to check it.) All was well.

The reality today is that the post house is getting cut out of the process more and more, as some producers opt to simply expand their editor's office to include makeshift dailies facilities on a laptop. In truth, it can be done this way, but now, editors and assistant editors are confronted with all the problems that post people traditionally have swept under the rug -- like a couple of dozen shots that are 1 frame out (out of hundreds).

Link to comment
Share on other sites

Shoulda, coulda, woulda! Eh, live and learn.

I would blame the Deva for not generating an error message that said, "hey! The mirror disk is not correctly formatted!" In a perfect world, it would've done that from take 1 on. Definitely, the SD mirror drives freak out if they're not correctly formatted.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...