1: https://www.domesday86.com/?page_id=978
I wonder if there's some way to tweak the now seemingly common SDR adapters to provide a plain ADC (ie: without demodulation). When folks are capturing old consoles, generally the RF output is avoided because of the extra noise injected. It would be ideal to work directly with the composite video.
Working with the composite video also would have implications for archiving VHS and other tape-based analog footage: right now, folks tend to use hardware devices called TBCs (time base correctors) to correct issues in the video signal from a VHS player. These are all obsolete at this point and growing increasingly expensive, so it would be nice to replace this hardware with software.
Tapes tend to, especially if copies were made tape-to-tape, be very jittery. These could be almost flawlessly fixed in the domesday software, much better than any TBC.
Since the capture is at the "almost RF" stage early in the tape player, the overall quality is very good too. There is the potential to view VHS in better quality than anyone has ever seen it, even back in the day.
The "almost RF" you're referring to here is a different end of things, the end dealt with by domesday, etc, which is the analog signal stored to the medium in question (whether tape, laserdisc, or something else). Using that signal is, as I think we agree, a very reasonable choice for constructing reasonable archival copies.
http://www.windytan.com/2014/02/mystery-signal-from-helicopt...
Windytan has hearing that puts a bat's to shame.
I've loved this blog though, since coming across it somewhat randomly - looking into decoding the radio-broadcasts that update the Helsinki tram-displays. I never got it to work, despite a few attempts, but it is still something I'd like to come back to.
I did get sucked into the world of decoding random 433Mhz transmissions, and doing protocol analysis with ESP8266 devices though. So that if the company sauna gets turned on I can now post to slack..
Fun fact: unlike for NTSC, this technically isn't true, because there is not a preceding black-and-white format that PAL was compatible with. Rather, PAL's black-and-white format (the line count and refresh rate) was defined at the same time as the colour standard. They chose their number of lines (625) to avoid having to do NTSC's 29.97fps thing.
Or so I think I have heard. Please correct me if I am wrong.
Ideally that'd get the CPU and power usage way down, freeing up CPU for things like streaming.
