Hi Guys,

Since you where all champs with helping me with my last issues I beseech your collective help once again.

I need to know if the timecode imbedded in the Nanoflash HD-SDI signal out slips for any of you? The way our post house works is it records the footage onto tape from the Nanoflash HD-SDI signal out, but it is having problems with the timecode slipping more than we already knew of (2 frames). We are using Firmware: 1.6.29 as it is the last update that doesn't have timecode delay issues when playing back.

Now please don't ask why Post don't edit the files from the cards straight onto the AVID, I've explained it in my other post, I just need to see if someone knows how to overcome this issue or if maybe a future update to the firmware will be more reliable with the Timecode syncing issues we are experiencing currently in our show.

Cheers Chris

P.S I'll get back to your replies its just I do all my posts at work during scene block throughs so sometimes I'm a little slow in replying.

Hello Chris,

Could we have some more information about your setup, so that we can answer your question better?

What camera are you using? Sony EX3 etc

What Format are you recording? 1080p24

What Bit rate are your using? 100Mb I-Frame

Also I assume that you are using embedded Time Code from your post, also are you using MXF, I would assume so since your post is avid, but it is always good to double check.

As for Time code we should be within 1 Frame more specifically 1/4 of a frame for the record, or are you referring to playback or your files?

Best Regards

If they are capturing baseband from the Nano (or tape) via HD-SDI this is how I understand Avid works with timecode:

It grabs the TC at the start of digitising and then adds a frame for each frame passed.

So there is plenty of potential for TC errors... as has been experienced by offline/online workflows for years and requires an 'eyematch' check of offline against online.

Don't know if that is what is occurring here, but I wouldn't lay the blame on the Nano straight away.

Trevor

Chris,

Some additional questions that would be useful to diagnose your problem:

1- How long are your takes?

2- Is the original timecode source generated internally within the camera?

3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras?

4 - If a multi-camera shoot, are the cameras gen-locked together?

5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take?

6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift.

Hopefully there would then be enough info (combined with the requests from Andy) to be able to analyze the problem.

Best,
Dave S

Offline Timecode Drift | Edit Geek (http://dylanreeve.com/videotv/avid/2005/offline-timecode-drift.html)

might also help you diagnose

Deart Tevor,

Thank you for the link!

Hey guys,

Thanks for all the replies, sorry about the late reply, but its been a busy week at work.

Okay I'll answer all the questions here I go;

Andy:

What camera are you using?: We are using 2 Sony F23's

What Format are you recording? 1080p 24f

What Bit rate are your using? 280M I-Frame

Yes we are using embedded T/C, and we are using MXF files to record to, and yes post is AVID.

And i'm referring to the playback of the system, I've ust asked Bruce (DOP) he told me that post weren't sure if it was their decks or our Nanoflash problem, because when they changed the tape deck, thats when it seems to have timecode issues. But the DP asked me to ask you guys if you knew of any situation were the T/C embedded in the metadata of the clip could slip?

Hi Dave

1- How long are your takes?:
Our takes differ, like as we speak we are shooting a 2:47 scene with 3 chars, and we sometimes shoot .10 sec scenes.

2- Is the original timecode source generated internally within the camera?:
No we use an external Timecode lock it box.

3- Or is this a multi-camera shoot with the timecode generated by a separate time code generator?, or timecode generated by one camera and fed to other cameras?:
This is a two camera drama with timecode generated by a separate timecode jammer.

5 - Exactly what do you mean by 'slipping' and how do you determine it? ie - are several cameras not maintaining exact relative time code? / is the timecode recorded internally in the camera different than the timecode recorded in the NanoFlash? / Is this some sort of timecode 'offset' that remains constant over the length of a take, or does the amount of offset drift over the course of the take?:
Sorry by Slipping I mean that the timecode is not stable and seems to be running out of sync overtime, thus been different from the sound t/c source. I'll have to find out more on this issue, as post are not sure what the exact problem or how the slipping is occurring, but all of our timecode boxes are syncing correctly.

6 - Have you tried doing a simple timecode record test? -- output the camera 'viewfinder with timecode' to a monitor and record both internally in the camera and externally to a nanoflash simultaneously (Ideally the Nanoflash should be in the shot as well so you can see the screen on the Nano right next to the tc numbers on the monitor.) Then you can compare what has been recorded with what you see on screen. 15 or so minutes should suffice, though make sure that you do a sync slate clap in the beginning, middle (every couple of minutes) and end of the take. Sync up the two recordings on the timeline and let us know about any offsets or drift.:
No we haven't done that test, I'll bring it up with my DP and let you know. The problem with recording internally, well to speak the Sony F23's do not have an internal system to record to (they are modelled after the Panasonic Genesis body), and we do not have any of the recording toasters on set with us so this might be hard.

Hope this helps.

Cheers Chris.

i'm referring to the playback of the system, I've ust asked Bruce (DOP) he told me that post weren't sure if it was their decks or our Nanoflash problem, because when they changed the tape deck, thats when it seems to have timecode issues.

and
The problem with recording internally, well to speak the Sony F23's do not have an internal system to record to


So how are they getting the images onto tape? Are you not recording to tape and Nano simultaneously?

Or are they recording to Nano then doing a baseband transfer to tape then ingest to Avid? (which would be a very convoluted workflow, which could very likely result in tc slippage against sep sound).

From your answer it sounds as if they either swapped a tape deck out for playback into avid purposes, or swapped it out for recording purposes - and either way the problem didn't exist before the swap-out. That would lead me to check the settings on the swapped out VTR.


For your verification test could you record to the Nano with the Lok-it TC display and the nano screen with TC arranged in one shot? Then do some stop start recordings and check that all the timecodes (2 in shot and one on file) match at the start and ends. (Or just use a digi-slate)

Wouldn't nail down the sep sound problem but should confirm that recorded video timecode is consistent with Lok-it at the Nano level.


FYI: Avid can 'read audio timecode' so if you can get the timecode as an audio signal onto one of the audio tracks of the nano then you can set that as an aux timecode track in the Avid for comparison with the genuine tc track. This can highlight any tc skipped frames that Avid might have missed.


Hope you get it sorted... do report back.

Hi Chris,

Hadn't realized until your last post that you were working with F23.
By the way, are you recording simultaneously to HDcamSR decks, or is the NanoFlash being used for the master record?
I don't tend to be on F23 shoots very often, so I'll just throw out a couple of WAGs based on my old 'days in film'.

First, I'm going on the assumption that with an F23 setup you are indeed genlocking the cameras.

As I recall the F23 gives you options to shoot 23.98 or 24. When shooting in 'true 24' you start dealing with a bunch of tech issues that you may not deal with in 23.98, since most video gear is based around using 23.98 as a standard rather than true 24. Even the NanoFlash manual mentions potential problems with NLE support if shooting true 24.

So my best guess is that, since your takes are relatively short, and when the problem occurs its drift seems to increase over time, and a very slight drift would often not be noticed over the course of a short take (so I would term the drift major), i'm guessing that somewhere in the system something is interpreting 24 as 23.98 or vice-versa. If it's a specific deck, It could have to do with the internal settings on that deck. It could also be an NLE problem.

If the above is the case, then when the problem occurs, the drift in numbers should take place at a constant rate. (ie, the drift at 12 minutes into a take would be twice the drift at 6 minutes in.)

(My film reference refers to the fact that when we first converted our Aaton cameras to shoot 30fps for direct transfer to video, we were always scratching our heads in terms of the reference rate for the DAT audio to keep it in sync, and the post house had to be on the same page as the sound recordist or everything would drift.

Best of luck with it. I know these gremlins can be hard to track down!