Jump to content

Deva Timecode is gonna get me sacked


HOPKIN
 Share

Recommended Posts

  • Replies 146
  • Created
  • Last Reply

Top Posters In This Topic

For quite some time, I have used my Deva to create the code for the day - proper TOD and Ubits, then I jam an SBT, which then becomes the master for the remainder of the day.

This SBT, now the master, is then used to jam slates, additional SBTs, etc - sometimes even to feed, hardwired, to an camera TC-In ....

This gives me the freedom to turn off my Deva whenever I feel the need to conserve power, without any worry about re-jamming all of the other TC needs.... upon power-up, all I do is rejam code to the Deva from the "Master SBT"

Although this process began when doing work in the bag, I do this on all of my cart work as well.

MF

Link to comment
Share on other sites

same here. I jam an ACL203 from my Fusion. That becomes my Master and jams the 2nd LockIt for the Alexa and then back onto the Fusion which is set to ContJamAll. Just one rejam to the Alexa´s LockIt after Lunch and that´s it.

Wish the Fusion had a build in Lockit like my 744. When in bag-mode every piece of gear adds weight.

Yes puzzling the Zaxcom website says -

Timcode Reader/Generator

Clock Accuracy: 1.54 PPM (1 frame out in 6 hours)

Isn't that up to Lockit standards?

Link to comment
Share on other sites

Yes puzzling the Zaxcom website says -

Timcode Reader/Generator

Clock Accuracy: 1.54 PPM (1 frame out in 6 hours)

Isn't that up to Lockit standards?

as sayed by others - there might be TC jumps created by the Fusion being powered on / off. I just don´t like the idea being a test driver for a potential yes/no TC drift. Better safe than sorry.

Link to comment
Share on other sites

as sayed by others - there might be TC jumps created by the Fusion being powered on / off. I just don´t like the idea being a test driver for a potential yes/no TC drift. Better safe than sorry.

As I mentioned earlier, the time code jump caused by a power cycle was addressed as of firmware v.7.54. However, I still observe a tenth or two jump for each cycle. So, if you do one or two power cycles, it's not a big deal. If you do many, that's a different story, as I've found the jumps to be cumulative.

Link to comment
Share on other sites

Hi Brynn

sorry to hear of your problems - and sorry to read one or two patronising, supercilious and unhelpful replies.

I used the same method for years on my old Deva 4 and had almost zero trouble - even when our paths crossed on the same shows. - i.e. set TC on DEVA and then o/p that to an Ambient Lockit box which now becomes the 'MASTER TC DEVICE'. From this Master TC Device, jam as many Lockit 'clones' as needed and stick one onto each camera and, yes, the DEVA itself.

Set the Deva to ext code/cont jam and plug in a Lockit. During your pre-shoot tests, use the 'mirror offset' feature to dial in as many Ms offset as required to keep editor happy.

So this leads me to ask

1) is it a camera problem?......... Is it one particular camera that drifts?- maybe the Deva is fine and one of the camera TC boards is 'ill'?

2) Is it a Lockit problem?........try hiring in a new batch for a few days ? If all works well, try feeding your units back in one by one try and weed out the 'rouge' unit that may be playing up...

my tuppence worth

S

Link to comment
Share on other sites

Clock Accuracy: 1.54 PPM (1 frame out in 6 hours)

Isn't that up to Lockit standards?

I think 1 frame per 6 hours is exactly what we often saw in dailies over the past 20 years. I can't believe anybody would complain about a 1-frame slip in 6 hours. I've probably worked on 10,000 hours of dailies that slipped worse than that, and I just fixed it. It's not a big deal. The FLX/ALE edit list (metadata for the dailies session) always reflected the truth.

this thread reminds me: Workflow test.

Very true. 113.gif

I'm sorely tempted to name the project, but I know of a fairly huge 3D horror movie made a couple of years ago that was a total trainwreck in post because they used multicam but did not use external genlock and external timecode. I'm guessing this added $100,000 of fixes in post and another 2 weeks to the schedule because of this problem. Renting or buying another timecode box for 6 weeks would've cost them maybe $1000 (literally). It's sad when these things happen, because if they had just asked post before they went into production, or if they had just done a workflow test, we would've immediately saw the problem and stopped it from happening.

Link to comment
Share on other sites

It could be that errors you are seeing could not be “Drift” at all. Especially if the offsets seem to vary randomly a few frames from day to day or throughout the day. The offsets could be caused by algorithmic errors in the firmware or software used anywhere in the production chain.

Because timecode in all file based media is actually calculated using an algorithm and time-stamp metadata and file constants like sample-rate and Bit Depth etc. errors can accumulate If there is an error in the algorithm used to calculate Time Code at any point in the workflow it can seem like Drift but in reality it is just a math error. Some times it can be so small that it is caused by floating point errors in some CPU microcode or rounding errors. These errors will show up even if all the clocks are very accurate and all running in dead sync. Algorithmic errors are more prevalent in non-integer timecode rates like 23.976 and 29.97

I developed a method to test for algorithmic error and you could use the following test to see if the “Drift” you are seeing is math based and not based on Drift or clock timebase accuracy.

Test is pretty simple.

1. Assemble all the devices that will be used in your workflow. Cameras, Sound Recorders, TC Slate, Lockits, And Editorial software and any conversion software used in the chain.

2. Set your Timecode master clock to 00:00:00:00 and start it running. Then quickly Jam all other devices that have their own TC clocks. Shoot a series of 4 or 5 short takes (20 Seconds is long enough) Hitting the sticks on the TC slate and recording the sound on the recorder for a visual reference of hard sync.

3. Set your Timecode Master clock to 23:00:00:00 and start it running, Re-Jam everything to the new time code and shoot a new series of 4 or 5 takes. Make sure you get the test shot before the clock rolls over past midnight.

4. Take all the takes and run them through your normal workflow that ends in the Editing software that you are using to determine sync. Sync up the takes from Step 2 and Step 3 noting any offsets between the audible sync and the Camera/Sound TC frame sync.

If you notice different offsets between the step 2 and Step 3 takes then there is probably an algorithmic error somewhere in the chain. To determine which device is at fault you then have a lot more work to do.

You have to eliminate each link in the chain by substituting a different device from a different manufacturer and repeat the test. When the difference in offsets disappear you have found the device with the firmware or software that has the algorithm error. Unfortunately if more than one device has algorithm errors they can offset each other or be cumulative depending on where the error occurs. Good Luck!

Link to comment
Share on other sites

I had the same problem of 1 to 2 frames of TC 'jitter' as post described it. A deva5.8. I then started using my 744t as the master and jammed all my clockits from it as well as running continuous jam on the deva. I actually bought a second deva and now feed both of them from the 744. I had a splitter made with one xlr TC out and two lemo TC outs. I have 3 ambient clockits boxes and 2 ts3 slates and jam everything using the 744 as the master. Works flawlessly.

Link to comment
Share on other sites

Hello all just a quick update. Did a test this morning with the deva in free run wih the alexas jammed from the deva. Three minute test with three boards. First board everything in sync. Second board everything in sync. Third board camera in sync deva off by one frame??????

Just to remind you all we are running at 23.976

Link to comment
Share on other sites

It could be that errors you are seeing could not be “Drift” at all. Especially if the offsets seem to vary randomly a few frames from day to day or throughout the day. The offsets could be caused by algorithmic errors in the firmware or software used anywhere in the production chain.

Because timecode in all file based media is actually calculated using an algorithm and time-stamp metadata and file constants like sample-rate and Bit Depth etc. errors can accumulate If there is an error in the algorithm used to calculate Time Code at any point in the workflow it can seem like Drift but in reality it is just a math error. Some times it can be so small that it is caused by floating point errors in some CPU microcode or rounding errors. These errors will show up even if all the clocks are very accurate and all running in dead sync. Algorithmic errors are more prevalent in non-integer timecode rates like 23.976 and 29.97

I developed a method to test for algorithmic error and you could use the following test to see if the “Drift” you are seeing is math based and not based on Drift or clock timebase accuracy.

Test is pretty simple.

1. Assemble all the devices that will be used in your workflow. Cameras, Sound Recorders, TC Slate, Lockits, And Editorial software and any conversion software used in the chain.

2. Set your Timecode master clock to 00:00:00:00 and start it running. Then quickly Jam all other devices that have their own TC clocks. Shoot a series of 4 or 5 short takes (20 Seconds is long enough) Hitting the sticks on the TC slate and recording the sound on the recorder for a visual reference of hard sync.

3. Set your Timecode Master clock to 23:00:00:00 and start it running, Re-Jam everything to the new time code and shoot a new series of 4 or 5 takes. Make sure you get the test shot before the clock rolls over past midnight.

4. Take all the takes and run them through your normal workflow that ends in the Editing software that you are using to determine sync. Sync up the takes from Step 2 and Step 3 noting any offsets between the audible sync and the Camera/Sound TC frame sync.

If you notice different offsets between the step 2 and Step 3 takes then there is probably an algorithmic error somewhere in the chain. To determine which device is at fault you then have a lot more work to do.

You have to eliminate each link in the chain by substituting a different device from a different manufacturer and repeat the test. When the difference in offsets disappear you have found the device with the firmware or software that has the algorithm error. Unfortunately if more than one device has algorithm errors they can offset each other or be cumulative depending on where the error occurs. Good Luck!

Ah jeez, now I have HOMEWORK! Thanks for this, in my bonehead way I had always suspected that "something else" was going on re sync.

phil p

Link to comment
Share on other sites

Hello all just a quick update. Did a test this morning with the deva in free run wih the alexas jammed from the deva. Three minute test with three boards. First board everything in sync. Second board everything in sync. Third board camera in sync deva off by one frame? ?????

Just to remind you all we are running at 23.976

On this test, the cameras were NOT on Lockits (on internal TC and sync), and the Deva was on its own clock? I understand you are trying to shoot a movie there, but a longer test (10+ min) might be more revealing...

phil p

Link to comment
Share on other sites

I'm not saying this is the case for you, but it is not always errors or technical issues on our side. On a recent show, we had 3 Alexas with sbt boxes on board jammed from a gr2 which also fed timecode to the recorder at 23.987. Continually we would be told of timecode issues off by as much as 8 frames and varying from take to take. No consistent offsets and after manually syncing by slate, there was no drift. After much hair pulling, an assistant editor casually mentioned that sound timecode was set to 30p. I asked for them to re-sync some takes with sound ingested at 23.98. Surprisingly there were no further issues or emails after that...

Link to comment
Share on other sites

I am not saying this is the case for you (also) but I am always suspect when a tried and true proven procedure that I have used on many, many jobs, is suddenly problematic on a job. I am not suggesting that we never question OUR methods, procedures or equipment when a problem shows up, I am just suggesting that we should use common sense and past experience to troubleshoot the problem. When I am using equipment and procedures that I have used for years without incident, I tend to not question my gear or setup first, but rather to look at some other factor in the chain of events that has resulted in a problem.

Link to comment
Share on other sites

This discussion brings to mind:

Many, many moons ago when I worked in radio, we often did remote broadcasts. These used landlines which were furnished by the phone company.

The typical scenario was this:

--RING--

PHONE COMPANY: Hello.

RADIO STATION: Hi. Uh, the feed for the broadcast isn't coming through. We go live in an hour.

PHONE COMPANY: Nothing?

RADIO STATION: Nope.

PHONE COMPANY: Well, everything's okay here. Check your patch bay and all your routing there at the station. That's likely the problem.

(We hang up and check the patch bay, console, and all the station's routing.)

--RING--

PHONE COMPANY: Hello.

RADIO STATION: Hello. Uh, we still don't have a feed.

PHONE COMPANY: There's gotta be something at your end. Check everything again.

(We hang up and check the patch bay, console, and all the station's routing again.)

--RING--

PHONE COMPANY: Hello.

RADIO STATION: Hello, again. Still nothing.

PHONE COMPANY: Well, we're sending you good tone, so it's gotta be you.

(We hang up, pull our hair out, try to find something... anything!. In our brains we begin computing how much advertising revenue we'll lose if this remote doesn't happen.)

--RING--

PHONE COMPANY: Hello.

RADIO STATION: Hello. We still don't have anything.

PHONE COMPANY: Well, let me get back to you.

(We hang up. About twenty minutes later the feed would go live.)

So, it didn't take too many of these for me to adjust my end of the proceedings. Over the following couple of years we had many conversations that went just like this:

--RING--

PHONE COMPANY: Hello.

RADIO STATION: Hi. Uh, the feed for the broadcast isn't coming through.

PHONE COMPANY: Nothing?

RADIO STATION: Nope.

PHONE COMPANY: Well, everything's okay here. Check your patch bay and all your routing there at the station. That's probably where the problem is.

RADIO STATION: We did. We already checked them again.

PHONE COMPANY: Well, we're sending good tone here so the problem's gotta be at your end. Check everything again.

RADIO STATION: Oh, we did. Thoroughly. We triple-checked everything.

PHONE COMPANY: We're good, so there's gotta be something at your end.

RADIO STATION: Even after the triple check, we traced, checked, and replugged everything, just to make sure.

(Slight pause...)

PHONE COMPANY: Well, let me get back to you.

(We hang up. About twenty minutes later the feed would go live.)

Link to comment
Share on other sites

Deva software version 7.55 fixes a problem with timecode jumping around by a frame or two randomly when using certain combinations of frames rates and sample rates. I believe 23.98 at 48khz was the main culprit.

The timecode coming out of the Deva was fine, but the timecode stamps on the WAV files were off by +/- one frame randomly.

According to my tests the timecode should be accurate to a small fraction of a frame now, but this type of timecode error is difficult to test so it is not out of the realm of possibility that there is still some error left in there that my tests did not show up.

It seems that no one noticed this bug since only recently did people start using this combination of frame rate and sample rate (about a year ago maybe).

A similar 7 year old bug showed up recently in all of our wireless timecode software. No one used 30 Drop Frame timecode mode so no one noticed that this mode would not be remembered after a power cycle. The TRX, QRX-IFB Option and ERX software have all recently been updated to fix this.

-howy

Link to comment
Share on other sites

Deva software version 7.55 fixes a problem with timecode jumping around by a frame or two randomly when using certain combinations of frames rates and sample rates. I believe 23.98 at 48khz was the main culprit.

The timecode coming out of the Deva was fine, but the timecode stamps on the WAV files were off by +/- one frame randomly.

According to my tests the timecode should be accurate to a small fraction of a frame now, but this type of timecode error is difficult to test so it is not out of the realm of possibility that there is still some error left in there that my tests did not show up.

It seems that no one noticed this bug since only recently did people start using this combination of frame rate and sample rate (about a year ago maybe).

A similar 7 year old bug showed up recently in all of our wireless timecode software. No one used 30 Drop Frame timecode mode so no one noticed that this mode would not be remembered after a power cycle. The TRX, QRX-IFB Option and ERX software have all recently been updated to fix this.

-howy

I'm glad the Deva TC is all good but we've actually been using 23.98 @ 48k a whole lot for much longer than a year......

phil p

Link to comment
Share on other sites

Does this sound familiar. Found it on an old post

" Very timely topic. I'm on a shoot now with two Alexa's. I jam from my Deva to two Deneke's SB2A's and to two TS 3's. The cameras indicate they are in sync and the on set DMT says they look like they hold TC with the slates.

The problem is when it gets to post for transfer they say we have a 2-3 frame offset. They also say the cameras and slates are in sync but sound is not. It's not a consistant offset or they could deal with it. It varies from 2-3 or sometimes just 1. I am using a Deva V running version 7.46 at 23.98 48K.

Any thoughts? I thought I would go back a couple of versio s on the Deva and see if that would help because it's not the first time I've done 23.98. But when Zaxcom took over the user group they don't seem to post the older software versions anymore.

Thanks.

Link to comment
Share on other sites

This seems to be happening more than we think

Sorry it took me so long to get back to you. I was surprised when the rental house sent out the older SB-2A's but thats what we got. I am still getting a 2-3 frame offset but the wierd thing is it's not consistent. It can be early or late. I was fortunate to have Glenn Sanders come to set and we decided after talking to Howy that we would try a factory reset. That didn't help. I am going back to version 7.36 my last working version. I will let you know on Tuesday how Monday's transfers go. If that does not work I'm affraid I will have to try another Deva to see if I'm having trouble with mine. I cant see why I would I just finished a series in late January and had no issues. That was at 30FPS and on 35mm but TC is TC and changing frame rates should not matter.

And John we have followed the jamming instuctions to a "T". Post says they have seen this with Deva's more than other machines. Have you heard of any body else having a problem with 7.46 ?

My post also seem to think Devas tend to do this more than any other machine. Have I really purchased a product that will not adhere to modern day shooting practices. Am I going to have to switch machines with someone to prove it. Will sending the recorder back to the shop sort it or has updating the software optimised my options.

Link to comment
Share on other sites

This guy swapped machines with a friend to prove it:

Well after two weeks of shooting I think Post and I agree with the Senator "CRAP happens :("

I followed the jamming instructions as described and even left the Denecke"s plugged into the Alexa"s. Same result. After having Glenn on set I contacted Howy and we went back to my last known working software. 7.36 from 7.46 with a factory reset. Same result. I then borrowed a friends V for a day with 7.46 to see if it was my machine having the error. It was marginally better with a 1-2 frame offset but not frame accurate. So I thought I could go into the menu setting and try using the offset function in the TC but because it's not a consistent offset post said not to bother. The dailies are getting done and I have gotten the night transfer guy to stop putting it on the lab report if it's not problem and to stop sending up red flags to those that have no idea what it really means other than to say "We're not in sync". Has any one else using a Deva had this issue? Transfer says they see this more with Zaxcom then other products?

Looks like swapping devas is not goin to sort it. But I will try and let you know how I get on

Link to comment
Share on other sites

And John we have followed the jamming instuctions to a "T". Post says they have seen this with Deva's more than other machines.

That is such bullshit. At Complete Post and Technicolor in LA, we'd usually relax if we saw on the sound report that it was recorded on a Deva!

Timecode drifts a frame or two all the time, and it's not the end of the world. They just have to jog it and move to the next scene. My guess is this also happened on your film project, and the dailies operator -- correctly -- just fixed it and moved on, which is his or her job.

I still say that SB-T's (or Ambients) on all cameras 100% of the time, providing external genlock and external timecode, will solve the problem, provided they're jammed from the Deva every few hours, and the Deva is not turned off.

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.

 Share


×
×
  • Create New...