Capturing full 525 lines of NTSC frame

[Nemesis]

I'll try and keep this short and sweet. I'm after ANY solution which will enable me to get a clean capture of all 525 lines in an NTSC field. Basically, I want a video capture that looks exactly like this (but for NTSC not PAL):
http://foro.doom9.org/capture/images/syncpic.jpg
Why do I want this? I'm ripping the analog video stream off laserdiscs that were used in various game systems, with the goal of emulating these systems in software. The disks in question encode important information in the vertical blanking region that is used by the hardware. They also encode separate video streams in the two fields, meaning it's much easier to work with separated fields than interlacing them, so I really do have a good reason to want to do an analog capture in this form.

Here's what I've investigated so far:

1. Off the shelf capture hardware
On this so far, I've drawn a blank. I've got an old Canopus DVStorm capture card that I've been using, which gives a great image, and I can happily separate the fields from my capture, but I can't rip the blanking region with it. I haven't been able to find mention of any particular capture cards or devices that will output video for the blanking region. They might be out there, but hours of Google searches have failed to find a single device name which I can confirm will do this. I don't care if it's hardware aimed at home users, or high-end broadcast hardware, any name/model number of any device that someone can confirm to me is capable of doing this will be appreciated.

2. Delaying vsync on the video stream
I've taken serious looks at modifying the video stream itself externally to offset vblank into the image region, so that I can take two captures with different lines masked out, decode each frame into images, and merge the two in software. I can offset it on the screen on my Sony PVM using the H/V delay feature, which looks something like this:

But this is for display only, the monitor doesn't pipe a modified video stream out. I tried my Extron DVS 304, but despite a lot of promising sounding features, it always strips the blanking content out of the input video stream, even though I can force it to output its own (empty) blanking content on the generated output video stream. It looks like the discontinued Extron IN1401 could probably do what I want, but I can't find one of these anywhere at this stage (though I've got alerts setup). I've also investigated building my own device to do this, but I can't find a chip that does what I want here either. Various devices like the LN1881 and EL4583 exist to extract sync information from a video stream without modifying it, but I have yet to find a clean way to actually remove sync information from a video stream. If I could do this, I could separate the sync, remove it, and try and run it through some kind of delay circuit to encode it back in at an offset, which would then allow me to pipe it directly into any capture card and capture the blanking region. If anyone knows of a device that can do this, or how to build a device that can do this, again please let me know.

3. Taking a full analog capture of the video signal and decoding in software
This would be my ideal solution, because it'd be more accurate and complete than an analog video capture. I'd do this happily, if I could find a data acquisition card/device that could do continuous streaming at around 20MHz at greater than 8-bit precision for under $1000. When I couldn't find this kind of a device, I seriously looked into designing and building it myself before I thought better of it. If anyone can point me at a solution in this area, it'd be appreciated.


So that's it in a nutshell. I've tried to be brief and to the point. If anyone knows of any solutions here that could help me achieve what I want to do, I'd greatly appreciate your input. Thanks.

[jagabo]

Maybe a digital oscilloscope board? Coupled to a PC or RaspBerry Pi.

http://www.bitscope.com/product/BS10/
https://www.amazon.com/KKmoon-Professional-Oscilloscope-Bandwidth-Arbitrary/dp/B01LYGZ1G2/

I don't know if they support continuous logging.

[DB83]

Maybe I have this wrong but my understanding of analogue (and digital for that matter) video that while an interlaced picture is made up of two separate pictures, they both essentially are the same since one alternating line is missing in either. Which is why you see a squished image in your caps as above.

Your inference that the pictures are totally different then does not add up. Not familiar with laserdiscs but maybe they worked in a way like dvds and (forget the exact term right now) sub-picture where, yes, you can get an alternative view. But to get that additional picture you 'rip' the content. Simple capturing can only see one picture at any one time.

But even if you could capture the entire analog transmission, I also scratch my head with that you could do with the 'hidden' bit. Surely an emulation is just that. You write your own code with what you think is happening since without access to source you can not repeat the sequence.

[Nemesis]

Maybe a digital oscilloscope board? Coupled to a PC or RaspBerry Pi.

http://www.bitscope.com/product/BS10/
https://www.amazon.com/KKmoon-Professional-Oscilloscope-Bandwidth-Arbitrary/dp/B01LYGZ1G2/

I don't know if they support continuous logging.

Continuous capture is indeed the problem. I have numerous digital oscilloscopes which can do a great job of capturing small, short segments of the video stream, but very very few oscilloscopes support continuous capture. Those ones for example don't. Of the ones that do, they're not quite up to spec, but they're getting closer. Saleae for example have a product, the "Logic Pro 8", that can continuously stream an analog waveform at 5MHz with 12 bits of precision. Unfortunately, I believe I'd need at least 15MHz to even consider attempting this, and ideally something more like 30MHz would be used.

Maybe I have this wrong but my understanding of analogue (and digital for that matter) video that while an interlaced picture is made up of two separate pictures, they both essentially are the same since one alternating line is missing in either. Which is why you see a squished image in your caps as above.

Your inference that the pictures are totally different then does not add up. Not familiar with laserdiscs but maybe they worked in a way like dvds and (forget the exact term right now) sub-picture where, yes, you can get an alternative view. But to get that additional picture you 'rip' the content. Simple capturing can only see one picture at any one time.

If the composite video signal was directly output from the unit to the external display, you would be correct, but this isn't the case for me. I'm looking at the Pioneer LaserActive for example. This unit has game modules that plug into the player, and have direct control over the LaserDisk player. Games for the system encode program code onto the laserdisk itself, which is read from the disk and loaded into memory, and then takes full control of the unit, with other graphics chips from the game module writing their own graphical content directly over (or under) the analog video stream. The Pioneer LaserActive also contains a digital frame buffer, and when this buffer is enabled, the analog video isn't directly output from the unit, it runs into this buffer first. When this buffer is enabled, one of the features the hardware provides is the ability to select even/odd field only, and in this mode, only one field is used, and is essentially line doubled when being output from the buffer, creating an output image with less vertical resolution, but the same aspect ratio. Many of the games for this system use this extensively to create "branching" cases in the game, where you make a choice which affects the outcome, and this is done without breaking the video stream with a seek operation by enabling video exclusively from either the left of right fields, depending on the choice made. The same kind of logic is used for selecting audio tracks, where the left and right channels for example can contain totally different audio, but the game can put the player into left/right channel only mode, where that selected channel is output to both speakers.

But even if you could capture the entire analog transmission, I also scratch my head with that you could do with the 'hidden' bit. Surely an emulation is just that. You write your own code with what you think is happening since without access to source you can not repeat the sequence.

Some systems, particularly laserdisk-based arcade systems, encode markers in the vertical blanking region. There is dedicated hardware provided that examines the video stream during playback, and looks for these markers. The hardware is designed to allow code to instruct the unit to take action at these marker points, such as pausing playback, or reading a location to seek to and continue at. This is to allow the program code that drives these games to not have to have absolute sector counts and positions encoded into them for playback, instead the video stream can change independently, and these markers in the video stream itself direct where the video needs to transition to. This would have made their development much simpler, and also helped with the issue that seek behaviour on these units wasn't precise, so the target could overshoot or undershoot anyway, while a stop marker in the video stream itself could be easily decoded and precisely honoured, where an absolute sector play count may have stopped playback too early or too late. Capturing these markers is essential in order to properly emulate the system.

[DB83]

Thank you for that detailed explanation.

One thing still baffles me tho. I did a quick Google on that Pioneer system and I was informed that the games are stored on LD-ROM disks. There is no mention of any write facility.

My gut feeling is that you are actually attempting reverse-engineering rather than simulation.

[jagabo]

Maybe a digital oscilloscope board? Coupled to a PC or RaspBerry Pi.

http://www.bitscope.com/product/BS10/
https://www.amazon.com/KKmoon-Professional-Oscilloscope-Bandwidth-Arbitrary/dp/B01LYGZ1G2/

I don't know if they support continuous logging.

Continuous capture is indeed the problem. I have numerous digital oscilloscopes which can do a great job of capturing small, short segments of the video stream, but very very few oscilloscopes support continuous capture.

Yes, but those are software scopes. If the raw data is sent continuously to the PC and software is performing the oscilloscope functions it should be possible to just save the data as a continuous data stream instead of triggering and showing a waveform. On the other hand, if they capture a block internally, then transmit it to the PC, then wait for a command to capture the next block, they may not work.

Just playing with my digital scope which has a 24 MSample buffer -- it looks like 25 MS/s will be sufficient for your purposes. Capturing for ~50 ms (about 3.5 NTSC fields) the chroma burst signal is still a pretty clean sine wave when I zoom in. At the next step down, 10 MS/s, the chroma burst is looking a little ragged. 25 MS/s is a little lower than DVD resolutions but should be sufficient for laserdisc (about 1/2 DVD resolution horizontally).

[Nemesis]

Thank you for that detailed explanation.

One thing still baffles me tho. I did a quick Google on that Pioneer system and I was informed that the games are stored on LD-ROM disks. There is no mention of any write facility.

My gut feeling is that you are actually attempting reverse-engineering rather than simulation.

I am indeed reverse-engineering the hardware. When I use the word emulation, what it means to me is to create a virtual environment through software which, as much as is possible, accurately recreates responses and timing of the original hardware, so that software running within this virtual environment behaves in the same manner as it would on the physical device. A fairly unique challenge with this particular system is the analog nature of the video encoded on the Laserdisc medium, and how to capture that as completely and faithfully as possible, knowing that any solution is ultimately just an approximation of the original medium. Usually in these kind of systems all the data is digital, so the method of storage and verification of the captured data is comparatively easy, but in this case the data medium is truly analog, so an analog capture is the best we can do. The encoding of non-standard markers in the vertical blanking region on the analog video stream in particular is what adds to the requirements of a traditional video capture process, but there's also the preservation aspect, and from that point of view, I want to try and make sure as much of the original data from the analog video stream is preserved as possible, because there may not be a chance to do another rip of all these disks. I have an extended collection on loan to me, and some of the disks are prototypes or otherwise extremely rare, and cost 5 figure sums to purchase! The likelihood of getting another pass at ripping them is quite low.

[solarfox]

One thing still baffles me tho. I did a quick Google on that Pioneer system and I was informed that the games are stored on LD-ROM disks. There is no mention of any write facility.

If you're referring to this:

with other graphics chips from the game module writing their own graphical content directly over (or under) the analog video stream.

then what he actually meant was "overlaying", not "writing."

The Pioneer Laseractive system was a specialized LD player which had a bay in the front for add-on modules that allowed it to be turned into a game system, or a Karaoke machine. The game-system modules were basically the guts of an NEC PC Engine / TurboGrafx-16, or a Sega Genesis, with additional circuitry that allowed the game-console electronics to read program data off the laserdisc, control the disc playback, and overlay or chroma-key their game graphics onto the live video coming off the disc.

[solarfox]

A fairly unique challenge with this particular system is the analog nature of the video encoded on the Laserdisc medium

Another challenge you'll face is getting the actual game code off of the discs, as well. If I recall correctly, there's an area of the disc that actually does have the initial program code stored as digital bits in a filesystem similar to that used by some of the Acorn Computers systems, which will not be accessed or played back if you just stick the disc in a standard LaserDisc player. I'm pretty sure the LaserActive reads this section of the disc and stuffs the data into a block of RAM inside the expansion PAC, and the PAC then executes it as though it were a game cartridge. (Basically, the RAM is mapped into the same address space as where a ROM cartridge would normally be.)

I suspect capturing all of this information is going to require some pretty clever custom-designed circuitry, grafted onto a functional LaserActive unit, in order to get at it...

[DB83]

But what of this extract:

"Games for the system encode program code onto the laserdisk itself, which is read from the disk and loaded into memory, and then takes full control of the unit,...."

Surely that suggests physically writing to read-only media.

Maybe a bad choice of words by the OP who might have meant that the game writes to memory and it is that memory that ultimately controls the game not the disk.

To the OP:

Good luck with that project. It may be simpler to play the games over a capture device. Note the changes and emulate from there rather than attempt to re-invent the wheel.

[Nemesis]

Maybe a digital oscilloscope board? Coupled to a PC or RaspBerry Pi.

http://www.bitscope.com/product/BS10/
https://www.amazon.com/KKmoon-Professional-Oscilloscope-Bandwidth-Arbitrary/dp/B01LYGZ1G2/

I don't know if they support continuous logging.

Continuous capture is indeed the problem. I have numerous digital oscilloscopes which can do a great job of capturing small, short segments of the video stream, but very very few oscilloscopes support continuous capture.

Yes, but those are software scopes. If the raw data is sent continuously to the PC and software is performing the oscilloscope functions it should be possible to just save the data as a continuous data stream instead of triggering and showing a waveform. On the other hand, if they capture a block internally, then transmit it to the PC, then wait for a command to capture the next block, they may not work.

Just playing with my digital scope which has a 24 MSample buffer -- it looks like 25 MS/s will be sufficient for your purposes. Capturing for ~50 ms (about 3.5 NTSC fields) the chroma burst signal is still a pretty clean sine wave when I zoom in. At the next step down, 10 MS/s, the chroma burst is looking a little ragged. 25 MS/s is a little lower than DVD resolutions but should be sufficient for laserdisc (about 1/2 DVD resolution horizontally).

It would be nice if more scopes worked that way, but unfortunately not many do. Digital oscilloscopes often have ADC chips capable of capturing data at the rate I require, but they almost invariably contain buffers, and the entire design of the hardware is based around rapidly capturing samples to the buffer, and when the buffer is full, they stop capturing and dispatch that data to the connected device. In the case of triggers being set, the device is indeed continuously writing to its internal buffer, but it isn't dispatching that buffer until the trigger condition is satisfied. That's really just how oscilloscopes are generally designed from the start, because you usually care about trigger events. Capturing a continuous analog stream into a glorified wav file should actually be simpler, and this is what data acquisition cards are all about, but unfortunately nobody seems to have come to market with a low-cost card aimed at hobbyists in this space which is up to spec. The market seems to be a combination of hardware aimed at industrial uses with $1000+ price tags, or people trying to make open-source hardware devices using about 2c worth of parts, but with much lower specs than I'd require. As of yet, we haven't got a no-name company out of China producing a mid-range affordable solution for hobbyists, at least that I've seen. Like I said I considered even building this myself, I think there'd be some good money in it, but while I could probably make the digital side of the capture hardware work, I simply lack the real-world experience in analog electronics to be able to do a good job on that part.

All that said, maybe there's a device out there I haven't found or overlooked. By all means, if you can track down either an oscilloscope or a data acquisition device that I can either buy or build, and the cost comes in at under $1K, I'd definitely want to take a look at it.

[Nemesis]

But what of this extract:

"Games for the system encode program code onto the laserdisk itself, which is read from the disk and loaded into memory, and then takes full control of the unit,...."

Surely that suggests physically writing to read-only media.

Maybe a bad choice of words by the OP who might have meant that the game writes to memory and it is that memory that ultimately controls the game not the disk.

Bad choice of words perhaps. Let me clarify: The LaserDisc is the game. A generic system BIOS does the initial startup of the system, but once a disk is loaded, the code for the game is read off the disk and loaded into memory, which then takes over. Program code is stored on the LaserDisc in the same manner as digital audio is embedded onto a LaserDisc, it's piggybacked off the analog video stream at a lower frequency, using it as a carrier wave. Error correction is employed to compensate for read errors. I already have a capture solution for this digital data, it's just the analog video I'm looking for a better solution for.

[pandy]

Brooktree 84x/87x and later Conexant based on Brooktree should be capable to perform something like this...

[jagabo]

And Pandy will write the drivers for you.

[JVRaines]

I believe the Osprey analog capture cards read the Vertical Blanking Interval and deliver the raw waveforms through DirectShow.

[raffriff42]

Why do you need to capture raw? Can't you work with the demodulated signal? Do you plan to demodulate in software?

I can't believe a laserdisc has any useful information at 50Mhz -- analog NTSC requires about 5 MHz, PAL a bit more. Modulated (professional 1" videotape), 10-12 MHz. Digital Rec.601 bitrate is around 15-17 MHz. None of them come close to 50 MHz.

Okay okay, you want all the low-level data -- what about slowing the rotational speed of the disc? You could capture the data at audio frequencies.

[Nemesis]

Why do you need to capture raw? Can't you work with the demodulated signal? Do you plan to demodulate in software?

I don't need to capture raw, but it would be nice if I could. That is just one of the three possible methods I've investigated. If I did capture the raw signal, I would demodulate in software, yes.

I can't believe a laserdisc has any useful information at 50Mhz -- analog NTSC requires about 5 MHz, PAL a bit more. Modulated (professional 1" videotape), 10-12 MHz. Digital Rec.601 bitrate is around 15-17 MHz. None of them come close to 50 MHz.

I never mentioned 50MHz, I said 15MHz would be the bare minimum to make the attempt, 30MHz ideally. The Laserdisc format encodes data at over 9MHz
See the following:
http://www.turing-machines.com/pdf/vlp.pdf
Now take into account that you generally need to sample at twice the frequency of the waveform you want to capture, meaning I really need a rate at over 18MHz. That's if I want to sample pretty much directly from the laser pickup, which I would if I was going down this route.

Okay okay, you want all the low-level data -- what about slowing the rotational speed of the disc? You could capture the data at audio frequencies.

I thought about that, but my gut feeling is it would require extensive modifications to the hardware.

[Nemesis]

Brooktree 84x/87x and later Conexant based on Brooktree should be capable to perform something like this...

I believe the Osprey analog capture cards read the Vertical Blanking Interval and deliver the raw waveforms through DirectShow.

Thanks for both these tips. I'd never heard of the Osprey cards before, I'm looking into them right now, and it sounds sounds like this VBI waveform feature might be able to do what I want. These cards seem to be little more than a Conexant Fusion 878A on a board, and the 878A datasheet is comprehensive, so I'm trawling through that now. With such a direct interface to a well documented chip, I might even have a go at hacking the drivers to expose the entire video stream in a raw form like this if possible, or maybe modify the open-source linux driver they've got.

I'm researching Osprey models right now. Does anyone have any tips or experience with particular cards they'd recommend or avoid? I'm ruling out the 5x0 line because it apparently doesn't support the VBI feature, but I'm looking closely at the 210 and 230 variants.

[jagabo]

Having access to the full analog waveform would also be useful for time base correction of VHS.

[JVRaines]

Having access to the full analog waveform would also be useful for time base correction of VHS.

Tantalizing, isn't it?

In the VBI frame output mode, VBI data capture occurs in the active video region and includes all the horizontal blank/sync information in the data stream.

They're calling it VBI in this mode but what they really mean is HBI data capture. With the horizontal sync pulse in the output, we should be able to fix those wiggly lines in software!

[jagabo]

Having access to the full analog waveform would also be useful for time base correction of VHS.

Tantalizing, isn't it?

In the VBI frame output mode, VBI data capture occurs in the active video region and includes all the horizontal blank/sync information in the data stream.

They're calling it VBI in this mode but what they really mean is HBI data capture. With the horizontal sync pulse in the output, we should be able to fix those wiggly lines in software!

My scope can capture several frames worth of video and export them as 8 bit samples. I'll try it out tomorrow if one of my old VHS decks still works. One problem I foresee -- I don't know how to demux the luma and chroma. I guess I'll start with some black and white test patterns.

[pandy]

And Pandy will write the drivers for you.

Drivers exist trough various linux projects related to VBI capturing...

Sarcasm understood however IMHO not needed (way easier to use this than creating driver or software for proposed oscilloscope), but if we drifting to such level of sarcasm then why not https://www.xmos.com/support/appnotes/AN00127 - class is there so software is "almost" done.

My scope can capture several frames worth of video and export them as 8 bit samples. I'll try it out tomorrow if one of my old VHS decks still works. One problem I foresee -- I don't know how to demux the luma and chroma. I guess I'll start with some black and white test patterns.

http://www.techmind.org/vd/paldec.html
http://www.jim-easterbrook.me.uk/pal/
https://github.com/svofski/CRT

[Brad]

Capturing the 1D signal is easy at this point. Decoding it into a nice video is the hard part.

https://forum.videohelp.com/threads/359690-Geek-fun-with-VBI-Macrovision-DVD-recorders-...eo#post2447831

I hope you're aware that people have already captured the video signals off LaserDisc games. Possibly all of them.

[Nemesis]

The Osprey cards looked promising enough that I've gone ahead and bought one. An Osprey 210 is in the mail, but since it's coming from the US and I'm in Sydney, it'll be a couple of weeks before I get my hands on it. When it arrives I'll have a play around with the VBI feature and see what I can make it do. Thanks again for the input, and if anyone else has any other ideas, feel free to chime in, I'm still interested in any other options that might be out there.

My scope can capture several frames worth of video and export them as 8 bit samples. I'll try it out tomorrow if one of my old VHS decks still works. One problem I foresee -- I don't know how to demux the luma and chroma. I guess I'll start with some black and white test patterns.

8-bit wouldn't be enough for a decent go at video would it? I'd assumed you'd need something more in the 12-bit range at a minimum. That's all just my assumptions though, no actual experience attempting it.

Capturing the 1D signal is easy at this point. Decoding it into a nice video is the hard part.

https://forum.videohelp.com/threads/359690-Geek-fun-with-VBI-Macrovision-DVD-recorders-...eo#post2447831

I forgot about that guy, looks like he's got a lot further than when I last looked at this. I've had this project pretty much on ice for the last 2+ years. Not sure if I'd call his solution "easy", and he's still looking for a better capture method himself, but it looks like a Connexant CX23880/1/2 based system with his custom driver can do what I want. I'll track one down and definitely give it a spin. It'll be interesting to see how good a result I get from his software decoder.

One thing I did some across though while going back through his thread was some blog posts Aaron Giles from MAME made years ago on, what would you know, capturing VBI data from LaserDisc games. He ended up working up a few DirectShow filters to capture VBI waveform data and convert it to an image for embedding back into the video stream, and last year he put them online here: https://github.com/aaronsgiles/VBIUtils. Since those Osprey cards support the VBI pin, those filters should pick up the data and basically do the work for me. Sweet!

I hope you're aware that people have already captured the video signals off LaserDisc games. Possibly all of them.

In the arcade space perhaps. Search the web for anything related to the Pioneer LaserActive though, and you'll only find one early and incomplete rip out there, done by me.


I'll tell you what though, all this really shows the need for someone to fill this high bandwidth single channel data capture space though, when we're tearing apart video capture cards and building custom drivers for them just to capture an analog waveform, or when we're looking for ways around our capture drivers so we can just simply get our hands on the actual data. Seriously, if there are any experienced electrical engineers reading this, do yourself a favour and glue a single channel 12+ bit ADC in the 30+Mhz range onto a decent USB3 interface, write yourself a bare bones driver and a command line tool to rip the data to a file, and start flogging them for some cash. I'd happily drop $250 on a device like that right now, and there are quite a few others out there who would too. The HAM radio market would eat it up, and you know what, one device like this, once picked up by a few bored and talented programmers, can result in software-based decoding solutions that would pretty well make every single audio or video capture device on the market redundant.

[jagabo]

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. Here you can see about 7 fields worth of video as a raw waveform:


[Attachment 39067 - Click to enlarge]

The dips in the waveform are the vertical retrace periods.

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.

Zooming into a small segment of the scan line (the picture here is alternating black and white 1 pixel wide vertical lines):


[Attachment 39069 - Click to enlarge]

Here are ~two fields of raw data imported into AviSynth using RawSource() and resized to 858 pixels wide (leaving the actual picture content 704 pixels wide):


[Attachment 39070 - Click to enlarge]

The lines are slanted because the captured data is arbitrarily captured at 20 ns intervals and the width of a video scan line is not an integer multiple of 20 ns. The width of one scan line here is about 3177.81 samples and RawSource() was set to 3178 pixels wide. So each successive scan line shifts a little to the left.

Finally, the actual test pattern that was being displayed:


[Attachment 39071 - Click to enlarge]

If the laserdisc really has data in the VBI you should be able to see it with a scope.

[Brad]

Not sure if I'd call his solution "easy"

I meant the composite output. It's a matter of installing the card & Linux and executing a handful of terminal commands to dump the data. (You may also need an adapter if you buy one of the cards that doesn't have a physical RCA input.)

As I said, then dealing with that data is a whole other exercise, but since you're a programmer you could try to improve upon the 4fsc decoding currently offered by Happycube's program.

If anyone wants to play around with 8-bit 4fsc samples, here are some from VHS. The camcorder tape samples are garbled, apparently because the content is too bright.

Google Drive links. The files are also attached at the bottom of this post.
https://drive.google.com/file/d/0B123gn ... sp=sharing
https://drive.google.com/file/d/0B123gn ... sp=sharing
https://drive.google.com/file/d/0B123gn ... sp=sharing
https://drive.google.com/file/d/0B123gn ... sp=sharing

For demodulation you need to add the step of soldering to the RF test point, but from what I've seen ld-decode seems to provide nice, stable demod + TBC + comb filtering on the software side once you've mucked with the hardware.

One thing I did some across though while going back through his thread was some blog posts Aaron Giles from MAME made years ago on, what would you know, capturing VBI data from LaserDisc games.

I was going to try to dig up those blog posts, but he seemed to be oddly vague about the hardware he used, and as I recall he said it was a bit of a hackjob putting it back together with the separately captured video image. So I figured the "raw" solution would be cleaner for you anyhow.

In the arcade space perhaps. Search the web for anything related to the Pioneer LaserActive though, and you'll only find one early and incomplete rip out there, done by me.

Kay, just making sure. I wonder if you could contact the guys who did the MAME work for any additional tips they may have. If they still exist on the internet.

[jagabo]

If anyone wants to play around with 8-bit 4fsc samples, here are some from VHS.

Here's a field from the first file with:

RawSource("CBL_Citytv-2007_1.4ta", index="0:409500", width=1820, height=262, pixel_type="Y8")

[Attachment 39077 - Click to enlarge]

It looks like all the raw data (vertical/horizontal sync pulses, etc.) is there to work with. Note that one field would really be 262.5 scan lines but RawSource() only allows multiples of 2 when importing Y8 data (it converts to YV12).

And one field from one of the videos after a line TBC:

RawSource("PRE_Home_Alone_MV_1_+TBC.4ta", index="0:383230", width=1820, height=262, pixel_type="Y8")

[Attachment 39078 - Click to enlarge]

From this I calculate the line length is about 1820.05 samples.

[JVRaines]

Now the interesting question is: can you do line TBC in software and turn the first sample into the second?

[pandy]

8 bit is not enough as complete signal need to be acquired so 300mV or more will be lost (unless clamp and sync separation processed separately) - side to this ADC usually offer lower accuracy than resolution especially for high frequencies - this parameter is called ENOB https://en.wikipedia.org/wiki/Effective_number_of_bits - usual 8 bit ADC for frequencies close to maximum supported sample rate will offer around 5.5 - 6.5 ENOB (so effective resolution is lower than specified - this is for example specified for digital oscilloscopes).
All above is important for close to perfect copying - if such approach is not a goal then requirements for ADC are relaxed.

[jagabo]

But VHS only has about 5 bits worth of signal to noise ratio and about 350 lines of resolution across the active picture frame. So these sample files are certainly enough for a proof of concept.