Thanks for update on current LTC usage!.

In the studios I worked in in college with the old type-c decks we did use IRIG-B but even then everyone was moving to VITC.  As editing was moving away from the razor blade and tape era to deck to deck on U-Matic decks!

Scott

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: jimlux jimlux@earthlink.net
Date: Wed, 08 Dec 2010 07:20:14
To: scmcgrath@gmail.com; Discussion of precise time and frequency measurementtime-nuts@febo.com
Subject: Re: [time-nuts] Time Code generator

scmcgrath@gmail.com wrote:

IRIG is uncommon in the audio/video industry, but still used in the
telemetry and lab environment (IRIG is the Inter-Range Instrumentation
Group, at White Sands Missile Range, after all).  I confess I doubt
anyone is still using magnetic tape with FM subcarriers on the range
these days, but you never know.. government facilities tend to use
really old equipment for a long, long time since the accounting rules
don't use depreciation (you buy it once, and it's free after that),
there's limited capital budgets for replacement, but often labor is
available to repair/limp along.

At JPL, we use IRIG to transfer time around between racks, particularly
for things like MIL-STD-1553B monitors, which timestamp the bus traffic
to the nearest microsecond or fraction, sync'd by the IRIG input.
There's something really convenient about needing just one cable/fiber
to perform the function.

Audio LTC is encoded differently than IRIG.. Biphase manchester,
different bit stream, different time encoding, etc.  Conceptually
similar though.  Any programmable hardware that can generate IRIG can
probably generate LTC as well.  OTOH, if you built your IRIG generator
out of discrete 7400 series TTL, you've got a lot of "white wires" to
convert to LTC.

Adding time code to video would be redundant.  All video is already time coded.

It turns out the time code is required to support editing.  Editors
don't actually move
bits of video data around.  What they do is create and modify an "EDL"
which is a
text file with a list of all the cuts and effects to be applied.  The cuts are
defined by the time. For example a close up of an actor's face might
be specified
at "camera roll XX from time T1 to time T2".  Later during final
rendering the software
will search the video data for frames with the required time codes

But many consumer level cameras "fake" it by defining time = zero at
the start of a
tape or the first frame in memory.  If absolute time needs to be record on a
consumer level camera then I'd shoot a few frames of a digital clock and then
later in a video editor adjust the time code

OK, all that said there is a group of people who routinely record WWV
audio on their
video.  Amateur occultation timers do this.  These people use video
cameras through
telescopes to record when a asteroid passes in front of a star and
blocks its light.
This can produce very acuate orbital data for the asteroid and if enough people
all over the world record it you can even deduce the shape of the asteroid.

On Wed, Dec 8, 2010 at 5:27 AM,  scmcgrath@gmail.com wrote:

--

Chris Albertson
Redondo Beach, California

Professional cameras have a integrated VITC generator which in addition to the time add the frame index to the time code which allows for creation of frame level Edit Decision Lists.

Consumer cameras cheat and synthesize time.  If you run a consumer tape through a professional system you will not have a time index.  And one will need to be added

Scott
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Chris Albertson albertson.chris@gmail.com
Date: Wed, 8 Dec 2010 08:54:15
To: scmcgrath@gmail.com; Discussion of precise time and frequency measurementtime-nuts@febo.com
Subject: Re: [time-nuts] Time Code generator

Adding time code to video would be redundant.  All video is already time coded.

It turns out the time code is required to support editing.  Editors
don't actually move
bits of video data around.  What they do is create and modify an "EDL"
which is a
text file with a list of all the cuts and effects to be applied.  The cuts are
defined by the time. For example a close up of an actor's face might
be specified
at "camera roll XX from time T1 to time T2".  Later during final
rendering the software
will search the video data for frames with the required time codes

But many consumer level cameras "fake" it by defining time = zero at
the start of a
tape or the first frame in memory.  If absolute time needs to be record on a
consumer level camera then I'd shoot a few frames of a digital clock and then
later in a video editor adjust the time code

OK, all that said there is a group of people who routinely record WWV
audio on their
video.  Amateur occultation timers do this.  These people use video
cameras through
telescopes to record when a asteroid passes in front of a star and
blocks its light.
This can produce very acuate orbital data for the asteroid and if enough people
all over the world record it you can even deduce the shape of the asteroid.

On Wed, Dec 8, 2010 at 5:27 AM,  scmcgrath@gmail.com wrote:

--

Chris Albertson
Redondo Beach, California

Chris Albertson wrote:

All digital video is timecoded..
Record that video on an analog 1/2" or 3/4" deck and you need the
timecode on the longitudinal audio track. Yes, primarily as you say, to
support editing.
It's been 12 years since I sat in an edit bay, so I'll bet that analog
gear is pretty much out of the picture by now, though.

That would work..(e.g. it's just like slating at the beginning of a film
take) Sometimes it would be more convenient to just record an audio
timecode on the audio track.

Where I could see timecode being handy is when you're trying to do
automated processing.  I worked on a system 15 years ago where we had
100 cameras, and we did the alignment by hand, and it was pretty
painful.  What's easy when syncing A and B roll gets tedious when
there's 100 takes you're essentially cutting together.

I think there's also a lot of utility in figuring a way to do it in the
"consumer electronics" space.  Say I was doing a radio interferometer
kind of experiment and just wanted to do a poor man's VLBI, using a
GPSDO at each station for time sync.

On 12/08/2010 02:27 PM, scmcgrath@gmail.com wrote:

LTC (Linear Time Code) and VITC (Video Time Code) is both being part of
SMPTE 12M-1-2008 which is the time-code formats for audio, film and
video recordings.

LTC is NOT IRIG-B, but a distinct code (I just checked the respective
standards to be sure). LTC enumerate picture frames and the rate changes
between 24 frames/s, 25 frames/s, 30/1,001 frames/s or 30 frames/s.
IRIG-B is quite unfit for this.

Cheers,
Magnus

On 12/08/2010 07:18 PM, jimlux wrote:

No, not all digital video. The time-code is optional in many of the
transfer formats.

Analog black-bursts is still here.

For Cameras it is not actual time which is important, but frame and line
alignment needs to be aligned. Digital video mixers has line-stores on
the input, so the cameras only needs to be synced to within a few lines
such that the line-store can solve the rest.

If you fail syncing up you need to use a frame-store, which you try to
avoid since it adds 40 ms of delay and you drop/duplicate frames. Even
if you cut between the frames on the editing line, it is still a
degradation you want to avoid, so syncing cameras is a good thing.

Taking the effort to sync up kind of make sense when you look on the
alternatives.

Cheers,
Magnus

Magnus Danielson wrote:

You're right.. I was thinking more that analog certainly isn't always
timecoded, but at least for digital, there's an inherent frame counter,
and dropped/doubled/partial frames are unusual in digital video systems.
They're positively frequent in analog systems (esp consumer vhs!) But
you'd still get caught if the frame rate isn't the same across your
system (which is often the case)

Consumer gear also usually doesn't have any ability to gen-lock.

I think that's the video equivalent of the 10MHz reference distribution.

On 12/09/2010 02:46 PM, jimlux wrote:

There is as inherent frame counting in the analog PAL and NTSC signals
as there is for their digital counter-part in SDI.

Not after the frame-store farm...

Inside a production location yes, as the house clock dictates the time
for all equipment... but not between the production locations, the
solution being the use of a frame-store farm to "clean" the incoming
signal into the local house-clock phase and frequency.

A number of false starts to align things to GPS have been attempted, but
there has been some speed in the development. One progress was the
definition of the SMPTE EPOCH in SMPTE 404M (which bounced the trial
publication after feedback from a time-nut asking what time-zone the
midnight of 1 Jan 1958 was being referenced, naturally it was UTC
midnight which was intended and thus the Zulu time-zone). The idea with
the SMPTE EPOCH (defined to where TAI and UTC align up) is that all
sample-rates, line-rate, frame-rates etc. for all signals has T=0 at
that time and then just follow the development of TAI, while the time of
day would follow UTC.

Unfortunately. Some of it is hackable thought.

It is.

Cheers,
Magnus