How to Compare Retro Upscaler and mClassic Image Crops Fairly in a Test

Use the 240p test suite grid from a known console. An NTSC SNES at 256×224, captured through a verified 4:4:4 chain in OBS Studio with FFV1 encoding. Count the visible pixel columns and rows against the full-frame reference. That is the only way to compare image crops fairly. Everything else introduces uncontrolled variables: the capture card's ADC sampling, the display's scaling, the mClassic's context-adaptive anti-aliasing, and the OSSC's zero-buffer line multiplication. Without that standardised method, a side-by-side crop tells you more about the capture setup than about the scaler.

The 240p test suite, developed by Artemio Urbina and available for SNES, Genesis, Dreamcast, Wii, GameCube, and PC Engine, provides the grid pattern that serves as the community's measurement standard. Load it on your source console, select the grid, and record the identical frame through each scaler in turn. The full-frame reference for an NTSC SNES is 256×224 active pixels; for an NTSC Genesis in 320 mode it is 320×224. Any crop, intentional or accidental, reduces those counts. The scaler that preserves the full count without clipping or overscan is the one that passes the full frame.

The failure case: a scaler or capture card that treats 240p as 480i will deinterlace the grid. It halves the vertical detail and introduces combing artifacts on the checkerboard edges. If you see diagonal lines that should be straight, the signal path has misdetected the source. Reject that chain and start over with a scaler that correctly identifies 240p, such as the RetroTINK 5X-Pro or OSSC.

Your capture chain must lock down every variable except the scaler under test. The reference setup, documented by Shmups Forum and RetroRGB, is: source console → scaler under test → Elgato Game Capture HD60 X → OBS Studio 30.0. The capture card must accept a 4:4:4 chroma subsampling signal from the scaler, not a 4:2:2 or 4:2:0 downsampled version. Chroma subsampling at 4:2:2 discards half the colour detail horizontally. It smears the red and blue edges of the test grid and makes pixel-counting unreliable.

Set OBS Studio to record in FFV1 or Ut Video at YUY2 or RGB. Both are lossless formats that preserve the exact pixel data from the scaler. Use a frame lock to ensure the capture card has re-synced after any switch in output. The mClassic may take one to two seconds to lock when the source changes from a 240p menu to a 480i gameplay segment. Grab five consecutive frames of the grid and verify that all five show identical pixel counts. If they vary, the scaler is applying dynamic cropping or the capture card is dropping frames.

The mClassic applies context-adaptive anti-aliasing to the entire frame. It softens 2D pixel art edges. Compare a mClassic output to a raw OSSC line-multiplied output and the mClassic will show fewer fully saturated pixels along the checkerboard edges. The transition from black to white spans two or three pixels instead of one. This is not a crop; it is the scaler's algorithm. To measure the crop separately from the softening, count the number of complete black and white squares in the grid, not the edge sharpness. The mClassic passes the input frame dimensions unchanged: 256×224 from an NTSC SNES remains 256×224 at its output. The softening is post-processing, not cropping.

The real-world consequence for pixel art: on a 4K OLED, the mClassic's anti-aliasing makes a 240p sprite look like it was rendered at a higher detail level. It also removes the hard pixel edges that integer scaling preserves. The OSSC's Line5x mode at 1920×1200 from a 240p source gives razor-sharp pixels with no softening. Neither is objectively better, but the test method must separate the crop measurement from the filter measurement. Count squares for the crop; use a FirebrandX CRT profile as the accuracy benchmark for the look.

The OSSC is a line multiplier with no framebuffer; its output at Line5x from a 240p source is 1920×1200. The RetroTINK 5X-Pro is a framebuffer scaler; its output maxes at 1920×1440. Both pass the full 256×224 frame by default. Zero pixels cropped horizontally or vertically. The difference in a crop comparison comes from the analogue-to-digital sampling stage, not from the scaling stage. The OSSC's ADC samples the incoming analogue signal at a fixed rate; the RetroTINK 5X-Pro's ADC may sample at a slightly different phase. If the sampling clock is off by one pixel, the resulting digital image will show a one-pixel shift at the left or right edge. It looks like the frame is cropped when it is actually misaligned.

To control for this, record the 240p test suite grid at the same moment. Use a frame lock on the capture card and overlay the two captures in OBS Studio using the lossless source. Align them by the top-left corner of the grid. If the OSSC output shows 256 columns and the RetroTINK output shows 255, the scaler is not the problem; the ADC phase needs adjustment. The Shmups Forum method calls for adjusting the sampling phase on the scaler until the grid shows clean, non-blurred vertical lines before you take the comparison shot.

FirebrandX produces the reference CRT and HDR profiles used in RetroTINK and MiSTer. They define the target look of accurate CRT emulation. These profiles set the expected luminance, colour temperature, and scanline mask density against which any scaler's output should be measured. When you compare a mClassic output to a RetroTINK 5X-Pro output, the FirebrandX profile tells you which one is closer to the CRT reference, not which one is sharper. Sharpness is not accuracy. The OSSC's line-multiplied output is sharper than any CRT ever produced, because a CRT's electron beam naturally blurs the edges between pixels. The FirebrandX profile accounts for that beam spread and sets the correct amount of scanline gap.

To use the profiles in a crop comparison, load the FirebrandX CRT profile on the RetroTINK 5X-Pro, or the RetroTINK 4K at 4K with HDR10. Record the grid and compare the scanline mask density against the mClassic's output. The mClassic has no scanline mask; it applies anti-aliasing instead. The comparison is between two different approaches to the same problem: making 240p look acceptable on a flat panel. The FirebrandX profile is the tiebreaker for which approach is more accurate to the original CRT experience.

Three Failures In An Uncontrolled Comparison

Three things break. First, the sharpness difference: the OSSC's Line2x through Line5x modes produce unprocessed pixel replication, while the mClassic applies a context-adaptive anti-aliasing algorithm that softens edges. A side-by-side crop without noting the processing difference will look like the OSSC is showing a more detailed image. It is showing a less processed one. Second, the chroma subsampling mismatch. If the mClassic is connected through a capture card that downsamples to 4:2:2 while the OSSC is connected directly to the display at 4:4:4, the colour detail difference will make the mClassic output appear blurrier than it is. Third, the input ceiling. The mClassic accepts a maximum of 1920×1080 at 60Hz. If the source console outputs 1080p, the mClassic can process it. If the source is 240p, the mClassic must first deinterlace and upscale to 1080p before applying its algorithm. That step adds one to two milliseconds of latency, measured by Time Sleuth, and introduces a processing pipeline that the OSSC bypasses entirely.

The fix for all three is the fixed capture chain described above: same capture card, same OBS Studio lossless settings, same 240p test suite grid, same frame lock, and both scalers set to output 1080p at 60Hz. Only then can you attribute the visible difference to the scaler's algorithm rather than to the capture chain.

The standardised crop comparison workflow was developed and documented on Shmups Forum and RetroRGB. Use the 240p test suite grid. Record lossless at 4:4:4. Count pixel columns and rows against the full-frame reference. Bob Neal's RetroRGB site is the central English-language repository for cable, mod, and scaler specifications, including the exact EDID and handshake requirements for each scaler. The Shmups Forum thread on OSSC calibration, which dates to the OSSC firmware 0.90 release, established the sampling phase adjustment procedure that prevents false crop reports. If you follow this workflow and get a crop count that differs from the reference, check both sources for the specific scaler's known sampling quirks before concluding that the scaler is cropping the frame.

The failure case for attributing incorrectly: a reader who sees a YouTube crop comparison that shows the RetroTINK 5X-Pro outputting fewer columns than expected may assume the scaler is defective. In reality, the capture card's EDID may have reported 1920×1080 when the scaler was outputting 1920×1440, and the capture software scaled it down, losing columns. The RetroRGB documentation of the RetroTINK 5X-Pro's EDID behaviour explains this mismatch. Check the capture card's reported input picture size before you count pixels.

Integer scaling from 240p to 1080p produces a 4x scale to 960p with black borders. The mClassic does not integer-scale; it upscales to 1080p using a non-integer algorithm that resamples the entire frame. This means the pixel grid of the source is not mapped evenly to the output grid. Some source pixels are stretched, some are compressed. In a crop comparison, the mClassic output will show the same number of active pixel columns, 256 from an NTSC SNES, but those columns will not align with the capture card's pixel grid in the same way that the OSSC's integer-scaled columns do. The result is a one-pixel-wide shimmer on vertical lines as the resampling moves across the frame.

To measure this, record the grid and zoom to 200% in OBS Studio. The OSSC's integer-scaled output will show each source pixel as a clean block of four or more output pixels, depending on the line multiplication factor. The mClassic's output will show a gradient at each vertical edge. That gradient is not a crop; it is the non-integer scaling filter. Count the complete squares, not the edge pixels, and note in your test report that the mClassic uses non-integer scaling.

Some scalers apply sharpening filters that create a ringing halo around high-contrast transitions like the black-to-white edges of the grid. A light or dark edge. The OSSC applies no sharpening; its output is a literal pixel replication. The RetroTINK 5X-Pro has a sharpness control that can introduce halos if set above the default. The mClassic's anti-aliasing algorithm does not produce a halo; it blurs instead. In a crop comparison, a halo around the grid squares indicates that the scaler's sharpening filter is active, not that the scaler is revealing more detail. To test for halos, record the grid at the same exposure and zoom to the corner of a black square. If you see a one-pixel-wide bright line on the inside of the black square, the scaler is applying sharpening. Disable it before you take the crop measurement, or note it in the test report as an uncontrolled variable.

The capture card's frame lock speed determines how quickly it re-syncs to a new signal. The mClassic, when switching from a 240p menu to a 480i gameplay segment, may take one to two seconds to re-sync. During that time, the capture card may show a black frame or a frozen frame. If you take your crop shot from that window, you will get a zero-pixel frame. The OSSC, with no framebuffer, re-syncs in microseconds, so the capture card locks immediately. To avoid the mClassic's re-sync window, record the grid from a steady-state output. Let the mClassic run for at least five seconds after the source console displays the grid, then grab five consecutive frames. If any frame shows a different pixel count, the re-sync is still happening.

The RetroTINK 5X-Pro's frame lock speed is documented in firmware 3.0 as sub-second for signal switches. The RetroTINK 4K is similarly fast. For all three scalers, the 240p test suite grid is the only pattern that guarantees a stable, unchanging output for the duration of the capture window.

Who Should Follow This Method

The standardised crop comparison method suits the capture and streaming hobbyist who needs to split a signal cleanly to both a lag-free play display and a recording device without degrading either. It suits the Hong Kong apartment gamer with limited space who needs one display for modern and retro consoles and must understand why their Super Famicom looks like a smeared mess on their 4K OLED. It suits the CRT-curious enthusiast who has access to second-hand Sony PVMs from local markets but needs to understand RGB modding and regional pitfalls. It suits the competitive player who perceives milliseconds of input lag and needs to know which scaler and TV settings add the least delay for rhythm games, shmups, or platformers.

Who Should Skip

Skip it if you are looking to buy a pre-modded console as a plug-and-play gift with no interest in settings menus. Skip it if you are a PC gamer trying to upscale old 3D PC titles from a Windows desktop. Skip it if you are a modern gamer wanting better anti-aliasing on a PlayStation 5 or Xbox Series X. The single thing that most often goes wrong: the capture card's EDID negotiation forces the scaler into a signal or subsampling mode that introduces a crop that has nothing to do with the scaler itself. Verify the capture card's reported input picture size before you count a single pixel.