Logilink USB Video/Audio Grabber (VG0029)

[lordsmurf]

So, we have AmarecTV that might drop frames which are unreported and maintains sync or
we have VDub that might drop frames which are reported and sometimes puts videos out of sync.

Yep, not many choices.
- Also OBS which actually isn't "capturing" at all (screen recording), and tends to introduce oddities that you'd expect with that method.
- But there are some forgotten programs, such as iuVCR, VirtualVCR, or ... I don't even remember now. So many capture programs, so long ago.
- Obviously ATI MMC for ATI Radeon, WinTV for Hauppauge.

They all have weaknesses and limitations.

I know which one I'd prefer to work with on the timeline.

Between those two, I'd have to agree. If I had capture issues, and the content was not important, I'd be tempted to use AmaRecTV myself. But I'd rather find a way to get VirtualDub to not drop frames, and many people doing it all the time.

Lordsmurf, what is an "expected" frame drop?

TS drops/dupes/inserts frames based on the signal. TS is designed to expect signal drops, thus content/frame drops. So since those are expected, logging is often skipped. Broadcasting has other more effective means to log signal issues separate from counting frames. But external non-signal issues, such as I/O, are the non-expected.

Now, that said, TS should still deal with those unexpected signal issues. And in fact AmaRecTV usually does a swell job at overcoming those. But not always, and a lot of sync loss is still potential (and reported by many other users in the past decade).

This quick Google definition may help with understanding here:
What is a transport stream?
A transport stream (TS) permits multiplexing streams that do not necessarily share a common time-base for transmission in noisy environments. The TS is designed for broadcasting over communication networks

That's what AmaRecTV was. A quick dirty analog hardware grabber for internet broadcast/stream. It makes perfect sense now. It explains many things.

The async of untimed source is dealt with swiftly, for end user experience. Current data integrity matters less than user experience, so drops/boogers/whatever are momentarily accepted, to maintain overall integrity. That's not acceptable for an ingest, however, only broadcasting. (I find the term "broadcast" used very loosely when it comes to most online uses, especially webcams and gamer streams.)

Bullshit. I verified across several comparison

I kept that in mind. Your assurances, however, are not aligning with the known facts. So the only conclusion to be drawn is that your tests were flawed, or a bad sample size (too short).

MPEG-2 concepts for AVI architecture???

Yes. TS is not MPEG. And I also said "essentially", as it's not 1:1 here. But it does share concept here, regardless of the final file. The TS treatment is prior to file write.

You have no idea

Pfft. I'm having to dust off my broadcasting knowledge from about 15 years ago here. I was never "in" broadcasting, but at the studios I had to communicate with them on their level, providing the deliverables.

in order to have an alternative to PVAStrumento and ProjectX.

That's nifty. You wrote a program to handle final delivery files from satellite rips. That's not what I refer to here.

It was created for capturing through analog cards or live camera, or whatever else it can interface.

No. Not "capturing" as it applies to videotape ingest.

Like VirtualDub.

No. Sources matter. VirtualDub was intended for analog consumer format videotape and analog TV sources, where the final expectation was a 1:1 duplicate of the card ingest. Frame drop/insert was not expected nor desired.

And BTW I have "broadcast" experience

Then act like it.

VirtualDub was created at the time of analog capture with separated video and audio cards.

No. Wrong.

There is reason for all the options in the setting, to also deal with jitter (always present) of the clocks inside the audio card and the video card, because they cannot be exactely the same even if a Quartz Oscillator is used. If it works, ok, but today it often fails with audio/video integrated cards and modern OS.

This is confusing. You correctly state audio can lose sync, integrated or not. Why is everything you post so hostile? It's like reading the ramblings of a crazy person at times.

Now, if you like to insist, post some evidence of what you wrote with technical examples, and data and results of experiments, otherwise

Not worth my time, especially considering that you tend to double down, regardless of what you're given. There have already been threads, where users posted "proof" of their issues for you (logs, samples, etc), and you just dismiss it or disappear. I don't have time for that nonsense.

stop your bullshit and your insane crusade against AmarecTV.

Stop humping software.

single day there are more and more evidences across many forums on how AmarecTV in better than VirtualDub today in keeping synch.

No there's not. It's mostly just you, "rah rah, sis boom bah, yaaaay AmaRecTV!"

[Bwaak]

Then you have no understanding nor knowledge to do that.

His demeanor is arrogant and patronising, yet his technical knowledge is non-existent and his empirical knowledge is not verifiable. Instead of using industry-standard terms he invents his own, but cannot define what they mean. He can meander for half a page, yet there would be little sense and substance in what he has written. It is better to ignore his posts altogether. Trying to make sense of them or to correct and disprove them would take an order of magnitude more time than the original message, because, as you correctly observed:

This is the only correct sentence you made.

[lordsmurf]

Instead of using industry-standard terms he invents

The jargon is confusing to novices, and doesn't always tidily fit into the chaos that is consumer format analog videotape conversions. Something like "TBC" is a wide term, and can lead you down the wrong (and costly) path.

Some terms matters, such as "jitter" or "tearing".
Some are too vague, and can cause wrong understandings.

In this exact conversion, "dropped frames" gets fuzzy, because of the reasons stated. When you zero in on analog videotape ingest, the term can vary from the use in broadcasting (or streaming). Most people will thank you for the clarification, but some will prove John Gabriel internet theory is as accurate as ever (look it up in the Google image search, if needed).

[dellsam34]

Can we all just get along?

[lollo]

I will try to be short in my reply, to address dellsam34 request.

That's what AmaRecTV was. A quick dirty analog hardware grabber for internet broadcast/stream. It makes perfect sense now. It explains many things.

Bullshit. You have no clue on how AmarecTV is designed.

So the only conclusion to be drawn is that your tests were flawed, or a bad sample size (too short).

Sure, 3 hours capture is not enough to detect asynch. And my tests are flawes, as the results from other users weel documented. Only your blah-blah is true.

This is confusing.

Some terms matters, such as "jitter" or "tearing". Some are too vague, and can cause wrong understandings.

You are confused because you do not know what a jitter is when talking about a clock. Do some google research. On my side, it is something that is clearly defined, can be mathematically determined, simulated when we design a circuit such an Oscillator or a PLL with our CADs, and measured in lab.

Not worth my time, especially considering that you tend to double down, regardless of what you're given. There have already been threads, where users posted "proof" of their issues for you (logs, samples, etc), and you just dismiss it or disappear. I don't have time for that nonsense.

Liar. Link a thread in any forum, a single evidence, of what you assert. I always replied to any question/doubt and never disappeared. Prove to me and to the others that this is not true.

No there's not. It's mostly just you, "rah rah, sis boom bah, yaaaay AmaRecTV!"

Just on your forum:
12th of May: https://www.digitalfaq.com/forum/video-capture/13506-cannot-capture-hi8.html#post90768
10th of May: https://www.digitalfaq.com/forum/video-capture/13502-vhs-capturing-glitches.html#post90733
and this is one of the guide I contributed to write on your forum (there are many others):
https://www.digitalfaq.com/forum/video-capture/12986-amarectv-virtualdub-inserts.html
I pointed it out because the workflow includes an external TBC, just in case you want to bullshit again about it.

Many other posts in your forum (where I do not write anymore) and videohelp forums.

His demeanor is arrogant and patronising, yet his technical knowledge is non-existent and his empirical knowledge is not verifiable.

It is clear to any reader that is not an engineer nor he's having a scientific approach or has knowledge on specific subjects. I hesitate sometime beeing too strong with him, but I can't stand lies. And do not like false statement without evidences, nor blah-blah.
He never, ever posted a sample of anything in thousand of posts.

Maybe I should be more kind with him and accept his low level knowledge on many subject, but sometimes I have to impression to talk with a "flat earth" adept or a COVID denier; it does not matter what you can prove, he always have "some word" saying the opposite.

[Baldrick]

Can we all just get along?

Nope. So I'm locking this one.