Capturing full 525 lines of NTSC frame

[Brad]

The ADC actually samples at 10-bit internally, anyway, so does that concern even apply?

[solarfox]

While I was looking up some information about another piece of the LaserActive system, I discovered (or re-discovered) something about the LD-ROM format that I had previously forgotten: The digital LD-ROM data is stored in the space that would normally be used for the PCM digital-audio tracks, which are read off the disc at the same time as the video and the analog audio tracks. So... how confident are you that there's any game-specific data stored in the VBI at all? Seems to me that it would have been a lot simpler for Pioneer to encode all the game data into the LD-ROM space, since they already had to give the Sega and TurboGrafx/PC-Engine modules access to that space to begin with in order to have the modules be able to read the game's software off the disc, rather than encode some into the LD-ROM PCM code and some into the analog video VBI...

[pandy]

The ADC actually samples at 10-bit internally, anyway, so does that concern even apply?

yes and no - my point was related to 'older' consumer devices + general approach with 8 bit ADC acquisition (for example most of oscilloscopes use or 6 bit or 8 bit - rarely they use 10 or more bit acquisition front end).
Older brooktree devices (like 878) use 8 bit ADC, conexant is improved design by using 10 bit ADC and adding support for 10 bit RAW capture - so modern CX2388x devices are capable to perform all what is required by OP...

[Nemesis]

Thanks for the continued input guys, it's all helping.

While I was looking up some information about another piece of the LaserActive system, I discovered (or re-discovered) something about the LD-ROM format that I had previously forgotten: The digital LD-ROM data is stored in the space that would normally be used for the PCM digital-audio tracks, which are read off the disc at the same time as the video and the analog audio tracks. So... how confident are you that there's any game-specific data stored in the VBI at all? Seems to me that it would have been a lot simpler for Pioneer to encode all the game data into the LD-ROM space, since they already had to give the Sega and TurboGrafx/PC-Engine modules access to that space to begin with in order to have the modules be able to read the game's software off the disc, rather than encode some into the LD-ROM PCM code and some into the analog video VBI...

In the case of the LaserActive you're right that they do encode game data into the digital audio track. I already have a custom process to capture this full data from the system itself. And when I mean full, I mean every single sector, including the lead-in, pre-gap, lead-out, with full subcode information. I actually have the true TOC data sampled directly from the lead-in. No PC-based drive can do that, in fact, I've needed to create my own CD image file format to store it, because no existing documented CD format can actually hold these sectors (probably because it's never been possible to directly read or write them on a PC). The analog video stream still has information in the VBI region I want though. For example, the LaserDisk TOC is stored in the VBI region, which I need, as well as picture stop codes. There's also time code information in there which the unit itself uses for seeking I believe. I do have some other LaserDisc games here though which are for arcade-based systems. I'm going to see if I can come up with a better result than the existing rips. All of that aside, it also just comes back to the principle of what I'm trying to do. I consider that this'll be the only chance to rip some of these disks (especially the prototypes), so I want to try and make sure I'm truly getting everything off them that I can.

I was looking through the LaserActive schematics today looking at good points to hook in for clean analog signals, and I spotted something interesting:


Remember how I said the LaserActive has a digital buffer? Well it turns out that whether that buffer is being used or not, the video signal is always converted to digital. I had thought this would be hidden inside some proprietary chip, but in fact it's done through this simple standalone ADC, an MB40568. This is an 8-bit ADC which is designed for composite video work, so that goes to show 8-bit seems to be enough to get a reasonable picture, provided the analog input signal has been prepped appropriately. I probably would have found it hard to work out the circuit to do that, but fortunately in this case I don't need to, because all the circuits are already in place for that inside this unit. Seeing that little chip in there already doing the heavy lifting for me, I figured why not try and capture a digital signal rather than an analog one? Turns out that ADC drives an output at around 20MHz, well within the capture range of a good logic analyzer, and fortunately my totally legit (and not at all a cheap Chinese clone) Saleae Logic 16 can endlessly stream 9 digital lines at 32MHz. That allows me to capture all 8 data lines, plus the clock input. All I needed to do was solder on some attachment points, generate a massive data capture log, knock out one dodgy program to scour the data for clock transitions to get the real data samples, and then using the RawSource method jagabo shared (thanks for that!), and here's what I got:


This isn't perfect, the clock signal doesn't give a perfect 50/50 cycle at the trigger point for the logic analyzer, so it's possible I'm missing the occasional sample at 32MHz. I've got a second logic analyzer in the mail, which if I use concurrently to split the data lines between two scopes, I can rip at 50MHz and make sure I'm getting every sample. I'd also be able to capture 10-bit data at 50MHz with this approach too, all I'd need is an ADC that can give me 10-bit precision.

Anyway, I'm still waiting on gear to do RF captures directly from the disc. When that arrives, I'll try and capture video in this manner, and decode it in software, as per this thread:
http://forum.lddb.com/viewtopic.php?f=32&t=2671
Until then, I'll probably mess around with this composite video capture and decoding a bit more, see if I can get both approaches working. With a 50MHz 10-bit capture solution too, I'll dig through catalogs for a better ADC, that would definitely help with the raw RF capture if nothing else. Getting the data to the PC is the hard part, and that part is largely solved with a couple of these totally legitimate and not at all cheap Saleae clones. Hmmm, if I capture only two data lines plus the clock per logic analyzer, I can get 100MHz. Is it overkill to stack 8 of these for a 16-bit 100MHz capture? Probably. Fun to try though.

[pandy]

With such approach i would go for some SDR HW https://en.wikipedia.org/wiki/List_of_software-defined_radios (best of course working from DC but not sure about LD coding/modulation - perhaps DC is not absolute must ) - side to this maybe GNU Radio (IMHO best approach for this kind of processing).

Or something like this http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-bo...=0&pageSize=25

+ some USB3 I/O like http://www.digikey.com/product-detail/en/ftdi-future-technology-devices-international-...253-ND/5431738

or

http://www.digikey.com/product-detail/en/cypress-semiconductor-corp/CYUSB3KIT-003/428-...347-ND/4989179

Depends on kits you should be able to fit in less than 300$

[jagabo]

I've had some success with lining up the sync pulses in software. A sample of PRE_Home_Alone_MV_1_-TBC loaded with RawSource():


[Attachment 39240 - Click to enlarge]

Obviously, the picture is badly bent. Again, the actual line length in the samples is somewhere around 1820.05 pixels and RawSource() is reading 1820 per line, so the picture would slowly slough off to the right (as in post #27) if it wasn't so bent (you can see it if you zoom into the chroma subcarrier in this picture).

After alignment on the falling edges of the horizontal sync pulse:


[Attachment 39241 - Click to enlarge]

I've made not yet made any attempt to adjust the length of each scan line, just copying 1820 pixels starting 8 pixels before the sync pulse (so the falling edge is visible). I'm just using the first sample that falls below a threshold as the trigger, then subtracting 8. Better results could probably be attained by upsampling, smoothing, and interpolating the waveform to get a more accurate trigger. The rising edge of the sync pulse is sharper and would probably work better but the chromaburst signal is contaminating it a bit. It would probably work after removing the chromaburst.

The chroma subcarrier is added to the signal (by the VHS deck) after it's read off the tape and isn't aligned with the sync pulse. If you zoom into the first image you'll see that it's aligned with the cap, not the picture content. And its pattern alternates, repeating every other scan line. After aligning with the sync pulse a lot of moire artifacts are visible so the picture looks noisier. This wouldn't be an issues if the video was run through a comb filter to remove the subcarrier.

The code doesn't adapt to changes in the sync level. It's hard coded for the sync level at the start of the sample clip. The different clips have different sync levels and levels that vary during the clips. The code doesn't work properly during the VBI so it screws the lines up in that region -- and doesn't sync through successive fields. And I've made no attempt to adjust levels to get a full range from blacks to whites in the active picture.

In short, this is simply a proof of concept. It's a very long way from being useful.

[jagabo]

I added a quick and dirty line length adjustment. Here's a field from CAM_Cardston-etc_2.4ta without any length adjustment (just aligning the end of the horizontal sync pulses):


[Attachment 39265 - Click to enlarge]

As you can see, the line lengths vary in groups, with most of them being too short. After adding line length adjustment:


[Attachment 39266 - Click to enlarge]

Opening the same field in the original 4ta file with RawSource() gives:


[Attachment 39273 - Click to enlarge]

Once it reaches the short scan lines it loses sync and you get a garbled picture.

[Brad]

With that camcorder frame, the edges along the black borders still look jagged after the line length adjustment. I don't get why the levels being too high would cause the card/driver to shorten the lines, but it does the same thing with other tapes if the gain level of the driver is set too high. So it's an error, not an accurate representation of the source. Unfortunately these captures were done with the gain set to the lowest value, so I can't just lower the value until it goes away like I did with the rest.

[jagabo]

the edges along the black borders still look jagged after the line length adjustment.

Yes, as I said this still needs a lot more work. A low pass filter and interpolation (rather than just triggering on the first sample that exceeds a fixed value) on the sync pulses should help in straightening out the vertical edges.

[Brad]

I captured several fields worth of video from a DVD player using ms oscilloscope and transferred the data to a Windows PC. As a quick test I viewed the data by importing it into Audacity as 8 bit unsigned integers.

[...]
Zooming into one scan line:


[Attachment 39068 - Click to enlarge]

Here you can see the horizontal sync pulse, the chromaburst, the actual picture content and finally the next horizontal sync pulse.

Audacity seems to max out at 100kHz for the import dialog. I guess the only difference this makes when viewing the samples that I posted is incorrect timecode?

[jagabo]

Audacity seems to max out at 100kHz for the import dialog. I guess the only difference this makes when viewing the samples that I posted is incorrect timecode?

Correct. In the image you can see that I left the sampling frequency at 44100 Hz. The point was just that you could see the raw waveform data with Audacity.