DV Stuff

Recovering from DV mistracking errors: Occasionally you'll
get
a tape that won't play back properly, showing blocking or
checkerboarding
in bands across the picture and/or towards one edge of the picture.
I've
now seen several tapes that won't play back properly in this way,
including
one that wouldn't play back correctly in either the Canon XL1 that
recorded
it nor in a DVCPRO VTR. I've found that most Sony gear will do a
pretty
good job where other manufacturers have a hard time with such tapes.
However,
when the really badly mistracked stuff won't play back
properly
in
just any old Sony machine, you can often recover the images in a VTR
with
Dynamic Motion Control capabilities such as the DSR-1600, DSR-1800, or
DSR-2000.
These will work with any DV25 tape: DV, DVCAM, or D-7. The DSR-2000
will
even recover mistracked LP DV tapes some of the time.

DVCAM tapes can be used in DV recorders and vice versa. I
used DVCAM tapes in my DHR-1000 when I couldn't get DV tapes longer
than
60 minutes in my neck of the woods. To suss out what tape you need,
take
the DVCAM running time and multiply by 1.5 (since DV uses a 10 micron
track
pitch to DVCAM's 15 microns). For example, a PDV-94ME runs for about
141
minutes when recording DV. Likewise, I've run many a DV tape through a
DVCAM
camcorder with no problems.

Recording DV unlocked audio via FireWire with the DSR-30 DVCAM
VTR
: Press and hold down RECORD and PAUSE while turning on the power. The
deck will emit a sustained beep, at which point you can release the
buttons. It will now accept unlocked audio. It'll record 15-micron
DVCAM still, but the audio will be unlocked. This trick is also
supposed to work with the DSR-200
camcorder. Note: the DSR-11, 20, 40, and other will record unlocked
audio
without needing this trick. Late-model DSR-30s are also supposed to
accept
"NS AUDIO" (nonstandard, i.e., unlocked) without too many conniptions.

Color bars on the DCR-VX1000 and DSR-200: Press and hold
PHOTO
and the START/STOP red button while turning the camera section on.
You'll get full-field bars which you can record, along with any
incoming microphone audio. You'll have to turn the camera off to get
rid of them. More recent cameras, like the VX2000 and DSR-PD150, have
colorbars selectable in the menu.

Color bars on the Canon XL-1: Turn on the camera to the
fully
auto mode (green square). Then press both the shutter speed
buttons
simultaneously for a few seconds, and full-field bars will appear.
Pressing
both buttons again for another few seconds turns them off (a definite
improvement
over the Sony).

Playing DV or DVCAM on DVCPRO VTRs: First, make sure your
machine
is up-to-date: VTRs made before June 1997 need an eprom upgrade to
play
DVCAM. Check the serial number: it's of the form MYxxxxxxx, where M is
a
month letter, A-L, and Y is the last digit in the year. F7xxxxxxx
means
the machine was built in June 1997, and it's OK. H6xxxxxxx would mean
the
machine was born in August of 1996 and the EPROM upgrade is required.
Second
— and this is very important — use the setup menus to specify DV
or
DVCAM before you insert the tape! The playback mode
“locks in”
when the tape is inserted, so if you set DV or DVCAM mode after
loading
the tape playback will still be attempted as if the tape were a DVCPRO
tape,
and you'll get really crappy results.

Line inputs on the VX1000 (or other consumer cams)? You can
fake it: first you'll need a 3.5mm dual-mono-to-single-stereo Y
Adapter,
Radio Shack Cat. No. 274-375B; this'll give you right and left channel
mic
inputs on separate mono jacks. Use an Attenuating Audio Cable with an
RCA
plug on the line end and a 3.5mm miniplug on the mic side: Radio Shack
Cat. No. 42-2461A. Sony also makes a stereo pair version of this; if
you
just need one, peel the two cables apart. You can now jack into
line-level
audio sources. With a bit of luck, you can even plug a line source
into
one side, and a mono mic into the other — and the levels might even
match
up... If you follow this route, be sure to gaffer tape the cables out
of
the way so that they don't get pulled or wiggled during the shoot, and
avoid
touching or moving the $%#@&! delicate miniplugs. Also, only
use battery
power when recording via these jacks lest any residual
power-supply
ripple or ground loops cause intolerable AC hum problems.

Using monophonic mics on cameras like the VX1000: the mic
input on the VX1000 and most similar cameras is a standard 3.5mm
stereo
minijack. If you plug in a mono mic, you'll only get one channel of
audio.
Use a mono-to-stereo adapter available from Radio Shack to fix this:
part
# 274-374. Or, use a 3.5mm dual-mono-to-single-stereo Y Adapter, Radio
Shack
Cat. No. 274-375B to give you separate mono right and left channel
inputs
for two mics.

Line/Mic adapter boxes and cables: if you don't want to mix
'n' match cables as described above,
Beachtek, Sign
Video, and
Studio1 offer very nice adapter boxes allowing switchable
line/mic
inputs and the use of XLR cables with many of the small consumer
cameras.
Equipment Emporium
and Calrad
both carry premade XLR-mini adapter cables of various sorts, many
designed
specifically for solving these sorts of connection problems.

Those Canon IF lenses on the DSR-500WS and possibly the
DSR-300
are so pleasant to use and make such nice pix —
if
you can avoid bumping the %$#@* macro button! The 18x on the DSR-500,
at least, has a large and easily-pressed macro ring lock button
located
on the left side of the lens. Older Canon lenses had a lock button you
had to pull up on to move the macro ring; it was virtually impossible
to bump the lens into macro mode accidentally. The new lenses have a
push-to-unlock button with such a light touch that accidental macro
shots are almost impossible
to avoid. On two occasions now I've managed to just brush against it
while
groping for other lens controls or when moving the tripod to a new
setup,
bumping the button and turning the ring just enough to screw up focus
but not enough to be readily visible in the finder. I
suggest
gaffer-taping the macro ring in place so it doesn't get moved
accidentally.

Mixing different brands of tape: In DV's early days, Sony
and
Panasonic tapes used different lubricants, and if you used one brand a
lot
and then switched to the other, incompatibilities between the
lubricants
(which get deposited on heads and tape guides) could cause VTRs to jam
up
or the heads to clog, sometimes permanently. Supposedly the lubricants
were
made compatible starting in 1997, but I'm still hearing horror stories
about
these problems in the summer of 2002.

This is not a DV/DVCAM vs. DVCPRO problem; while many of the
people
reporting the jams are inserting the occasional DV tape into a DVCPRO
transport,
many others are seeing the problem in DV and DVCAM equipment, which
(high-end
DVCAM gear aside) can't play back DVCPRO to begin with. It also
happens
when other brands of tape are intermingled, not just Sony and
Panasonic.

Anecdotal evidence would seem to indicate that the biggest
problems
occur when one brand of tape is used exclusively for a long time, and
then
the other brand's tape is used: instant mess! If one switches back and
forth between the different tape brands frequently, say, switching
between
Sony and Panasonic every three or four tapes, the problems don't seem
to
appear.

Frequent switching apparently prevents a critical mass of one
lubricant building up in the transport; switching tapes may clean off
accumulations
of gunk before they get heavy enough to cause problems. Whether this
is
really a solution, or if frequent switching only leads to a
longer-term
buildup of cross-contamination pollution on the tapes themselves, is
unknown.

I run about 50% Panasonic DV tapes in my gear, with the remainder
being a mix of Sony DV or DVCAM, JVC, and the occasional Fuji. I've
never
had a problem. It's rare that I run more than four hours on one brand
before
using the other brand of tape, so that may be a good starting place as
to what a safe interchange frequency may be.

Thus there appear to be two general approaches to this problem:

Pick one brand of tape, and “stick” with it (sorry about the
pun!).
You simply won't see the problem. If any foreign brand of
tape
comes
into your facility, do not put it into your VTR; make a
FireWire
dub of it onto your chosen tape brand on your machine, using the
client's
camcorder or VTR as the source deck.

Interchange tape brands frequently, so the gunk from one never
builds up a critical mass inside the transport to jam up the other
tape
when it's inserted. Always clean the heads when changing brands,
too.

Problems with tape interchange of this sort seem to be reduced
by using a tape cleaner in between the different tapes. Especially in
this
instance, do not rewind and reuse the cleaning tapes; you'll just be
mixing
old gunk with new if you do so. Also, do not wait until you've run one
pass on the new brand tape and seen blockies or dropouts: using the
cleaning
tape at this point may only polish the gunks firmly into the heads.
Clean
the heads before inserting the new tape.

Your results may vary: and if you've had any positive or negative
experiences of this sort, I'd like to hear your story...

FireWire Frustrations: FireWire 400 (FW400) has more than
enough bandwidth even for dual-stream DV, yet plenty of problems can
occur when running FireWire disks and FireWire cameras on the same
bus.
There are a few possible reasons for this:

The FW bus can only run as fast as the slowest device on it.
Although Macs, PCs, and most drives should be talking S400 (400
Mbit/sec), many cameras and decks, both consumer and pro, only
support
S100 or S200 speeds. If you hang an S100 deck on your bus, you've
just
cut max throughput by a factor of four.

A DV stream runs about 29Mbit/sec (including audio, aux data,
etc.). That's nearly 1/3 of the usable bandwidth on an S100 FW bus,
leaving only two raw streams' worth of bandwidth for disk I/O.
However,
due to the bursty nature of disk I/O, one needs about twice DV's
data
rate to ensure timely delivery of data--and that's with internal ATA
drives. Given the "thin pipe" of the remaining 71 Mbit/sec
bandwidth,
playing/recording a single stream of DV while supporting DV I/O on
the
same bus is getting uncomfortably close to the limit.

Some devices do not like to co-reside on a FW bus. Some
Canon single-chip camcorders, Apple iSight webcams, and even some
disk
drives have been cited as "not playing well with others".

Many cameras / decks / converter boxes have used a very minimalist
implementation of the 1394a spec, barely sufficient to find a
compatible A/VC host on the bus and talk to it. Hence the oft-observed
"baby duckling syndrome": hook up two FireWire decks to a Mac or PC,
turn 'em on, and the first thing each one sees is mommy. Sometimes the
decks talk to each other, ignoring the computer, sometimes one talks
to
the computer and the other is ignored, etc.

FireWire bridge chips in disk housings have comparable
pathologies. Folks report that some drives work well on the end of a
daisy chain but not in the middle of a daisy-chain, for example.

All these same caveats also apply when using a FW800 bus, of
course.

I routinely play/record using a 7200rpm IBM DeskStar in a
three-year-old ADS Pyro case using the Oxford 900 chipset with a Sony
DSR-11, DHR-1000, or PD150 daisy-chained off it on an 800 MHz TiBook.
I'm just lucky in that all this stuff happens to play nicely together.
Your mileage may vary, depending on what equipment you're using.

Also note that using a common, low-cost FireWire hub will not
help solve these sorts of problems. The best workaround I know of is
to
segregate disks on one bus, and your DV device on another. If you have
a desktop or tower computer, you can add a PCI FireWire card; if you
have a laptop with a CardBus slot, adding a CardBus FireWire adapter
is
the way to go.

DPS Spark problems: Vynny Ward compiled an excellent help
page
which is now posted here.

Betacam

NEVER stuff a Betacam tape into a UVW-series VTR without
checking
to see if there's already a tape inserted. The tape will go in just
about
all the way on top of the existing tape; it'll then jam in place. UVWs
do nothing to prevent this! Fortunately, unless you've really rammed
it
in enthusiastically, you can usually pry it out, and usually without
any
permanent damage occurring...

Phil Dippel at Technisphere
adds: “Anyone who ships UVW-1800s should always make sure that they
last place a small cassette in the well. If you ship after a large
cassette
was inserted the posts can bend after the machine receives a shock.
This
will insure that the machine can no longer accept small cassettes
until
a technician repairs the unit.” This caveat probably applies to all
UVW-series
machines.

Character Generators & Titling:

I spent almost four years writing software for the Abekas A72 in
the early ’90's; I learned a lot about what works and what
doesn't work when putting text on a video screen.

Doing good CG in interlaced video is trickier than you might
think. Doing it right in compressed interlaced video (such as DV) is
even
harder. With interlace, you can have problems of line
twitter
on static or moving text, as well as roll-induced
"crawlies" and distortions. With compression, you add problems of
codec pathologies. And there are always pitfalls associated with
colors
and bandwidth.

Line twitter occurs when you have fine, single-line detail
that
appears in one field but not in the other. The detail so rendered will
flicker
at the frame rate, while the rest of the image updates at the field
rate.
The frame rate (29.97 Hz in 525-line NTSC; 25 Hz in 625-line PAL) is
slow
enough that your eye notices the flicker, and it's very annoying.

First, make sure that the fonts you use don't have fine,
single-line
horizontal strokes that will show up as line twitter. Look at heavier
fonts
in the same family: instead of light or roman, look at bold,
extrabold,
or black variants. But bear in mind that instead of using Coronet or
Script
Light, you might have to switch to Helvetica or Times Bold. Often I
find
that the delicate typefaces I prefer in print work just won't
translate
properly
to video, and I have to find something else instead.

If you're dead-set on using a fine, light typeface, try building
a font that thickens up the strokes: use outline, soften, glow, or
extrusion
(solid drop shadow) effects in a similar color or brightness.
Sometimes
a soft drop shadow in a similar color with a minimal offset can be
used
— even Premiere 4.2's limited text capabilities will give you that
much!

The problem with interlace and rolls is that as the text
moves up the screen, its position with respect to each field's line
structure
can either change, or stay the same. If it stays the same, your text
will
look as good moving as it does when it's still. If it changes, the
text
will lose resolution and may flicker, distort, and crawl around as it
rolls.

Imagine characters in a screen font with a height of 10 lines.
When placed on a page at its starting position, the even scanlines in
the
character all fall on the even video field, while the odd scanlines
fall
on the odd field. As the text sits there, the even fields show lines
2,
4, 6, 8, and 10 in the text, while the odd fields show lines 1, 3, 5,
7,
and 9. All ten scanlines in the text are seen over the course of any
two
fields.

Now start a roll. Any decent CG updates the roll on a field
basis; after one field is displayed, the text is moved up a certain
amount
for the next field, up the same amount for the next field, and so on.

Let's say that the director wants a nice, slow roll, to kill
some time. You've selected 60 lines/second (CGs that allow you to set
the
roll rate usually use scanlines per second as the measure, and in
NTSC-land
the 59.94 Hz field rate is rounded to 60 Hz to keep operators from
getting
bogged down in fractional math. If you're in PAL-land, assume you're
rolling
at 50 lines/second for this example), and pushed the "go" key on the
CG.

Now in the first even field, character scanlines 2, 4, 6, 8,
and 10 are shown. Next the text is moved up one scanline
because
at a nominal field rate of 60 Hz, one scanline per field results in 60
lines
per second. So when the odd field is displayed, the text, being up one
line from its even-field position, has lines 2, 4, 6, 8, and 10
displayed again — and lines 1, 3, 5, 7, and 9 don't get put
onscreen!
The next vertical interval comes along, and the text is moved up one
line
again, so that the even scanlines once again appear in the even field.
The
next vertical interval arrives, and up goes the text again — one line!
—
so that the next odd field, like all the even and odd fields before
it,
shows the even scanlines of the text. The odd scanlines in
the
text never appear onscreen!

The result is half-vertical-resolution text that looks awful.
Thin horizontal strokes will either appear about twice as thick as
they
should, or twice as thin, depending on your luck (sometimes you get
the
evens, sometimes the odd scanlines, depending on the CG you're using,
the
initial position of the text, and the field timing when you press the
"go"
key).

Now go back and double the roll speed, to 120 lines/second (or
100 lines/second if using a 625/50 CG). Now, the first even field
shows
the even scanlines. Come the vertical interval, the text is moved up
two lines (two lines per field times 60 fields per second gives
120
lines per second); the relative positioning of the text with respect
to
the field structure remains the same, since the even scanlines are
moved
up two lines to the next higher even scanline, while the odds are
moved
up
to the next higher odd line. When the odd field is displayed, the odd
scanlines
in the text are shown, just as they should be! The full vertical
resolution
of the text remains.

You may have noticed a pattern here. When the roll rate (in
lines/second) was the same as the field rate (in fields/second), the
roll
looked awful. When the roll rate was twice the field rate, things
looked
fine. As it turns out, this relationship holds for all integer
multiples: roll rates that are odd multiples of the field rate
look
awful.
Even
multiples look great. Thus for 525/59.94 (or 525/60, more or
less)
video,
good roll rates are 120, 240, 360, and the like. In 625/50, the good
ones
are 100, 200, 300, 400, and so on.

Unfortunately, in 525/59.94 the only two decent rates that are
slow enough to be read are 120 and 240 (and the latter only on a good
day!).
625/50 video is better — not only are the roll rates about 20% slower,
there are almost 20% more active scanlines in a frame, so in 625 you
can
roll at 100, 200, and 300 lines/second without straining any eyeballs.

What about roll rates that aren't integer multiples of the field
rate? As you might guess, as the text moves, its positional
relationship
to the field structure no longer follows an integral structure, but
changes
on a field-by-field basis. This leads to two things:

Unless the CG you are using offers sub-pixel positioning, the
roll
won't be able to execute smoothly, and the text will stutter or
judder
up
the screen.

The roll motion will "beat" with the field structure, as the
scanlines
themselves appear to roll through the text (at a rate proportional
to
the
difference between the roll rate and the nearest integral multiple
of
the
field rate), causing time-dependent rippling distortions of the text
(the
"crawlies") that look really horrible.

What real CGs do to avoid this is to offer only the “good” rates
by default; extra work is required to set arbitrary roll rates. When
you
select timed rolls (the total time is set, rather than the speed),
better
CGs will fiddle things to wind up with a good rate. Some may just pick
the
rate that comes closest to meeting the desired time; some Chyrons run
part
of the roll at one rate, then “shift gears” to finish at a different
rate
to get the desired total duration; the A72 (and probably the Texus)
“adaptively
spaces” the text in the roll, stretching or compressing the vertical
line
spacing to allow a good roll rate to be used and still meet the time
target.

What crummy CGs offer in the way of speed control is none at
all. For example in Premiere 5.0, where they've finally understood
that
folks want to roll credits, there are no tools for setting or
even
reporting roll rates in the titler: one just has to adjust things by
trial
and error. This stinks: if you're stuck with such a CG and need to
produce
for interlaced video, complain loudly to the vendor about their lousy
non-video-aware
tools, and then go look for a CG that does things right (
Inscriber Technology's
CG is one of the few that does; you might also check out Pinnacle's
TypeDeko on the PC, McRobert's Comet CG on the Mac, and Boris Graffiti
on PC or Mac. These may offer proper controls... and there may
be
others out there as well. Let
me
know
what you come up with and how well it works — or doesn't).

Codec Pathologies: Most titlers in nonlinear editors render
nice,
sharp text. That's just fine for display on a computer screen, but
it's
too sharp for either bandwidth-limited
broadcast or for compression: DV, M-JPEG, MPEG, or the like. This is
true whether or not the text is antialiased; even antialiased text can
have sharp vertical, horizontal, and diagonal transitions with
significant energy in spatial frequency bands outside the codec's
comfort range.

Overly sharp text stresses the codec; in DCT-based codecs this
results in “mosquito noise” or “feathering”
artifacts
that cause visual noise scattered around the immediate vicinity of the
text. Moreover, the character of this noise varies depending on the
relationship
of the stressing image to the DCT block boundaries, which means that
as
your text moves (in a roll, crawl, or scroll) the mosquito noise
surrounding
the text will “fly around” just like a flock of hungry mosquitos. It's
very
annoying.

The trick is to prefilter the text so as to avoid these problems.
Running a simple soften or blur filter over the text will make it look
a lot worse on the computer screen — but it will actually
improve its appearance going through the codec. Not a lot of
softening
is necessary, but a little bit almost always helps.

Bandwidth — or more precisely, an excess thereof — has been
a
CG problem since day one. Many CGs (even high-end broadcast CGs)
simply
render text, antialiased or not, into their frame buffers, then encode
the results as a video signal and send it out. Unfortunately, the
sharp
horizontal luminance transitions across characters can contain
significant energy at frequencies above the passbands for NTSC or PAL
systems (or even the circuits in unencoded, component analog VTRs and
terminal equipment), which causes ringing and overshoot in the signal
(I've measured 20% overshoot on the outputs
of some top-end CGs).

For example, if you set the peak white in your text at 80 IRE
(for NTSC, or 80% in PAL), the overshoot will hit almost 100 IRE or
100%.
Many CGs offer a default white value in their palette of 80 IRE,
because
anything brighter causes an overshoot beyond 100 IRE or 100%: this
results
in “sync buzz”, that annoying 60 Hz (50 Hz for PAL) buzz you'll get in
over-the-air
audio when overmodulated picture carrier bleeds into the sound
subcarrier.
[Amusing note: the hardware folks who designed the Abekas A72 were
very
careful to bandwidth-limit the video outputs to avoid this ringing and
overshoot.
As a result, you can use a peak white of 100 on the A72 with no
problems.
Of course, we got lots of complaints from New York producers who
really
liked that hard-edged, ringing video quality they got out of their
Chyrons;
you can't satisfy everyone...] Again, the solution to the problem is
proper
prefiltering: 100 IRE / 100% white is perfectly usable but only as
long
as you smooth off the sharp edges to prevent ringing.

Color choices are also important when designing titles.
Sure,
just like you I'd love to use a deep, saturated red — but it usually
doesn't
work out in practice.

First, the chroma bandwidth of all of our current production
formats is at best 1/2 the luma bandwidth (in 4:2:2 digital video) and
often only about 1/4 as good (4:1:1 or 4:2:0 DV; BetaSP, MII) or even
worse
(3/4", S-VHS, Hi8, VHS, Video8). Since most text is comprised of fine
detail,
there's not enough area for the color to fully express itself: what
you'll
mostly get are noticeable color bleeds of the text onto the background
and vice versa.

Second, any time you encode the video as NTSC or PAL for
composite
display or for analog transmission (which as of mid-1998 is how most
of
us are seeing TV, Digital Satellite Systems and DVDs aside [and even
then
many folks are connecting DSS and DVD via a single-wire composite
feed]),
you'll get cross-color and cross-luminance artifacts at sharp
transitions,
especially when trying to use brightly-colored text. Often the dot
crawl
artifacts seen on such text will render it unreadable. What makes this
worse
is picking a text color that's at the opposite side of the vectorscope
from
the background: for a real howler, try red text atop a cyan background
or
magenta text on a green ground, and view it on a composite monitor:
ouch!

What can you do? Sad as it might seem, you have to back off
the saturation and go for more muted pastel tones. Also, picking
colors
in
the same wedge of the vectorscope (yellow on red, or cyan on blue, for
example)
causes fewer out-of-band excursions of the color subcarrier, and
minimizes
dot-crawl artifacts.

It's critical to view your rendered text on a real,
honest-to-goodness
composite video monitor; the computer monitor (or even an RGB video
monitor)
showing a full-bandwidth uncorrupted RGB signal is no
indication
of what the text really looks like once it's been put on
video.

The one seeming exception I've found to these overall guidelines
is rendering yellow text atop blue or cyan backgrounds (at least in
NTSC;
I've not tried this with PAL encoding). This violates all the rules:
I'll
use fairly saturated colors for both text and ground, and they're
opposite
one another on the vectorscope. For whatever reason, this doesn't seem
to cause as many problems as other, similarly pathological
combinations.
It could be that the yellow/blue change vector is fairly close to the
B-Y
axis, where humans' spatial color sensitivity is near a minimum; it
could
be that the Y signal excursion is not as great, so less cross-color
appears;
it could just be a personal preference and associated aesthetic
blindness!