Im recording on tape and the nanoFlash at the same time on a Panasonic HDX900 in 1080I

The nanoFlash is set in .MXF file, HD SDI timecode embeded triggered record 35Mbps Long GOP.

There is a time code mismatch between the tape and the nanoFlash.
Is there a way to fix this ?

Thank you

Dear Francis,

Could you tell us a little more about the problem.

Is the time code off a fixed amount, such as a frame or two?

When i do some record/pause there is missing frames between each clips

here is the time code of the 6 clips as seen on FCP


10:00:01;22--10:00:17;21
10:00:17;00--10:00:26;29
10:00:31;29--10:00:37;13
10:00:41;16--10:00:47;15
10:00:47;22--10:00:57;21
10:00:57;14--10:01:06;00


there is no missing on the tape between each clips

Dear Francis,

We will test this at our office to determine if we can duplicate what you are seeing.

Dear Francis,

We have been discussing your timecode lapses.

Since you are running tape at the same time, we wonder if the following is happening:

1. You record something on tape.

2. You stop.

3. You roll again.

At this point, we wonder if you camera repositions the tape, to line up the tape to start immediately after the last take.

In doing so, it may roll timecode (and it may roll backwards, as the tape is backed up slightly to reposition the tape.)

If it does roll timecode, backwards or forwards, we interpret this as a signal to start recording.

The above is just a theory at this time.

We know of other cameras that unload the heads after a pause/stop in recording, then must reposition the tape, and while this is happening, the timecode does roll.

Hi Francis and Dan,
I don't know if with the tapes is different than when recording in the NANO and in the SxS as the same time.
In this case, the camera and the NANO start and stop recording at different moments (SxS start few frames earlier and finish few frames earlier), but the TC is the same frame by frame.
Cheers,
rafael

Dear Rafael,

Thank you for your confirmation that the timecodes on each frame are identical, in your testing.

Hi there

thanks for the fast answer
It gave me some tips to what to look at, I really appreciate :-)


I've run some othere test this morning


I did a time code burning recording with the NanoFlash.

The NanoFlash is most of the time late next to the burned in time code.

The tape is dead on with the burn in time code.


thanks

If you have the pre record buffer "on" the timecodes will not match as the timecode is captured directly from the SDi Stream while the video is delayed by 4 seconds in the buffer. As a result there is a 4 second difference between the camera timecode and the NanoFlash timecode.

In addition the NanoFlash needs to see timecode incrementing before it will go into record, so there is a delay of a few frames at the start and end of each recording if you are using timecode to trigger. This can result in some small gaps or in some cases some overlaps.

Dear Francis,

We will be testing this.

Does you camera, the HDX900 allow you to burn in the timecode?

Or did you record an image of a timecode slate?


We are surprised by the timecode being off as we just completed extensive testing of the timecode portion of our firmware. But, of course, we can not test with every camera.

Hi,

Yes as Alister mentioned, the timecode is off when pre-record buffer (System->Pre-Buffer) is used. This is a bug in the software right now.
Otherwise, with a window burn of the timecode, our starting timecode should exactly the window burn or maybe sometimes be off by a single frame, when the timecode is viewed in Final Cut Pro.
Is this not the case?

Tommy

Hi

Im not using the pre-record buffer.

I record from a Panasonic HDX900 1920x1080 60i
drop frame in both the HDX and the NanoFlash.
Tested in Record run.

Hi Francis,
You are not using the NANO buffer, but you may have activated the one in the camera (Pre-recording function). That one could hold 7 seconds picture.
rafael

hi There

I just got another unit
Probaly the other one was defective i dont know we'll see.

I'll keep you informed

The HDX900 does allow characters to be inserted in the SDI stream. So, one could record with characters "on" and play back to see if time code displayed on the nano agrees with time code in the burned window. This is something I will check when I can, since I don't have an editing system with which to make side-by-side comparisons.

In fact, one has to be careful not to end up with characters on nano files accidentally. I find it best to use the "Monitor Out" (on the side of the camera) instead of the "Video Out" on the back of the camera. The Monitor Out is more difficult to change (requires a visit to the menu), but the Video Out characters can be added with the flip of a switch... very dangerous. Also, the Video Out can be changed from HD-SDI to SD-SDI (or even composite) very easily if the wrong switch is moved.

Exactly i use too the monitor out on the side of the camera for the time code burn in.

I did some further test with a new unit, same problem.

What the editing guy wanna do with it is doin a pre editing with the footage recorded on the Nano flash and after, relink the in/out with the tape. Of course to be able to do such both time code tape and nano must be the same. im no editing specialist thats about the way i understand it.

I did a recording test again, this time i did a record of a scriplink the have an accurate visual reference. the time code displayed by the scriplink come from the HDX900 itself.

I did a log and transfer into FCP from the firewire output of the HDX900.
and imported the QT clips from the Nano to FCP.

The timecode displayed from the tape differ next to the QT clips from the Nano.

The pre record fonction in the HDX is switched off. so the problem doesnt come from there.


ill try to persuade my client to record only with the NanoFlash and forget about the tape.
Maybe the Nano wasnt meant to be use with the tape time code as reference.

By curiousity ill perform hte same test with a Focus Enhancements FS-100 to see if the same problem occure

Thanks for your support :-)

Francis,

It is a little distressing to hear of this issue. I haven't had to deal with that yet, but I'll investigate it to see if I have the same problem. Thanks for the heads-up!