Dazzle Capture with Wins 10

[lollo]

You don’t own a recommended frame TBC and you give your input on the effectiveness of those based on other people’s experiences.

Are you sure? Me and the group of people I am part of (dedicated to capture old TV shows) own several TBCs, and btw the name "frame" you used is not appropriate. And on top of that we are not limited to VHS/S-VHS sources.

Before you open your mouth you should start your brain and realize who you are talking to!

Finally, do not hide behind somebody else, talk for yourself.

[Gary34]

I realize that you have a lot of experience and I didn’t intend to get into a back and forth with you. You kinda show up really hostile every time someone mentions a card that isn’t an IO data or a Haugpauge.

Me and the group of people I am part of (dedicated to capture old TV shows) own several TBCs, and btw the name "frame" you used is not appropriate.

Frame sync, anyways I never hear you state your personal experience with AVT or Datavideo units.

[lollo]

You kinda show up really hostile every time someone mentions a card that isn’t an IO data or a Haugpauge.

No Gary, I am just hostile against the falsity that are written about these two cards. These lies are not supported by any fact or real data, just blah blah.

If you read my old posts, you can see that I always recommended the 710USB and the 600USB and few others as well, because they are excellent. But they are out of productions: if you own them ok, it is absolutely fine, but if you are looking for a card now you can just buy the USB-Live2 and the GV-USB2 because they are performing the same.

And I also recognized that your point about the DV bridge to USB is a nice feature.

[lollo]

Frame sync, anyways I never hear you state your personal experience with AVT or Datavideo units.

What do you want to hear? I (we) use them only when needed, because they are not really fully transparent, and we aim for the best quality for archiving memories. They are inside the workflow for tapes needing a rebuild of the base of the time between the frames; it happens when there is a physical defect in the media, or some marginal synch loss, poor recording, etc., leading to skipped frames and then a/v asynch among others bad results.

But you know what? I always perform a dual capture without them, to get some additional frame that otherwise is missed/replaced in the "cleaning" operation performed by the TBC. Just to let you understand how much we are obsessed (and I save you the description of the nightmare AviSynth processing to rebuild what is supposed to be the original)

[Gary34]

But you know what? I always perform a dual capture without them, to get some additional frame that otherwise is missed/replaced in the "cleaning" operation performed by the TBC. Just to let you understand how much we are obsessed (and I save you the description of the nightmare AviSynth processing to rebuild what is supposed to be the original)

I’ve read about it. I’ve learned a good amount from a lot of your post.

[Gary34]

But you know what? I always perform a dual capture without them, to get some additional frame that otherwise is missed/replaced in the "cleaning" operation performed by the TBC. Just to let you understand how much we are obsessed (and I save you the description of the nightmare AviSynth processing to rebuild what is supposed to be the original)

That is way above and beyond what most people would wanna do for home videos. I just hit capture and then Vdub says no drops and then I go to the next step. I was wondering your experience with the AVT 8710s, Datavideo TBCs, and I guess the BV TBC 10s but with the Big Voo Doo I’ve heard there aren’t that many that are good. I’m mainly wondering about your experience with AVTs and Datavideo units. I don’t doubt if you have experience with them but I never read anything about your personal experience with the recommended TBCs. I’m not trying to be rude.

[CaptureCraft]

I just hit capture and then Vdub says no drops and then I go to the next step.

Vdub can report only about frames lost after it captured them. You have to have really bad setup to make it happen.

[Gary34]

Vdub can report only about frames lost after it captured them. You have to have really bad setup to make it happen.

As soon as Vdub drops a frame you see it in the counter on the right. You don’t have to have a bad setup to drop frames.

[CaptureCraft]

Vdub can report only about frames lost after it captured them. You have to have really bad setup to make it happen.

As soon as Vdub drops a frame you see it in the counter on the right. You don’t have to have a bad setup to drop frames.

Yes, you'll see, but why Vdub would drop a frame?

[Gary34]

Anything in the workflow can cause drops.

Virtualdub isn’t causing the drop. Vdub is telling you hey there was a dropped frame there. When you capture analog media and it is dropping frames like that you are trying to download corrupt data. The drops happen because of the analog side of things usually because of timebase errors. It’s not because of the software. That’s why people use TBCs and es10/15s. Trying to capture 10 bit uncompressed can also cause drops. Background task running on your computer can cause drops.

[CaptureCraft]

Vdub is telling you hey there was a dropped frame there.

Sorry to disappoint you, but there is no such thing. There is no flag or any other explicit sign anywhere in the capture chain.
The only thing here is timing, which could tell that if there is no new frame at certain time, then maybe, just maybe, the frame is missing.
It's a guess work.
So, the only way for Vdub to know if the frame is dropped is if it was received by Vdub but not recorded into a file.
And that could happen only if the setup is bad, like slow hard drive and/or CPU, so Vdub doesn't have enough time to record it, so it has to drop it.
There is no way to tell for sure if frames were dropped before they reached Vdub.
So, if you really want to be sure, you have to do at least 2 captures and then run frame-by-frame comparison.
I do it all the time.

[Gary34]

Here is the dropped frame counter.
[Attachment 89966 - Click to enlarge]

So, the only way for Vdub to know if the frame is dropped is if it was received by Vdub but not recorded into a file.
And that could happen only if the setup is bad, like slow hard drive and/or CPU, so Vdub doesn't have enough time to record it, so it has to drop it.

Analog tapes were captured on old Pentium 4s. They weren’t fast CPUs. Capturing only uses one core so single core speed is what is important. Any CPU made in the last decade has the core speed for capture. If you were capturing 8 bit losslessly compressed. I just looked for something with two cores and two drives that was windows 7. Virtualdub doesn’t receive the frame because it is too late and that’s when it drops because it wasn’t there when it was supposed to be. Virtualdub knows when a frame is supposed to be there. Vdub doesn’t receive the frame to drop it. To keep your computer from dropping frames you don’t want it to have anything else going on and disconnect from the internet.

[CaptureCraft]

Here is the dropped frame counter.
[Attachment 89966 - Click to enlarge]

You don't need to show that. I know VD.

Virtualdub doesn’t receive the frame because it is too late and that’s when it drops because it wasn’t there when it was supposed to be.

What?!? Why? what is your assumption is based on?
Have you ever seen VD's logs with all the timings?
If it would drop every "late" frame you would get half of what you have now.

[Gary34]

If it would drop every "late" frame you would get half of what you have now.

It drops every frame that is too much later than the expected time code. The audio doesn’t drop so you get audio desync.

[CaptureCraft]

If it would drop every "late" frame you would get half of what you have now.

It drops every frame that is too much later than the expected time code. The audio doesn’t drop so you get audio desync.

Again, what is your assumption is based on?
Is it in docs? Have you run tests? Any other reliable sources?

[Gary34]

There is a lot of forum information about how that works on this forum and digitalfaq. I have done test on the stuff that you are talking about just by capturing. My capture computer has two cores and is pretty slow. I know a faster drive and CPU won’t help with dropped frames. People did this when computers were very slow. There is information about how Vdub works on both forums.

[Gary34]

There is no way to tell for sure if frames were dropped before they reached Vdub.
So, if you really want to be sure, you have to do at least 2 captures and then run frame-by-frame comparison.
I do it all the time.

Maybe you have a capture card that doesn’t report dropped frames.

[Gary34]

Okay I looked at your comments from other posts now and your captures are more demanding than they have to be. You capture 10 bit uncompressed. 8 bit is more than enough for VHS. Capturing 10 bit uncompressed can cause dropped frames because it is a lot of data for real time capture. Capturing 8 bit using losslessly compressed Huffy or another lossless compression is a better idea.

[CaptureCraft]

I took a deep dive into Google, AI,Microsoft WDM.
Turns out WDM has IAMDroppedFrames interface to report dropped frames count. It counts frames which were dropped during the capture process. Meaning the frames were captured, but not delivered.
Usually that means, the buffer overflow, when VirtualDub (or any other program) can't process frames as fast as they being captured. So, capture card has to drop them.
As for frames, missed because of a low and/or bad signal there is no mechanism to catch such frames.
Different cards handle this scenario differently. Most of the cards just wait for the next detected frame. This way your timing is screwed, aka audio out of sync.
However, some cards duplicate last captured frame. I know BM does it. It gives perfect timing, but, oh boy, so many duplicates.
And some could give you just a blank frame.
So, I stand correct. If your VirtulDub reports dropped frames then you have slow system, aka bad setup.

P.S. I do not capture uncompressed video. I'm not sure why you have such impression. I did it once for test purpose, but that was it.

[Gary34]

I took a deep dive into Google, AI,Microsoft WDM.
Turns out WDM has IAMDroppedFrames interface to report dropped frames count. It counts frames which were dropped during the capture process. Meaning the frames were captured, but not delivered.

Why are you bringing up WDM? Typically cards connect to virtualdub through direct show. If frames are dropped they are not captured.

Usually that means, the buffer overflow, when VirtualDub (or any other program) can't process frames as fast as they being captured. So, capture card has to drop them.

Virtualdub doesn’t drop frames because it can’t keep up. It’s not the software that can’t keep up. About any computer can capture 8bit huffy.

As for frames, missed because of a low and/or bad signal there is no mechanism to catch such frames.

Frame TBCs replace the sync pulse and give a new time code. It will fix a weak signal or bad timing. It buffers whole frames.

So, I stand correct. If your VirtulDub reports dropped frames then you have slow system, aka bad setup.

I don’t get dropped frames but you can have dropped frames no matter what kind of setup you have if your tapes are bad enough I’m sure.

P.S. I do not capture uncompressed video. I'm not sure why you have such impression. I did it once for test purpose, but that was it.

Yeah I saw where you said you capture in H.264 which is a lossy delivery codec and shouldn’t be used for capture. It’s also highly compressed and spikes your CPU usage.

[Sharc]

Yeah I saw where you said you capture in H.264 which is a lossy delivery codec and shouldn’t be used for capture. It’s also highly compressed and spikes your CPU usage.

If you want to minimize hassles with dropped frames/inserted frames/out of sync issues try AmarecTV as your capture app and capture into YUV 4:2:2 using a "lossless" codec like huffyuv, UTVideo, Lagarith (all free). AmarecTV outputs a log which is very helpful to analyze the capture and indicates where to inspect the stream in more detail for identifying possible issues.
User Alwyn has written a guide how to setup and configure AmarecTV.

[lollo]

Interesting off-topic about dropped frames, I just want to clarify something (but the whole topic is not that easy):

> So, the only way for Vdub to know if the frame is dropped is if it was received by Vdub but not recorded into a file.

Not only, it can decide to drop a frame arriving too late (or too early)

> And that could happen only if the setup is bad, like slow hard drive and/or CPU, so Vdub doesn't have enough time to record it, so it has to drop it.

That's another reason for dropping frame, meaning system problem

> There is no way to tell for sure if frames were dropped before they reached Vdub.

Replace Vdub with capture card naming and then this is correct. Frames dropped prior to A/D conversion on the capture
card cannot be taken into account.

> So, if you really want to be sure, you have to do at least 2 captures and then run frame-by-frame comparison.

That's a good practice, but when a dropped or inserted frame appears at the same moment in time (i.e. a defect on the media), it won't tell you anything.

>> Here is the dropped frame counter.

Which is somehow useless. The best capturing software is AmarecTV, first because it does not generally introduce a/v asynch like VirtualDub do (especially with modern cards and modern OSs), and second because it provides a detailed report about what is happening during capture.

>> There is a lot of forum information about how that works on this forum and digitalfaq.

Yes, but you are just re-writing concepts from others without really understand the mechanism behind, same as CaptureCraft.

>> Maybe you have a capture card that doesn’t report dropped frames.

A card itself cannot and does not report dropped frames.

>> Turns out WDM has IAMDroppedFrames interface to report dropped frames count

In fact is the filter AVI Mux reporting the dropped frames. Here the graph of my own capture software I use sometimes for cross-check. Also note that is not possible to insert frames in my software, for that we need a more sofisticated program like AmarectTV or VirtualDub.


We had a post about dropped/inserted frames here: https://forum.videohelp.com/threads/416657-Analog-Capture-inserted-and-dropped-frames

As a complement to that discussion, following are some more details.

This is the log of a capture of a problematic tape done with AmarecTV, where you have isolated innserted frames, inserted frames consequence of a dropped frame, buffered frames (arrving a little bit to late but taken into account thanks to a buffering of the software) and isolated dropped frames.
The understanding of the different mechanisms should be easy, but I am attaching the original log file and the Excel file I used to extrapolate the data:

VT=00:00:00.041s( 0) 4
VT=00:00:00.073s( 1) 5 ok
VT=00:00:00.105s( 2) 6 ok
VT=00:00:00.137s( 3) 7 ok
VT=00:00:00.200s( 4) 8 ok
VT=00:00:00.233s( 5) 9 ok NT=00:00:00.233s( 6) Total=1
VT=00:00:00.264s( 7) 10 ok
VT=00:00:00.296s( 8) 11 ok

VT=00:00:01.065s( 27) 30 ok
VT=00:00:01.097s( 28) 31 ok
VT=00:00:01.160s( 29) 33 1 dropped
VT=00:00:01.223s( 30) 35 1 dropped NT=00:00:01.223s( 31) Total=2
VT=00:00:01.256s( 32) 36 ok
VT=00:00:01.321s( 33) 37 ok

VT=00:00:35.593s( 890) 894 ok
VT=00:00:35.627s( 891) 895 ok
VT=00:00:35.658s( 892) 896 ok
VT=00:00:35.785s( 893) 899 2 dropped
VT=00:00:35.818s( 894) 900 ok NT=00:00:35.818s( 895) Total=5
VT=00:00:35.882s( 896) 901 ok
VT=00:00:35.913s( 897) 902 ok
VT=00:00:35.946s( 898) 903 ok
VT=00:00:35.978s( 899) 904 ok
VT=00:00:36.042s( 900) 905 ok NT=00:00:36.042s( 901) Total=6
VT=00:00:36.074s( 902) 906 ok
VT=00:00:36.106s( 903) 907 ok

VT=00:07:26.771s(11169) 11174 ok
VT=00:07:26.804s(11170) 11175 ok
VT=00:07:26.837s(11171) 11177 1 dropped
VT=00:07:26.867s(11172) 11177 buffered
VT=00:07:26.933s(11173) 11178 ok
VT=00:07:26.965s(11174) 11179 ok
VT=00:07:26.996s(11175) 11181 1 dropped
VT=00:07:27.026s(11176) 11181 buffered
VT=00:07:27.090s(11177) 11182 ok
VT=00:07:27.123s(11178) 11183 ok
VT=00:07:27.188s(11179) 11185 1 dropped
VT=00:07:27.252s(11180) 11186 ok
VT=00:07:27.284s(11181) 11187 ok NT=00:07:27.284s(11182) Total=11
VT=00:07:27.315s(11183) 11188 ok

VT=00:46:19.823s(69490) 69504 ok
VT=00:46:19.887s(69491) 69506 1 dropped
VT=00:46:19.952s(69492) 69508 1 dropped
VT=00:46:19.983s(69493) 69509 ok
VT=00:46:20.016s(69494) 69510 ok
VT=00:46:20.079s(69495) 69511 ok
VT=00:46:20.112s(69496) 69512 ok NT=00:46:20.112s(69497) Total=21
VT=00:46:20.143s(69498) 69513 ok

Attached the original AmarecTV log file and a link to my excel processing file if somebody is interested to look more in detail: ufo_s1a_amtv_v2a.avi.txt

excel processing file: https://docs.google.com/spreadsheets/d/1zOZOQl3W9URcIVyylqf8i5cFlMKyzydj/edit?usp=shar...f=true&sd=true

edit Some more details about the AVI Mux behavior: https://learn.microsoft.com/it-it/windows/win32/directshow/avi-mux-filter?redirectedfrom=MSDN

"Dropped Frames
The AVI Mux filter calculates dropped frames based on each sample's media times, if available, or else the sample's time stamps. It writes a zero-length index entry for every dropped frame.
..."

[Gary34]

And that could happen only if the setup is bad, like slow hard drive and/or CPU, so Vdub doesn't have enough time to record it, so it has to drop it.

That's another reason for dropping frame, meaning system problem

Remember that he is capturing 10 bit H.264 losslessly compressed.

There is no way to tell for sure if frames were dropped before they reached Vdub.

Replace Vdub with capture card naming and then this is correct. Frames dropped prior to A/D conversion on the capture
card cannot be taken into account.

Meaning it’s not true.

Here is the dropped frame counter.

Which is somehow useless. The best capturing software is AmarecTV, first because it does not generally introduce a/v asynch like VirtualDub do (especially with modern cards and modern OSs), and second because it provides a detailed report about what is happening during capture.

The dropped frames counter isn’t useless and I can’t get AmerecTV to work with my Pinnacle cards so I have no opinion on that software. I’ve heard it’s good but I don’t know. I’ve never had A/V sync issues in Vdub but I use a frame TBC.

So, if you really want to be sure, you have to do at least 2 captures and then run frame-by-frame comparison.

A lot of people won’t want to do that. I never have those kinds of issues anyways.

>> Maybe you have a capture card that doesn’t report dropped frames.

A card itself cannot and does not report dropped frames.

You know what I mean. Same as you pointing out the difference between frame and frame sync TBC earlier. Everyone generally says frame TBC with Datavideo and AVT units. You are getting kinda particular.

[lollo]

Remember that he is capturing 10 bit H.264 losslessly compressed.

You just discovered that (losslessly) 5 minutes ago (before you were not aware of it)

You know what I mean

Sometime I don't, but I am not native english, so maybe is a problem on my side.

You are getting kinda particular.

It was not in purpose, as I wrote before "sometime I don't"

[Gary34]

You just discovered that (losslessly) 5 minutes ago (before you were not aware of it)

I didn’t expect someone to be capturing losslessly compressed 10 bit h.264 then blaming drops on the software and slow drives or CPU without realizing they are putting way more strain on the drive and CPU than is necessary for no reason. I guess he just thought I would assume he captured losslessly.

[lollo]

I can't talk for him.

Capturing lossless means less load on the CPU compared to a real-time compression (but that's not the full picture for frames drop). About the write bandwidth, as I staded the 10-bit capture for VHS/S-VHS is just a waste of resources. For better filtering you can increase the bit-depth later in post-processing (with dithering) .

[Gary34]

Capturing lossless means less load on the CPU compared to a real-time compression

You're correct. Still capturing H.264 losslessly in 10 bit is a lot on the CPU.

[Sharc]

I would suggest to make lollo's post #52 a sticky, or make it a thread of its own. Thanks lollo for this example

[lordsmurf]

You kinda show up really hostile every time someone mentions a card that isn’t an IO data or a Haugpauge.

Yep. Every time. Vocal minority. Some people think loud and aggressive = righteous.

It is an old card out of production,

Your beloved GV-USB2 is a 2000s-2010s card, too! It's not new either. I don't care if it's still sold "new" on Japanese sites, or imported by Amazon.com in limited quantities (from Amazon Japan). It may be a simple issue of overproduction + large warehouse full of NOS

Pretty much everything Hauppauge USB is 2000s.

This cult-like adoration of a capture card is honestly weird. Contrary to some people (most of whom are pushing false narratives on purpose), I'm not in love with ATI or AIW cards. Find my posts from 20-25 years ago, where I pointed out those issues/imperfections. I recommend multiple cards, to multiple audience types, for multiple reasons. You get pissy when any GV-USB2 flaw is pointed out, or read that another card has been chosen. Whereas I don't really care what somebody uses. I give my advice, and if they don't take it, fine. And if they have problems, that's on them. (With exceptions, namely org archivists and businesses, they need to do better.)

they are not really fully transparent,

False statement. It's neither entirely true, nor even generally true. Bad TBCs exist, definitely. But high-transparency units do too.

or some marginal synch loss,

That's not a thing. Audio sync loss is a symptom of bad timing, which is intrinsic to the VHS format. There's no such thing as a VHS tape without timing issues.

Maybe you have a capture card that doesn’t report dropped frames.

Yep, those exist.

Frames dropped prior to A/D conversion on the capture card cannot be taken into account.

That's inaccurate. If frames are dropped pre-card, it leaves gaps that are then the card's problem to deal with. It's not an either/or, but a continuous issue from tape/deck to digital file. The problem is additive, and compounds.

The only thing here is timing, which could tell that if there is no new frame at certain time, then maybe, just maybe, the frame is missing.
It's a guess work.

It's not guess work.

For example, when a frame is damaged, it causes signal offset. Partial, whole, multiples. Data is missing, that much is known. How much is unknown until the signal "rights itself" again. Hardware and software assists by dropping/inserting frames until it happens. Yes, that means "good frames" are often lost due to bad frames, which is why drops/inserts are rarely a single frame at a time.

So, the only way for Vdub to know if the frame is dropped is if it was received by Vdub but not recorded into a file.
And that could happen only if the setup is bad, like slow hard drive and/or CPU,

No. If frames are too close together, the drop often must happen. That's not the fault of the software, but of the incoming signal.

There is no way to tell for sure if frames were dropped before they reached Vdub.

Not true. The very nature of timing can tell if the timing is wrong, leading to drop/insert frames.

So, if you really want to be sure, you have to do at least 2 captures and then run frame-by-frame comparison.
I do it all the time.

Or just use a TBC?

__________

Honestly, I think the internet as a whole is getting dumber. Threads like this are a shitshow of misinformation, not much better than Youtube. Speaking of, one Youtuber is now claiming GB-USB2 has TBC inside.

I don't have the time, nor patience to reply to everything in this thread.

Video capture is starting to become like politics, with some pretty loud and wrong fringes.

I miss the days where we could agree on facts, and then form opinions on gear. These days, people form opinions, then perform mental gymnastics to justify it. It's bass-ackwards (ass-backwards).

[lollo]

Your beloved GV-USB2 is a 2000s-2010s card, too! It's not new either. I don't care if it's still sold "new" on Japanese sites, or imported by Amazon.com in limited quantities (from Amazon Japan). It may be a simple issue of overproduction + large warehouse full of NOS

Bullshit. USB-Live 2 and GV-USB2 are still in production, that's all that matters.

This cult-like adoration of a capture card is honestly weird.

I am not in love with any card, I like many of them, including Pinnacle 710 and ATI 600 USB and few others. I just suggest the USB-Live 2 and GV-USB2 because you can buy them new at a fraction of the price of the others two, and they perform better of equal.
Contrarly to you, I do not have a conflict of interest big like a house, because I do not sell anything.

False statement. It's neither entirely true, nor even generally true. Bad TBCs exist, definitely. But high-transparency units do too.

There is no device which is really full transparent. Neither is the ES15 I gave a demonstration recently. The difference is that I am practical and see the facts, and for the latter is not really an issue when needed to solve specific defects.
My approah is always the same: do not use an external TBC if is not needed, because they are not fully transparent. Not so difficult to understand.

That's not a thing. Audio sync loss is a symptom of bad timing, which is intrinsic to the VHS format.

That's what I wrote.

There's no such thing as a VHS tape without timing issues.

It depends on the grade of the timing issue. Again, you can capture VHS tapes for 3 hours without an external TBC and have no dropped/inserted frames nor a/v asynch. That's a fact.

Frames dropped prior to A/D conversion on the capture card cannot be taken into account.

That's inaccurate. If frames are dropped pre-card, it leaves gaps that are then the card's problem to deal with. It's not an either/or, but a continuous issue from tape/deck to digital file. The problem is additive, and compounds.

No.

Honestly, I think the internet as a whole is getting dumber. Threads like this are a shitshow of misinformation, not much better than Youtube. Speaking of, one Youtuber is now claiming GB-USB2 has TBC inside.

It that's the case is a bullshit, same as yours when you talk about USB-LIve 2, GV-USB2, AmarecTV and so on.

I miss the days where we could agree on facts, and then form opinions on gear. These days, people form opinions, then perform mental gymnastics to justify it. It's bass-ackwards (ass-backwards).

I miss old days as well, but at the same time I miss any fact or evidence posted by you about some (not all, few are obvious) of your statements/claims/opinions. There is not a single post over the internet in which you add an attachment, a script, a comparison, a "flower" (just kidding). Not a single one. Just as simple as that.