Xref: utzoo rec.video:6910 sci.electronics:6756
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!astroatc!brown
From: brown@astroatc.UUCP (Vidiot)
Newsgroups: rec.video,sci.electronics
Subject: Re: VTR colour recording (and how does SECAM do it?)
Message-ID: <2152@astroatc.UUCP>
Date: 27 Jun 89 16:56:44 GMT
References: <124@nisca.ircc.ohio-state.edu> <566@axis.fr> <367@ctycal.UUCP> <1533@unccvax.UUCP>
Reply-To: brown@astroatc.UUCP (Vidiot)
Organization: Vidiot's Hangout
Lines: 63

In article <1533@unccvax.UUCP> dya@unccvax.UUCP (York David Anthony @ WKTD, Wilmington, NC) writes:
<	This point is not often covered here, but basically, you can't
<record baseband video (with encoded chrominance) on a helical scan
<video tape recorder.  The entire reason is a **mechanical** one, and
<is basically the fact that you can't obtain a constant linear scanning
<velocity where the rotating headwheel's head tip contacts the tape.

Since I only have promotional flyers for two different 1"C decks, and since
they don't say exactly what is going on, from what I can gather 1"C decks
are NOT color under helical scan VTRs.  Here's why, I remember seeing a
spec on 1"C decks in a series of articles in a trade rag about various
video decks.  Also, one of the promotion flyers makes a point of the fact
that you don't have to bother with a "color under" system.  Also, there
isn't a sub-carrier input connection on either of the two decks.  The
sub-carrier input is used by a TBC to lock up the color sub-carrier for
use by the TBC.

<	Luminance and chrominance are separated. The luminance
<goes on its merry way to be recorded as a narrowband FM track
<at about 4 mHz with a 1 mHz deviation. (Mr. Video will no doubt
<correct me as to specifications).  Chroma, on the other hand, is
<processed in such a way that it is **heterodyned down** below
<the luminance track.  The signal which does the heterodyning could
<come from two places:

VHS numbers are:  normal VHS	3.4-4.4 MHz	629KHz SC
			SVHS	5.4-7.0 MHz	629KHz SC
			3/4"	3.8-5.4 MHz	688KHz SC

<	But, the mainstay is still colour under. These signals can
<even be broadcast, with appropriate massaging using a time base
<corrector (basically, a big fat FIFO which is trying to be kept
<half full by prompting the VTR headwheel to "slow down" or 
<"speed up" its filling, and whose output is being clocked by 
<precise, stable signals).  

Actually the TBC doesn't tell the VTR to speed up or slow down the headwheel.
Depending on how big the buffer is in the TBC, a system known as advanced
sync is used, ie, the TBC receives house sync.  It sends sync timing to
the VTR that is advanced, whereby the video coming out of the VTR is there
before it is needed.  This advanced sync tells the VTR when to put out
the video in relationship to the vertical sync, but the headwheel will only
speed up or slow down due to its trying to keep up with the required sync
because of drag/tension problems.  Even then these speed changes are very
small.  Besides, even using internal sync, the same thing will happen to
the headwheel.  But, by the time it gets out of the TBC, it now matches up
to house sync.  The TBC looks at the incoming video line and finds out where
the horizontal sync is and lines up the video line.  It also puts away the
color information.  When needed, the video is put back out with correctly
shaped horizontal sync pulses, the video signal at the correct reference
levels and the color also sent out, with a new color-burst and any timing
errors that it sees corrected.

One problem with TBCs is that the audio is also advanced.  Unless one also
passed the audio through a digital delay unit that matches the advanced
timing of the TBC, every time the video is sent through a TBC or frame-
store unit (like a TBC), the audio will appear to happen before the video.
I have seen that many times with CNN newscasts.
-- 
	        harvard\     att!nicmad\
Vidiot            ucbvax!uwvax..........!astroatc!brown
	        rutgers/  decvax!nicmad/
	ARPA/INTERNET: brown%astroatc.UUCP@spool.cs.wisc.edu