Do digitizing analog video tapes companies usually use a TBC?

[lordsmurf]

To me, frame TBC is a misnomer. A TBC is a TBC,

No.

Here is DPS-575 switched between synchronizer and TBC modes. From the description/comments to the video:]

His comments there are beyond stupid. Technobabble jabberwocky at its finest.

[lollo]

A good "definition" of TBC is given by our "friend" 12voltsvid: https://www.youtube.com/watch?v=Ul0LwlIbFW8

How a TBC works, for those that don't know is, and t here are 3 types of TBC. Actually 4 if you consider the earliest analog types, but for this description I will only talk about digital types. In the digital mode there are 3 types. 3 line, field, and full frame.
They all work in a similar manner, and it boils down to the amount of memory they contain. Remember that memory was very expensive back in the 80's and 90's so most consumer devices were 3 line. What that means is that only 3 horizontal lines were stored in memory. 1 being read in, 1 in memory, and 1 being read out with the timing corrected.
Field store reads the entire field in, and then as the second field is being read in, the first is being read out. Frame, well you get it. The entire frame, both fields are read in and as the next frame is being read in the first out.
The problem is that with a frame store your video is delayed by 1 full frame, or 1/30 of a second. So you don't want to run trough a frame store while editing, and then through another one when playing the edited tape, now you are 3 frames back. For every generation, you loose a frame of sync, do that a few times, and well you get it. Lip synch error.
So typically in a production facility a TBC was not used during the editing or tape, and only used on final playback to make the signal legal for transmission. Proc amps were more common for correcting video levels ect.
When editing analog tape the additional jitter incurred when editing didn't affect the tape much, and again even with the added time base errors adding up through multiple generations, on final playback these were easily taken care of by the final TBC. It was a double edge sword, because you want to have the best quality signal going onto your master tape, but at the same time, adding an extra frame of delay is unacceptable

When we talk about lineTBC and frameTBC we force a little bit the differences between them, just because in term of devices the TBC inside a VCR differs from a TBC inside a specific stand alone devices.

TBC of the DVD-Recorders used in passthrough are somehow in the middle (but again, technically not an accurate definition).

TBC of specific cards like Canopus RX are close to a lineTBC, for BrightEye 75 are closer to a frameTBC (dellsam34, correct me about the BE75 if I am wrong )

[dellsam34]

His comments there are beyond stupid. Technobabble jabberwocky at its finest.

Yeah, He seemed to be confused between line TBC and frame TBC.

[dellsam34]

TBC of specific cards like Canopus RX are close to a lineTBC, for BrightEye 75 are closer to a frameTBC (dellsam34, correct me about the BE75 if I am wrong )

BE75 for example has full frame TBC, frame synchronizer and an input from a signal generator for Genlock, Some other devices like the TBS-800 and the likes from Grass Valley have full frame TBC, line TBC, chroma and luma DNR, frame sync and an input for Genlock.

The way the frame synchronizer work in those devices is that if there is an input signal from a sync generator it defaults to that and sync all devices to it, this is called Genlocking, If there is no input or input is disabled it just uses its internal clock and syncs audio to video perfectly, most manufacturers call this "Free run" mode, some call it "Audio lock" mode.

The way I see it, most of the confusion and the different naming is due to the environement are used, In studio environement they use different terms because the way they use TBC function, In consumer environement such as dubbing tapes and now capturing which is mostly single source VCR's we use different terms. Even in studio there are differences between production and broadcasting, Production you want clean stable picture, In broadcasting you want synchronized sources.

[lollo]

Excellent, thanks for providing the details!

[Bwaak]

That's the most useless video ever, Here is my comment there in case you missed it, My mention of synchronizer in pro equipement refer to Genlock:

What a load of horse $hit. At the end of the video you stated that there is a difference between a TBC and a time base corrector, Isn't the TBC is the Time Base Corrector? Any way there is two types of TBC's, Frame TBC corrects VBI (Vertical Blanking Intervals), and line TBC corrects HBI (Horizontal Blanking Intervals), The synchronizer in pro equipment it synchronizes multiple inputs to a master clock, in capture devices it locks the audio to the video. Line TBC is found in some VCR's and camcorders, Frame TBC is found in some capture devices and stand alone TBC boxes, Frame synchronizer is found in some capture devices, standard converters, pro switchers.

I don't see your comment under that video, thanks for providing a copy here. The DPS-575 user manual says:

In Sync mode, the internal TBC is not active, and the TBC LED on the front of the unit is off. The Composite Input must be a stable, RS-170A signal (such as a satellite or live camera feed).

In TBC mode, generally used for heterodyned signals from sources such as a VTR, the unit time base corrects the Composite Input signal. The TBC LED on the front of the unit is on.

Below are screenshots from "Today's video : equipment, setup, and production" by Peter Utz:

A good "definition" of TBC is given by our "friend" 12voltsvid: https://www.youtube.com/watch?v=Ul0LwlIbFW8

How a TBC works, for those that don't know is, and t here are 3 types of TBC. Actually 4 if you consider the earliest analog types, but for this description I will only talk about digital types. In the digital mode there are 3 types: line, field, and full frame. They all work in a similar manner, and it boils down to the amount of memory they contain.
...

The bolded part agrees with my understanding.

The way I see it, most of the confusion and the different naming is due to the environement are used, In studio environement they use different terms because the way they use TBC function, In consumer environement such as dubbing tapes and now capturing which is mostly single source VCR's we use different terms.

Who are "we", and why should "we" use different terms? Can you provide the references for the terms you use?

[Bwaak]

My mention of synchronizer in pro equipement refer to Genlock

Genlock seems to be a slightly different thing:



It would be nice to have a glossary with terms' definitions, along with the references to reputable sources.

[Bwaak]

Another description of genlock from the same book. Genlocking means using one of the source devices as the source of sync pulses, which is different from using sync pulses from a standalone sync generator. AFAIK, there must be a dedicated input for using sync from a sync generator, while genlocking can be done using regular video fed through a standard video input connector.

[dellsam34]

Who are "we", and why should "we" use different terms? Can you provide the references for the terms you use?

Unless you are a production manager or some sort of broadcasting engineer or technician, In this subforum "we" talk about capturing, Should I have to state the subject of the discussion on top of every post I write?

[Bwaak]

Unless you are a production manager or some sort of broadcasting engineer or technician, In this subforum "we" talk about capturing, Should I have to state the subject of the discussion on top of every post I write?

I don't see how capturing analog video is different from, say, preparing a broadcastable tape. The requirements are the same - stable image with high quality and no jitter, etc. The tools are the same too, at least until the video is saved to a file.

If you call other people's definitions "horse $hit", I would like to see references and quotations for the terminology you use.

[dellsam34]

Nope, The requirement are not the same, Studios don't have VHS and Video8, they use professional gear, Their players and TBC's are not your average Joe VHS player and AVTTool TBC, The quality expectation are higher.

[Bwaak]

Nope, The requirement are not the same, Studios don't have VHS and Video8, they use professional gear, Their players and TBC's are not your average Joe VHS player and AVTTool TBC, The quality expectation are higher.

Lest you have forgotten, the original purpose of TBC was to make unstable low-quality video like R2R 1/2-inch, 3/4-inch and to a lesser extent 1-inch broadcastable. Professionals use everything from Umatic and skip-field in the early 1970s to smartphone videos today. But let's not get distracted.

To have a productive discussion and to understand each other, we need common terminology. It would benefit the confused ones if you shared a couple of reliable references, citations or links for the terminology that is not "horse $hit". I suppose that manufacturers of the equipment as well as the target customer base, that is, broadcast professionals, should have established the terminology long time ago. Then we can make a sticky out of it, so that every forum visitor would be able to refer to the terms.

[Bwaak]

@dellsam34, let us start with one of your favorite devices, BrightEye 75.

BrightEye 75 converts standard definition analog component or composite video, or high definition analog component video to SDI with simultaneous conversion of two channels of audio and embedding. A TBC/Frame Sync is a standard feature and allows the BrightEye to work with any type of video input.
...
The built-in TBC/Frame Synchronizer allows you to feed asynchronous or noisy signals to the BrightEye 75. These are then digitized and time-base corrected by noise-tolerant tracking circuitry.
...
Analog video is converted at 14 bits of resolution and digitally decoded to YCrCb components (601). The signal is then time base corrected and frame synchronized to the reference input.
...
Full bandwidth analog video is converted to HD SDI digital video. The signal is time base corrected and frame synchronized to the reference input.
...
Ref In - This BNC accepts an analog composite video signal which is used as the genlock and timing reference for the internal TBC/Frame Synchronizer. Typically the reference signal is Color Black or Color Bars fed from a master sync generator.
...
TBC - This control turns the TBC/Frame Sync function on or off when an external reference is present on the Ref In BNC.
...
When the Frame Sync control is turned On and a proper reference signal is connected to the Ref In BNC, the video output of the unit is synchronous and locked to the external reference. The output may be timed with respect to the Ref In using the timing controls. In this case, the unit will accept asynchronous video and time base errors will be corrected.

When the Frame Sync control is turned On and no reference signal is connected, the unit acts as a time base corrector only. The output is not synchronous to any reference, including the input.

The operating manual has a glossary in the back:

Frame Sync
A Frame Synchronizer is used to synchronize the timing of a video signal to coincide with a timing reference (usually a color black signal that is distributed throughout a facility). The synchronizer accomplishes this by writing the incoming video into a frame buffer memory under the timing direction of the sync information contained in that video. Simultaneously the memory is being read back by a timing system that is genlocked to a house reference. As a result, the timing or alignment of the video frame can be adjusted so that the scan of the upper left corner of the image is happening simultaneously on all sources. This is a requirement for both analog and digital systems in order to perform video effects or switch glitch-free in a router. Frame synchronization can only be performed within a single television line standard. A synchronizer will not convert an NTSC signal to a PAL signal, it takes a standards converter to do that.

TBC
A Time Base Corrector is a system to reduce the Time Base Error in a signal to acceptable levels. It accomplishes this by using a FIFO (First In, First Out) memory. The incoming video is written into the memory using its own jittery timing. This operation is closely associated with the actual digitization of the analog signal because the varying position of the sync timing must be mimicked by the sampling function of the analog to digital converter. A second timing system, genlocked to a stable reference, is used to read the video back out of the memory. The memory acts as a dynamically adjusting delay to smooth out the imperfections in the original signal’s timing. Very often a TBC will also function as a Frame Synchronizer.
See also: Frame Sync.

Time Base Error
Time base error is present when there is excessive jitter or uncertainty in the lineto line output timing of a video signal. This is commonly associated with playback from video tape recorders, and is particularly severe with consumer type heterodyne systems like VHS. Time base error will render a signal unusable for broadcast or editing purposes.

To conclude,

• BE75 operating manual has no mention of "Frame TBC", it is advertised as a TBC/Frame Synchronizer. I suppose that when you say "BE75 for example has full frame TBC" you mean that it has TBC with a frame-sized window.
• The operating manual does not support the claim that "a frame synchronizer works on one video source only to synchronize audio to video". Frame Synchronizer is for synchronizing the timing of multiple video sources.
• Frame Synchronizer is useless in case of only one input signal, like capturing off a VCR.

[Bwaak]

Now returning back to the video I linked above, which was disparaged as "the most useless video ever", "a load of horse $hit", "beyond stupid" and "technobabble jabberwocky".

The video shows Leitch DPS-575, digital processing synchronizer. (See operating manual).

Here is what the DPS-575 operating manual says:

"In Sync mode, the internal TBC is not active."

"In TBC mode, generally used for heterodyned signals from sources such as a VTR, the unit time base corrects the Composite Input signal."

Here is what the author of the video says:

"In synchronizer mode, it syncs each video frame to a master clock, so you can switch between tape, camera, satellite, etc. without any glitching. This was useful in analog TV stations. It operates on the vertical sync signal only.

In TBC mode, it additionally re-times each horizontal scan line. This is what most of us are interested in today when transferring old tapes to digital. The h-sync off the tape isn't nearly as stable as the original signal and TBC mode corrects that (as best as it can). Some TBCs are better than others when dealing with consumer tapes."

Additional quotations from the DPS-575 operating manual says:

The DPS-575 is more than just a synchronizer. In addition to the features listed above, other functions include:

• Time Base Corrector
• Audio Synchronizer
• Digital Framestore with Linear Keyer

...
Genlock In and Genlock Loop connectors are used to loop a genlock signal through the unit to establish the timing for its video output signal.
...
With the addition of the four-channel audio synchronizer module, the DPS-575 can provide dual stereo audio and video synchronization.

Conclusion:

• Unlike the BE75, which is TBC first and synchronizer second, the DPS-575 is advertised as synchronizer first, with additional features like TBC.
• The description of the Sync mode from the video agrees with the operating manual.
• The description of the TBC mode from the video agrees with the operating manual.
• The manual clearly discerns between video sync, which is a primary function, and A/V sync.

[Bwaak]

davideck wrote on this forum twenty years ago. Here is an exceprt:

The design of any specific TBC may differ in detail, but the fundamental operation remains the same. Whether we are talking about a Line TBC or a Full Frame TBC, the output processing operation is the same, and in both cases all sync elements making up the Black Burst Sync reference are synthesized and replaced.

The memory section [of a TBC] might be a full frame, or just several lines, but in both cases the memory serves as a FIFO to allow the timing characteristics of the Video output to be distinct from that of the Video input. Think of the memory as a funnel. Video input samples (water) can be added in variable amounts at various times while the output stream remains constant. As long as the memory is not overfilled or emptied, its output rate remains stable.

If only several lines of memory exist, then the Video input timing must be slaved to the Video output timing. Line TBCs often have an "Advance Reference" output to be fed to a VCR's Gen Lock or Reference input for this purpose. This adjusts the VCR Video output timing (TBC Video input timing) to keep the TBC's memory approximately half full. Consumer VCRs do not provide this connection.

If a full frame of memory exists, then the Video input timing can be completely independent and freely drift with respect to the Video output timing. An occasional image disturbance will be created whenever the input Vertical Sync frame timing drifts through the output Vertical Sync frame timing (as a Frame is lost or gained), but the need to slave the Video input timing to the Video output is eliminated.

So, "frame TBC" is a TBC with a frame-sized window, which allows to duplicate or drop complete frames in case with the timing between input and output grows larger than frame.

"Line TBC" cannot drop/insert frames, and to function properly it needs to send Advance Reference signal to the playback machine, which must have an appropriate input and must adjust its speed accordingly.

I suppose, TBCs built into VCRs and camcorders are tightly integrated with the playback mechanism, so they can achieve precise timing without dropping or inserting frames. External TBCs that do not send servo signal to the playback machine must have full-frame buffer.

Looks sensible to me.

He mentions correction window in another post:

A "Line TBC" has a limited correction window of several lines. A "Full Frame TBC" has an infinite correction window because it can drop or repeat entire Frames whenever the video input timing passes through the video output timing.

Frame Synchronization requires an infinite correction window.

It is not clear to me, how a frame-sized memory corresponds to the size of correction window. A 1991 Equipment Reference from Broadcast Engineering (skip to page 121) lists TBCs / frame synchronizers that have 1 field, 1 frame and infinite correction window. So, I suppose that a frame-sized correction window is not the same as infinite correction window. But davideck implies that infinite correction window can be achieved with frame-sized buffer. Can someone shed light at the difference?

[lollo]

I suppose, TBCs built into VCRs and camcorders are tightly integrated with the playback mechanism, so they can achieve precise timing without dropping or inserting frames.

And that's whty some users like myself and dellsam34 wrote in the past that a frameTBC may not be necessary, if the lineTBC on the VCR is able to perform well (tapes in good conditions) while lordsmurf's workflow predicts a frameTBC in any case.

The question about dropping and inserting frames also relies on tapes condition (if not external conditions are involved about the capture hardware and software). When everything goes right, the lineTBC of the VCR is adequate enough to clean the image and if the tpes are ok you have 0 dropped/inserted frames, and a nice capture.

If the conditions of the tapes are not ideal, the frameTBC helps to do not drop frames, keeping audio and video in synch.

About the infinite correction window concept, I assume simply refers to the fact that the frameTBC may rebuilds the entire field (or frame)

[Bwaak]

If the conditions of the tapes are not ideal, the frameTBC helps to do not drop frames, keeping audio and video in synch.

What is your definition of Frame TBC? Please explain, how Frame TBC helps to not drop frames. Please, explain, how Frame TBC ensures A/V sync.

About the infinite correction window concept, I assume simply refers to the fact that the frameTBC may rebuilds the entire field (or frame)

The question was, how memory size - 8 lines, 16 lines, 1 field, 1 frame, more than one frame - corresponds to window size. Is it the same or different? What exactly does infinite size window mean? Does infinite size window require a memory buffer of a certain size? If one implies another, why some TBCs were advertised as having 1 frame window, while other having infinite window?

[lollo]

Please, explain, how Frame TBC ensures A/V sync.

Is in what you linked, a "buffering" allowing right positioning of frames arriving too early or too late (that will be discharged by the capture card if no corrective actions):

Now consider the memory section. It might be a full frame, or just several lines, but in both cases the memory serves as a FIFO to allow the timing characteristics of the Video output to be distinct from that of the Video input. Think of the memory as a funnel. Video input samples (water) can be added in variable amounts at various times while the output stream remains constant. As long as the memory is not overfilled or emptied, its output rate remains stable.

why some TBCs were advertised as having 1 frame window, while other having infinite window

No idea, maybe marketing.

[Bwaak]

Please, explain, how Frame TBC ensures A/V sync.

Is in what you linked, a "buffering" allowing right positioning of frames arriving too early or too late (that will be discharged by the capture card if no corrective actions):

Now consider the memory section. It might be a full frame, or just several lines, but in both cases the memory serves as a FIFO to allow the timing characteristics of the Video output to be distinct from that of the Video input. Think of the memory as a funnel. Video input samples (water) can be added in variable amounts at various times while the output stream remains constant. As long as the memory is not overfilled or emptied, its output rate remains stable.

The quote that you have used is a general description of TBC. In regards to TBC with frame-sized buffer, davideck also wrote:

If a full frame of memory exists, then the Video input timing can be completely independent and freely drift with respect to the Video output timing. An occasional image disturbance will be created whenever the input Vertical Sync frame timing drifts through the output Vertical Sync frame timing (as a Frame is lost or gained), but the need to slave the Video input timing to the Video output is eliminated.

If frames can be lost or gained, how exactly "the frameTBC helps to do not drop frames, keeping audio and video in synch"?

[lollo]

I read it the other way around: if a video drift ("lost" or "gain" a frame in the proper timing sequence) the buffering (a FIFO or a LIFO is basically a Dual-Port RAM) allowing the recovering. But it is my speculation, I do not know if the author well expressed his thoughts...

[Bwaak]

I read it the other way around: if a video drift ("lost" or "gain" a frame in the proper timing sequence) the buffering (a FIFO or a LIFO is basically a Dual-Port RAM) allowing the recovering. But it is my speculation, I do not know if the author well expressed his thoughts...

Forget about the author's thoughts. Let's just think about it. You have a buffer that can store a whole frame. You have a precision clock for sync signal. This clock is neither sync'd to another clock (genlock), nor it is used to adjust source tape machine speed (advance reference). So, we have two devices with completely independent clocks: a tape machine and a TBC. The TBC reads in new lines into its memory, and reads out old lines. If the tape machine is too slow, there are no new lines to buffer after the memory has been read out, so the TBC reads out the same memory again, inserting a frame. If the tape machine is too fast, then the buffer will be overwritten before it is read out, so a frame is lost.

In this case, how "the frameTBC helps to do not drop frames, keeping audio and video in synch"? This is your statement, can you explain what do you mean, and how it is achieved?

[lollo]

Do you understand the concept of “buffering”? Good night (it’s late here &#128521

[Bwaak]

Do you understand the concept of “buffering”? Good night (it’s late here &#128521

I do, which is why I asked you to explain how "the frameTBC helps to do not drop frames, keeping audio and video in synch" considering that the clocks on the player and the TBC are independent, and buffer underrun and overrun are possible.

[lollo]

If we want to go into details we should have the schematics and the application kit for the electric circuits, and perform a simulation at device level with a CAD.

I never designed a TBC system, but if I had to, I would also rely on the video architecture (expected number of fields per second).

If the buffer is full, the source problem is not completely fixed. i do not know if you have ever used a TBC, but they cannot fix everything.

And again, all this is sort of speculation and not accurate discussion. Reading or linking few documents on-line is good but not enough

[Sharc]

^ Agree.
As I know there is no clear and globally agreed definition or standard what a "TBC" is and what it should really do, in the sense of an international standard. TBC stands for Time Base Corrector, and that's it. It's not even a protected term or protected trademark AFAIK. So every manufacturer producing a device, box, piece of software which somehow acts on the timing signal of the video could call his thingy a "TBC", and he can't be sued for it. So we can only study the manuals and diagrams and try to understand what's under the hood, and eventually run our own tests and draw our own conclusions. Eventually we may give that specific "TBC" functionality a new name (TBC-like, quasi-TBC, TBCish, full-TBC, gimmick-TBC, and so on), in an attempt to qualify and classify it for our purpose.

[Bwaak]

If the buffer is full, the source problem is not completely fixed. i do not know if you have ever used a TBC, but they cannot fix everything.

You don't say. Look, you made a statement that "frame TBC" helps to reduce or avoid dropped frames compared to "line TBC". Maybe you meant something else that what I am thinking about. Maybe you was not thinking of ensuring that all consecutive frames are preserved, are in the same order with 1:1 correspondence to input frames, and instead you meant replacing a damaged frame with the one already in the memory (dropout compensation).

It is not about schematics, it is about what you have meant by your statement.

As I know there is no clear and globally agreed definition or standard what a "TBC" is and what it should really do, in the sense of an international standard. TBC stands for Time Base Corrector, and that's it.

Why, there is very clear definition of what TBC does - it makes sure that the sync pulses that an analog TV uses for making a picture are very precisely timed, so that the picture does not lose sync and therefore does not visually break up. This was the primary goal - to produce a broadcastable signal from wobbly helical machines.

Eventually we may give that specific "TBC" functionality a new name (TBC-like, quasi-TBC, TBCish, full-TBC, gimmick-TBC, and so on), in an attempt to qualify and classify it for our purpose.

And this was my ask a dozen of posts ago, that if "we", whoever "we" are, have come with these names, "we" need to give them clear definitions that everyone can refer to, to make discussions more productive.

[lollo]

What I meant with my statemements is clear to me (and apparently to other readers). If you do not understand is your problem, not mine. I also do not understand what you’re trying to prove (except maybe that lordsmurf is wrong) but that really does not matter 😉

Edit: it appears evident to me now that you never used a frameTBC, otherwise all your claims would be erased by facts!

[lordsmurf]

I don't see how capturing analog video is different from, say, preparing a broadcastable tape.

That's quite obvious. But we're trying to help you learn the difference.

The requirements are the same

No.

I would like to see references

Some of us are references.

I suppose, TBCs built into VCRs and camcorders are tightly integrated with the playback mechanism, so they can achieve precise timing without dropping or inserting frames.

No, not correct.

davideck wrote on this forum twenty years ago

I liked David, but he had some jumbled information at times. What I'd refer to as rounding errors, in attempting dumbed-down explanations. And, at times, it led to inaccuracy and confusion.
For example:

. A "Full Frame TBC" has an infinite correction window

This is not correct. Frame TBC is not infinite window. Infinite window refers to field. But that term is also bastardized, and often used wrongly to describe random TBCs, and even random mixers/keyers/etc.
The irony here is he already referred to it:

A "Line TBC" has a limited correction window of several lines.

Field is essentially "all lines" (whatever the number), and "infinite" really refers more to the digital buffer/RAM. Sure, in a non-jargon sense, in another context, you could refer to frame as infinite. But it's as wrong as using "jitter" wrong (ie, vertical bouncing is NOT jitter, but rather in-frame wiggling lines it technical jitter).

As I often say: terms can matter.

But davideck implies that infinite correction window can be achieved with frame-sized buffer. Can someone shed light at the difference?

^ Which should hopefully answer this question.

And that's whty some users like myself and dellsam34 wrote in the past that a frameTBC may not be necessary, if the lineTBC on the VCR is able to perform well (tapes in good conditions) while lordsmurf's workflow predicts a frameTBC in any case.

The key here is "may not". Average tapes will fail horribly here, so the advice is horribly misleading to newbies. It depends on many factors (all aspects of tape, capture card, workflow hardware in use). In your exact case, I still believe AmaRecTV is "doing something" invisibly (ie, not reporting), rather than some unicorn case where you get no drops. So claiming no drops might not actually be no drops. Most users see huge problems with lack of frame TBC, most evident from audio sync loss.

About the infinite correction window concept, I assume simply refers to the fact that the frameTBC may rebuilds the entire field (or frame)

No.

So every manufacturer producing a device, box, piece of software which somehow acts on the timing signal of the video could call his thingy a "TBC", and he can't be sued for it. So we can only study the manuals and diagrams and try to understand what's under the hood, and eventually run our own tests and draw our own conclusions. Eventually we may give that specific "TBC" functionality a new name (TBC-like, quasi-TBC, TBCish, full-TBC, gimmick-TBC, and so on), in an attempt to qualify and classify it for our purpose.

Yep.

I long ago settled on 3 terms, and these are fairly well adopted by many:
- TBC
- TBC(ish)
- rackmount/pro TBC

The rackmount/pro (or "pizza box") is not meant for consumer sources, and always fails in some way.

The TBC(ish) is devices that sorta-kinda have some TBC-like functionality, such as DVD recorders, mixers, keyers, whatever. Not true TBCs, almost always weaker, almost always side effects or caveats. These are budget realms, and your saved dollars buy you more nuisance in usage. Sometimes lesser quality.

Then actual TBCs, both frame and line (and field, aka multi-line, aka "infinite window"). These are what you want if you value sanity, and quality. Not all are the same, some are flawed (like black AVT-8710), others have issues now (DataVideo TBC-1000 caps, most units popping out now).

...

If I missed something here, ask it again, I'll try to follow up when I have more time. Busy now, skimmed more than read, but trying to help demystify quickly.

[Bwaak]

What I meant with my statemements is clear to me (and apparently to other readers). If you do not understand is your problem, not mine.

You made a statement. I am just asking you to clarify it.

• What is your definition of Frame TBC.
• What do you mean by "the frameTBC helps to do not drop frames, keeping audio and video in synch"?
• How the above functionality is achieved by "Frame TBC" as opposed to "regular TBC"?

For the last half a page you could not give a straight answer.

[lordsmurf]

"regular TBC"?

No such thing exists.