Startech USB3HDCAP opinions

[manono]

I'm really not sure what to do in order to fix this...

You got the field order wrong. Before the QTGMC line put AssumeTFF. If that doesn't work to give you smooth motion, try AssumeBFF.

[Polsom]

You got the field order wrong. Before the QTGMC line put AssumeTFF. If that doesn't work to give you smooth motion, try AssumeBFF.

You're a lifesaver, setting the Top Field First fixed everything. I was really worried I had managed to screw up the capture somehow.

Apologies If I appear to be jumping to conclusions quickly It's just that I really have little idea of what's going on behind the scenes so aside from being able to tweak settings I can't really understand what's going on when things don't go right.

[jagabo]

Also, look into cleaning up that chroma subcarrier noise in all the colored areas.
https://forum.videohelp.com/threads/384137-Clean-analog-interference-(RGB-SCART)#post2489957

[Polsom]

Also, look into cleaning up that chroma subcarrier noise in all the colored areas.
https://forum.videohelp.com/threads/384137-Clean-analog-interference-(RGB-SCART)#post2489957

I will have to have a look into cleaning up my captures at some stage, for now I'm still struggling with the basics.

After I did another 8 Hour encode of the same file I've got but another issue, for some reason all of a sudden the audio is out of sync. It appears to be fixable as affecting the resultant audio by hastening it by about 5.600 seconds in VLC gets the sync just about right across the whole video - I would like however to know what the exact difference is. Using Media Info shows a 1 second difference in the length of the 2 tracks but I'm not really sure if that's accurate.

This appears to be the result of the Cutting command in StaxRip, It looks like it's cut the junk frames but not the audio. I've read a little about this and it seems like adding the pad=false flag to the end of the command might fix my issue. It's worked fine on a small clip but then so did everything when I tested the previous config on the small clip so I don't think that's a good way of being sure.

I don't want to have to encode the whole thing again, so If I could somehow adjust the audio start point to match the video for this encode and then find out how to make sure this doesn't happen on any further encodes that would be great.

EDIT: Using MKVToolNix to hasten the audio track worked fine to clean up the encode, not entirely sure if it's 100% matched because I've only eyeballed what I could make out using VLC but this result is FAR better than running another 8 Hour Encode.