Quality test - Mighty Bomb Jack (NES)

2024-11-06 11:50:20 pm

I have the same recording setup since a long time. My NES is connected to a HDD-recorder through composite. I'm still using anri-chan to encode since yua crashes for me when loading raw-files from my recording device.

I've always used d4f12d to encode as it's my understanding that all NES games should use that. However, for fun I just tried d1f12d and was surprised to see that the video quality was greatly improved. There is a big issue though. When I use d1, I don't get any option to fix bobbing, which is something that I need in the process. See the attachments.

So my question is, is there a way to get the better video quality from using d1, but at the same time fix the bobbing issue?

Thread title:

Attachments:

d1f12d_test_HQ.mp4

d4f12d_test_HQ.mp4

nate

2024-11-07 09:22:25 am

simple question, somewhat complicated answer. it will depend on what you mean by "quality". i'm going to assume you mean resolution, especially chroma resolution, which translates to something like "sharpness", especially when viewing the video fullscreen. anri (and yua) downsample chroma for LQ-HQ output, so you lose chroma resolution when encoding at d4 compared with encoding at d1. they have to do this because of compatibility. in general full chroma resolution is not supported by much playback software/hardware. yua does not downsample chroma for IQ and XQ. i can't recall whether anri does. i think there is a chance that it also does not. so you might try encoding as d4/f1/2d IQ and XQ (even though it tells you they aren't necessary) and view that output fullscreen and see if it looks better to you.

unfortunately the bobbing you see after encoding as d1 comes from the nes being d4 resolution (240 lines, sometimes called 240p, the p being progressive, as in progressive scan). anri uses a sophisticated algorithm via an avisynth plugin to reconstruct the missing 240 lines to make 480p, but because there were no missing lines in the first place, the result is chaos. the algorithm is only meant for 480i (d1 resolution) input. (these numbers all assume ntsc.) actually, if you play a nes game on a crt tv and look closely, you will see something similar to this bobbing, because ntsc crt tvs were made to display 480i, not 240p. i think a lot of us were kids and just kind of assumed it was supposed to look like that. but we aren't used to seeing this bobbing on computer screens, so it looks really bad.

anyway, the standard answer for this problem around here is to encode as d4f12d and then submit IQ/XQ, which look better fullscreen (especially if your video player has a good upscaling algorithm). but again, i can't remember if anri supports full chroma resolution in IQ/XQ. if it doesn't, to stop yua from crashing, you might open a non-interlaced file in it (such as a random .avi or .mp4 downloaded from the internet), then hit the d4 radio button to change yua into d4 mode, then open your input file. if i'm right then yua will stay in d4 mode, which might bypass the crash, which i suspect is due to yua running the interlaced d1 codepath.

simple question, somewhat complicated answer. it will depend on what you mean by "quality". i'm going to assume you mean resolution, especially chroma resolution, which translates to something like "sharpness", especially when viewing the video fullscreen. anri (and yua) downsample chroma for LQ-HQ output, so you lose chroma resolution when encoding at d4 compared with encoding at d1. they have to do this because of compatibility. in general full chroma resolution is not supported by much playback software/hardware. yua does not downsample chroma for IQ and XQ. i can't recall whether anri does. i think there is a chance that it also does not. so you might try encoding as d4/f1/2d IQ and XQ (even though it tells you they aren't necessary) and view that output fullscreen and see if it looks better to you.

unfortunately the bobbing you see after encoding as d1 comes from the nes being d4 resolution (240 lines, sometimes called 240p, the p being progressive, as in progressive scan). anri uses a sophisticated algorithm via an avisynth plugin to reconstruct the missing 240 lines to make 480p, but because there were no missing lines in the first place, the result is chaos. the algorithm is only meant for 480i (d1 resolution) input. (these numbers all assume ntsc.) actually, if you play a nes game on a crt tv and look closely, you will see something similar to this bobbing, because ntsc crt tvs were made to display 480i, not 240p. i think a lot of us were kids and just kind of assumed it was supposed to look like that. but we aren't used to seeing this bobbing on computer screens, so it looks really bad.

anyway, the standard answer for this problem around here is to encode as d4f12d and then submit IQ/XQ, which look better fullscreen (especially if your video player has a good upscaling algorithm). but again, i can't remember if anri supports full chroma resolution in IQ/XQ. if it doesn't, to stop yua from crashing, you might open a non-interlaced file in it (such as a random .avi or .mp4 downloaded from the internet), then hit the d4 radio button to change yua into d4 mode, then open your input file. if i'm right then yua will stay in d4 mode, which might bypass the crash, which i suspect is due to yua running the interlaced d1 codepath.

ktwo

2024-11-07 11:50:39 am

Thanks. I think I can follow most of what you wrote.

I tried the trick you suggested in yua, but it didn't work. Maybe yua can't handle vob-files (at least not the ones my HDD recorder produces). However, it worked when I ripped the raw-file with anri and then fed it to yua. For unknown reasons, yua didn't produce an XQ encode, but I did at least get an IQ. It's possible that it looked marginally better than the HQ version, but it was still far from the d1 encode.

Given how much better the d1 encode looks in my eyes in terms of visual quality, it's a pity that it doesn't seem to be possible to get a fully usable encode with that setting. But if there is no fix for it, I'll just continue with d4.

nate

2024-11-07 08:07:08 pm

that's too bad the workaround didn't work. yua definitely handles vobs. i worked hard on it. i would have you send me the problem input file but i no longer have the ability to compile and distribute yua like i did back in the day, so even if i were to fix the problem, it wouldn't help us much. and even if i were to regain the ability to compile yua, there's the problem of the ffmpeg api probably having changed so much, i would have to rewrite half the ffmpeg-related code. i could compile and link against an old version of ffmpeg, but there wouldn't be much point in making a modern release of yua that couldn't read modern formats.

anyway, how are you viewing the output? what software? do you know what upscaling algorithm it's using? i know some open source players like vlc let you change the algorithm it applies for resizing. some common algorithms are bicubic, bilinear, and lanczos (which i prefer). i'm sure there are more recent ones too, probably even some based on machine learning models trained specifically to make old school game graphics look good when upscaled. you might try playing with different algorithms to see if you can get the d4 output to look like you want (or even better). and then you could apply that algorithm by opening your run in e.g. avisynth or avidemux or even just raw virtualdub and filtering it with the upscaler you want (the option is usually called "resize" or "rescale" or something like that) and saving a new master. i don't think we want to allow upscaled input for submission to sda though because it would mean taking away viewers' ability to choose the upscaler.

btw, yua probably did produce XQ but renamed it to IQ because the bitrate was low enough to count as IQ (and then XQ was unnecessary). anri has the same behavior. happens a lot with old school stuff because it's so low resolution and the graphics are so simple with not a lot of movement, even after getting scrambled by analog video.

that's too bad the workaround didn't work. yua definitely handles vobs. i worked hard on it. i would have you send me the problem input file but i no longer have the ability to compile and distribute yua like i did back in the day, so even if i were to fix the problem, it wouldn't help us much. and even if i were to regain the ability to compile yua, there's the problem of the ffmpeg api probably having changed so much, i would have to rewrite half the ffmpeg-related code. i could compile and link against an old version of ffmpeg, but there wouldn't be much point in making a modern release of yua that couldn't read modern formats.

anyway, how are you viewing the output? what software? do you know what upscaling algorithm it's using? i know some open source players like vlc let you change the algorithm it applies for resizing. some common algorithms are bicubic, bilinear, and lanczos (which i prefer). i'm sure there are more recent ones too, probably even some based on machine learning models trained specifically to make old school game graphics look good when upscaled. you might try playing with different algorithms to see if you can get the d4 output to look like you want (or even better). and then you could apply that algorithm by opening your run in e.g. avisynth or avidemux or even just raw virtualdub and filtering it with the upscaler you want (the option is usually called "resize" or "rescale" or something like that) and saving a new master. i don't think we want to allow upscaled input for submission to sda though because it would mean taking away viewers' ability to choose the upscaler.

btw, yua probably did produce XQ but renamed it to IQ because the bitrate was low enough to count as IQ (and then XQ was unnecessary). anri has the same behavior. happens a lot with old school stuff because it's so low resolution and the graphics are so simple with not a lot of movement, even after getting scrambled by analog video.

ktwo

2024-11-09 12:54:35 am

I was just viewing with wmp (and a few other basic players) with the default settings. I'm not sure how to change the algorithm in VLC, so that was also with the default settings and the result was about the same as with the other players.

I appreciate the suggestions on how to possibly improve the video quality, but I feel like it's getting into too much of uncharted territory for what I'm prepared to do. The d4 videos are still watchable, so I'll go ahead and submit those. Thanks for all the feedback.