We DO NOT need to capture VIDEO when capturing the final AUDIO stream. Video is supposed to be captured before, with whichever audio plugin that syncs.
This is incorrect for certain graphics plugins, like TAS Soft Graphic Plugin. There are missing load frames from the video if you don't use Eternal SPU and used a sync audio plugin.
Then we are not able to compare screenshots because the frames don't match. Are we?
I think it will still match. It isn't like the capture with the missing frames have new frames. They just have duplicate frames of the last frame before the missing frames start as spacers. For example, a capture with missing frames would have the frame counter go like so: 0, 1, 2, 3, 10, 11, ... while a capture without missing frames would have the frame counter go like so: 0, 1, 2, 3, 3, 3, 3, 3, 3, 3, 10, 11, .... I hope I explained this clearly.
Thanks a lot for your work BadPotato. As for PSX MegaMan X6, I've already found all the desyncs and encoded the video. It will be up soon (I hope). When I get some time, I will try out what you made, BadPotato.
We DO NOT need to capture VIDEO when capturing the final AUDIO stream. Video is supposed to be captured before, with whichever audio plugin that syncs.
This is incorrect for certain graphics plugins, like TAS Soft Graphic Plugin. There are missing load frames from the video if you don't use Eternal SPU and used a sync audio plugin.
Yea, that is weird, I do 120 GB captures with .kkapture with it auto splitting...
Also, command line to the forked application is there, but command line to .kkapture itself isn't there.
Sounds like progress can be made in making it easier at least. I should mention that usually what I do is make a save state 15 frames before the known desync point. Comparing screenshots to see the exact desync point is a great idea, and if you can delete on fly after the compare, I think the space usage would be low.
To be honest I don't see the need for higher resolutions than 720p (native resolution = 240p) or 1080p (native resolution = 480p; use PointResize 2x first). The most important thing is to avoid YT's 480p mode which degrades quality too much.
There is a need for certain systems that do support higher resolutions like N64.
Easier, yes, but you have less control on the resize method. The better resize methods are usually more CPU intensive and will be harder to do on fly. As an encoder, I would like to have the choice of what resize method.
DSS2 is not using VfW, hence the DirectShowSource2. DirectShow technically doesn't have a limit, but Avisynth does have a memory limit =p. Usually, what I do is concat some files and make a bigger AVI file. Obviously this requires more space.
I had a different problem yesterday. I uploaded an MP4 of 13 minutes length and when I opened the page it would tell 13 minutes but immediately change to 6 minutes and only show half the video. I fixed it by encoding differently (different --crf in x264).
YouTube doesn't like MP4s, try remuxing in MKV instead next time.
Since you are doing lossless, that's fine. The script may be off since you seem to be on Genesis, not NES, which would have a original resolution of 320x224 (I believe). The tag is necessary to get the right aspect ratio as on a TV.
I'm now curious. joel96 what is your main goal? To make TASVideo publishable encodes? If so, then you are on the right track. If this isn't so, then well it might be a bad idea to use the script at all. The point of the script was to make publishable encodes on TASVideos. Also to speed things up, it be preferred you get on IRC to get help from us.