Posts for: #videomachine

Draft: Philosophy of VCR Alignment

Attention: this is not yet working methodology, just my drafts of what I am considering of including in the final document. While I am working on writing the centroid methodology document, I will be publishing draft sections of what I am working on.

The text is intended to be followed by technical illustrations and pictures - these will be in the final document, but are not going to be included in the drafts.


What is good alignment?

In my personal opinion based on operating a video club where we routinely watch magnetic media, a tape system can be considered well-aligned when it satisfies the following practical points:

  1. Good playback of audio and video - good sync, good image quality, no fuzzies, zero tracking setting usually is the sweet spot for most tapes
  2. Tape flows smoothly through the transport and doesn’t crease/get caught/get damaged by anything
  3. For recording systems only: recorded audio and video signals play on other machines with no tracking adjustments

Most VCRs will play video just fine and will not damage the tape in their default state. You generally do not need to perform alignment in the first place as normal wear the VCRs experience still does not take the machinery too far out of the normal alignment.

However if you are rebuilding the machine and swapping key components around, the re-alignment becomes mandatory to get the machine to play anything. Therefore it seems fair to say that alignment is not a thing you do to improve the quality of playback but instead a technical operation you execute when you need to re-calibrate the VCR for a known good reason.

So the golden rule is don’t touch it if it works. Good alignment is when the player will reproduce the tapes. I had to re-align my player because it would not reproduce any tapes at all (the image came out corrupted since parts from different VCRs differed in exact geometry and adjustments).

Another thing worth mentioning: there exists a nominal alignment for the VHS system to which all VCRs were calibrated during the era when they were still around. These days all equipment you find will generally have experienced a degree of wear or simply has aged.

This gives a rise to the philosophical question of what is better - making the VCR aligned to the nominal specifications of the VHS system or making the VCR aligned to effective good playback of the tapes in modern times?

What is correct alignment?

If today was not the present day, the correct way to align a VCR would be the procedures described in detail in the service manual. These procedures require use of VCR-specific jigs and special alignment tapes which will encode correct signal that embeds inside of it geometric relationships so important to the configuration of the tape transport.

This is the first kind of correctness: normative correctness. A normative-correct alignment is the one made according to the original factory references. Such an alignment embeds exactly the key geometric values of the VHS system and brings VCR to agreement with the specification as it was printed.

Normative correctness was the correctness when the VHS format was not obsolete: the most assured way to record media that will be universally playable by assorted VCR machines was to calibrate the recording machine to normative correctness.

Normative correctness is the ideal. But factory alignment tapes and jigs are essentially unobtanium at this point. If you are very limited on resources like me, this path is impossible/too expensive/requires a prohibitive amount of effort.

However there is a second kind of correctness: effective correctness. An effective-correct alignment is the one that actually succeeds in playing back a broad sampling of VHS tapes, both commercial and home video. Effectively correct alignment has such key geometric values that they are in good coordination with the VHS standard and they result in accurate playback by the contemporary as-is device.

Effective correctness is what this methodology is aiming to attain. Not normative correctness. A VCR aligned according to the methodology presented here will be good at playing back tapes and will satisfy the requirements of “aligned well”… but it will not be a factory aligned VCR.

But today is the present and it has been many years since the VHS format became obsolete. Here is my opinion: effective correctness at this point is equivalent to normative correctness, but they are not the same thing.

In modern times, you can push VCR slightly further if you aim for effective correctness over normative, since the very parts VCR is made from are no longer very normative.

Philosophy and engineering of the dynamic systems

A well engineered, practical dynamic system (any machine, piece of software, any abstract design) generally exploits dynamic stability in some fashion.

If there is something dynamically unstable the engineering design calls to stabilize it. And now if something is dynamically stable (inherently so or because of a control system) then it will have a specific relation to dynamic state - be at some local extrema in the state space.

All of engineering effectively has to do with local optimization. The result is that engineered systems generally work in states which are locally optimized.

Here is how this connects to physical reality of VHS:

  1. The video heads must trace exact paths over the video tracks on the VHS cassette. Here is the local extrema: the resulting RF signal is at its highest when video head is aligned with the track, anything less than good alignment results in reduction of RF signal
  2. The control (CTL) pulses must arrive at the exact time the video head begins/finishes the traversal of the video track. Here is the local extrema: any deviation in pulse timing will offset the video heads off the correct tracks, the only correct alignment is the one which maximizes playback RF
  3. Two video heads must traverse the tape symmetrically and identically. There is nothing different about them - both heads read signal identically and are functionally interchangeable. The system is symmetrical, completely. Here is the local extrema: any deviation of one head from another changes the RF signal reading. The resulting playback is at its optimal when both heads behave symmetrically. If there was any residual azimuth or offset between the video track and video head, we will immediately see asymmetry in that one specific video head
  4. Capstan must pull the tape at the exact rate corresponding to video tracks and CTL pulses. Here is the local extrema: if pull speed is less than required or if pull speed is higher than required, then there is a constant shifting offset between the video heads and video tracks. This results in loss of stable RF and instead we get long-duration pulses (whenever heads ‘slide off’ the video track and show us the space between video tracks)
  5. Hi-Fi signal should be largely close and almost in-phase with linear audio signal. Here is the local extrema: these signals are synchronized during the recording, so any time offset during playback suggests that the geometric distance between the video drum (Hi-Fi audio) and the A/C head (linear audio) is incorrect.

So here is the fundamental statement on which this methodology is based on: VHS system in its aligned state sits at the local extrema by some key measurable parameters.

Therefore we can perform a alignment of a VCR by iteratively pushing it towards the local extrema using the commercial video tapes as a reference.

So what do I do?

In order to effectively repair a VCR you must understand the physics behind how everything works. How the servo system works, how the video head reads data off the tape, etc…

Explaining this is beyond the scope of the current document. That is the knowledge that should be obtained in parallel with this if you really do attempt something like this.

Phase Code for Accurate VCR Alignment

Sometime during the video club operations recently an anomaly was noticed: on VCR7 BR-S800U the ideal position for tracking was off-center. Actually, multiple commercial tapes exhibited better tracking meter values for adjusting the tracking knob about 1/3rd in tracking+ direction.

Because the A/C head alignment was known to be reasonably good but X-value was never adjusted before now, I assumed it is most likely an issue related to X-value. But to be entirely real - technically there exists a coupling between A/C head azimuth and X-value adjustment, because tilting of the head also tilts the CTL head and shifts the distance slightly, so these two adjustments cannot be fully separated from each other.

The picture above is just an illustration - previously this tracking level could only be attained by rotating the knob 1/3rd clockwise, while in this same neutral position the tracking meter would show -2..-3 dB or so.

Here’s the gist - for a well aligned VCR, the best tracking preset position should be somewhere around the center (meaning no alignment offset must be applied to play the tape at the maximum FM signal level). The system can be considered well-aligned if it satisfies the following checks:

  1. Phase difference between Hi-Fi and linear signal is very low (because phase of linear audio playback depends on X-value, when the audio/control head is well aligned the phase difference will be the lowest)
  2. Phase difference between linear track left & right is approaching zero (because azimuth of the audio/control head makes both tracks be aligned with the tape - no residual phase difference between them)
  3. The optimal tracking preset is in the center, while the shape of the tracking signal response for sweeping the entire tracking preset is largely symmetrical (e.g. Hi-Fi tracking loss occurs roughly at same positions of tracking offset)

So there is an important element here - measuring relative phase offset. Previously I did this using a 7 kHz sine wave… which only lets me align things to precision of a single sine wave cycle at 7 kHz.

Which is 33.35 mm/s (NTSC tape speed) divided by 7000 Hz (reference frequency) - the length of a single sine wave cycle of linear audio at 7 kHz is approximately 4.8 micrometers.

Suddenly, an idea appears: because it’s not possible to tell phase offset (and therefore geometric offset) on a normal sine wave beyond 1 cycle (~4.8 micrometer) accuracy, what if I did amplitude modulation on the sine wave code to encode a higher-order phase correlation?

The idea is inspired by LTC timecode (encoded in linear audio tracks) and by the way laser rangefinders work (determining both fine and coarse components of phase offset). The result is a phase code:

The entire transmission of these codes is phase-aligned, e.g. each of these codes contains the same sine wave phase. The code then allows both fine and coarse measurement of phase:

  1. Coarse measurement in time window of up to about 1 second (33,500 micrometers worth of geometric distance) is possible by taking code transmissions and comparing their binary code as well as the timing of where the pilot begins
  2. Fine measurement in time window of up to 1 cycle (4.8 micrometers) is possible by comparing the phase of the sine wave in the pilot or anywhere across the code

This specific code is made to be very easy to sync and “catch” on the oscilloscopes - the pilot level is always greater than transmission levels, so it’s easy to catch it by simple level trigger.

Five bits of sequential code are simply a linearly incrementing Gray code (so each two nearby transmissions only differ by a single bit). The field number is initialized to the field number currently transmitted - I got the code to be properly synchronized with the video.

The same sequential code is transmitted twice - first for field 1, then for field 2. So the sequential code increments every NTSC frame, and it’s the field ID bit that distinguishes codes bound for one frame but from different fields.

The code is also useful for absolute adjustment of audio phase relative to the video phase - my test generator is now programmed to output audio/video in such way that the beginning of the pilot exactly coincides with the start of transmission of the video frame. The entire code is one field long.

So now are the real oscilloscope traces from the VCR7. First, the initial state of phase difference between Hi-Fi and linear sound outputs revealed the real misalignment in X-value:

It makes sense - tilt of the A/C head and X-value are the only two variables previously not aligned on this VCR, with tilt being adjusted in the previous blog post.

Important note: the source tape with this signal was recorded on my well-aligned VCR. The methodology does not sit in simply nullifying the phase between Hi-Fi and linear audio since this requires a tape that was recorded on a well aligned deck.

So naive matching of the phase here results in only aligning one VCR to another VCR. The centroid methodology requires something beyond this - the signal becomes a reference and what’s hunted is not perfect match between Hi-Fi and linear audio phase but specific conditions under which the mechanical system falls into a local optimum/extrema. More on this in the next post…

But after performing the alignment in question, here is the final result:

A considerable improvement! The signals are now basically in-phase. Some residual remains - that’s the result of the centroid alignment methodology overriding pure transfer of alignment from one deck to another.

The specific meaning of the residual phase offset is this: the optimal point at which the VCR7 appears to perform most mechanically aligned across the test set of tapes seems to be slightly different than the “factory ideal” alignment of VCR1. Both VCRs are now within some small residual of the optimal alignment - one because it was aligned at the factory and used very little since while being kept in good condition, other because it naturally settled into the correct alignment after centroid iterative methodology.

One last thing - I also checked ability to record field-synced signals to the tape in order to create better alignment records (essentially alignment tapes that are referenced to a specific VCR rather than the VHS standard). On the picture below you can see almost success:

What’s missing here is pretty funny. The A/V data is stored as an mp4 file and then output by the BlackMagic Intensity Pro card with the supplied toolset (which is SO JANKY by the way).

The sound is accurately timed to frames and fields… except the mp4 files count video from the start of first image line. But analog signals have 21 lines of preamble - the vertical blanking interval together with vertical sync pulses, so the mp4 file must be encoded with this preamble duration baked in.

That’s something I ended up fixing later - works beautifully now, the output of the card contains both video and audio in correct sync (which can be verified independently and then from there it can become a source of calibrated signal for recording and using alignment record tapes).

Final thoughts on X-value adjustment

The X-value adjustment nut on BR-S800U is kinda strange at first - it requires many rotations for small ultra-fine adjustments. The effect of azimuth adjustment tends to be considerably more impactful on the phase of linear audio, however even these slight ultra-fine adjustments of the taper nut seem to change how the tracking works.

So I put together a graphic that explains somewhat why azimuth adjustment is coupled with X-value adjustment and why the magnitude of phase offset is magnified with audio tracks.

The final methodology was like this:

  1. Align X-value until tracking shows ideal behavior
  2. Adjust azimuth coarsely to bring linear in sync with Hi-Fi audio
  3. Vary X-value (without changing it - just shift it up, then shift down, then back to initial) - observing that tracking behavior still changes same way as before
  4. Adjust azimuth precisely to match waveform phase
  5. Vary tilt to see if it has any effect - it had no effect, wanted to confirm
  6. Final tracking sweep to check if everything is okay - if there is a residual offset anywhere, the procedure is repeated

Debugging CTL Issue for BR-S800U

Today I will be showing Tank Girl at the video machine… but yesterday during testing the tape exhibited a particular kind of a fault:

  • CTL counter is not advancing (which means the servo system is not sensing CTL pulses)
  • The image is unstable (it works fine for a bit, but then snow covers the screen for a moment)
  • Tracking meter is unstable (wobbly and unsteady suggesting that FM envelope is very bad)

The image being unstable is the consequence of servo system not having CTL signals as the input - the system does not know where video tracks begin and end actually, so as the playback continues the video head paths keeps drifting at a slight offset relative to the video tracks on the tape, periodically falling into the space between the tracks where there is no video data.

My initial hypothesis is related to one item I have not adjusted back when performing re-alignment of this rebuilt VCR: the tilt of the audio/control head.

In the VHS system, the A/C head reads linear audio (a form of low quality audio recorded along the length of the tape - unlike Hi-Fi which is mixed with video data) and it reads the control track - which stores pulses indicating exactly where each video track begins.

If this control track cannot be read, the servo system will not be able to synchronize properly to the video tracks on the tape and will result in the sort of symptoms that I got.

This head can be rotated in various axes in order to better conform to the flow of the tape. My initial adjustment set tilt only very coarsely and has not updated it since - so decided to perform the fine adjustment on top and see if that recovers playback of the problematic tape (spoilers: it did).

The tilt of the A/C head on the JVC BR-S800U is adjusted by four screws/bolts:

  • ① Forward tilt - the adjustment most relevant here
  • ② Azimuth adjustment - side-to-side lean relative to the tape (rotation on axis perpendicular to the plane of the tape)
  • ③ Height adjustment - shifts the A/C head up and down
  • ④ Taper nut for X-value adjustment - longitudinal position of the A/C head, only relevant for fine-tuning audio-video sync/the coarse component of the distance between the video drum and the A/C head

So… I went and did it. This was the methodology I came up with the day prior for this specific situation and this specific JVC BR-S800U:

  1. First check tape transport for any visible issues (make sure of the initial state of the alignment). Tape flow checks are implicit after each of the next steps
  2. Connect oscilloscope to linear audio R output and to CTL pulses, synchronize it on CTL pulses
  3. Record voltage magnitude of the CTL pulses and linear audio R output in the initial condition.
  4. Adjust forward tilt ① of A/C head and monitor change in waveform. Desired: find balance where CTL and audio are both at their highest values
  5. At this point the head is approximately more correctly tilted than before. Re-connect oscilloscope to linear audio R & L outputs
  6. Perform head height adjustment by turning hex nut ③. Since the reference has a linear stereo audio recording, attempt to equalize amplitude of two waveforms
  7. Perform azimuth adjustment ④ to match phase and maximize output level of two waveforms, correcting the residual error
  8. Re-connect oscilloscope to linear audio R output and to the CTL pulses, synchronize on CTL pulses. Check magnitude of the CTL pulses and record it
  9. Go back to step 4 and repeat forward tilt adjustment again while monitoring the change in waveforms. Perform at least two iterations of this process, then decide whether to continue it based on those results
  10. After these adjustments perform a full tape transport check and ensure that tape flows smoothly

I did the procedure, though it turns out a very small tilt adjustment was enough to increase CTL strength and no other actions in this methodology had any further strong effect (however, it was important to do them to ensure that iteration converges).

Checked the result on many tapes - both test tapes and the known problematic tapes. There is definitely a minimum threshold for CTL track signal level beyond which BR-S800U just completely gives up and this threshold is higher than that of other VCR’s I have (makes sense - it’s an editing VCR).

The specific values for CTL signal level (measured at test point TP2 of the SERVO/M-CTL board) for the same section of the reference tape with known good CTL pulses:

  • Initial: 0.34 V
  • Adjusted: 0.37 V (~9% increase)

With this adjustment, the previously problematic tape now plays just fine. No issues with tracking whatsoever, no issues with servo lock, no issues with Hi-Fi sound. In my experiments, it seemed that the threshold for CTL pulses to be considered valid in BR-S800U seems to be around ~0.30 V. Issue can be considered solved!

Video Machine: ViewCast Osprey Weirdness

Here is an analog gremlin that appeared in the video system a couple weeks ago and has been annoying me a little. The specific issue here is very poor luma-chroma separation - crosshatching patterns and apparent ringing:

First I checked if it was any form of interference - however the patterns remained regardless of the current signal chain or which equipment was turned on. This required further in-depth debugging…

This was pretty much the sequence of it:

  1. Attempted to bypass the analog rack by looping analog output of one capture card (BlackMagic Intensity Pro) to input of the other (ViewCast Osprey 450e). However the issue remained - so the analog rack plus long umbilical cable to it was excluded completely.
  2. Disconnected auxiliary input to ViewCast Osprey and all audio connections - completely detached the umbilical cable. Still no effect.
  3. Got my SMPTE test pattern generator (I love it so much), plugged it directly into the computer. All analog processing is bypassed and input is connected to reference source. Still no effect - the issue is inside the capture card then.
  4. From there I continued to fiddle with various settings of the capture card… mainly switching between the television signals and the B/W composite mode. Noticed strange behavior - B/W composite mode will generally NOT engage.

B/W composite mode not engaging is an anomaly from a couple showings ago - we were watching Thirty Nine Steps in black and white (and on EP-mode VHS using the JVC BR-S800U VCR that I rebuilt). But the actual B/W mode refused to engage.

B/W mode is supposed to turn off chroma filtering and pass luma unchanged - it can increase quality on a true black and white television signal.

After turning off automatic television signal detection (it got turned on by accident at some point during testing) the B/W mode still refused to engage. But… after switching to PAL-M and then back it suddenly started working again. I suddenly realized what this reminded me of - there is a “sticky AGC” behavior with ViewCast Osprey that reveals internal controller part and the actual hardware are not always properly in sync to each other…

Together with the B/W mode the signal quality suddenly came back too. The image suddenly became clear and with none of the artifacts from before. There is still an artifact with the luma burst field on the right side of “STAND BY” text, but that is a known problem with output (OBS performs a rescale operation where it should crop instead - 1:1 pixel mapping is ruined).

So, the capture card seems to have two parts to it - the hardware that does the actual decoding and has its own states, and the controller which sets the states for this hardware. I think that this controller is not entirely comprehensive of the hardware state, so at some points there is a bit of a hysteresis or a corruption.

There are two kinds of hardware vs controller mismatch hysteresis on this card that I observed so far:

  • Video gain is automatically detected during the initialization of the TV signal and then never touched again. The video gain will be set to somewhat random level - if two devices don’t match quite in analog video voltages, one will be distinctly brighter than the other… If switch happens with no lock loss. If switch causes loss of signal lock, it will reinitialize gain randomly.
  • Configuration of the hardware luma/chroma separation circuit gets corrupted between different TV signal standards and in particular when B/W mode is enabled in automatic standard selection mode.

So as a result, just switching the automatic television standard detection helps with these issues completely. B/W luminance only mode also works. As a bonus, here is the test pattern when passed through the B/W mode:

Video Machine: Subtitle Rendering

Some time ago I updated the video machine subtitle-related features, specifically:

  • New custom CEA-608 subtitle decoder, which captures subtitles directly from the VBI waveform
  • New custom CEA-608 subtitle encoder, which generates caption bytes that then get used by subtitle encoder hardware or can be transmitted elsewhere
  • Added a CEA-608 to Pango markup converter and switched subtitle rendering from driver-based hardware subtitles to pretty high-resolution text provided by text-pthread plugin for OBS

Previously it would use the decoder from the capture card. This meant that subtitles would be locked to the current analog input (more on this below), end up baked into the video stream and they caused a short hang-up whenever they were turned on/off. The subtitles would get caught along with filters like sharpening and so on… generally resulting in blurry text.

There is a subtlety about displaying analog subtitles (ha ha) - the main video signal sometimes passes through the time base corrector, which is a lossy process prone to corruption of the subtitle waveform. In case of time base errors in the source signal (which is very common for old VHS media) the TBC tries to fill in corrupted data by repeating the previous video frame. This results in repeating of two last bytes of transmission over and over.

To get around this the auxiliary input is used to source the CEA-608 CC waveforms. The primary video input signal is what connects to the screen and the auxiliary input is what I see on the panel - and what subtitles are decoded from.

Video Machine has a custom decoder for these waveforms - it obtains raw data samples from the capture card, then performs clock detection & NRZ bit scanning with clock re-synchronization. The CEA-608 waveforms encode two bytes of data per a single frame.

I also added a CEA-608 encoder which is able to turn this Markdown-like formatting into a valid CEA-608 byte sequence. This is also the same message that was used for test images throughout this post:

A quick brown fox jumps over the lazy dog
{@2}{r}Red {g}Green {b}Blue {y}Yellow {c}Cyan<br>
{@3}{m}Magenta {w}White *Italic* _Underline_<br>
{@4}{gR}BG {bG}BG {yB}BG {bY}BG {mC}BG {cM}BG {rW}BG

Here are the specific commands that implement custom CEA-608 codes:

  • {@row,column} encodes a “place at specific part of the screen” command sequence
  • {w} or {white} encodes a foreground color adjustment
  • {W} or {WHITE} encodes a background color adjustment
  • Supported unicode characters are converted to corresponding CEA-608 codes
  • Bold text, strike-out, etc are not supported by CEA-608

This is the final result as decoded and rendered by the Video Machine subtitle system:

During this testing, I noticed that my CRT TV does not seem to present subtitles encoded to row 1 - it consistently ignores anything that is attributed to row 1 (because row 1 is numerically encoded as 0, it could be a one-off error in the decoder of that TV?). Plus something I already knew before - it only has 4 lines of decoding buffer, so I had to shorten the test phrase, otherwise parts of the color test would get cutoff.

I also noticed that by mistake I swapped the buttons that pick subtitle source between “driver” and custom video machine decoder. The subtitles have been running on my custom decoder for at least two of the past streams and I didn’t even notice.

Here are the same subtitles decoded on my VCR/CRT combo unit I use as an electronic badge. The decoder on this TV does not seem to support background codes, but all other formatting codes seem to be supported pretty well: