Jump to content

timecode jumps over rf


trombles

Recommended Posts

there have been a number of useful discussions here concerning wireless transmission of timecode, but i've not been able to find an answer to the following question … what are the consequences in post production of time of day timecode that has a timecode "jump" in the clip?

case in point: in my quest to make life a little easier for my hard-working associates in the camera department, i have in the past considered ways of using the camera hop as a timecode device, and eliminate the bulk of the sb3 box. the lectro d4, for example, could be used as a stereo hop, with the third channel being used for tc. i've tested it, and it seems pretty solid, but when I begin messing with the d4 transmitter - powering down, removing the antennas to cause noise and dropouts - the camera (fs7 with the module) doesn't cut, but it does show a three frame glitch in the timecode before switching over to its internal generator. 

another thing i wonder about is the presumed "correction" that would occur when using an erx as a timecode source. if the camera wanders away from the zaxnet source, then wanders back a while later, discontinuous timecode, however slight, will inevitably result. if the camera is rolling when this correction takes place, how much of a problem is this for post production? 

 

Link to comment
Share on other sites

You seem to have a bit to learn about time code and how it's implemented in digital cameras. 

Sending time code via an audio channel can work okay as long as cross-talk isn't an issue.  Time code is basically a square wave audio signal.  Depending upon the camera, as long as the level is appropriate and the waveform remains reasonably intact, the camera will probably read it okay.  If not, it should be obvious.

What ERX "presumed 'correction'" are you talking about?  (Note that presuming is one of the most common mistakes newbies make). Also, I question this "inevitable result" you mention. 

When a camera begins recording (digitizing) a clip, it stamps the beginning time code in the header of the file.  From there on, running time code is computed by the playback software  based on this start number and the number of samples past midnight.  Never mind exactly how the math is computed, the thing to understand here is that digital files do not have continuous running time code embedded alongside the video and audio tracks as was the case with LTC (Linear Time Code).  Each digital file embeds the start time code and the rest is computer magic.

Have you done workflow tests with any of your methodology?  If so, what were the results?

 

 

 

Link to comment
Share on other sites

hello, john.  thank you for your reply.  i am aware that ltc is essentially a stamp at the beginning of a clip.  my workflow test was as follows ...

tc from sd633 > lectro d4t.  sony fs7 with XDCA-FS7 rear module receiving tc via d4r.  the camera reads the tc perfectly well, and from a vast distance, as i would expect with the d4.  however, when i try to create noise on the tc audio track by messing with the d4t, i can cause a bump in the camera's read of the tc.  this doesn't cause any discontinuity in the video or the audio of the clip, but upon review of the resultant clip, the tc jumps to some random value as the wireless feed drops out, then returns to the expected value three frames later, when the camera begins reading its own tc.  this discontinuity is visually indicated in the scroll of the sony catalyst browse software.  

what i am trying to determine is, can this cause a problem upon ingesting for the post department?

as for the erx, unlike other zaxcom products, the erx is dependent upon zaxnet for its tc sync.  of course it has its own generator, but unless i misread this thread ... http://jwsoundgroup.net/index.php?/topic/22141-erx-hard-wire-timecode-jam/ ... the erx generator is not as accurate as the generator contained in my nomad, and will therefore cause a correction in the tc if the erx leaves contact with the nomad for, let's say, an hour.  it won't be the random value like i saw with the d4 fs7 test, but it will be a jump, and i'd like to learn if this does or does not have any consequences for post production if the camera is rolling when zaxnet re-establishes contact.

 

Screen Shot 2016-05-30 at 11.06.45.png

Screen Shot 2016-05-30 at 11.06.28.png

Screen Shot 2016-05-30 at 11.06.14.png

Link to comment
Share on other sites

I appreciate you trying to make things easier for the cam dept., but in my experience using transmitted TC directly is always a little iffy, and you can't know if things are really working perfectly while you are rolling.  I'd suggest trying one of the known-good camera TC solutions like Mozegear, Tentacle, ERX or etc that are smaller than the SB3 but just as reliable, and way more so than wireless TC on its own.

Link to comment
Share on other sites

2 hours ago, trombles said:

i am aware that ltc is essentially a stamp at the beginning of a clip.

Sorry to deviate the conversation, but I just wanted to correct something so that confusion can be avoided:

LTC (linear timecode) is NOT a stamp at the beginning of a clip, but SMPTE timecode data encoded as an audio signal. It ends up resembling a series of square waves as John has pointed out. This is what you feed to devices like cameras and audio recorders, which then interpret this data into actual values that can THEN be used to stamp a timecode value as metadata in files in the case of digital cameras and digital audio recorders. The value that is stamped in the metadata of the file is considered the "Start TC" value, which refers to the timecode value when the file is first created. This is how timecode is used in digital file formats.

The other thing to consider here is the difference between timecode and sync.

While wirelessly transmitting LTC to camera will ensure that the camera has the accurate timecode value at the start of the clip, it does not ensure that the camera's clock will be running at the same speed as the recorder's clock. Depending on the pairing and the length of the clip, by the end of the clip the camera could be a few frames off in an EDL.

Here's a useful video produced by Ambient that describes the relationship and differences between TC and Sync:


Additionally consider that wireless systems that are not designed for timecode transmission (as in the case of Ambient, Timecode Systems, Betso, Zaxcom, etc), have an inherent delay built into them. This delay is usually a few milliseconds, which is small, but worth considering. Professional wireless timecode solutions very likely make up for this delay in their designs.

2 hours ago, trombles said:

as for the erx, unlike other zaxcom products, the erx is dependent upon zaxnet for its tc sync.  of course it has its own generator, but unless i misread this thread ... http://jwsoundgroup.net/index.php?/topic/22141-erx-hard-wire-timecode-jam/ ... the erx generator is not as accurate as the generator contained in my nomad, and will therefore cause a correction in the tc if the erx leaves contact with the nomad for, let's say, an hour.  it won't be the random value like i saw with the d4 fs7 test, but it will be a jump, and i'd like to learn if this does or does not have any consequences for post production if the camera is rolling when zaxnet re-establishes contact.

Lastly, with the release of firmware version 2.0+, the ERX actually has an (auto)calibrating feature that calibrates the internal clock of the ERX to that of the Zaxnet source. This has lead to the ERX being as accurate as within 1 frame after 10 hours.

Link to comment
Share on other sites

Good clarification, José.

trombles:  Somewhere in past threads are specific ERX accuracy figures I posted for tests done on five units with the original firmware.  At that time the ERXs were fine freewheeling for an hour or two.  In another post are results of the same five units when using the 2.0 firmware with calibration, and they easily achieved what José listed above.

Link to comment
Share on other sites

10 hours ago, John Blankenship said:

When a camera begins recording (digitizing) a clip, it stamps the beginning time code in the header of the file.  From there on, running time code is computed by the playback software  based on this start number and the number of samples past midnight.  

To clarify, the timecode value on WAV files is recorded as the number of samples elapsed since midnight, the timecode value in a Quicktime is stored as a discreet value in hours, minutes, seconds, and frames.

As for what the camera will do if the incoming LTC jumps in the middle of the recording will be determined by the cameras software, and I'm sure different cameras would handle it differently (I've never tested).  If the camera only records a single timecode value at the beginning of the clip, then a jump in the TC you are feeding camera won't matter, but your tests seem to indicate the FS7 will record the tc values that it receives.  Discontinuous TC can cause problems when syncing, how much of a big deal it is, I'm not sure.  If you want to have timecode that wirelessly syncs the camera, I would recommend a solution that has it's own generator built into the receiver, like an ERX.  The TC stream will be continuous, and post will be happy.

Link to comment
Share on other sites

On 2016-05-30 at 6:12 PM, Philip Perkins said:

I appreciate you trying to make things easier for the cam dept., but in my experience using transmitted TC directly is always a little iffy, and you can't know if things are really working perfectly while you are rolling.  I'd suggest trying one of the known-good camera TC solutions like Mozegear, Tentacle, ERX or etc that are smaller than the SB3 but just as reliable, and way more so than wireless TC on its own.

Good points!

I just would like to add that if you want to use wireless distributed TC, do consider one of the professional solutions. Ambient can distribute TC via LockitNetwork and Timecode Link. Betso has a wireless transceiver for TC, and Zaxcom has ZaxNet.

I use the Timecode Buddy system and it works great!

It distributes TC via the 865MHz-923MHz band to and from the MiniTRX transceiver, and via WiFi to iPhones and iPads using the WiFi Master unit (which now seem to have be replaced by the :Pulse and :Wave units).

For one-camera productions, I put a MiniTRX (now replaced by the MiniTRX+) on the camera, and receive TC from the camera, then send it to my bag where I have the WiFi Master unit. With both the camera and mixer set to Rec-Run, my SD664 starts recording whenever the camera is rolling. Very convenient, me thinks. I know most of you want to be in control of REC/STOP, but for me, filming documentaries, it's great not having to think about going in and out of REC - and getting an indication whenever the camera is rolling (audible beep in my headphones and the screen showing that the mixer is in REC-mode). If I want to go into REC to record background sounds or such, I just press REC and speak a note into the shotgun mic.

The MiniTRX can of course also receive TC from the WiFi Master unit, and distribute it to the camera, when needed. When not receiving TC from the master unit, it can be set to jam sync until a radio link is established again.

The range is very good, up to hundreds of meters.

For me, the system lives up to its name, it's a Timecode Buddy. :-)

 

Cheers

Fred

Link to comment
Share on other sites

Even if I'm happy working with ERX's TC, trombles's test is still interesting to understand the camera's behavior.

From my experience, if FS7 looses its ext TC from behind, it will automaticaly switch through its internal clock, which is rather accurate than previous models (seems at least for one hour it hold the tc quite acculate but I didn't have done a precise test).

Here, his test doesn't show the case. I wonder if Lectro D4 outputing some digital noise when it looses the signal, that the camera accidentaly interpret to false timecode, or it's simply camera doesn't working as supposed to be. What happens if we simply use a trusted tc generater hardwired to the camera and just unplug the cable? 

Another question is... If TC on quicktime (or whatever nonlinear digital files) is simply a time stamp on file's header, why are we seeing the TC drop in this case? 

Masaki

Link to comment
Share on other sites

Hello,

In the video 1'42'' they say that the TC is written at the beginning of the clip but also at the end. If there would be a glitch in TC and the math of number of video frames VS TC doesn't sum up would this cause a problem? What is the TC out used for?

I didn't know that the TC out was also written.

 

Pat

Link to comment
Share on other sites

Hi Patrick,

Not sure, cause in this case the clip starts at 16:27:07:20 and ends at 16:29:24:04. TC drop occurs in between 16:28:41:07 to :11, timecode jumps 7 hours and 12 minutes but strangely stays at the same second - where I thought it might be a miss read /miss trascode of LTC audio signal. 

Link to comment
Share on other sites

The time code stamps can happen at multiple points within the video file, which supports edited and multi clip files.  If the Tc doesn't change, then only the beginning of the file needs a Tc stamp, however the software creating the file can record as few or as many Tc samples as is needed, I.e. each time a change is detected the camera could write another sample.

Link to comment
Share on other sites

thanks, everyone, for the interesting and very useful information.

4 hours ago, Masaki Hatsui said:

I wonder if Lectro D4 outputing some digital noise when it looses the signal, that the camera accidentaly interpret to false timecode, or it's simply camera doesn't working as supposed to be. 

when the discontinuous tc value occured, i had just switched off the d4t.  i suspect that switching off the d4t, as opposed to having it leave the reception range of the d4r (also part of the workflow test), causes enough noise to overwhelm the quite robust square wave tc signal.  hard to tell though, listening to tc is something i only do on very special occasions.

to be totally honest, mostly i'm trying to get a little more mileage out of my d4. while it's an excellent tool for any number of applications, it doesn't always make a great camera hop.  i considered using it as a tc distribution platform, but this excellent thread has convinced me not to send a mouse to do a rat's job.

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