Looking for VHS capture advice, evaluations and helpful opinions

[Sharc]

@Alwyn: and here the tricky-clicky Handbrake settings to crop and resize to your preferred 720x540 square pixels. Yes, it's doable as well. And no, I didn't inhale certain mushrooms to find out how to do it.


[Attachment 81631 - Click to enlarge]

[916Area52]

Again, thank you all for the time and effort.

Though HandBrake was my training wheels effort at AVI to mp4 conversion, I’m dissatisfied with the sync issues. Time to move on.

It’s been awhile since I’ve experimented with Vdub, (VirtualDub-1.9.11 and VirtualDub2_44282) for capturing, not editing (again, sync issues). So, I moved on… Used Egato Video Capture dongle/software and half way through my VHS tape collection, realized that the end product could be much better. Again, moved on… Used I-O Data GV-USB2 dongle with OBS. Realizing again, it could be better.

@Alwyn “Perfect is the enemy of finished, after all”

LOL, thank you for this.

As I see it from the feedback my new software workflow (and learning curve) should look like this:

AmaRecTv - for capture
AVIDemux - for trim
VirtualDub - (VirtualDub 1.10.4 / 1.10.5 test 7 Latest version 1.10.4 / 1.10.5 test 7 (October 13, 2014)? and/or VirtualDub2 20 Update 19 Latest version20 Update 19 (March 20, 2020)?) for conversion (AVI to mp4) and any post editing

AviSynth is waiting in the bullpen.

[Sharc]

Again, thank you all for the time and effort.
Though HandBrake was my training wheels effort at AVI to mp4 conversion, I’m dissatisfied with the sync issues.

Really? Not to defend Handbrake but I didn't get sync issues - with the exception of your 1st flawed example in post#1.

[916Area52]

Again, thank you all for the time and effort.
Though HandBrake was my training wheels effort at AVI to mp4 conversion, I’m dissatisfied with the sync issues.

Really? Not to defend Handbrake but I didn't get sync issues - with the exception of your 1st flawed example in post#1.

I'm seeing a sync issue with your last attachment " IVTC_out.mp4 (14.36 MB, 3 views)".

[Sharc]

Again, thank you all for the time and effort.
Though HandBrake was my training wheels effort at AVI to mp4 conversion, I’m dissatisfied with the sync issues.

Really? Not to defend Handbrake but I didn't get sync issues - with the exception of your 1st flawed example in post#1.

I'm seeing a sync issue with your last attachment " IVTC_out.mp4 (14.36 MB, 3 views)".

Nothing here ..... all in sync. I must be missing something ....

[916Area52]

LOL... or I

[Alwyn]

here the tricky-clicky Handbrake settings to crop and resize to your preferred 720x540 square pixels.

Halleluiah! I have spent hours/days/months trying to make that all work. Thanks. No Preview realtime though (have to go back and forth to Summary tab). Still don't like it.

[916Area52]

@Sharc, Apparently the error I experienced was on my end. Opened “IVTC_out.mp4 (14.36 MB, 3 views)” using the VLC player and there where no sync issues. Why the difference in what player is used is a mystery to me.

Using lollo settings outlined in post #11 “In "Graph2(Preview)" disable deinterlacing (useless resource consuming feature)
In "Advanced" set Priority to High, enable "Match the start timing of the audio with a video" and enable Make a report file, to have a full log of what happens during capturing; in particular you can check there where are located the inserted and dropped frames (if any) and understand why.”

And Sharc settings in post #22

The attached are my results…

[916Area52]

here the tricky-clicky Handbrake settings to crop and resize to your preferred 720x540 square pixels.

Halleluiah! I have spent hours/days/months trying to make that all work. Thanks. No Preview realtime though (have to go back and forth to Summary tab). Still don't like it.

Why is "720x540 square pixels" important?

[916Area52]

Just thinking aloud... I'm intrigued. Came across this YT for AviSynth for beginners https://www.youtube.com/watch?v=RXByaCFgIHc, will be looking into AviSynth more.

[Alwyn]

IMO, that bitrate is too low for a movie, even a VHS movie. I'd be shooting for around 2000kbps "average bitrate". What that is in CRF I wouldn't know.

Why is "720x540 square pixels" important?

Personal preference; I see no reason why SD should be any different to almost every other video format, and there are no worries about aspect flags not being read correctly.

[Sharc]

here the tricky-clicky Handbrake settings to crop and resize to your preferred 720x540 square pixels.

Halleluiah! I have spent hours/days/months trying to make that all work. Thanks. No Preview realtime though (have to go back and forth to Summary tab). Still don't like it.

As I see it, all these "annoying" locks are made to prevent people from doing incorrect rescalings ("stretching"), ignoring PARs, making useless and flawed upscales, outputting wrong AR's etc.
Any GUI requires time to use it properly and eventually should protect users from producing flaws and complicated installations/setups. Learn how to use Avisynth and ffmpeg instead and one can do whatever one wants or likes ....

[916Area52]

Like to say, Thank You, for the plethora of knowledge, experience and time shared here. Along with the kindness and the manner in which it was shared, is nothing short of stellar/amazing. Clearly, I have a Lot more to learn and it is good to know there is quality resource available.

Think I’m good to go (emphasis on “Think”) … Off to redo my ever-growing VHS collection.

Attached.

Thanks to you All again,
Roy

[Alwyn]

Wow!

[i4004]

if you notice async on longer videos, that's probably ffmpeg input driver (inside the handbrake) being .avi dropped-frame agnostic ie non-aware.
you won't notice it on short clips.

solution?
vdub2 encoding, or loading video to avisynth first, then to h.brake, if it accepts .avs input.
also encoding video via some lossless codec in vdub2, then loading it to h.b. (yes, it already is lossless, but resaving it will remove drops.)

check your video for dropped frames(vdub2: go->next drop frame)

[lollo]

If the captured video has dropped frames and then A/V asynch, there is no (simple) solution.

The inserted frames can be removed with a simple AviSynth script, but this may introduce A/V asynch, if not already present.

VirtualDub (and any other software) cannot determine a dropped frame in a capture. It can only show an inserted frame, because this last does not consist in a real frame, but in a few bytes indicating to repeat the previous frame. Unfortunately the VirtualDub naming is wrong.

[i4004]

truth, they should of call it null-frames as in that dialog box.

"go to next null-frame"

If the captured video has dropped frames and then A/V asynch, there is no (simple) solution.

frames are dropped/inserted precisely to keep sync. so yeah, if video has drops/insert AND still async, that's tough, you can only split it to smaller parts, sync those, join.

but i wasn't thinking of that, but a situation where modern encoders cause async in final file, while source file plays ok.
for example encoding avi with nulls in hybrd.
i think none of the "all-in-one" input drivers copies code of vdub/avs avi handling, which they should.

[lollo]

frames are dropped/inserted precisely to keep sync. so yeah, if video has drops/insert AND still async, that's tough, you can only split it to smaller parts, sync those, join

No.
The dropped frames happens at capture software level when a frame does not arrive in time and the capture software does not know what to do. They always lead to a/v asynch.
Inserted frames happens when a video frame does not arrive in time, and the capture software repeat the previous frame trying to keep audio/video in synch. It may succeed or fail.
On top of that, there could be dropped frames at hardware level (player, capture card) that the capture software is not aware of.

but i wasn't thinking of that, but a situation where modern encoders cause async in final file, while source file plays ok.
for example encoding avi with nulls in hybrd.

That does not refer to the capture process. I do not use any GUI, so I cannot help there. As info, having few inserted frames in a capture, and encoding with ffmpeg command line, keeps the a/v synch of the source.

[i4004]

No.
The dropped frames happens at capture software level when a frame does not arrive in time and the capture software does not know what to do. They always lead to a/v asynch.

certainly not.
i presume you were not using vdub to capture video?
although from "old guard" even avi_io didn't have sync issues most of the time.
but i mostly use(d) vdub.

so it worked ok even on older vdubs (and i have plenty video to prove), after that this was introduced
https://www.cithraidt.de/sync/index.html
(that concerns audio resampling, but that doesn't mean it won't insert or drop frames if drift is too much, ie capping white noise etc.)
and then applied to directshow capture (by vdub author), as vdub sync is vfw only.

On top of that, there could be dropped frames at hardware level (player, capture card) that the capture software is not aware of.

yes, when you're capturing with "integrated" capture solutions, ie dv cameras, canopus advc etc.
that's different to old analog capture cards that digitize video only, while audio is captured with sound card.
bt8x8 and philips saa 3xxx chips.
in that case vdub is fully aware of audio and video drifts. and tries to correct them.

As info, having few inserted frames in a capture, and encoding with ffmpeg command line, keeps the a/v synch of the source.

capture this:
video segment<->white noise<->video segment<->white noise etc.

encode in yourt way, and then see if it drifts more.

then again, i don't encode with ffmpeg, maybe it differs to ffmpegsource().
maybe it's vapoursynth's application of ffmpegsource.
lots of maybes that don't concern me too much as i don't think avc or mpeg4 are good codecs for vhs footage anyway.

[lollo]

certainly not.
i presume you were not using vdub to capture video?
although from "old guard" even avi_io didn't have sync issues most of the time.
but i mostly use(d) vdub.

so it worked ok even on older vdubs (and i have plenty video to prove), after that this was introduced
https://www.cithraidt.de/sync/index.html
(that concerns audio resampling, but that doesn't mean it won't insert or drop frames if drift is too much, ie capping white noise etc.)
and then applied to directshow capture (by vdub author), as vdub sync is vfw only.

Certainly yes.

You probably do not know what you are talking about. Having experimented VirtualDub and all other capture software since decades on my side as well, and also developped my own capture software.

The dropped frames lead to a/v asynch, whatever capture software you are using (and VirtualDub sometimes is not the best). That's why we use an external TBC. The link you provided has nothing to do, and relates to VirtualDub internal procedure to keep a/v in synch when audio and video are captured with separated cards and then different clocks (which was the big VirtualDub advantage long time ago and its main problem today with modern cards and OSs).

yes, when you're capturing with "integrated" capture solutions, ie dv cameras, canopus advc etc.
that's different to old analog capture cards that digitize video only, while audio is captured with sound card.
bt8x8 and philips saa 3xxx chips.
in that case vdub is fully aware of audio and video drifts. and tries to correct them.

Again, different scenario, and I already explained several times that concept of capturing audio and video through different cards.

capture this:
video segment<->white noise<->video segment<->white noise etc.

encode in yourt way, and then see if it drifts more.

Useless experiment, but it won't. I have many captures with videos interleaved with blank sections capture in the middle. In any case, it is just an experiment, nobody will use that, but rather crop the blank portions.

then again, i don't encode with ffmpeg, maybe it differs to ffmpegsource().
maybe it's vapoursynth's application of ffmpegsource.
lots of maybes that don't concern me too much as i don't think avc or mpeg4 are good codecs for vhs footage anyway.

No clue on what you are using nor on the problems you have. On my side, I use both HuffYUV and low CRF h264 as delivery format for VHS captures, and both are excellent choice.