Software TBC that doesn't need the frame edges?
 

Reading some of the forum posts regarding jmac689's attempt at creating a software TBC has inspired me to start my own attempt at creating a software TBC. I've just wrote a conceptual software TBC that demonstrates my idea and it's already showing promising results.

In plain English, it's an algorithm that continually shifts and scales the lines of an image in order to reduce the amount of vertical edges present on the image. It can take advantage of the GPU and takes a few seconds per image.

These example images were captured using a JVC SR-MV45 VCR with the built-in TBC/NR turned off, a For.A FA-125 external TBC, and a Pinnacle 710-USB capture card.

Let's start with a basic example:

Admin refused to unhide hidden content
nothing will help to see hidden content

As you can see, the oscillation of the jitter has been considerably reduced. It isn't perfect, however, but it's definitely better. For this example, though, you could just use the edges of the frame for reference to correct the jitter; a technique done this way would potentially look better than the technique I'm using.

But perhaps the biggest key advantage of this technique is that it can still reduce horizontal jitter even when the edges of the frame are not visible!

The original capture of this next image did have the edges of the frame visible, but for this demonstration I've clipped the heck out of the blacks before feeding it to the software TBC. Now there is absolutely no frame edges to adjust to!

Admin refused to unhide hidden content
nothing will help to see hidden content

Evidently, the main issue with the end result is that the title is noticeably distorted. This is mainly because this software TBC does not account for temporal motion yet. Once I add some code to account for temporal motion, the results may look even better. Still, not bad at all!

Of course, this algorithm isn't perfect by any means. A few seconds per frame is considerably slow, and as you saw with the last example there can be distortion present in the final result. Also I've only tested this algorithm on two examples, but I'd like to get some additional examples of content to try it out on.

The other problem is that sometimes the software TBC widens the entire image (see the first example). A very simple solution is to "normalize" the line shifting parameters so that there is no global scaling adjustment.

For these demonstrations I didn't separate the fields before applying the algorithm. It's an essential step for practical purposes but the oscillation of the horizontal jitter was smooth enough that I didn't bother to.

For the moment, I've implemented this algorithm in Python, using the PyTorch library (so this software TBC is technically using deep learning technology, but it's not actually deep learning). Therefore, it would most likely be packaged as a VapourSynth filter if, in the future, I make this software TBC available publicly.

That's all, for now. I'll keep fine-tuning this algorithm and hopefully get my hands on some more examples to try it on.

Finally i was waiting for someone to use Jmac's ideas.if i can help you somehow (not coding) let me know

I will always fully support the creation of a software TBC as much as I can. For example, submitting captures/recordings, of varying degrees, in need of correction, since I have a large body of test tapes and homemade DVDs (made by others, with not-great equipment).

Not trying to squash your effort but if you have coding skills maybe you can join the VHS decode project and get the ball rolling:

This could be great in cases where the tapes are not accessible any more but there is a digital copy in a reasonable quality. I have lots of mpeg2 files, interlaced and encoded at crazy bitrate hoping for something like that. Looking forward to this, and to the source code too!

Yeah I mostly need help with getting some good test clips (already sent lordsmurf a PM about this, but it would also be nice to have test clips from others). The more test clips, the better.

I've thought about that, actually. Maybe I'll help out once I'm finished with this project (except that software is technically never finished, it is either maintained or abandoned).

I think software TBC is far more valuable than RF capture ever will be. While it would be interesting to see RF succeed, it will not be a game-changer for capturing. A software TBC, however, will be.

I have no time to put together clips right now. However, I do immediately know of a homemade DVD with issues, and a DVD released without issues. That may prove very useful for this research. And that I can start uploading that very soon, sometime next week. (Feel free to nudge me via PM next week, if I've not uploaded by then.)

You can do both, You don't have to have the capture setup, You can grab RF files that have already been captured and work on them, The thread has a lot of posts with links to download such files.

Oh that's cool.

--------

Quick update here: I've made a couple of changes to the algorithm. I was able to fix the scaling problem I mentioned in the original post, and I added code to separate the fields and process each one separately. I've also reorganized the code so that it'll allow me to apply this algorithm to entire videos instead of a single image. I still haven't added code to account for temporal consistency yet, though.

While scouring through forum threads of software TBC discussions I came across a comparison video of jmac's software TBC using a Robotech commercial for the material. I figured I'd download it, crop jmac's software TBC version out of the frame and pass only the original untouched part through my own software TBC. Each frame took a little less than 1fps to process.

And, here's how that turned out...



The top left is the original capture. The top right is jmac's software TBC. The bottom center is my own software TBC (currently dubbed "Virtual TBC 1" or "vTBC1").

I will say that there are only a few areas were jmac's TBC beats out mine, mostly where frame edges are available for tracking (such as the text at the end). Despite my result being a bit wobbly, I find it way more watchable than the original capture (and even most of jmac's). What's especially notable is that the original video I had wasn't even an interlaced encode, it was a pretty compressed MPEG-4 progressive file that contained both fields per frame (so there's blending and blocking being shared between the fields, not an ideal situation).

I've noticed in my internal testing that when the fields aren't separated and both fields contain the same image, the end result is definitely cleaner. I had to separate the fields, though, for this algorithm to be more practical. For improved results, I would imagine that for each frame, two versions of the image would be passed through the TBC: one with both fields as a progressive image and one where the fields were separated. Then there would be some criterion that would check which one produced "better" results (probably by checking how many vertical edges there are in the images, and picking the one with the least).

A thought that has popped up in my mind not much later after I made the first post, is that the best way to create an ideal software TBC is not to create just one, but create multiple, one with each different approach. Or, you make one software TBC but it's highly adjustable. This is because, especially for a complex problem like software TBC, an attempt to create a "one-size-fits-all" solution is a path to failure and suffering. No matter how advanced your software is and how many cases it can cover, there will always be a specific case or purpose it's best at. So if you create multiple pieces of specific purpose software, and pick and choose each one for each situation, you end up with an overall better result. Of course, one still has to be conservative with how many different versions of the same software they make, or else which one to use gets more and more confusing.

The demo I posted above proves this point. You can see how sometimes jmac's TBC beats mine out, when it's able to accurately track the frame edges. So if there were some "hybrid" solution between his and mine, where it would use his solution where the frame edges can be tracked and fallback to mine where it can't, then results could potentially be even better.

I hate to double post but I was hoping for someone else to respond before I made this update post, lol. (And I can't edit my previous one either, but this update is big enough.)


Progress update: Yesterday and the day before, I did a crapton of tweaking and experimentation with the software TBC, trying all sorts of different things and see which helped it and which didn't. Not only have I managed to speed up the algorithm by more than three times (now able to process at 3-4fps instead of 1fps), but I managed to significantly improve the visual quality of the results as well as the stability.

Provided here is an updated comparison video:



Top left is original capture (same as previous post), top right is jmac698's software TBC, bottom center is the most recent revision of my software TBC as of this writing.

I still haven't written anything to account for motion tracking yet.

The quality of this TBC has reached to a level where I will be taking a break from development on for a bit. I will resume development once I get some more test clips from lordsmurf. I am mainly doing this because I don't want to focus on development for only one test video only to realize it won't work as well for all the other test videos.

------

Nitpick thing here: is the question mark at the end of the title automatically added or was that added by an admin? I personally find having the question mark in the title a bit weird (I didn't originally add it there) because to me it makes the title sound like I'm asking for a software TBC (which I'm not), rather than presenting one.

Wonder how much of that mess a line TBC inside a VCR can fix on the original tape? it will be an interesting comparison.

Hi imgkd. Your window in comp2.mp4 looks fantastic compared to the other two! Great job. Of course, without the original for reference, someone just looking at the completed clip would still immediately notice something is very wrong.

I'm not Sir Smurfy, but here is one sample of multi-gen VHS -> DVDR that I acquired online. This one suffers from over-compression in addition to heavy timebase errors that appear to vary based on scene brightness. (White background = outright flashing of the entire frame!)

I have samples of other content, but which are you most interested in: super-screwed examples like this, or more mild? Do you want some captures with TBC off vs TBC on, where possible?

Thanks. Yeah it still definitely needs work, but I’ve been considering some ideas to further improve the results.

That sounds like an interesting sample. I’ll check it out later today.

I’m interested in both mild and super-screwed. TBC off vs TBC on might be useful as well for a “ground truth” comparison.

I would like to announce that this project has officially been resumed.

Just today I found yet another tweak that improved the quality of the results. Not big enough to post yet another comparison video, but definitely noticeable.

Second, I've been re-re-revisiting the conversations jmac had on his project and will take some of those posts for possible inspiration.

Thirdly, I've decided that there will be three types of software TBCs: spatial TBCs, temporal TBCs, and registration TBCs. Each type will have its own use cases:

• Spatial TBC - Corrects each field independently. Useful for sources with limited temporal correlation or as a prepass for seriously degraded sources.
• Temporal TBC - Corrects each field using neighboring fields. Useful for most sources with moderate to high temporal correlation, good for reducing smooth wobble.
• Registration TBC - Aligns each field to a reference field. Useful for aligning a wobbly source + superior detail with a non-wobbly source + inferior detail.

Spatial TBCs will probably have the most effort dumped onto them as the other two types are built on how Spatial TBCs work.

Lordsmurf once suggested an idea on Doom9 to apply heavy temporal NR to reduce the wobbliness, and use that as a reference. From some very very limited experimentation it is evident that this idea works better for some denoisers than others. So far my best luck has been with hqdn3d; however there's tons of ghosting, and it doesn't perform motion compensation. MCTemporalDenoise sort of works but doesn't reduce the detail enough to remove the wobbliness. I will continue to scour through more NR filters (I'm feeling like dfttestMC might be the right fit.) Note that I haven't tested the full idea (with the line alignment and everything), just the part with using the NR to remove the wobbliness.

In addition to using temporal NR + registration TBC, I've also been exploring ideas on borrowing concepts from image denoisers to improve spatial and temporal TBCs. For example, for each patch in the field a non-local search of the closest patches are found and grouped together. Then the lines are shifted such that all the patches are as similar to each other as possible. Extending this to become a temporal TBC is quite simple: search patches among multiple fields and not just the current one. To make this practically work, the similarity metric for the patch searching would have to be robust to line misalignments, and the similarity metric for the optimization part of the system would have to be stricter. Perhaps the patches are searched at multiple scales and deformations to further strengthen the optimization.

What's also evident from analyzing some of the samples is that there are a few different kinds of jitter: there's the smooth wobbly kind, the rough jagged kind (such as the Robotech sample), and the extremely severe but much less frequent jitter. Tackling the latter would involve processes similar to film dirt removal: have a process for masking out the "non-jitter" parts (using a combination of vertical delta thresholding and temporal detection), and make the optimization extremely severe. This would undoubtedly require a dedicated temporal TBC.

Shortly after writing the post above (can't edit the previous post since too much time has gone by), I had a semi-major lightbulb moment for creating a simple temporal TBC: Grab a few frames, transform the frames such that each new frame is now a time slice of all the frames for each line, run those new frames through the spatial TBC, then undo the transformation to get the stabilized frames.

It didn't take me long to apply this idea, and it totally works.

However, as a consequence of this idea the temporal TBC (now named "Temporal TBC 1", the previous TBC now being "Spatial TBC 1") only looks at each line independently throughout each group of frames, it doesn't account for spatial smoothness at the same time. What this means is that, temporally, objects that stay still have zero wobble, but they appear slightly less smooth. To solve this, I used a 2-pass pipeline, which I detail out in the demo explanation.

Currently, Temporal TBC 1 filters 180 frames (360 fields) at a time. So that's roughly 6 seconds worth of data for each line to stabilize. No overlap, so theoretically there could be jumps in the line positions every 6 seconds, but I don't see it at all.

For this new demo I picked a different sample that Lordsmurf has PMed me.

The left is the original clip.
The right is the same clip run through the following pipeline: Spatial TBC 1 > Temporal TBC 1 > Spatial TBC 1 (1/3rd strength) > Temporal TBC 1 (1/3rd strength).



Due to the very primitive "motion compensation", the second shot in the trailer is the least treated, since everything is moving at a faster rate. OTOH, check out the frames at around the 15-second mark.

You'll notice that the lines are not quite perfectly straightened, but they're certainly more straightened than the original clip.

Temporal TBC 1, when used in conjunction with Spatial TBC 1, appears to be extremely effective for clips such as this one. However, more complex techniques involving proper motion compensation may produce even better results. Not to mention that this 2-pass method I did is quite slow (both TBCs approximately operate at 3-4fps, but it's being run a total of four times, which makes it slightly less than 1fps).

Oh wow ... wow wow wow :) ... I've wanted to see some clean-up on this for 20+ years now.

Can you upload that as either lossless AVI, or high bitrate (low CQ, like 10) 4:2:2 H.264?

That's really quite good.
Not perfect, but way better.
As of now, I'd be willing to say that TBC, for this clip, has the power of ... hmm ... not an ES10/15, at least as good as a weak ES20/ES25, maybe a choking JVC or Panasonic, much better than ADVC-300 super-weak. That's a compliment!

I was just thinking of you a few days ago. I lost the link to this thread (honestly forget we even had a thread, just remember the PMs), and was crawling through my nightmare of a PM box trying to remember your username (take no offense, my memory of names and dates has always sucked; women always loved that! :laugh:).

Heavy NR can defeat some errors, but the side effects are always hard to overcome. As I recently wrote in a VH post about herringbone, sometimes the only cure is to "beat it death with NR". That's a terrible solution, but I'm really glad it gave you an idea -- especially on this topic.

Sometimes Avisynth stuff is literally headache-inducing frustration for me, and jmac's stuff was hard to understand (for me). So I'm really glad his research is paying off, as I told him everything I could think of, gave him samples, and even gave him a TBC for shipping costs (< yeah, I've wanted a software TBC for a long, long time! but also noting it was a flawed unit that I picked up cheap at the time, 10+ years ago)

Bah, not afraid of 1fps. I recently tried some insane AA methods, and it was 0.1fps. :laugh:
I remember 2fps with QTGMC when still in infancy on old single-core P4 hardware.
3-4fps for some that looks back+forward is actually quite good.
Also remember Avisynth+ x64 and MT modes, and for preview AvsPmod x64, and VirtualDub2 x64. Was that taken into account for the fps?

There is another technique you may want to look into, in terms of back+forward+NR. This is the method used for de-dropout, but it is extremely harsh. This is an area where I want to learn more Avisynth, to tweak it, which is something nobody has ever done (that I have seen) with this complex code. I have, and gotten it to be less damaging, but it's still entirely NOT feasible for some clips (namely cartoons). That's a big script that I'll have to attach to a reply post, I'm not on my main video restore system at the moment. Perhaps you can learn how to tamp down the negative effects, and keep the positives?

This software TBC is important to me, and I'll always try to drop what I'm doing to help however needed. If you need or want more samples, I'll see what I can dig up. I know of a few uglies, and I can give you some actual ES10 performance with the same tape to shoot for.

You can always email me if needed. If you don't already have it, PM me.

Thanks! Yeah, definitely not perfect (and I bet you Temporal TBC 1 will fail horribly on live-action footage), but I've got plenty of ideas left.
Also the fact that it's good enough for you to start comparing it to actual hardware with semi-functioning "TBC" functionality is an achievement in itself.

The lossless AVI of the processed video weighs in at 204MB, a bit much for the standard forum attachments. I don't have Premium Member either (so FTP isn't really an option, though I should really consider getting Premium Member). (And free file sharing sites here are discouraged as well for good reasons.)

Doesn't help that my username is five letters, isn't a proper word and has almost no vowels, lol.

Funny you mention that herringbone thread, I literally just read that thread before making my last post.

jmac's own posts made some sense for me, but TBH most of it didn't really seem relevant (most of it was toying around with "relative TBCs" and hacking capture drivers).

These software TBCs are implemented in Python, so it's 100% independent of Avisynth or even Vapoursynth. Writing this stuff in Python gives me a lot of access to a bunch of well-established machine learning and computer vision libraries which allow me to prototype stuff like this a lot faster. When I deem that these TBCs are ready for public release I'll port them to C (hoping I can have the core algorithms in one section and then "adapters" to produce Vapoursynth and Avisynth filters). FYI, I actually have never written an Avisynth filter before, though I've messed around with and studied a little bit of C and C++ in the past. I'm confident I can find my way through the SDK.

Thanks, yeah the more samples the better. I'm interested in all sorts of use cases for TBCs, to cover as much forms of jitter and types of videos as possible.


EDIT: Missed a section from Lordsmurf's post:
Hmm... would be curious to see.

I gave this clip a quick treatment, to enjoyably view. And enjoyable it now be! :D

Of course, it can always get better.
But it's come a long, long way.

See attached.
This is mostly me playing around.
It's aggressive with sharpness and NR, some stabilization and chroma work, quick audio treatment.

BTW: The reason for the aggressive sharpness? To stress test the interlace and timing wiggle. It can really pull out flaws. The IVTC came before that, but still.

Do you have the "super ones" (ch11) commercial, same movie? That has even more meaning to me.
All of the non-credit for this particular clip (in this thread here) can actually be rebuilt using the Megazone 23 BD or DVD. The spinning Robotech logo can be recreated in After Effects from scans of the logo. The Cannon credit page also recreated. But the ch11 footage is unique, does not exist anywhere else

I need to digitize the whole tape again, post-movie bonuses, using AG-1980P with no NR. It has several samples of damage, from minimal to moderate to insane.

Avisynth is great and all, but I don't really see a need to port this, as Avisynth will have limitations that your own software may not. Something this heavy may need to have its own environment, variables, interface, etc.

Have you looked into AI algorithms for doing this? People are accomplishing some pretty crazy things on images and video using AI and Machine learning these days. Maybe you could train one of these neural networks designed for video using both originals, good captures and bad captures with lots of wiggling of the same material to try to transform the bad captures into something closer to the original.

As far as Robotech samples go I only have this one, the one I used previously for comparisons with jmac (see earlier posts), and then two live-action footage pieces with what appear to be "interviews". That's all.

Good point on not needing to port to Avisynth, we may indeed need a dedicated interface especially for some of the heavier/more manual work.

Spatial TBC 1 and Temporal TBC 1 utilize something called "stochastic optimization", which is indeed a component used in training neural networks. However, I don't think it's enough to call either TBC "AI".

With a standard supervised neural network system you need to have many training samples of TBCed vs non-TBCed clips, which are quite difficult to obtain, especially for a very wide range of types of videos (cartoon, live-action, high detail, low detail, etc.) and jitter (smooth wobble, jagged wobble, etc.) that a practical set of software TBC tools need to cover. The other alternatives are unsupervised neural networks and "untrained" neural networks (which is an unsupervised neural network being trained on-the-spot). Unsupervised neural networks may be more robust to many examples but aren't going to perform as well in general. Untrained neural networks can visually output superior results but are very very memory- and time-hungry.

I will consider exploring neural networks for TBCs, but I don't expect them to be the de facto TBCs for the reasons mentioned above.

Hi did see this about paper-shredder machines how to reconstruction of strip-shredded text documents i was thinking if there is some help or tips how to do software TBC :)

http://sibgrapi.sid.inpe.br/col/sid....%20ID%2088.pdf

and

https://github.com/thiagopx/deeprec-sib18

are you using OpenCV library in python for this ?

i have tested it a little in c++ language but im not a programmer
vhs maybe to bad quality to use Edge Detection like this https://medium.com/sicara/opencv-edg...l-7c3303f10788 to align the fields
just thinking out loud :)

Strip-shedded text document reconstruction appears to be a very different problem from software TBC. In software TBC we already know the orders of the lines and we can rely on the overall picture details to a limited extent (the extent depends on the amount of jitter). In strip-shredded text document reconstruction the order of the pieces is completely unknown.

For Spatial TBC 1 and Temporal TBC 1 I'm just using PyTorch. I'm going to explore a few more ideas, some of which will use stuff from OpenCV.

That's just Canny edge detection, which in fact I might end up using for some of my ideas. However it's going to detect a lot of vertical edges that come from the jitter rather than the edges that are part of the "non-jittered" image (at least in lower settings). In some ways this could be used to an advantage.

ok interesting to see how it progress :)

imgkd any progress on the TBC software :)

i myself have been testing jmac698 TBC V0.61 and trying to understand how it works
if i understand it use a gradient mask to detect better the left and right side edges like this Picture i Attached it

and then use minmax() function to detect the lowest pixel value at every line here is that function POST Nr:3 https://forum.doom9.org/showthread.php?t=162790

and with that it creates a clip that is 2 pixel wide and that have the inputs clips hight

2 pixel wide because Left half side lowest pixel value and Right half side lowest pixel value

and that creats the offset clip that goes then in to the Rescale() function and that use the dejitter() function to offset the line by the lowest pixel value per line

example if the luma value is 3 it shift it 3 pixels then to the right or left

but this is my best guess about jmac698 TBC how it works

i did use RemoveGrain(11) on the clip i did input to the findpos_h() function that creats the offset clip and that did help little

i was thinking if it's better to resize the video only vertical to get something to work better in the tbc software

i did test this function to RemoveDeadPixels(x, 1, 7, 255) to change the lowest pixel to white X in the parameter is the horizontal coordinate to the pixel to change to white and then use a align function to align

more info here about RemoveDeadPixels function POST Nr:11 https://forum.doom9.org/showthread.p...915#post699915

a good old app to pixel peeping i use is Mouse zoom 1.5

I've written down a couple new ideas to try out, and have been developing one idea in particular, but that's all. No new TBCs to show for now, though.

I've mostly been waiting for LS to give me some more samples so I can test out these TBCs on a wider variety of content.

Given the sheer novelty of this stuff (as something that actually works), I have been entertaining the thought of developing this into proprietary software. If I start being less specific in future posts, this is why.

jmac's software TBC project is mainly considered a failure outside of a few toy samples*.

The main problem is that if you're producing a piece of software that relies purely on the image content, such as software TBC, it is by definition a computer vision problem. You must treat it like a computer vision problem. Jmac didn't treat it like one. (He proposed later ideas that were closer, but he never actually prototyped them.)

One may argue that jmac's TBC relies on the black borders. But what are "black borders"? In real-world cases they're almost never black, the borders are not always reliable, and regardless it's still part of the image content. And often times you don't have the borders at all (a good software TBC shouldn't need the borders).

Computer vision is a major (and very broad) field consisting of tons of tools, various algorithms, and various high-level methodologies. So to write a good software TBC (or in reality, multiple software TBCs), you need to study lots of techniques in the computer vision field and have a basic understanding of how they work, their pros and cons and what they're best for. Followed by lots of trial and error.

This is what makes my suite of software TBCs distinct from Jmac's prototype.

--------

Also, I believe Jmac details this algorithm in the first post of the filter:

My interpretation of this is it creates a video with only completely white and completely black pixels, where the white ones are pixels that are brighter than the threshold, and the black ones otherwise. Then the left-most and right-most white pixels are used to determine where the jitter is.

There are many different types of jitter. That idea may work for more "jagged" sources, but that, or any sort of purely spatial techniques for that matter, won't work at all for smooth wobble-type jitter.

--------

*To contrast this, the only thing I'm using to test my software TBCs are real-world examples. Therefore, if the TBCs work, they work on real-world samples.

ok thanks for the update and information :)

Any progress on this? this looks like something I could greatly use as I am having a hard time finding a Field TBC tht isnt an arm and a leg in price, and my VCR only has a line tbc.

As a dev, I think python is the better choice, especially with all the integrations you can do in the future with AI/ML. Even if we dont train our own, existing stuff can just improve image quality overall. I have seen some crazy AI enhancement of very old footage.

Youtube has a lot of examples like https://www.youtube.com/watch?v=EjVzjxihGvU

AS for proprietary. I encourage keeping it open source and allowing the community to work on, but I know everyone deserves to make money how they can. I just hope you keep the pricing reasonable if you do monetize.

You're not understanding what this is for. This isn't something to avoided costs of an external frame TBC, nor line TBC. It's a post-capture line TBC, for restoration, when sources are gone. If you have the original tapes, recapture with a proper workflow. This will never supplant a proper hardware workflow, merely complement it.

That has nothing to do with this project.

This sort of specialized video tasks is more likely to be harmed by community support, not aided. I've seen this happen before, and it didn't end well. I'm all for open-source, but it's not always the best choice for everything.

Hmm, understandable, but at the same time. Unless there is ever an affordable TBC option (sub-$100) then external TBC isn't an option for many (for many financial reasons). Maybe Ill dabble in AI restoration or AI post-capture field TBC myself, but thats a long term idea.

And I know you say many times it can be purchased and then sold, but you still need to fork over the money, and life gets in the way and 2-3 years later, its still sitting in the closet. So it's not a great option for many people, because that's just how people work.

I posted here a couple years ago. Got a VS30U, and the ATI Wonder 600 USB. But an external TBC has always alluded me due to cost (I managed to get a KeyWest Voodoo for $70, but it caused audio sync issues and died about 20 mins in). I got the VCR for like $50 working, and the 600 USB for something similar if not cheaper. But then the TBC prices re $200+ and rising. Just a balance of quality and money.

So if we can use software to augment that, it could save people money. I don't expect it to be as good as external, but even if its 30-50% as good, it's better than 0. And even just that could be good enough for some to ignore the external TBC.

Because at this point, I am about to just give up and capture VCR > PC directly, and call it a day and just hope I get decent quality without an external TBC

Unfortunately I am not great at AI or Video, even if I am a dev, I specialized in a different direction for my career, so it would take me good while to ramp up. I would need to dig deeper than my surface level understanding of all the technical aspects of analog video capture.

So I get it LordSmurf, and I know you are right and where you are coming from, and I respect your experience, but as hardware becomes increasingly harder and harder to get, some of this stuff needs to move to software, or we need to start designing an open source board to do all this. Maybe push into the maker scene and program a bunch of arduinos to do what 1 board does, or design a custom board. Either way, we can't just rely on old hardware forever. We might need to program an arduino to do what 1 tiny chip did on the original board. But we have to start trying stuff and pushing the envelope (i wish i was more into hardware too at this point).

Software TBC cannot recreate frame TBC.

Yes, but:
- If hobby -- All hobbies have costs (DIY video = hobby, even if short-term hobby). Buy it, use it, resell it.
- If business -- All businesses require capex. Quit being a cheapskate, it will only result in horrible quality that should never be foisted upon paying customers of services.

Please use "AI" correctly, as it's gotten to be ridiculous in recent years. NN alone is not AI.

Nod of understanding. Yep.

Good stuff. :congrats:

Yep, almost always a bad TBC, not unexpected. (Exception = early production models, not commonly found.)

Nice. Some years ago, that was possible. Not common, rare actually, but possible. But not now.

I don't know that anything was ever $200 -- at least not a good model of anything.

It's not about "quality" or "being good". It does not work, at all. Software is an attempt to untangle bad timing -- line TBC functionality. Frame TBC isn't for that, it's for frame, most notably dropped frames. Once a frame is lost, you can't get it back. It's not about quality, it's about not being a function that can exist. You cannot create the missing data. It's missing.

You need a budget option. That entails (at minimum_ the ES10/15, ideally add the DataVideo DVK to create a TBC(ish). What you suggest, VCR>card, will almost always result in dropped frames, because you have no framesync TBC (the ES10/15 sort-of privode line TBC + frame sync, but not frame sync TBC). The DVK is a weak frame TBC, which is why you add it -- the video must be pre-processed, and VCR line TBC sometimes isn't enough of a purifier to appease the DVK.

You must understand that some functionality cannot be recreated in software, and probably never will. It's not that easy, otherwise it would have been done long ago.

It's not that easy. The cost to simply develop a board is more than the $200 that you (seemingly?) want to spend on a TBC.

I agree. It's the main reason I got into hardware refurb work 5 years ago. If I can at least restore gear, it gives the community more to work with.

Some of us already are. It's not that easy.

After reading up on how a frame TBC worked, I was like "You can do that in code" but something clicked finally about analog signals. I was completely forgetting the part that in order for any software to process that signal, it needs to be converted to a digital signal. and the Analog to digital conversion is how you lose the data needed to create a frame. Now I realize where i was making an error in my logic.

I also have kind of derailed this topic, though I do want to add a last thing. Now that I realize what you are getting at, maybe the key isnt a TBC per say, but the Analog to Digital conversion. We do various conversions to an image. But maybe we need to take the analog signal and convert it to just labeled data? take each line of video, or whatever we can get, label it up with all the meta data, and send it on. Then recreate images from the data + labels and then use the label information to do things normally you couldn't in software? Just spitballing, I know its probably been considered already, but I feel like there is something there.

Thank you for the ES15/DVK suggestion. I might go this route, because even if it not super cheap, its multiple parts that can be purchased over time and better budgeted for.

And you mentioned hobby or business, but im not really either. THis is a 1 time project for me. The only reason i am going this far, is these tapes are the only remnant of memories of my wife's father, who she lost in her early 20s. Due to fires, and time , pictures, and many things are lost. One of those is voice, which is only on these tapes. So I want to do everything I can to squeeze as much as possible out, without breaking the bank on top tier equipment.

That was my thought at first as well, but it is also important to state what a software TBC "is not". The intention is line TBC, on already-digitized captures, where the original source tapes are no longer available. The intention is not to be cheaper, lazier, recreate lost data, etc.

This is not likely to be an "easy button" newbie/dummy-friendly approach, but I imagine it to be more like barrel/pincushion distortion correction in camera lenses. Yes, it will have a set of profiles for common situations, but it will have some manual correction ability as well.

That's where you're still not understanding the role of a TBC. Analog video data isn't always "whole", but partials. This is a simple way to put it, but it suffices for this conversation. A capture device requires a "whole" frame, otherwise it has to be dumped. The TBC "makes it whole" for capture. Capturing partials/pieces is not possible because of how the incoming data is timed. The ingest device would need a TBC instead -- and to be honest, that's how it should have been! But it costs more $$, more R&D, so capture card makers didn't do it.

Arguably, line TBC should have been inclusive as well. All DVD recorders (not just the rare ES10/15), all capture cards. But that's just not what happened.

So what we have now are lots of wiggly crappy videos that need to be saved with a software TBC -- if it can exist. And I think we're getting close now, with IMGKD leading the development.

I figured you weren't in it for business, and that makes it hobby. Yes, short-term hobby is still hobby. Video isn't like home DIY (not really hobby) were you decide to change out your own sink plumbing connections. I would argue that plumbing is a need, while video is a want (but an important want, ie family history).

I think you'll do fine, you're on the right path here. You have the original tapes, you're planning to use good gear (JVC with line TBC), so you don't need software TBC.

... and I think enough derail for now. :wink2:

Year old thread but this is my exact question.

They say RF capture allows you to bypass the need for a frame TBC entirely.

When you are referring to software TBC here, I'm assuming you mean line correction and not frame as pointed out above. However RF capture briefly spoken about in this thread as being (not useful), some have stated it allows you to bypass the need for frame correction or frame TBCs.

Is this true, and why would that be?

Yes it's true check your thread. A TBC is a just a capture device that doesn't convert back to analog, If you have a way to get that perfectly timed digital signal straight to computer wouldn't you want that?

I'm not sure who "they" are, but it's not accurate.
Continue this topic here: http://www.digitalfaq.com/forum/vide...quired-rf.html

It's not true. It conflates.

- Timing correction (TBC) is required for consumer analog formats, especially VHS.
- To date, no software TBC exists, referring to Win/Mac/Linux type software, what most people think of as "software" (or apps, etc). No such TBC may ever exist.
- Dedicated chips are currently needed for TBC, and may always be the only way. And no, the on-chip software/firmware cannot simply be ported.

This thread is for a project that stalled out. Both time, and because software TBC is an uphill battle.