Post subject: Sega Master System aspect correction
Joined: 10/14/2013
Posts: 335
Location: Australia
About a year ago, Sega Master System dumping changed to include overscan. This allows much more accurate aspect ratio correction at the cost of black borders around the entire game. I messed around and made a commented AVISynth script that takes the aspect ratio of the clip with overscan enabled, crops the clip to what it would be were the option not enabled, and then applies the aspect ratio to the resulting clip. This results in a clean clip with the same aspect ratio correction as if the clip did not have the overscan removed. It's worth noting that this means the resulting clip is not 4:3, but is instead displayed with an accurate aspect ratio, although without the overscan being visible. You can download test file and script here, the file's about 4mb. Alternatively, here's the script by itself:
# Load Source
AVISource("sms_overscan.avi")

# New boolean value for SMS Current encoding package code (variables required for aspect correction)
SMS = true
hd = false
handheld = false

# Odd number scanline fix
last.height % 2 > 0 ? StackVertical(last, Crop(0, Height-1, 0, 0)) : 0

# Save clip dimensions for later
overscan_width = float(Last.Width)
overscan_height = float(Last.Height)

# Crop overscan
SMS ? Crop(13,27,-15,-25) : Last

# Changes to the waspect / haspect code
waspect = SMS ? Int(4 * overscan_height / last.height * 10000) : 4
haspect = SMS ? Int(3 * overscan_width / last.width * 10000) : 3

# Current encoding package code for aspect correction
height = hd ? 2160 : last.width > (last.height * waspect / haspect) ? (last.width * haspect / waspect) : last.height
width = handheld ? height * last.width / last.height : height * waspect / haspect
width = (width % 4 == 1) ? width + 3 : (width  % 4 == 2) ? width + 2 : (width  % 4 == 3) ? width  + 1 : width
height = (height % 4 == 1) ? height + 3 : (height % 4 == 2) ? height + 2 : (height % 4 == 3) ? height + 1 : height

# Current encoding package code, slightly changed for testing output
hd ? PointResize(width, height) : handheld ? last : LanczosResize(width, height, taps=2)
I'm not experienced enough with the console to know if cropping is consistent between games (although it can easily be checked and altered) or if the encodes would be preferred with the overscan included, as I'm not sure which is correct in terms of console accuracy, but if aspect ratio is the only contributing factor to enabling the overscan setting, then this might help deal with that. Edit: Originally, there was an extra line (line 18) left in the script's download and in the code pasted here. It was commented out, but still present. I used it for testing and it should not be used in the final script as it extended the cropping beyond what was needed to crop the overscan. It has since been removed from both locations.
I'm not as active as I once was, but I can be reached here if I should be needed.
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11492
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
feos wrote:
The console outputs huge overscan that is mostly visible on tv, and after stretching, the original game screen ends up being stretched horisontally up to something around 16:10.5.
Are the numbers you end up using for ARC equal to these? Otherwise, I'm unsure about either option, but the overscan area sometimes has a certain color instead of black, so it at least has some value in my eyes. Now, with aspect ratio becoming editable from the batch call, you can just dump without overscan and then give the clip the right AR. Probably we could allow both ways. Need to know the filesize diff I think, ideally for a scene with black overscan area and for one with non-black.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 10/14/2013
Posts: 335
Location: Australia
feos wrote:
Are the numbers you end up using for ARC equal to these?
The numbers that end up being used for the correction are as follows: 4 * 284 / 256 * 10000 = 44375 3 * 244 / 192 * 10000 - 38125 Simplified, that would be 71 and 61. That, applied to the cropped width and height yields an AR of 18176:11712 (or simplified, 284:183). 284/183 = 1.56043956044 16/10.5 = 1.52380952381 So back to the original question, I'd say yes. This was also compared for accuracy to the clip with overscan being resized to 4:3 and then cropped down. It looks like 284/183 is the "something around 16:10.5" that you were thinking of.
I'm not as active as I once was, but I can be reached here if I should be needed.
fsvgm777
She/Her
Senior Publisher, Player (226)
Joined: 5/28/2009
Posts: 1215
Location: Luxembourg
On a CRT television, most of the left and right overscan area won't display, if at all, as in this example picture. However, on an LCD television, you are going to see the entire overscan area (or at least a lot more), as seen in this picture. Similarly, capture cards will also capture the entire overscan area (or at least a lot more) (see basically every single Master System speedrun on SDA). BTW, we don't crop away the overscan area for PS1 either for proper aspect correction (but then again, PS1 changes resolutions a lot more than SMS does AND would also be game dependent). I'm more in favour of keeping the overscan area intact, even if the border is black. For more information, read marzojr's post. By the way, BizHawk dumps PAL SMS with overscan at 284x288.
Steam Community page - Bluesky profile Oh, I'm just a concerned observer.
Joined: 10/14/2013
Posts: 335
Location: Australia
That makes sense. My initial problem was that I wasn't sure if it enabling the overscan was an emulator-specific option, for instance if it was something artificial generated to help with the aspect ratio correction but not present on the actual console. Given all the information provided here, I'd also vote to keep the overscan in the encodes.
I'm not as active as I once was, but I can be reached here if I should be needed.
SonicFan53
He/Him
Joined: 2/6/2020
Posts: 93
Would this work for, say... the 8-Bit version of Sonic the Hedgehog? I'd test myself but idk how to use these encodes....
*playing Sonic Chaos*