Some pretty good info in here. I hadn't considered the method shown to correct the horizontal sampling in captured footage. I'm definitely going to try that out sometime.
For the section on capture cards, I'm wondering if it's even worthwhile to include a short (or even long) list of example capture devices. So many words would have to be dedicated to a very large range of devices in order to do that properly. Instead of doing that (or, if you prefer, as a supplement to that), why not list important qualities to look for in a capture card? Some examples:
- PC interface (PCI, USB2, USB3) and the pros and cons of each
- video connections supported (HDMI, component, VGA, etc.)
- max supported res (can it actually do 1080p60?)
- proper 240p support (rare in HD capture devices)
- ability to handle unusual framerates
- ability to handle resolution changes on the fly
- ability to record uncompressed video vs. forced H264 capture
- chroma subsampling format
- video/audio delay in capture preview (generally not an issue in internal/USB3 cards; can vary wildly in USB2 cards)
- DirectShow compatibility (ease of integration with third-party video capture and post-processing software)
- DVR functionality, ability to capture when a PC is not even present, rewind / instant replay functionality, etc.
- passthrough and transcoding functionality (The Avermedia LGP is a darling of the fighting game community for this reason. A PS3 can be connected to the LGP via component to bypass HDCP, then transcoded to HDMI for display on a tournament monitor with no lag added in the process.)
Anyway, here's some thoughts I had on various parts while reading through it:
All of the newer consoles since the PS2 and Gamecube era use 480i for 99% of the games, but also some of the older games used 480i in parts or for the whole game.
I think this sentence should be a little more clear in that you're specifically talking about only the PS2 generation when you say that the vast majority of "newer" games run in 480i.
Some games gained a few milliseconds processing time by decreasing the vertical size of the picture.
Could you clarify this?
Modern consoles output at 720p or 1080p with 30 to 60 frames per second.
Technically, the consoles themselves all output at 60hz. Whether the games actually draw a new picture on every cycle is a matter of whether they can keep up, as it has been for decades.
Also: I would link to Fudoh's XRGB cross-comparison instead of his standalone Framemeister review. It's more current, corrects some minor errors that were in the mini's review, and gives a good idea of some of the metrics a consumer should use when deciding on an upscaler. I'm a little irritated that the Framemeister seems to be the end-all, be-all recommendation to people just getting into RGB equipment. IMO, not enough effort is spent to inform people about what it actually does better or worse than other devices in its field, which brings me to...
The Framemeister adds a small delay to the signal, around 25ms. If you have a very slow TV this might be a problem, but even on an average TV with 30ms input lag it won't matter.
This is some very strong language... Forgive me for standing on a soapbox for a moment, but I have a very, very hard time putting down money on any kind of gaming setup that has more than 1 total frame of lag. I'd have a really hard time pairing a Framemeister with even the fastest LCD monitors, let alone average HDTVs. This is the main reason why I never once considered buying one over an XRGB-3. A minimum of 2 frames of lag in a best-case scenario is something I expect out of generic $50 boxes from China, not $300+ high-end equipment designed specifically for gamers.
To use the full potential of this card for retro gaming you need a way to connect the SCART RGB output of the consoles to the DVI-I input of the capture card. The RGB signal of consoles uses composite video as sync information. But to capture RGB you need a clean sync signal that is stripped of the composite video.
Is it really the sync "cleaning" that's the important part for this, or is it the separation into horizontal and vertical sync? Or both? Just curious.
To record your gameplay you should use a lossless codec like Lagarith or the highly optimized H264 encoder x264vfw.
Another viable solution is to just record completely uncompressed video with no compression codec at all. You might need a decent external HDD array to do so for 1080p60 video, but it's possible to tweak some programs like VirtualDub so that they're optimized for this. (IIRC, vdub can be configured to eliminate some of the overhead that normally occurs in the Windows file-writing process.) This uses virtually no CPU resources at all and ensures no encoding errors, at the obvious expense of using more disk resources instead. Worth considering depending on what the bottleneck in your particular capture PC happens to be.
This procedure can be done with video edition programs like VirtualDub or picture editing programs like Photoshop.
typo
x264 should be set to the Superfast or Ultrafast preset. This doesn't lower the quality of the encodes, but makes it possible to record on mid-range CPUs in real time.
This generally doesn't lower the quality of the encodes
when bitrate isn't a factor (i.e. when you're just recording locally to your HDD). It is a big factor for livestreaming, though. An x264 stream at Ultrafast/1Mbps is going to take a noticeable hit in quality when compared to a stream at Medium/1Mbps, so I think this section should be clarified. Generally, when both CPU usage and bitrate are factors, the x264 encoder should be set to the slowest (most-thorough) encoding setting that doesn't cause a noticeable hit in performance (such as frame drops).
By setting the keyint setting to something low like 10 you can increase the performance in video edition software at the cost of slightly bigger file sizes.
typo
