Do digitizing analog video tapes companies usually use a TBC?

[lollo]

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.

No. Always remember that I have a dvb-s dump of the same program that I recorded some year before and then captured. So I have a reference to check if there are dropped/inserted frames not reported by the capture software.

https://www.youtube.com/watch?v=jVRkQQxODf8
https://www.youtube.com/watch?v=KJ5WSPceqjs&t=4s
https://www.youtube.com/watch?v=1TK159f1-3M

Most users see huge problems with lack of frame TBC, most evident from audio sync loss.

Agree.

edit: added YouTube links

[lollo]

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

[Bwaak]

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

Ok, if you neither intend to explain your statement nor want to retract it, I am going to disregard it.

[lollo]

I am going to disregard it.

Good choice

[Bwaak]

From the below ad I infer that full frame buffer facilitates infinite correction window. Still, it is not clear to me what exactly does it mean. The buffer is needed to absorb imprecise rate of incoming lines, the larger the buffer, the less possible are buffer underruns or overruns, I get this. But buffer underruns and overruns are possible even with frame-sized buffer if the speed on the source machine is not controlled from TBC (I guess this is what "non-servo locked VCRs" from the ad means), in this case the TBC would drop or insert a whole frame instead of showing garbage within a frame.

Does this capability - to drop or insert frames or fields - describe what "infinite" correction window means?



EDIT: another TBC with "full-frame infinite window correction":

[oln]

This source also equates a full frame of buffer with infinite window.

Thinking it probably indicates that it will output a fully stabilized/standards conformant 25/29.97 fps signal at all times whatever the input (which may or may include dropping/inseriting frames). A tbc with only some lines of buffer like some that are found in vcrs don't do this (hence the talk of using "frame tbcs" to avoid desync/drops at the capture card level even with a built in vcr tbc). I guess one wouldn't technically HAVE to do that with 1+ frame of buffer though.

EDIT: that article you referenced earlier does seem to differentiate between infinite correction window and ">525 lines" / "5-field PAL" / "1 frame" so not sure now.

[lordsmurf]

This source also equates a full frame of buffer with infinite window.

Nope.

Read it again:

Modern day TBCs, with their vast digital memory, can correct up to an entire field (262.5 scan lines) of incoming video. These are known as “infinite window” TBCs (obviously more effective than the two line correction capability of some “TBCs” built into high-end consumer VCRs).

That refers to a whole field.

You can have "infinite lines" (aka whole field) without dumping RAM buffer, but you can't have "infinite frames" without dumping the RAM buffer.

....

Stop putting faith in marketing materials. The folks who write those rarely have more than tenuous grasp of the tech being discussed. Lots of confusing and nonsensical BS is found in technical marketing materials all the time. Even the manuals can be this way.

Look up "technical copy writer" sometime. That's who does this. They get notes, or a quick conversation from the engineer/dev/whoever. And then it's their job not to screw it up. Too often the copywriter doesn't get a followup to confirm that they wrote it correctly. The person who signs off on the material, sends it to print, usually knows even less than the copy writer did. It's a clusterfuck of misinformation.

This has gotten far worse in the online era, but was especially bad in the 90s and 00s, early online years.

the larger the buffer, the less possible are buffer underruns or overruns, I get this

Under Siege movie: "A gigabyte of RAM should do the trick"

[Bwaak]

Thinking it probably indicates that it will output a fully stabilized/standards conformant 25/29.97 fps signal at all times whatever the input (which may or may include dropping/inseriting frames). A tbc with only some lines of buffer like some that are found in vcrs don't do this (hence the talk of using "frame tbcs" to avoid desync/drops at the capture card level even with a built in vcr tbc). I guess one wouldn't technically HAVE to do that with 1+ frame of buffer though.

So far I haven't heard convincing explanation of how a TBC with full-frame memory can prevent frame drops, considering that the playback speed of a source machine is not being continuously corrected by an external TBC and can, supposedly, get more than one frame apart from the perfect sync.

On the other hand, all VCRs have built-in servo, which may not be precise enough to ensure H-sync without TBC, but is reasonably precise to ensure V-sync, otherwise we would not see normal picture. Maybe even a non-servo-locked VCR does not drift more than 1 frame in real life.

So maybe this is the reason for the frame TBC claim: to have buffer large enough to account for the biggest drift that can happen realistically.

--

The claim that "line TBC" built into VCRs is insufficient does not hold water IMO, considering that (1) back in the 1980s 32-line memory was considered enough for heterodyned video (that is, color under formats like VHS or Hi8 or Umatic), and that (2) a built-in TBC should be more intimately linked to VCR mechanism, improving its precision beyond regular V-sync.

Maybe the desirability of frame TBC is to use the memory to replace a whole field of frame in case of really bad video, which, I guess was not considered back then in professional usage. For smaller issues there is dropout compensation that can replace one or several lines using either adjacent lines of the same field/frame, or lines from a prior field/frame. OTOH, even a single repeated frame is often visible, so I am not sure whether I would prefer a half-damaged frame or a frozen replacement. In any case, if there are few damaged frames, they can be replaced in an NLE, so all TBC has to do is provide uninterrupted sync during the damaged section.

In the early 1980s it was predicted that standalone TBCs would become extinct, replaced with built-in TBCs. According to industry analysts, this did not happen because a zillion of different formats required sync and conversion. Also, because TBC does analog conversion as well as A/D/A conversion and it also delays signal up to a whole field or frame, it was advised to edit/dub without TBC, and use it only for the final dub or directly for broadcast.

that article you referenced earlier does seem to differentiate between infinite correction window and ">525 lines" / "5-field PAL" / "1 frame" so not sure now.

That threw me off as well, so I am still not sure whether these are different things, or just different terminology used by manufacturers and printed verbatim.

[Bwaak]

Standalone TBCs from late 1980s:



Frame synchronizer, TBC and genlock:

[lordsmurf]

So far I haven't heard convincing explanation

I don't think you're approaching this topic correctly. You seem to have (wrongly?) made up your mind about what a TBC is (or is not), and are randomly referring to random documents/images found online as "proof" of whatever. Why should we "convince" you of anything?

For example, ancient rackmount broadcast TBCs have almost zero in common with modern TBCs intended for consumer analog sources.
And FYI, that's why those junk units were on eBay for years for less than $50, worthless to modern needs, bought (and later resold) only by gullible/unknowledgeable newbies. Eventually the crap just got (properly) recycled, and you see less of it cluttering listings now.

How many actual TBCs have you used, tested, taken apart, reverse engineered, etc?
None? Because I'm betting none.

[dellsam34]

I bet if you look hard enough you will find a website calling a signal pulse generator a TBC, Lol.

[Bwaak]

Ok, after two pages going back and forth I figured out for myself what "line TBC" and "frame TBC" are: these are non-standard terms used primarily on this forum and a couple of other ones that describe a TBC with correction window smaller than a field, and a TBC with correction window that can fit a whole frame, respectively.

In the process I found out that some forum members are eager to disparage others' words and videos despite that a particular video I linked described the functions of a particular TBC/FS in full accordance to the user manual. It would be foolish to expect these members to apologize.

It also became evident that some forum members confuse frame synchronizer with A/V synchronizer and ascribe specific functionality to "line" and "frame" TBC. They claim that "frame TBC" cannot be found on playback decks, which is not true, there are decks that have frame-sized buffer.

Some members claim that frame TBC can reduce or even completely prevent frame drops, but they could not explain how this result is achieved. Another dubious claim that consumer-grade TBCs perform better on consumer-grade video sources than pro TBCs was not reasonably supported. In fact I provided a table that shows that in late 1980s pro TBCs included consumer-grade connectors like SVideo, because SVHS and Hi8 were used professionally in low-budget operations.

All in all, some members possess vast acumen from experimenting with different devices, but have little theoretical knowledge and do not follow industry-standard terminology. What is worse, even when using their own terms, they often cannot support their claims.

[oln]

Some members claim that frame TBC can reduce or even completely prevent frame drops, but they could not explain how this result is achieved.

I don't think it's possible to entirely prevent drops/inserts in the TBC unit itself unless the vcr is servo locked to it which only some professional vcrs are capable off (or a tbc that's part of the VCR itself) at least as there will inevitably be some drift between the clocks in the vcr and tbc. How well they handle other signal issues will vary depending on implementation. They are capable of producing a stable signal out of the tbc for a capture device to ingest and prevents any more drops/inserts/desync at the capture side which is one purpose of using them for video capture. Nearly all Capture devices lack the buffering and such to do that even if they use the same video decoder chip as in the TBC.

Some members specifically want models that handle the output from the Prosumer JVC and Panasonic SVHS VCRs with built-in TBC (which do not seem to ensure an entirely stable output signal on their own) well, and that will not act up with copy protected tapes and tend to dismiss anything else not acting similarly. The TBCs in question (datavideo TBC-x000 /avt-8710 and the like) don't really feature the capability to correct horizontal instability to a very large degree so they don't work all that great with other vcrs that lack a built-in TBC so whether they perform "better" on consumer tapes kinda depends a bit on the setup. That's not to say that there won't be variance between pro units and newer/older tech on how well they will work on a shoddy nth gen EP recording though.

[lordsmurf]

I bet if you look hard enough you will find a website calling a signal pulse generator a TBC, Lol.

Probably. I've seen some wonky crap called "TBC" before. I get irritated when technobabble enters the fray, such as "double/triple buffer" or whatever.

Ok, after two pages going back and forth I figured out for myself what "line TBC" and "frame TBC" are: these are non-standard terms used primarily on this forum and a couple of other ones that describe a TBC with correction window smaller than a field, and a TBC with correction window that can fit a whole frame, respectively.

No.

In the process I found out that some forum members are eager to disparage others' words and videos despite that a particular video I linked described the functions of a particular TBC/FS in full accordance to the user manual.

You linked a jabberwocky video from Youtube. The Youtuber didn't know his ass from his elbow, in terms of TBCs. He mixed stuff up, and anybody that watches it will walk away dumber for seeing it.

It also became evident that some forum members confuse frame synchronizer with A/V synchronizer and ascribe specific functionality to "line" and "frame" TBC.

No.

They claim that "frame TBC" cannot be found on playback decks, which is not true, there are decks that have frame-sized buffer.

Specify your claim.

Some members claim that frame TBC can reduce or even completely prevent frame drops,

Correct. That is the exact function of frame sync TBCs, referring specifically to those designed for use with the vastly-more-unstable consumer analog sources.

but they could not explain how this result is achieved.

You confuse inability with lack of want (due to lack of time).

Another dubious claim that consumer-grade TBCs perform better on consumer-grade video sources than pro TBCs was not reasonably supported.

You're screwing up terms again. There is no "consumer-grade TBC", but rather TBCs made for consumer sources. Furthermore, "pro" TBCs, assuming you refer to broadcast type units, were designed for different sources. Those are confused by the chaos that is consumer analog, and fail miserably. But this conversation gets more complex when you discuss something like U-matic, which was not clean, but yet still had different needs.

In fact I provided a table that shows that in late 1980s pro TBCs

Completely worthless info in the digital era of consumer source conversion.

included consumer-grade connectors like SVideo, because SVHS and Hi8 were used professionally in low-budget operations.

Did you ever work with S-VHS or Hi8 video in that era? Because if you had, you'd not say such things. There were multiple issues using lower end sources, and it's a reason that high school and local cable channels looked like crap. (Of course, those same sources, now, can look excellent on transfer, with modern gear in a proper workflow.)

industry-standard terminology.

No such thing exists for "TBC".

That's not to say that there won't be variance between pro units and newer/older tech on how well they will work on a shoddy nth gen EP recording though.

Huge, huge variance here. Often unacceptable. Many actually make the video more unstable, in trying to lock (or not lock) as it would to the expected non-consumer sources. That's the entire problem. Bwaak is completely unaware of, for example, certain version of certain TBCs that specifically have a "VHS mode" and "BetacamSP mode", due to such aspects. Those were from that odd 00s time that blended analog and digital production.

[dellsam34]

I don't think it's possible to entirely prevent drops/inserts in the TBC unit itself unless the vcr is servo locked to it which only some professional vcrs are capable off (or a tbc that's part of the VCR itself) at least as there will inevitably be some drift between the clocks in the vcr and tbc. How well they handle other signal issues will vary depending on implementation. They are capable of producing a stable signal out of the tbc for a capture device to ingest and prevents any more drops/inserts/desync at the capture side which is one purpose of using them for video capture. Nearly all Capture devices lack the buffering and such to do that even if they use the same video decoder chip as in the TBC.

It doesn't have to be servo locked to the VCR, Depends on the design, Most frame TBCs use the VBI in the luma signal to correct the flow of data or clock and generating a new clean one there on, These are usually designed for consumer players. Some designs have the capability to either use an external timing signal or the VBI from the video itself, They can also use an internal clock in the event of a complete absence or weak VBI signal, these usually found in the pro analog to digital converters, I demonstarted this on my YT channel with blank tapes. So yes frame TBC's can prevent frame drop.

There is no "consumer-grade TBC", but rather TBCs made for consumer sources. Furthermore, "pro" TBCs, assuming you refer to broadcast type units, were designed for different sources. Those are confused by the chaos that is consumer analog, and fail miserably. But this conversation gets more complex when you discuss something like U-matic, which was not clean, but yet still had different needs.

There are probably hundreds of TBC designs, Most of them are proprietary companies' secret designs, Apart from marketing terminolgy, there were no standards or rules governed this field, Every manufacturer used their own nomenclature.

[Bwaak]

It doesn't have to be servo locked to the VCR, Depends on the design, Most frame TBCs use the VBI in the luma signal to correct the flow of data or clock and generating a new clean one there on, These are usually designed for consumer players. Some designs have the capability to either use an external timing signal or the VBI from the video itself, They can also use an internal clock in the event of a complete absence or weak VBI signal, these usually found in the pro analog to digital converters, I demonstarted this on my YT channel with blank tapes. So yes frame TBC's can prevent frame drop.

Are you saying that such a consumer TBC would sync not to a precise internal clock or to external clock (sync generator) or to another video (genlock), but to V-sync of the same video it is correcting? This would result in a non-standard frame rate.

This also may result in slightly wider or narrower frame due to shortened or increased time per line... but maybe this is not a big deal for digital, and with a frame-sized buffer the lines can be rescaled to the correct length.

Can you name a make and model of a TBC that does this? Does it mention this feature in the user's manual?

[Cornucopia]

I believe what dellsam34 is saying is that some units will read the V-sync as a trigger for marking that as a starting/stopping point and then use those markers' regions to map to known-proper (internal or external, but usually internal clock) sync timing, which given a big enough buffer can then be output at the proper time. With enough bandwidth, this could be done for H-sync as well, and I expect that is part of what that longstanding LD/VHS capture method in another thread has going for it (that and RF capture).

Scott

[dellsam34]

Correct Scott, It's the blind man analogy, As long as he is walking fine leave him alone, If he started to deviate give him a little hand to correct him. That's the whole reason why we have 60 fps and 50 fps today, Camera's and TV's were locked to the mains frequency and VCR's record that on the tape for playback reference.

[Bwaak]

That's the whole reason why we have 60 fps and 50 fps today, Camera's and TV's were locked to the mains frequency and VCR's record that on the tape for playback reference.

Actually, cameras and TVs were not locked to the mains frequency. All the sync pulses were generated in a studio. The signal would be broadcast to home TVs, which would sync themselves using pulses in the signal. Yes, vertical frequency was chosen to match mains frequency to eliminate AC ripple ("hum") to avoid weaving motion on TV screen. But this is off topic.

[lordsmurf]

I'm fairly certain that Bwaak is somebody we already know.

His contrarian nature, and faux "expertise", is betraying him. Along with the habit of using random info online (Google Books, Youtube, etc) as "proof" of whatever. But it's taken out of context or outright misunderstood by him.

I'm amused at the multiple attempts to play victim ("some members being are mean to me, wah!"; translation: "they're calling me out on my BS, no fair!"), and it's being completely ignored (as it should be). It's truly comedic to see a person go from deer-in-headlights over basic aspects (ie, what is TBC), then suddenly become an expert on analog broadcast signal processing.

I hope other newbies don't fall for that sort of "Google expert" BS. Nor think he's asking serious questions, and see it as the trolling it is.

[lollo]

Our old friend ConsumerDV, but I think he's a nice person (tech stuff apart)