SpritesMind.Net

I've got this on the backburner for a few days while I work on other projects. I'll come back and have a fresh look at it again soon. The dumping program is very close to working now, so I don't think it'll take much longer.

Thanks for the heads up, Nemesis. The progress is exciting!!

At some point, since we have multiple people interested, I guess we should coordinate who owns what?

Misty wrote:Thanks for the heads up, Nemesis. The progress is exciting!!

At some point, since we have multiple people interested, I guess we should coordinate who owns what?

My list:

Pyramid Patrol
3D Museum
Rocket Coaster

I will update with any other games I get.

On another note, thought you guys would find this place interesting:

http://laseractive.wordpress.com/

Gah, I just had a huge post written and hit back by mistake, wiping it all, so let me summarize.

I haven't attempted to capture the digital data from MegaLD disks again in the last little while, but I have done some more work on capturing the analog video stream. I've been looking into just how to get the most out of my capture card, the Canopus DVStorm, and I've discovered the card doesn't have a hardware MPEG2 encoder like I thought, but rather, all the encoding is done in software. If I perform the capture process through Adobe Premiere Pro using the DVStorm plugin, I can get a lossless capture of the raw interlaced video stream. Of course, "lossless" in this sense just means it hasn't lost any more quality after the analog to digital conversion process, but this card does have extremely good capture quality, with a dead stable picture and virtually no noise, so the results are very good.

Here are some test captures I've done:
http://nemesis.hacking-cult.org/MegaDri ... ssless.avi
http://nemesis.hacking-cult.org/MegaDri ... erlace.avi
The first video shows the capture quality of my card capturing the interlaced video stream, and outputting the video using the lossless huffyuv codec. The second video is an edited version of the first, demonstrating that the captured video data can be perfectly de-interlaced. I used VirtualDub's de-interlace filter to separate the even and odd fields out of each frame, and output them side by side.

Note the file size: Around 35MB for 59 frames (around 2 seconds) of video! Obviously this is impractical for direct use in an emulator, but I think I will release a lossless version of the video data for the LaserDisc cames, with a much smaller, lossy compressed version along side it, for direct use in emulators. I think the lossless version should exist, simply because I don't expect many of these LaserDisc games to ever be dumped more than once. I think the more quality we can hold onto, the better.

I also want to try something else to try and increase the quality of the captured video. I'm strongly considering capturing each video half a dozen times or so, and attempting a kind of sample analysis on the video stream, to try and filter out analog signal noise from the video, and construct a cleaner video stream than any single capture could achieve. Using a weighted sample averaging method across each of the video streams for each pixel, with some distribution tests to discard any wild samples to prevent them skewing the results, I think we should be able to get a much cleaner result. With the low noise, high quality, and dead stable output I get from this card, I think it should be possible. I'll do some more tests on this in the future.

Nice capture, but Sonic is only interlaced in two player mode. The rest of the game is progressive 50 Hz (for PAL) video. Each field is actually the full frame.

Actually, that's a different kind of interlacing I believe. My understanding is that the PAL and NTSC video signals are both interlaced, with an odd and even field making up each frame. PAL video is only 25 frames per second, but it's 50 fields per second, with each field effectively having half the number of lines (or vertical resolution). My understanding is, this means the Mega Drive is dropping half the vertical resolution for each frame of data it generates (I think this data is dropped by the RGB encoder? Or is it not output from the VDP itself?).

The VDP interlacing modes are slightly different. They cause the VDP to offset each rendered frame (which means each rendered field, since half of it is being discarded), by half a line. While the interlacing in the NTSC and PAL video signals interlace the fields by one full line, the interlacing modes on the Mega Drive offset the fields by half a line, meaning the two lines in each field "overlap" slightly. I would think this would also introduce a "scanline" effect, since there is a larger gap between successive lines on the screen in one direction than the other. When you're doing interlacing on the Mega Drive, it's effectively an extra level of interlacing, so you're interlacing an interlaced video signal.

The visual effect of all this is a little hard to visualize, since a CRT screen doesn't have "pixels", it just has a surface which is illuminated from a target point being focused on by the electron beam at a given point in time, and radiating out from that point, and lines are analog, not digital, so everything overlaps and blurrs into each other. It's for this reason I've never seen an emulator quite come close to the way the video really looks on a TV, especially when the VDP interlace modes are active. The real TV shows a lot of "jitter" effect with the VDP interlace modes due to the overlapping lines, while emulators just double the vertical resolution and give a stable image.


Anyone feel free to correct me on this, analog video signals aren't exactly my area of expertise, and I'm not clear on all the details of how the PAL and NTSC video signals are encoded. The captures I've taken do show that there's a VINT generated between each "field" of the video, since the bubble shield changes its visual state on VINT. If the VDP is outputting a video signal at 50Hz with the full vertical resolution, that's something I need to know about, because I'm only capturing half that data. My current understanding of PAL and NTSC however, is that what I've captured is correct.

Nemesis wrote:My understanding is, this means the Mega Drive is dropping half the vertical resolution for each frame of data it generates (I think this data is dropped by the RGB encoder? Or is it not output from the VDP itself?).

When the VDP is in single density interlace mode it is displaying the same data as normal mode, but with every other frame offset by a half scanline which leads to the interlacing effect.

In double density interlace mode it does the same thing, but only looks at even lines of tiles (etc.) on one frame and odd lines at the other.

So it isn't actually looking at the entire (say) 320x480 frame and only pulling out 320x240 regardless of the display mode. Likewise, in single density interlace mode it isn't scanning the same frame twice for each line.

The amount of video bandwidth in terms of what data is read from RAM remains constant across all three display settings.

For example in single density interlace mode you can load up two images, one with even lines and one with odd lines. If you alternate between which one you are showing every V-Blank, it looks exactly like an interlaced image would look like in double density interlace mode.

The only difference is that in the latter mode you get some 'hardware assist' and don't have to manually fiddle with things on a frame by frame basis, because the VDP knows to only parse data for even lines on even frames and odd lines on odd frames.

So in a nutshell the RGB encoder isn't dropping anything and the VDP isn't internally handling a larger sized display and only sending out half of the results. In a way that's too bad as it would be nice to get a 320x480 progressive display, but the VDP would have to be clocked twice as fast and have a lot of design tweaks. ;D

Thanks Charles, I was still a bit confused until I read your post and saw where my error was. It's not the VDP interlace modes that were confusing me, it was the NTSC/PAL interlacing. I thought the VDP was outputting a full frame's worth of PAL video data 50 times a second, but I see now the VDP outputs 313 lines per frame in progressive scan, with a "compressed" line during vblank, resulting in effectively 312.5 lines per frame progressive. The PAL video signal on the other hand has 625 lines per frame interlaced, with 312.5 lines per field in the interlaced video signal, so a "frame" of progressive video data from the VDP is actually a "field" of video data for the interlaced PAL signal.

I am still a little unsure of the exact effect of the PAL/NTSC interlacing interacting with the VDP interlacing though. The VDP interlace modes offset odd/even frames by half a scanline, so one frame draws "between the lines" of the other one. When the VDP output is being encoded to a PAL/NTSC video signal however, these VDP "frames" are actually being used as fields, to generate an interlaced video signal, so what effect does the VDP offsetting its output by half a scanline between odd/even frames have on the way the interlaced PAL/NTSC video signal is generated? It's literally trying to interlace an interlaced video. What effect would this have on the way the TV which is actually displaying this signal draws the fields, IE, would the odd and even "frames" (fields) be drawn simply interlaced between each other, with a consistent spacing between the lines, as they would have been without VDP interlacing active anyway, or are they "doubled up", with the second field partially offset either up or down on the screen, causing there to be an uneven "gap" above and below the field scanlines, or possibly, one field being drawn directly on top of the other, rather than interlaced between it?

I've got both a TeraDrive and an Amstrad MegaPC, so I might do some comparisons on the visual effect the interlace modes have when running through a TV as an interlaced PAL/NTSC video signal, as opposed to when they're directly output as a progressive signal to a VGA monitor.

The way NTSC and PAL works normally (interlaced) is that it displays half the lines vertically (262 for NTSC), then the vertical blank occurs half way through the last line, giving a total of 262.5 lines (NTSC). That half a line means the next display starts halfway between the previous lines, filling in the space between the lines with the other half of the display for another 262.5 lines. It's why it's called interlaced - half the lines appear between the other half. Each half is called a field and occurs at 60 Hz (NTSC). Two halves make a whole frame at 30 Hz.

The way consoles work is they don't offset the vertical blank, and so generate only 262 lines. Then the next frame occurs, but not half a line off, so it draws right over top the old lines with all new pixels. So you only get half the lines with a blank line between each. Since each field occurs over top the old field, you have in effect separate frames, not fields, at the field rate, 60 Hz. This is progressive, not interlace.

So the MD normally generates 320x224 lines at 60 Hz. It's not interlaced. Old TVs have no problem with this. New TVs may have trouble if they think the signal is always interlaced - it will try to deinterlace a display that's actually two completely separate frames.

Your AVI of the 30 Hz "interlaced" video is actually 60 Hz progressive. It has all the display info, but thinks it's interlaced. You just need to alter the AVI info to say that's is not 720x576 30 Hz interlaced, but 720x288 60 Hz progressive with a display aspect ratio (DAR) to make that display correctly (4:3).

The MD is capable of real interlaced output, with two ways of handling the fields: it can generate the exact same display on both fields, keeping the cells as 8x8, or you can switch to "real" interlace mode which changes all cells to 8x16 and displays half on one field and the other half on the other field. In that mode, the MD shows 320x448 at 30 Hz interlace.

The way consoles work is they don't offset the vertical blank, and so generate only 262 lines. Then the next frame occurs, but not half a line off, so it draws right over top the old lines with all new pixels. So you only get half the lines with a blank line between each. Since each field occurs over top the old field, you have in effect separate frames, not fields, at the field rate, 60 Hz. This is progressive, not interlace.

Aha! This is the bit I didn't understand. So both "fields" are drawn directly over the top of each other normally, giving you 50fps progressive in PAL mode with 312.5 actual raster lines per frame (as opposed to 25fps interlaced at 625 raster lines per frame), and when the VDP is running in interlace mode, the fields now get offset by half a scanline, and that's when real interlacing is actually happening.

Thanks, I finally understand how the interlacing modes are displayed now.

Nemesis wrote:

The way consoles work is they don't offset the vertical blank, and so generate only 262 lines. Then the next frame occurs, but not half a line off, so it draws right over top the old lines with all new pixels. So you only get half the lines with a blank line between each. Since each field occurs over top the old field, you have in effect separate frames, not fields, at the field rate, 60 Hz. This is progressive, not interlace.

Aha! This is the bit I didn't understand. So both "fields" are drawn directly over the top of each other normally, giving you 50fps progressive in PAL mode with 312.5 actual raster lines per frame (as opposed to 25fps interlaced at 625 raster lines per frame), and when the VDP is running in interlace mode, the fields now get offset by half a scanline, and that's when real interlacing is actually happening.

Thanks, I finally understand how the interlacing modes are displayed now.

312 or 313, not 312.5. The half line is what signals interlace, so progressive modes are always an even number of lines. But other than that, I think you got it now.

You get 262 lines in 60Hz, 313 lines in 50Hz. Not sure if 60Hz interlace mode has 262.5 lines or 261.5 lines, 50Hz should have 312.5 but you may never know unless you measure and verify.

TmEE co.(TM) wrote:You get 262 lines in 60Hz, 313 lines in 50Hz. Not sure if 60Hz interlace mode has 262.5 lines or 261.5 lines, 50Hz should have 312.5 but you may never know unless you measure and verify.

Well, NTSC SHOULD be 525 lines per frame for spec, so it SHOULD be 262.5. You can change that slightly and most (old) TVs won't have any problem with it. It's new TVs that want signals to be exactly to spec... which causes issues with old consoles that don't go by spec.

I still maintain there is absolutely no need for lossless video here, at least not as an end result. This is baseband analog composite NTSC and inherently full of artifacts that were not intended to be there, but were only there as an inherent flaw of the technology used to store them. LD is limited in bandwidth, I think it can carry 4.2MHz (which is pretty close if not identical to legal broadcast NTSC quality at the point of transmission).

I would recommend either recording this lossless initially or at high-bitrate I-frame only MPEG-2 (something like 25Mbps should be sufficient and yet still way less than the 280Mbps or so that your lossless file represents). Do a bit of Avisynth processing (decomb, light spatial-only denoising, levels correction that is uniform across the entire video) and then re-encode it at the same I-frame only 25Mbps bitrate. This video will at least be equivalent quality to the original LD, if not slightly better. Moreover, being stored as I-frames only means it is possible to seek to any frame without decoding multiple frames (as is required with P- and B-frames). Also, one could choose to run the bitrate down on their own while still keeping the video I-frame only and save on space (but you won't get anywhere near the average 6-8Mbps DVD video bitrate with equivalent quality, as I-frames are much larger than P- and B-frames). There's a limit to how much quality you can get out of an analog NTSC signal, and lossless is way, way above that limit. If you're that worried, use 50Mbps I-frame MPEG-2 instead of 25Mbps and you'll pretty much be wasting bits to store the video, but still wasting less than full lossless.

Your multi-capture technique is sound, and would be a much better alternative to spatial denoising. It won't help with luma/chroma crosstalk because that is more or less inherently part of the signal (unless your capture card has a really good comb filter, this can be somewhat handled with software though).

Levels can be a big thing, though, because if the whites or blacks are crushed during capture or at any point during processing, they're lost forever without going back to a step in your workflow from before the loss of detail. Analog NTSC video is measured in IRE, with blanking at 0IRE, nominal black at 7.5IRE in the US only (this is called "setup" and NTSC-J has no setup), and broadcast-legal white at 100IRE. Signals can go above 100IRE depending on the equipment but I would be highly surprised if that would be an issue here. Also, depending on your capture card, it will either place 0/7.5IRE at RGB 0 and 100IRE at RGB 255 (incorrect way to do it, but there's a whole ton of incorrectness within the video industry, it amazes me that things even work at all sometimes) or it will place 0/7.5IRE at RGB 16 and 100IRE at RGB 235 (which is per the standards dealing with digital video, I think even in HDTV but not 100% sure there).