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

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!

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:

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: