Jump to content

Random timecode offsets


Herwig

Recommended Posts

I'm experiencing strange time code offsets on my present show. Deva V, v. 7.56, 24 fps, 48048, mirror f-mode with pulldown to CF card, 2x Alexa's at 24fps, syncing in Avid v. 5.5.3. Test shoot in preproduction showed no problem, but since starting both cameras and slates are reported to be in sync, audio tc reported off randomly, sometimes 1 second, sometimes 2, and other times accurate. Zaxcom suggested removing pulldown switch which didn't help; I also tried feeding Deva tc from ext sync box which also didn't help. More recently report has been random offsets of 1-12 frames. Any ideas as to what's up?

Herwig

Link to comment
Share on other sites

Wow, one second off is a big deal. A frame sometimes happens, but a whole second is not right. 

 

My only thought is to go with TC boxes on both cameras and possibly a third external master TC box for the Deva, and rejam all every 4-5 hours. 

 

I'd be curious to know if the TC slate consistently agrees with the Deva or consistently agrees with the camera. My bet is that it agrees with the Deva, and one of the cameras is buggy. I would also go with ext. genlock for a multi-camera shoot to avoid "rollover" timecode issues.

Link to comment
Share on other sites

No, cameras are not changing speeds.

Also, the reports say cameras and slates are consistently in sync, so not sure of the benefit of putting sync boxes on the cameras. But thanks for the suggestions.

The benefit would be that they would be in sync to the sound as well to each other.  

 

There was a long thread not long ago about this kind of thing w/ a DEVA, and the OP ended up not solving the issue and changing recorders (I think).  My memory was that for some reason he would not got to a Lock/Buddy-all-around setup, so we never found out what the deal was (?)

 

philp

Link to comment
Share on other sites

Also, the reports say cameras and slates are consistently in sync, so not sure of the benefit of putting sync boxes on the cameras. But thanks for the suggestions.

 

So out of timecode slates, two cameras, and the Deva, only the Deva is slipping? That's a big clue. If that's the case, then I'd get one external timecode box, jam everything off that at the beginning of the day, and run the Deva in external.

Link to comment
Share on other sites

" The benefit would be that they would be in sync to the sound as well to each other "

but

" out of timecode slates, two cameras, and the Deva, only the Deva is slipping? That's a big clue. If that's the case, then I'd get one external timecode box, jam everything off that at the beginning of the day, and run the Deva in external. "

it does read to me that the DEVA TC is the odd one out!

that could be the case...

that could happen...

Link to comment
Share on other sites

" out of timecode slates, two cameras, and the Deva, only the Deva is slipping? That's a big clue. If that's the case, then I'd get one external timecode box, jam everything off that at the beginning of the day, and run the Deva in external. "

it does read to me that the DEVA TC is the odd one out!

that could be the case...

that could happen..."

When I used an external sync box on the Deva it made no improvement. I think my next step will be to try a different recorder.

Link to comment
Share on other sites

Well I don't know where the problem is in your case but I would question the Workflow.  You are just asking for trouble using the 24.00 frame rate in cameras that are normally run at 23.976.   This complicated  by the non standard sample rate of 48048 makes things worse.

 

The chances for math errors to happen in pull down/pull up operations is very great here.  All it takes is one link in the chain set to the wrong sample rate or frame rate to throw a monkey wrench in the whole mess. 

 

The 24.00 and 4808 combo made sense (as much as it could) when shooting on Film and doing Telecine Transfers to 29.97 video.from linear (non file based) media..This method was developed to fool the machines into slowing down their electronicly controlled motors to stay in sync since there was no metadata stored in DAT or 1/4' tape that told the machines what speed the original was recorded at.   When we went to file based recorders, we had to create a "F" or fake mode that recorded at a pulled up sample rate but marked the metadata with a normal sample rate so the telecine controlers would automatically pull down the files.  However without Telecine, none of this is necessary

 

.  When using a file based Recorder and file based Alexa and a Modern version of AVID (also file based)  there is no reason to do any of the girations necessary for shooting at speeds requireing pull-down and pull up.  Speed changes in file based media are simulated by changing the math used in calculating the playback sample rate and the time code is calculated based on that sample rate so the opportunity for error is great. 

 

A better workflow would have been to shoot everyting at 23.976 and 48k.  Set the Avid project to the same frame rate and if the project is going to FILM OUT  (which is becoming rare these days) they can do the pull up of everthing  to 24.00 in the prep of the stems for mastering the release formats. 

 

-----Courtney

Link to comment
Share on other sites

I would agree with Courtney. Are you sure the cameras are running at 24fps and not 23.98? I have not worked on a project with the Alexa's running at 24fps. Is picture being pulled down to 23.98 in transfer?

 

Does the off set vary do to the length of the take?

 

Also there could be a issue in the Avid's settings or how the files are being imported or pulled down a second time.

 

 

Whit 

Link to comment
Share on other sites

Doh, I missed the 24fps part! Are they really shooting at 24.00fps in camera? If so, then I would expect 24.00TC across the board, and then pull everything down in import (which can be done, but requires tests and people aware of the situation). I agree with Courtney: 23.98 (aka 23.976) is far easier and has less potential for error, in my opinion. 

Link to comment
Share on other sites

I would agree with Courtney. Are you sure the cameras are running at 24fps and not 23.98? I have not worked on a project with the Alexa's running at 24fps. Is picture being pulled down to 23.98 in transfer?

 

Does the off set vary do to the length of the take?

 

Also there could be a issue in the Avid's settings or how the files are being imported or pulled down a second time.

 

 

Whit 

 

Yes, cameras are definitely at 24.000 fps. They are pulling down to 23.98 for editing. I don’t think the length of the takes is showing a trend since they say the time code is randomly off, or even on at times, but I will check on that.

 

Most of my jobs in the last year and a half have been with Alexas at 24fps. These include a series, a feature, and second unit on 2 other series, and all used this same workflow of cameras and sound at 24fps, sample 48048 f-mode with pulldown, and these all went through Technicolor in Toronto. Another feature was shot at 24fps, 48kHz, no pulldown and edited at 24fps, and post was done in Spain.

 

The only things that I can tell are different on this job are that I upgraded the Deva firmware from 7.41 to 7.56 before the shoot began, and that Technicolor is not involved, although the synching is being done by the same techs who were on the last series.

 

On that last series there was an occasion when I got reports of weird time code offsets after returning from hiatus. It was eventually determined that the Avid had got a firmware upgrade from 5.5 to 6.5 during the break and was handling the 24 fps audio differently, and that got sorted out in a couple of days. A few years ago when I had similar reports of random time code offsets I switched recorders and the problem went away. It turned out that the Deva had issues and eventually got a new DSP board.

 

I will have further discussions with post, and will try Rich's suggestion of eliminating f-mode. I am still planning to try a different recorder later this week to see if makes a difference.

 

Herwig

Link to comment
Share on other sites

Herwig,

 

The "F" mode just stamps files that are recorded at 48.048 to 48. It only changes the stamp not any sample rate or timecode. Which could cause issues in the Avid on how the files are being read or treated. Since your timecode seems to vary so much I would not think that is the issue, but it will eliminate one variable.

 

Also have you considered going back to 7.41 on the Deva software? 

 

The workflow I have been using with the Alexa has always been 23.98 so no pull down has to be done the project remains in 23.98 HD world. I sure there are reasons for shooting 24 and pulling down to 23.98 but I not aware of what the advantage would be. 

 

Whit

Link to comment
Share on other sites

Yes Whit, I plan on going back to 7.41 to see if there is a change; I still seperately plan on swapping out the Deva as well.

To explore more I took about 20 mirrored files from the CF card and played them in Wave Agent and made note of the time codes as best I could at the slate clap. I then compared these to the code on the Deva display at the clap when playing off its hard drive. It's rudimentary yet I noticed that the code from the mirrored files was consistently ahead of the original by approximately 4 to 8 frames. Same results when mirrored without both F mode and pull down. If F mode only engaged mirrored tc was significantly ahead (55 secs in one take) and if pulldown only engage then mirrored code was significantly behind (30 seconds in one take).

Herwig

Link to comment
Share on other sites

  • 2 weeks later...

Okay, as I had planned I tried another Deva for a couple of days, this on version 7.47, but there was no improvement in the random offset. When I went back to my recorder I returned for a couple of days to the version that I used to run before this particular show (7.41)  and that too made no improvement.

 

I spoke to the manager of media services at Technicolor here who said that the issue I described is a known issue with Devas at 24fps, 48048-F. He reported it was common for there to be random offsets of 0-6 frames plus or minus. He's found that a SD788 running simultaneously would be dead on. As I mentioned earlier in the thread Technicolor was not involved with my current project but has handled my material many times in the past. 

 

My show is now finished. Post was perplexed by the issue but not overly concerned. They synched to the slate clap. I let Zaxcom know about the issue early on in the show. I will follow up with them to see if it is being addressed.

 

Herwig

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...