TBC2 with CBV001 etc

1

is there a particular reason why TBC2 is so terrible at time base correction ? I mean the upscaling and other features are great, and it does work well as a dual video input device, but not as a TBC. I tried CBV001, and it does not work even on minimum glitch settings. it is so sensitive that it need another tbc before it if your signal is not 100% perfect.

is this something that might be fixed in a future update or is it a hardware / design thing ?

also I think the idea of being able to play doom on it would be cool, with a midi controller for a controller. why not ?

1 Like
2

The main purpose of a time base corrector is to sync one or more out-of-sync signals, for mixing/switching purposes. (The signals need to have valid or near-valid sync to begin with.) I don’t have a TBC2 myself so grain of salt, but as I understand it, the TBC2 does this pretty well.

In the world of intentionally glitchy video as an art form, a time base corrector is often recommended to stabilize the glitchy video enough that a modern digital devices can handle the signal so as to avoid black or blue screens that indicate loss of signal. Some TBCs are better at this than others, but that’s not because some are “terrible at time base correction” just that some aren’t as tolerant to out-of-spec signals. In other words, using a time base corrector to stabilize artistically glitchy video is a purpose for which they weren’t actually designed.

What I think you’re probably looking for instead of a time base corrector is a sync restorer like the sync_ope. There might be others out there that people can recommend, but this is the only I personally know about.

3 Likes
3

Hi Joe, thanks for the lesson about time base correctors. When I say "is there a particular reason why " I meant like do the designers at LZX actually dislike glitch art and purposefully design their gear not to work with it on principal. the TBC2 has 0% tolerance for glitch devices such as CVB001 so it seems like it could be intentional. Dont get me wrong I love LZX TBC2 but would love it more if it was more robust and take anything that is thrown at it .

I actually tried the Sync Ope , any it doesn’t make any difference to whether the TBC2 will accept the signal, it cuts out instantly. also based on my tests Sync Ope does not completely restore the signal. ,when plugged directly into a capture card it only seemed to improve the signal quality by about 10% , I think next I’m going to try Syntonie Stable. the demo on youtube seems to work very well. so hopefully its going to allow me achieve my full HD gitch potential,

also I need to test TBC2 with a VCR.has anyone on this forum tested this ? I can imagine its just going to cut out and freeze. I have a friend who has one so I might borrow it and check it

4

Ah yeah, I forgot about the Syntonie Stable!

Stable requires non-glitched input at the processor input, and then you take a copy (or modified version) of that input from the processor output, and glitch in your CBV001, then feed the glitched video into Stable’s stabilizer input, and you’ll have stable video from the stabilizer output then. I think this is actually similar to how sync_ope stabilizes video. Is this how you were using the sync_ope, with non-glitched video on the input then taking that video from the video send jack, glitching it, and then feeding it back into the video return and taking your final output from the output jack? As far as I know, that should have helped and made it possible for the TBC2 to accept the video. If you weren’t feeding the sync_ope with a non-glitched signal on the input, though, then I’d expect the result you described. (Similarly, if you don’t feed the Stable with non-glitched input on the processor input, there’s no hope of stabilizing anything.) I don’t have experience with the sync_ope (or the Stable), though, so grain of salt, I don’t know if maybe it has any flaws that prevent it from working the way it’s intended.

2 Likes
5

When TBC2 first came out it was programmed to “hold last frame” whenever it lost signal which it does with glitch. It may still be that way. It should be changeable with a firmware update I believe. For what its worth, the OG CTBC is very tolerant and great with glitch.

6

Not much to add to what @joem said.

Analog to digital video conversion relies on a pixel clock to sample the incoming signal, pixel clock which is derived from the external video sync, so when the sync is invalid (as when process with CBV001), the whole decoding gets tricky as it depends on a unreliable pixel clock.

Then it is possible to have the ADC in free running mode (its own pixel clock unrelated to the external video sync), so the full signal can be sampled regardless of the validity of sync, though it will still asks to “re-clock” the external video and identify sync somehow, and decide what to do when there is no valid sync (hold the last frame, try to display it). So I don’t think TBC2 would be limited by the hardware to support invalid signals, though I imagine it would be a lot of work in the digital realm. And TBC2 does work as intended, which is to bring two asynchronous video sources into the system, upscale/downscale/interlace/deinterlace, and convert them to RGB on a shared sync.

I don’t think it comes from the fact LZX would dislike glitch stuff, it’s just tricky to deal with non-valid signals, and maybe not a priority.

When it comes to broadcast TBCs or digital mixer internal TBCs, it’s important to keep in mind that at the time they were designed, Composite video and VCR where the current standards, which means that video gear manufacturers could have full teams working on those complex digital systems, and addressing common issues like signal stability, because there was enough demand for that.

That’s why I went for another, simpler approach, which is sync restoration like Stable and sync-ope does, as it doesn’t involve any digital signal processing, mostly extracting clean sync from the non-glitch source, and then re-insert it after the signal has been glitched. Combined with black and white level clipping, it ensure that the signal at the output is always valid. Works well with TBC2. Then of course, the hard glitches caused by sync corruption are corrected.

Sync-ope would benefit from a better clipping circuit, as sync re-insertion is important, but black level clipping is as much important, as any signal going under black level will be interpreted as sync by the receiving device. Then it should already help a lot than no stabilisation at all, here is a recording I did with CBV001 and Sync-ope, and it works quite decently https://www.youtube.com/watch?v=bGB2AVLldoQ
Though there is a little bit of instability, I haven’t tried it with TBC2 so maybe it’s not stabilized enough to have it decoded properly.

As mentioned, a sync restorer still relies on a clean sync at its input, so VCR or an already glitched source won’t work unfortunately.

3 Likes
7

Sorry, this is totally wrong. You are confusing TBCs and frame synchronizers. A frame synchronizer takes a nominally good video signal and allows it to be in time with the rest of the signals in an analog video system. The purpose of a real time base corrector is to correct the inaccuracies of an analog tape deck. In fact, an old school TBC will not work as a frame synchronizer - it will need to push the tape deck into the right synchronization via the ‘advanced sync’ connector.

8

Fair point. I guess I should have clarified that I meant a TBC in terms of the LZX TBC2. Either way, neither a TBC nor a frame synchronizer is really good at rebuilding sync that’s been completely destroyed/removed via glitch-art devices.