Micomsoft SC-500N1 RGB Capture Card

[Sixfortyfive]

which already means a colorspace conversion from (in case the XCAP's running in YUY2) and you're writing uncompressed RGB to your harddrive.

I'm having a hard time pinning down where this conversion would be happening. If it is, then the information provided in these programs is pretty unclear.

This is what the recording format is set to by default in VirtualDub when using the XCAPTURE-1:



And this is what the file properties show when playing back the video file in Media Player Classic:



The file seems to be recorded and played back in YUY2, at least according to what I have to work with. What am I missing?

Adding a "convert format" filter set to 4:2:2 YUY2 output in VirtualDub has no visible effect.

I was under the impression that the Shuttle can't record in RGB, so you're already converting RGB back into YUV422 right there.

I'm not sure if I follow. The Shuttle videos were recorded the same way, the only difference being that the default output settings in VirtualDub were in the HDYC or v210 formats instead of YUY2 depending on what the Shuttle was set to.

EDIT: I'm messing around with the alias format filter right now as suggested, and this might help. Going to play around with it a little.

[Fudoh]

The file seems to be recorded and played back in YUY2, at least according to what I have to work with. What am I missing?

nothing. Looks good. I wasn't aware that VDub was able to write uncompressed YUV2.

The Shuttle videos were recorded the same way, the only difference being that the default output settings in VirtualDub were in the HDYC or v210 formats instead of YUY2 depending on what the Shuttle was set to.

yes, they were recorded the same way, but in this case (WiiU instead of 360) you're source signal was RGB instead of YCbCr, right ? I don't think that the Shuttle can record RGB (unlike the higher end Blackmagic units), so you're converting RGB to YUV already.

[Sixfortyfive]

Made some progress.

Dreamcast: no alias filter vs. 601 Full
Xbox 360 (RGB Expanded mode): no alias filter vs. 709 Full
Wii U: no alias filter vs. 709 Limited

In all cases, using no alias filter seems to be the same as using 601 Limited.

When using an alias filter, no matter what settings are chosen or what source is used, the file is identified as RGB instead of YUY2, so I guess this is doing a (proper) color space conversion?



So I guess my question is what I should pick for different sources now:
- always 601 for SD sources, always 709 for HD sources?
- whichever Limited or Full setting matches the source? How can I tell what the source is running? Should I just assume one or the other depending on certain factors (console, cable type, etc.)?

Need to see if I can find comparable options in OBS.

[Fudoh]

The results on the WiiU capture using the filter in VDub seem close enough.

So I guess my question is what I should pick for different sources now:
- always 601 for SD sources, always 709 for HD sources?

yes. If you set your console to output in RGB the transformation from 709 to RGB is happening in the console already, so maybe the WiiU's screwing up right there ?

- whichever Limited or Full setting matches the source?

YCbCr is always limited range. RGB should always be full. Limited range while using RGB should be forbidden.

How can I tell what the source is running?

whatever you set your source to. 360 and PS3 allow the proper settings. PS4 as well. XBO as well (I assume). No idea about the WiiU.

[Sixfortyfive]

If you set your console to output in RGB the transformation from 709 to RGB is happening in the console already, so maybe the WiiU's screwing up right there ?

Wouldn't be able to tell you for sure, as there are literally no color adjustment options on the Wii U. Of the available settings for this filter, 709 Limited just seems to be the most accurate.

whatever you set your source to. 360 and PS3 allow the proper settings. PS4 as well. XBO as well (I assume). No idea about the WiiU.

I'm mostly concerned with older consoles on that question, PS2 and earlier. Should I assume that SCART is full and component is limited? What about lesser cables?

Thanks though. Now I can at least run my 360 capture setup out to my monitor without one or the other looking like crap.

[Ed Oscuro]

So, folks, what do you think:
http://www.eevblog.com/forum/beginners/ ... o-digital/

As far as I can tell, the query is hoping to find 1:1 pixel mapping (that's off the console's internal resolution, nevermind what you actually get in the analog video output) and save it in that same format, without regard for 4:3 aspect ratio or standard resolutions.

I had some questions about workflow.

- Is it plausible to try and capture 1:1 pixels on any retro consoles? Don't we always just capture at whatever settings we get?
- How big an issue would the 16 pixel macroblock size matching for H.264 be? i.e., trying to save at some nonstandard resolution that's not divisible by 16?
- How well do these capture systems cope with mixed 240p/480i effects, like Square games on the SNES, or high-res title screens / menus, switching back to 240p or some other resolution?
- Does framerate conversion work well?

[Fudoh]

- Is it plausible to try and capture 1:1 pixels on any retro consoles? Don't we always just capture at whatever settings we get?

I don't think anybody tried yet. Recognition of the exact sample resolution is kinda the holy grail in developing the perfect A/D stage.

- How big an issue would the 16 pixel macroblock size matching for H.264 be? i.e., trying to save at some nonstandard resolution that's not divisible by 16?

you can always pad to an integer multiple of 16....

[Sixfortyfive]

So, folks, what do you think:
http://www.eevblog.com/forum/beginners/ ... o-digital/

As far as I can tell, the query is hoping to find 1:1 pixel mapping (that's off the console's internal resolution, nevermind what you actually get in the analog video output) and save it in that same format, without regard for 4:3 aspect ratio or standard resolutions.

I had some questions about workflow.

- Is it plausible to try and capture 1:1 pixels on any retro consoles? Don't we always just capture at whatever settings we get?
- How big an issue would the 16 pixel macroblock size matching for H.264 be? i.e., trying to save at some nonstandard resolution that's not divisible by 16?
- How well do these capture systems cope with mixed 240p/480i effects, like Square games on the SNES, or high-res title screens / menus, switching back to 240p or some other resolution?
- Does framerate conversion work well?

I think your revulsion for 1:1 pixel capture is misguided. It could ensure that the capture equipment doesn't scale anything poorly. You could capture at 1:1 and then adjust to the proper aspect ratio in post-production in whatever manner you like, without being at the mercy of however the capture device would do it. I don't have a clue if that's even feasible, but I definitely see the appeal. If eventually outputting to the intended aspect ratio is part of your process, then you often have to rescale the output anyway since 720x480 is neither 4:3 nor 16:9.

H.264 only requires dimensions that are divisible by 2. And in any case, you can do lossless capture then tweak whatever the codec forces you to in post.

240p/480i can be problematic, at least on an XCAPTURE in VirtualDub. It can handle the transitions quickly, but the framerate gets halved on interlaced sources and that will cause audio to go out of sync every time it happens. It's feasible to correct all of that in post, but it would be time consuming to get it all perfect, especially if it's a transition that happens frequently. Timing issues can be avoided in streaming software like OBS or XSplit, but it takes a second or two longer for the card to re-sync to the new resolution in those programs, and they'll throw out or insert null frames if the source framerate doesn't exactly match the capture framerate, which in turn isn't an issue in VirtualDub. Switching between 480p/720p/1080p doesn't mess with the timing, but if you're recording such transitions then it's obviously not going to be pixel-perfect because those resolutions don't divide into each other evenly.

I'm not sure what you mean by framerate conversion, but I can say that recording to the exact framerate in VirtualDub doesn't seem to be an issue. It seems very much possible for VDub to spit out frames exactly how it receives them, with no tearing, inserts, or drops, if you adjust all of the appropriate settings. The framerate can be adjusted to several significant figures, either in capture or post, and this is useful because the precise framerate that different consoles run at varies by quite a bit.

[Ed Oscuro]

Fine job telling me that my revulsion is misguided, and then bumping up against the same practical issues I did in trying to find a way to make it work, 645

The OP in that thread has talked about nostalgia and video playback - it's worth pointing out some of the complications that arise from these very picky requirements, ways in which the output will not be faithful to the original, and asking whether those benefits still are relevant or worth the tradeoffs. It's confronting the abstraction with the reality of analog practice.

Couple quick responses to the last #2 and #3:
- So long as the information is there, sure, some kind of post-processing to fit different resolution frames together. I'd like to know if there are capture devices that don't flinch at doing this. Unsurprisingly, it sounds like the answer is "not really." Perhaps postprocessing frames by hand is the best way of doing it for accuracy, but I'm not sold on that requiring require 1:1 pixel inputs either. If it makes it easier to do, then that's worth noting, however. Perhaps the issue is really "can we capture raw RGB sources and fiddle with them," not so much 1:1 pixel capturing per se - the signals being rather more complicated than the abstraction of the single pixel suggests, as Fudoh notes with the A/D conversion.
- Framerate differences are important for output. We're not talking about files just chilling out arbitrary space, but actually having something that can be played back and not lose information on the viewer. Dropping or splitting frames is not quite great. Again, the point here is not to force a choice, but rather to clarify that this is an area that will need to be confronted for media playback on today's PCs.

Thanks for the various corrections and information, guys!

[blizzz]

Is it possible to record 15kHz sources as 480i 29.97fps with the SC-500N1, like you would on a Dazzle? That would solve the problem with games that switch from 240p to 480i. As long as it doesn't switch constantly it should be feasible to cut the video by hand. In theory it should also be possible to detect 240p in a 480i recording with software and automate the process.

[Sixfortyfive]

- whichever Limited or Full setting matches the source?

YCbCr is always limited range. RGB should always be full. Limited range while using RGB should be forbidden.

I'm still experimenting with this.

Shenmue through Dreamcast VGA seems to have better color contrast if I apply a full RGB filter. But Saturn VF2 through SCART seems to have washed out colors if I apply the same filter.

(EDIT: Disregard this specific comparison. I examined some footage in closer detail and found that applying a full-range filter to VF2 also improved things overall, revealing details that weren't visible in the default setting.)

Do you think this is something that varies by individual game? I have to wonder if maybe some developers targeted 16-235 in the first place, even if the console outputs 0-255.

[Fudoh]

I have to wonder if maybe some developers targeted 16-235 in the first place, even if the console outputs 0-255.

that's very well possible. Japan has this HUGE problem with their 7.5IRE black level offset on NTSC signals. To this very day, every second japanese Blu-Ray is mastered wrong with black levels completely off. Has been a problem forever, still is one and will likely remain a problem for the years to come.

[lettuce]

Can someone tell me where the heck AmaRec software saves snapshot that you take please?

[blizzz]

By default in a 'pic' folder next to the executable.

[lettuce]

Hmmm, i dont appear to have a pic folder for my install. Im on version 3.00c, and cant see any options to select a folder, just only for video capture not pictures though

[lettuce]

Any ideas?

[CkRtech]

I don't have the software, myself, but isn't there a configuration screen somewhere? Something that would show you a path? Like



Alternatively, you could just take a few screenshots and then search your hard drive for files modified in the last few minutes. Somewhat extreme, but that should find it pretty fast.

[lettuce]

I don't have the software, myself, but isn't there a configuration screen somewhere? Something that would show you a path? Like



Alternatively, you could just take a few screenshots and then search your hard drive for files modified in the last few minutes. Somewhat extreme, but that should find it pretty fast.

Found it now, for some reason need to re-install the program and once i did that it then created a Pic folder in my location i set in the general tab. Thanks for the suggestions

[NightSprinter]

So, this is extremely strange: My Model 2 Saturn (which we all know has issues with RGB out) is putting out a blurrier pic (and color banding, despite for my NEC monitor and my PEXHDCAP the SCART cable is wired for raw sync) in RGB with the card set to 320x240x59.94 RGB32, but is showing a crystaline picture if set to 720x240x59.94 YUV2. I'm going to post a couple of pics (the RGB one I had to resize to double to make it viewable).



What the hell happened to this card on RGB? On my monitor, there's no color bleeding or smudging of fine details.

[blizzz]

The RGB modes use some weird internal scaling. Never use it, it doesn't work. Best disable it in the driver settings.

[NightSprinter]

Strange, the checkbox for auto resolution scaling and RGB24/32 output isn't enabled in the device properties. All I have RGB input to is just the basic 320x240x59.94 RGB24 listed in Amarec.

[NightSprinter]

Also, for some reason on my PEXHDCAP, there's color artifacts even when using the YUV2 colorspace for my 240p recordings. Think this is a problem with that recent Startech driver?

[blizzz]

What kind of artifacts? Have you checked the color correction option on the advanced tab in Amarec?

[NightSprinter]

Yeah, seems to work nicely now. Out of curiosity, with the issues caused by the new driver's RGB input selections, would you advise reverting to an older version that didn't support RGB24/32?

[blizzz]

I haven't done enough tests to give a proper answer. I only compared the 108 and 114 drivers a long time ago (108 had better component quality). The current drivers have higher saturation I think. If you've got the time you could compare the old driver to the current one and report back.

[NightSprinter]

The older drivers seemed to have buggered something up fierce. I had to go back to the 1.126 driver just to get capture from the RGB input to work. I can, sadly, state that anyone who wanted to capture any IREM M72 arcade games are out of luck. I have my linux arcade box connected and running groovyume, and neither the first or second R-Type could sync (the crossbar or whatever lists the refresh as 50Hz, when it's not 50Hz). In fact, it seems to have this issue on ANYTHING that doesn't output NTSC or PAL refresh rates. Also, for some reason selecting RGB32 flips the image and rotates it 180 degrees.

[blizzz]

There are several examples of 54Hz games in the first post. I would be surprised if R-Type doesn't work with this card.

[NightSprinter]

Yeah, given that the first page mentioned Lode Runner arcade wasn't working, the same for R-Type is true I'm afraid. As Groovymame/Groovyume on my customized Arch Linux install has the video card directly output the game's original frequency/resolution, here's a screencap from VideoKeeper showing what's wrong. Also, apparently my desktop fails to show as well in anything but VirtualDub if the refresh rate is any higher than ~60Hz. Here's a screenshot that shows VideoKeeper unable to take sync input/refresh from R-Type (Heh, XRGB-2 Plus anyone?).

[blizzz]

A small build log of a Mini ITX system for the SC-500N1.
I had been planning to do this for a long time, but never found a case I really liked. A while ago I found the Xigmatek Nebula and just ordered it. Most of the hardware I've used is just spare stuff I had lying around.



First impression was that it is quite a bit bigger than I expected. The specs on the site I use to browse for hardware (Geizhals.at) listed it as 206x206mm, but in reality it is 260x260mm. I've worked on a 200x210mm case this week, and the Nebula feel noticeable bigger. But the pros of this are that you have more space for hardware and cooling.



The Specs

• Xigmatek Nebula, Mini-ITX
• Zotac H67-ITX Wi-Fi
• Intel Core i3-2100T, 2x 2.50GHz, boxed
• Corsair CS Series Modular CS450M
• exceleram Black Sark DIMM 2GB, DDR3-1333*

*the worst memory I ever had. I normally buy Corsair memory, but got this one for cheap some years ago. One of the two DIMMs failed and caused me a lot of trouble and I'm not convinced that this one is still 100% ok. Always buy RAM from one of the major brands.

Installation wasn't hard. The only problem were two of the motherboard screws that needed an angled screwdriver to tighten because the space is blocked by the HDD cage. The CS450M is an excellent PSU for ITX builds. It only has power cables for the motherboard hardwired and everything else is modular. I just needed one extra power line for 2x SATA connectors. It only has one 6/8 pin connector for GPUs, but that shouldn't be a problem for ITX builds.

One of the problems of the case is that the orange corner (more about that later) has a black cover that limits the space for GPUs severely. Luckily you can remove it with two screws and it doesn't change anything. Once removed you can fit GPUs of up to 24cm length. Cable management isn't perfect, but they added enough spots for cable tighteners so it works out quite well. The case has two slides for 3.5" HDDs (no rubber against vibrations though) and a seperate spot for a 2.5" SSD. It also comes with one 2.5" to 3.5" slot adapter.

Airflow is managed through holes in the bottom of the case and a 120mm exhaust fan, plus the exhaust of the PSU. This shouldn't be a problem unless you try to put a high end graphics card into the case. Something like a 750Ti (or a 760) should be fine. The CPU cooler is limited to 80mm height, so you probably don't want to put an overclocked i7 in this case. I think it's possible to use a water cooler like the Corsair H80i if you remove the HDD cage. But for my i3 the boxed cooler is fine.


Once the PC starts you can see why I chose this case. The orange corner lights up! It has both LEDs for system power and HDD access. For a capture box it might look nice to only connect the HDD LED. That way you get an orange glow while you're recording
The rest of the case is very clean, with the power button on the top. For a small and light case that's the perfect spot.

Finished build



Overall it's a nice case. A smaller alternative is the Cooltek Coolcube. I could also see this as a stylish media player or Steambox.

[Fudoh]

Mine's smaller