MAMEWorld Forums - News - DU: Laserdisc updates and more

Aaron! Nice to cross paths again. Has it really been 10 years?

You might remember I dismissed this approach as hopelessly impractical, but I guess it was just impractical for me, as it clearly does work.

> My guess is that it was intended as a demonstration of the ability to decode the full
> NTSC signal from raw signal data, including both audio and video with proper color.
> From that perspective, I was hugely impressed. It looked great and sounded clean (for
> non-deinterlaced NTSC).
>

That's what I got from it as well. I've experimented with the ld-decode software stack using an earlier hardware solution (a particular WinTV card with a raw 28 MHz 8-bit ADC mode), and this sample looks as good or better than what I was able to produce. I wouldn't say it beats a traditional video capture on all counts, but I think this is mostly due to software, particularly the comb filtering.

Perhaps the course events could look like this:

1) Get some raw captures with Simon's new hardware. I think it's close to ideal for the task; any improvements beyond this would be marginal. A few fanatics will archive these raw captures. Ideally there would be captures from 2 or 3 different source discs per title.

2) Convert to (digitally) lossless video files with the best quality possible from the current ld-decode software. Note that this requires "editorial" judgement for settings such as sharpness, noise reduction, dropout detection, etc., to get the best results. As such, there may be some disagreement about what "best quality" really means.

3) If these video files are significantly higher quality and/or more accurate than comparable traditional captures, it pretty much proves that the captures are viable as 'archival' quality. We can finally stop obsessing over the digitization step at this point.

4) Convert these video files to the current CHD format. IIRC, it uses Aaron-built 4:2:2 YUV lossless compression for video, linear PCM for audio, and decoded binary data for the line 17/18 VBI information. It might be worth considering RGB video, >720 horizontal pixels, or bitmap VBI, but I don't think these are particularly necessary.

5a) If, in the future, the software decode process is significantly improved, make new versions of the CHDs.

5b) If, in the future, MAME supports RF decode directly, replace the CHDs with raw captures in whatever format is required, along with metadata to tune the decode/DSP signal chain. (This combines 'preservation' and 'presentation' in one package.)

This allows things to move forward, regardless of when step 5b happens, if it happens at all, and allows people to see and make use of what's been done. I'd prefer to have raw intead of "baked" versions out in the wild at earlier stages, but it doesn't seem practical.

I'm out on the periphery here, so of course you're free to ignore all of this. Just trying to do what I can...