My method to find out the true aspect ratio of SD consoles.

[Shikore]

Hi, this is my first post here so be kind with me
I also don't know if this accurate or if this is already known. So please forgive me if this is the case.


So I was thinking about this picture from FirebrandX where he believes that the proper aspect ratio for the SNES is the right one. I tried to understand why this is the case and tried to find a formula for it.
The goal here is to calculate the aspect ratio as it was displayed on standard CRT TVs calibrated for NTSC content; not to find out the intended aspect ratio by the devs.

Here is how I do it for the SNES but I think it can work for any SD analog console.

Assumption: The aspect ratio for a standard NTSC signal is 4:3 for 480i/240p lines of video.

With that in mind we measure the video line timing of the SNES. I haven't an oscillocope with me but fortunately this page has the timings for me.
As you can see on this picture. A single horizontal line of video from a SNES is in total 63.508 µs and the active time is 47.678 µs (the part where the visible video is sent to the display).

Now we compare these timings with the NTSC standard. I've found this document (table 2) that states the NTSC video line timing is 63.5 µs for the total line time and 52.6 µs for the active time.
The interisting thing is that the blanking time occurs at the same rate while the active time for the SNES is reduced. My understanding is that the TV will display the signal like an NTSC video in 4:3 but as the active video is not the same the aspect ratio will be different than 4:3.

Here is the situation: We want to find the aspect ratio of the red area while the CRT thinks he is displaying the blue area.



We can use basic proportionality: 4/3*(47.678µs/52.6µs) = 1.2086...
This would give us a correct aspect ratio if the SNES was diplaying 240 lines of active video but there is only 224 of them.



And now: 224/240 = 0.9333...
This gives an aspect ratio of 1.2086.../0.93333... = 1.294894079 which is different by almost 3% over the standard 1.333 / 4:3 aspect ratio used.

Here is some comparison shots :

Spoiler

So what do you think about all this ?

[Fudoh]

this has been my method since I started to wonder about it.

The core point here is that the actual horizontal resolution doesn't really play into it. Active scanline timing for Genesis 256px and 320px modes is almost identical.

The often refered to method explained on the Nesdev wiki* is much more complicated and I honestly can't follow it through, because I don't understand how the pixel aspect ratio suddenly plays into it, when you can completely ignore it for followig the above method.

* https://wiki.nesdev.com/w/index.php/Overscan

[maxtherabbit]

Don't forget to take overscan into account. Most consumer CRTs have more vertical than horizontal

[Fudoh]

but does it affect the math? If a certain percentage of the 4:3 image is cut off, the same percentage would play into any other source.

[Dochartaigh]

I have an easier method: I put it on my 4:3 CRT TV and when the image is edge-to-edge (with just a touch of overscan) it's the proper 4:3 ratio the developers developed each game for (because they were developed to be played on 4:3 CRT TV's

[fernan1234]

I have an easier method: I put it on my 4:3 CRT TV and when the image is edge-to-edge (with just a touch of overscan) it's the proper 4:3 ratio the developers developed each game for (because they were developed to be played on 4:3 CRT TV's

You can do this with a 16:9 display too (CRT or otherwise). Just get a full 4:3 image up there, take note of where it begins and ends horizontally, and then stretch your analog stuff to match it. The problem is that not everything has the same active lines.

[Sirotaca]

This is a great resource for this sort of thing: https://pineight.com/mw/index.php?title=Dot_clock_rates

It lists pixel aspect ratios for all sorts of hardware, and from there it's trivial to figure out what the correct width of the active area should be.

[Dochartaigh]

You can do this with a 16:9 display too (CRT or otherwise). Just get a full 4:3 image up there, take note of where it begins and ends horizontally, and then stretch your analog stuff to match it. The problem is that not everything has the same active lines.

I actually have little strips of marked painters tape on the bezel of my 4K TV to help with this. Have ones for 4:3 image, and 2x480p for 4:3 and 16:9 image - helps a lot when fine-tuning to get it quasi-right.

[FBX]

I don't mean to sound like an ass, but "my method" doesn't mean it's the correct method. Nesdev provides all the clock timing details you need to understand the 256 * 8/7 formula. This is the same for the SNES, NES, 256 mode on the Genesis, SMS, and originally started with the Colecovision. The Chrono Trigger image I posted isn't the only example that shows the accuracy of said formula. Give it a 'try' on the triforce shown in the intro to A Link to the Past.

[Fudoh]

Nesdev provides all the clock timing details you need to understand the 256 * 8/7 formula. This is the same for the SNES, NES, 256 mode on the Genesis, SMS, and originally started with the Colecovision.

based on this, how do you argue for different width settings for the GEN's 256px mode versus its 320px mode, when the active vs. full line timing ratio is identical for both output resolutions? I'm not try to argue against any opinion or method, just trying to fully understand both.

[maxtherabbit]

but does it affect the math? If a certain percentage of the 4:3 image is cut off, the same percentage would play into any other source.

right but the percentages of vertical cropping and horizontal cropping are different, so it would mean that the display is "stretching" the image slightly more in the vertical plane

[orange808]

but does it affect the math? If a certain percentage of the 4:3 image is cut off, the same percentage would play into any other source.

right but the percentages of vertical cropping and horizontal cropping are different, so it would mean that the display is "stretching" the image slightly more in the vertical plane

Doesn't that imply slight differences between individual displays? This is quite a rabbit hole.

[Taiyaki]

Interesting thread but ultimately all retro consoles were intended to run in 4:3 format as this was the standard on home tv's and arcade monitors (aside from the odd ball games that used multi screens). With crt's horizontal pixels are not displayed the way modern monitors do, so they drew the pixels in different resolutions but this was done knowing the final result would fit the full screen.

[Fudoh]

right but the percentages of vertical cropping and horizontal cropping are different, so it would mean that the display is "stretching" the image slightly more in the vertical plane

have you ever run a test DVD like Avia on your average 90s consumer CRT? To assume a true visible 4:3 aspect ratio for on screen content was nothing but a gamble.

[holaplaneta]

Hi there, sorry for reviving this thread, but I am in the process of upscaling some captured video from a retro pc that I got using a vision datapath card.

I recorded DOS games at 640x400 at 70Hz (for what I understand is double scanned VGA of 320x200) and I was wondering how I can calculate the aspect ratio correction for upscaling them as pixel perfect as possible (if there's such a thing). I want to try this generalized formula from Ste from HD Retrovision, which can be used with various video signal measurements to calculate the proper correction ratio for any type of input:



I have been trying to find the values of active line duration (referred as screen active line time in the formula), picture active line time and picture active number of samples for each of the following resolutions:

640x400 @70 Hz
320x200 @70 Hz (result would be the same as 640x400?)
640x350 @70 Hz
720x400 @70 Hz
640x480 @60 Hz

I found these pages which I believe have the values I am looking for, but I am really clueless about the naming conventions. I have done some research but I am not sure if these sites have what is needed to get all the values for the posted formula, mostly because I have to confess that I am not sure what values to look for: Is the value called "picture active line time" in the formula the same as "horizontal sync"?, is the other one called "whole frame" too? As you can see, maybe the formula's wording varies from the ones in these Internet pages:

http://martin.hinner.info/vga/timing.html
http://tinyvga.com/vga-timing

Any guidance will be much appreciated.

Thank you and stay safe.

[Fudoh]

IMO this doesn't apply to PC output resolutions, since - contrary to TVs - you pretty much always had all your geometry settings right in front of you. The picture on pretty much any PC CRT was always set to 4:3. While on TVs overscan was a thing, underscanning was an important part of of the picture on PCs to guarantee readability of text along the edges.

[holaplaneta]

Thank you for the fast response Fudoh, you are always there for the community.

If you were in my position, how would you approach the aspect ratio correction of an old PC's 640x400 70hz source to make it 4:3 ? With just a normal aspect ratio calculator that counts the resolution for width and the height like this one?

https://calculateaspectratio.com/

So 640x400 in 4:3 would be 533.33x400 ?

[Fudoh]

What's your end scenario? Are you capturing to take screenshots or to put them in a video?

If you want aspect ratio corrected screenshots you should stay integer on one axis. For videos it doesn't really matter.

Do a 3x or 4x integer scale on both axis (e.g. 640x400 to 1920*1200) and then do a bilinear scale to your desired resolution (e.g. 1440x1080 if you want to put it into a Full HD video). The important point is to upscale integer to a resolution higher than your target first and then downscale bilinear. Aspect ratio correction is included in the 2nd step.

[holaplaneta]

Thank you for your reply! Man, those screen captures looks amazing! Were they done from original hardware (old PC)?!

So for example, in VirtualDub, the first 3x interger upscaling to 1920*1200 should be using "Nearest neighbor", "Precise bilinear" or "Bilinear (interpolation only)"?

I understand that the following downscaling to 1440*1080 should be done using: "Bilinear (interpolation only)" or "Precise bilinear" ? Which bilinear option is the one you would recommend?



Also, not sure if I can ask this question in this thread, but what would you recommend to convert the 70fps from the 70Hz in the captured videos to 60fps (or less) without losing audio sync or shifting the audio pitch? I am capturing audio separately from a Roland MT-32 and I am afraid that converting the frame rate might alter the pitch of the audio. Do you recommend that for YouTube videos I should do a frame rate conversion in Virtual Dub to "Process every other frame (decimate by 2)" so they end being 35fps? Would YouTube play them correctly with that "odd" frame rate or would it redecode them at 30fps or 23.29fps? (I will do tests about this)

Thank you again, have a great weekend and stay safe Fudoh.

[Fudoh]

upscaling is done using nearest neighbour. Make sure the relative target size is 300% or 400%. Downscaling is best done using "precise bilinear".

For framerate conversion: as long as you don't touch the source frame rate adjustment, nothing will be out of sync or changed in pitch. You can usually use "decimate by 2" first, as long as the game doesn't have actually more than 35 fps (I couldn't think of anything). I would then add an "interpolate" filter with a target framerate of 59.94 or 60Hz. Here you can try if nearest frame or linear blending looks better. Blending will add interpolated frames that can look weird when paused, but in motion this looks pretty good. With nearest frames duplicates are inserted, but since 35 to 60Hz is a non-integer factor, it won't look good on smoothly scrolling titles. Here you might be better off with the blending option. 35 to 60Hz by inserting just duplicates will introduce an NTSC 3:2 like stutter.

You can upload 35 or 70Hz to YT directly, but people are using 60Hz displays, so they'll hardly ever see the content as captured.

[holaplaneta]

Wow, excellent answers and tips.

For framerate conversion: as long as you don't touch the source frame rate adjustment, nothing will be out of sync or changed in pitch.

Does this mean in theory (since these old DOS games like Monkey Island are like around 15fps I suppose), that could I just capture the source video from my old PC directly at 35fps and not have any missing frames or audio bits?
And then afterwards interpolate that captured video to 59.94 or 60Hz with the filter mode methods you mentioned?

This information is a masterclass. I really appreciate it.

Thank you sir.

[Fudoh]

that could I just capture the source video from my old PC directly at 35fps and not have any missing frames or audio bits?

the fps you're using for your capture don't impact audio. Half-framerate capture is usually alright. Do a few test recordings though before deciding for good.

[holaplaneta]

Thank you Fudoh.

I have done some tests that you can see here:

https://imgur.com/a/hjyNscb

The results are that capturing directly to 70fps and then interpolating to 60fps directly from the source (as a video filter in VirtualDub) using nearest neighbor gave the best results, even when the screen scrolls horizontally. At least for this particular game that has a low framerate.

Decimating the frame rate by 2 or capturing directly at half frame rate did not yield good results. Also using linear blending for interpolation did look better in motion in a way but did not fix the screen tearing in some frames. However even when the source video at 70fps had some tearing, (I suspect this is because the video signal is not exactly at 70Hz but sometimes 70.08 or so) using nearest frame for the interpolation fixed this. Again, I believe that these results only apply to a game with low framerate like Monkey Island which has some choppy scrolling anyway.

Thank you for all your help. Have a great evening.

[6t8k]

this has been my method since I started to wonder about it.

The core point here is that the actual horizontal resolution doesn't really play into it. Active scanline timing for Genesis 256px and 320px modes is almost identical.

The often refered to method explained on the Nesdev wiki* is much more complicated and I honestly can't follow it through, because I don't understand how the pixel aspect ratio suddenly plays into it, when you can completely ignore it for followig the above method.

* https://wiki.nesdev.com/w/index.php/Overscan

I believe you were quite close to the answer. I'll touch upon a few aspects you're probably familiar with, but just to get the whole picture for everyone (and/or the possibility that I'm corrected/complemented and learn something as a result), allow me to go back a bit.
In analog video, there is no horizontal resolution(*), because there are no pixels, which is why active/total line extent is stated in terms of a time duration (in digital video, you have additional means of expressing that). Because there are no pixels, there is, consequently, no pixel aspect ratio. The only thing video signal norms for conventional analog television systems expected in that regard was that the signal be projected onto a rectangular visible area that had a 4:3 aspect ratio resulting from the physical length of two adjacent sides. Of course, the visible area was usually not what you'd call rectangular, but this is what was idealized. In case a given analog signal was deemed as not properly fitting onto said area, people were expected to "turn the knobs" on their TV, if available, until the image neatly filled out the visible area (colloquially, the "screen"). There was no standard that defined the exact structure of a TV screen (which varied across different CRT TV products), or how exactly the video signal should be projected onto it -- in other words, which exact portion of the video signal the 4:3 spec applied to.

The methodology presented here is only applicable when the video signal takes a wholly digital path, from generation to display (e.g. emulation, FPGAs in combination with a contemporary LCD display), and to then recreate an aspect ratio the originally analog signal would plausibly have when displayed on a (conventional) analog TV screen. When an analog signal is displayed on an analog screen instead, and you think the proportions are off, you "turn the knobs". When an analog signal is sampled for digital display instead, the display aspect ratio additionally depends on the way it's sampled, and things get more complicated. If OP's comparison shots originated from emulation, with a square-pixeled rendering being the baseline, the methodology is a fine approximation to how it would be displayed on a CRT. It'd be a mistake, however, to take OP's comparison shots as a paradigm showing how proportions would look on each and every CRT exactly – there is no such thing, you'd be chasing a phantom.

The Nesdev wiki article, then, talks about pixel aspect ratio because it adopts a digital video perspective, where the NES' analog signal output is sampled. Being in the digital video realm, we now have pixels as well as a horizontal resolution, and pixel aspect ratio then comes into play because the display aspect ratio – the aspect ratio of the image as displayed – is defined by storage aspect ratio × pixel aspect ratio. Pixel aspect ratio itself depends on the interplay between the pixel rate (if the analog source signal is generated by a digital circuit like in this case, as opposed to say, an analog video camera) and the parameters that are used for sampling the signal for digital use. If you want to hone in on an aspect ratio that could plausibly manifest if a CRT was fed with the same underlying analog signal, you have to choose those parameters carefully. For example, if you straightaway sample a 525 total lines/NTSC signal according to the Rec. 601 standard, you get non-square pixels with an aspect ratio of 10:11.

I'm not sure right now if this perspective inevitably applies to emulation, I guess depending on how you as a developer emulate the PPU and render video output, it could, but doesn't have to. I'm quite sure it shouldn't matter for the user. When using emulation or an FPGA in combination with a contemporary digital display, I'd always refer to OP's method. Deriving an aspect ratio correct factor by taking on a sampling viewpoint in this case is not "wrong", just like OP's method is not "right", but it only muddles things. The article addresses a different purpose.

Just a side-note, the article mentions CRTs, so one should be mindful not to mix analog and digital video concepts in one's understanding here, but the specific reasonings behind its mentions of CRTs in some contexts seem coherent to me.


(*) There is an effective maximum subjective, optical horizontal resolution of CRT screens, which is called TV lines, but that has to do with the respective CRT's build and the transmission medium, not the analog video signal itself (not to be confused with scanlines, the analogy for the vertical dimension is called the Kell factor; effective vertical resolution = number of active lines per frame × Kell factor).

[Unseen]

There was no standard that defined the exact structure of a TV screen (which varied across different CRT TV products), or how exactly the video signal should be projected onto it -- in other words, which exact portion of the video signal the 4:3 spec applied to.

What about the various test cards that almost universally have some round features that are supposed to display as a circle?

[6t8k]

These do not naturally display in the same proportions across different CRTs, the manufacturer or user was supposed to use them for calibration (so they do, ideally). They don't provide a fixed signal -> screen mapping. You can take an analog signal and say: data begins here, and it ends there, so this should in the end be displayed as 4:3, but the issue remains, as you, well, still have to display it somehow, in 4:3, ideally. :P There is no clear left and right edge of the active area, as sources can more or less, within some tolerance, begin and end a line whenever they please. To my knowledge a well-defined H/V beam travel distance ratio also never made it into the pertinent analog video specs.