Current status of ld-decode / vhs-decode (true "backup" of RF signals)

[lordsmurf]

They're not easy to solve, requires time of study and work, and most of us have other responsibilities too.

You seem reasonable. That's refreshing.

I would use the Spiderman movie as a source.

Retail tapes should not be the source of comparison. Those were not even recorded, but instead created by magnetic contact.

On the other hand, the final goal is to capture videos and watch them, whatever "principle of preservation" is supporting it. Otherwise is like never buying a TV because each year a better model hits the market.

That's it entirely. Capture with the best now, as available now.
Leave the future to the future. You can re-capture anything that truly needs to be better at a later date (because the technology for it does not exist yet). I did this with scanning photos years ago, and will later re-scan/process a few that merit the attention (and that tech is just now starting to give results, but still not quite there yet).

I understand the fact that vhs_decode in not yet established as the ultimate preservation/capture tool because its post-processing not yet at his best (while the RF capture is, more or less).

RF capturing still has bias from the head in use. That's why a thrift store VCR tends to be highly inadequate.

we now that and are aware of the limitations.

Unfortunately, not everybody knows this. A lot of people have gotten "too big for their britches", making wildly inaccurate claims as to how viable and quality it is. But it is not. It may be "the future", but it's definitely not "the current".

because some of the most knowleadgable videohelp could have been involved, but if you guys do not want so, then is fine to decide to leave this attempt.

Some of us are doing this in private, amongst ourselves, slowly, to our own timelines, away from the stupid elements of the project. For example, I have an AG-1970 set aside that I intend to use. What I expect is a sharper image, but with more image defects that were hidden/removed by the VCRs and TBCs.

And understand that I will be trying my best, as I have some extremely rare recordings that are worth the tiny boost in sharpness. I'll even go so far as to mix RF/standard workflow captures to create the best final version of the recording.

I'm actually NOT all that confident in the idea that you can "get the tape RF now, worry about making it better later". Vaporware is common, time obsolesces everything. But for these few recordings, which have already been captured 3-4 times over the past 20+ years, for 1970s tapes that are aging within that 35-65 year window, I'm not against storing a supposed "RF copy" on a HDD or SSD (or both). But I'd not bet money on it -- at least not any more than the drives cost.

Sometimes people (WRONGLY!) state that I'm a "perfectionist". But if you want to gets nuts, let's get nuts!

[dellsam34]

On the hardware side, for the project to have a wide compatibility and better support they will have to design the heads pre-amp and make it part of the hardware, Then you can take the output from the heads' rotary transformer of any VCR or camcorder, any format, pro or consumer, and amplify it without needing the VCR, If you approach pro formats you may get some robust support, relying on the VCR pre-amp and consumer formats only is going to hinder the project progress.

Ideally design a BLDC control board for both the capstan and the video drum motors to have a better control of the tape transport and throw away the entire electronics of the VCR, That way with any VCR you can do 525 and 625 formats' official speeds, and any low speed such as LP, EP, SLP ...etc. Not only that but having control of the tape transport you can recover stretched or shrunk tapes, tapes with damaged edge of the control track, you can have manual tracking, you name it.

[Orikson]

The thing is, you are still riding dead horses, as the main problem are the actual heads, that wear out and are not produced anymore. So you will never have a consistent source for them, as one always have to rely on the used ones that are around.

So to make it good in the long term, you might need a substitute for the heads. I know that magnetic storage systems are still used in many companies, but for backup of data. So I don't know if you can modify a head e.g. of a LTO or DDS drive

[dellsam34]

That's not the vhsdecode's problem, Conventional capture is affected as well. My point was that if only the tape transport is needed, than there is a good supply of VCRs that were made as late as 2016 that are in good condition enough to get the available stock of un-captured tapes transferred to digital, You need new heads if recording or repeated playback is intended, As far as I know only a negligeable number of people doing this for hobby or nostalgic purposes. So heads are not going to be a problem for at least the next 40 years, given the fact that heavily used machines from early 80's are still functioning, so 2010's VCRs with light use should be fine for more few decades for a single play per tape, But you can't use such low end machines for regular capturing via composite for a decent quality capture.

[harrypm]

For the 20 people who still look though this thread for project update info, which as mostly been abandoned compared to reddit and discord and the commit logs of the project its self alongside the wiki.

I figured I would post about the new hifi-decode GUI and some new dark mode snips overviewing the GUI tool chain, also the new tbc-video-export tool which has full Linux/Windows/MacOS x86/MacOS Arm support and makes fully complient FFV1 files V210 files and soon with some updates broadcast complient ProRes files for Mac users.

Recently there has been a focus on build automation, meaning every update will automatically get built into archival ready self contained binarys zero external depedencys required, this has already been fully setup for the export tool and will be for the new metadata tool which will provide graph data image and vector assets alongside automatic PDF reports in a human readable format with a single command.

Also the conventional capture argument has been killed by a German, yes I know americans tired and the japanse hoped, but its over now thanks to MISRC "Multi Input Simultaneous Raw RF Capture" the name is pretty dead pan but It can do RAW S-Video or RAW CVBS capture at 12-bit resolution so basically its as good as your current gen capture chain chips with 40/65/85msps options just change a Crystal/ADC package and change the firmware a little for your desired speed 40msps is what we have settled for the standard release, comming to a chinese fab near you soon!

This means people will have a plug and play duel channel capture device for Video RF + HiFi FM (+ Linear/TC/Ref via sub board) this is in additon to the next docs update featuring the workflow for the current syncronised CX Cards which provides a clear upgrade path for exising CX White card users or new commers who like a pure CLI or PCIe based workflow that is highly scripted at under 100USD cost to anyone in the world market wise even with new optimised amplifyers.

Thanks to these new upgrades for the CX Card, a new mod is on the horison for existing DomesDay Duplicator users, providng an audio capture device using the same clock so Video RF + Syncronised baseband audio capture this will be comming in the next few weeks to months as its tested and standerdised.

Also we figured out how to make lower end HanTek ossiliscopes output direct samples, they work for CVBS/FM capture too so a new additon to the ever expanding list of FM RF archival ready devices.

Now for some images!

HiFi-Decode


[Attachment 76656 - Click to enlarge]


[Attachment 76657 - Click to enlarge]


[Attachment 76658 - Click to enlarge]


-----

ld-analyse toolchain in use

VHS-Decode


[Attachment 76660 - Click to enlarge]


CVBS-Decode


[Attachment 76659 - Click to enlarge]

-------

TBC-Video-Export

S-Video --> FFV1


[Attachment 76663 - Click to enlarge]


Composite --> FFV1


[Attachment 76662 - Click to enlarge]

On these notes happy newyears & Chinese newyears and happy FM RF archival, and decoding forever!

[WaxCyl]

Very impressive Harry!

[dellsam34]

As far as I know audio for video should always be 48KHz not 44.1KHz, the only case I see 44.1KHz could be used is when capturing HiFi audio from a music video to save audio only.

How long does it take to decode one hour capture file? I may give that MISRC hardware a shot when it becomes available.

[harrypm]

HiFi-Decode is just sampling from the FM signal not baseband so the decoder is entirely software defined output, you can define anything upto 192khz (24-bit interger) I will note these images is just the inital demo snips used as the commit refrance, more accurate ones to current workflow will be used for the userguide although GUI is just a bit of polish, carrier adjustment mini-game comming soon.

But for clarity the toolchain and recommended workflow is 48khz even the RTLSDR Decode scripts use 48khz for realtime HiFi FM decoding.

HiFi-Decode is real-time able with enough raw compute tossed at it such as a AMD 5950x or newer but will improve over time its 20-40msps files that will be slow today, noise processing is the big hit compute wise.

For video decoding speed thats a verible question relative to sampling rate of your captures really Speed Testing Doc exits to jornrnal the speed gains with newer hardware 16fps video decoding speed has been achived last year with the M2 Ultra with newer hardware even faster should be possible but not everyone can get top end CPUs tested as soon as it comes out.

[dellsam34]

So with the new MISRC hardware, is capturing both RF HiFi and RF video with perfect sync into one single file possible? or separate files are created and muxing and syncing them is part of the decode? Also would it be possible to add a convenient 2ch audio ADC for linear input into the hardware?

[harrypm]

So with the new MISRC hardware, is capturing both RF HiFi and RF video with perfect sync into one single file possible? or separate files are created and muxing and syncing them is part of the decode? Also would it be possible to add a convenient 2ch audio ADC for linear input into the hardware?

Its 32-bits of data in a .bin file then the extract tool currently makes 2 files for the signed or unsigned format data streams .s16 or .u16 from 12-bits actual data, then that can be FLAC compressed filtered and down-sampled or decoded directly.

Key point being there is a extra 8-bits of bandwith for an audio ADC for so HiFi ref + linear + timing signals like head switching or anything else etc this a very dev board style duel ADC setup with a lot of applications with just a flick of a few switches and a little firmware tweak here or there it can be used as a ossiliscope upto the 2v range.

The hardware sync is crystal perfect, and there is a SMA for external clock output for outher devices, but some level of software automated checking and alinement is required for dropped frames and such, but we already have tools for that written when the CX Cards were being modded to do the same thing.

There is plans for a 4 port TRS/XLR combo jack sub-board with so balenced inputs ready for use on everything from VHS to Betacam decks, its just a matter of finalising a design and doing test fab runs.

[dellsam34]

Well, I'm not into firmware tweaking and that sorts of things, so I guess this is not ready for primetime yet, I will check back in a while and see when things come down to an average hobbyist level.

[i4004]

"oscilloscopes"
a weird error given semantical depth of other things you discuss.
you would probably prefer some slavic languages where words are pronunced exactly as they're written.

and "alignment". same type of error, cutting corners....

This means people will have a plug and play duel channel capture device for Video RF + HiFi FM (+ Linear/TC/Ref via sub board)

(my bold on your quote)
i would of really expect there would be analog audio input too on that german board, in 21-st century, without any extras.

that strikes me the most: it seems audio was afterthought throughout the project. "let's make few more boards given this weird situation, we'll put them..somewhere....".

while most pcs have perfectly functioning audio inputs, that you can resample at will and match to video you're capturing.
it's so unthrifty, so unprotestant.

https://www.cithraidt.de/sync/index.html
program from 2003.

News:
2003/09/25: Released VirtualDub-1_5_04_sync1_04
- added sync-routines and modified bt848-tweaker in VirtualDub 1.5.04
- added keyboard support for bt848-tweaker

you introduced so much layers of complication: for example whole hi-fi audio path.
it's just analog audio, 2 channels, capture it via pc audio input.
but you can't, because you don't have frame of reference, you're just dumping raw rf data to file, you're not inspecting that file "on-thy-fly" ie prior to writing it on the disk to check for framerate (which you can derive from the number of full lines you've captured, you don't need headswitching signal to do that...then again, you probably can't do that, as you're choking on too much data as processing speeds suggest) and then adjust that to fit audio samples, or adjust both video and audio clocks for a better match, like newer versions of vdub do.

so it seems one can't capture the audio (at all) unless he's capturing headswitching signal too?

Audio is 24-bit 3 channel 46875sps (46khz) file the mapping is:

Left/Right/Headswitch

from
https://github.com/oyvindln/vhs-decode/wiki/Clockgen-Mod

yeap, surely looks like you're doing exactly that.

stuff should be simplified, as this way you'll remain nich-of-the-niche.
one piece of hardware (to capture rf video, headswitching and 2 channels of analog audio) and one piece of software (with a gui) to do capture.
after that complicate as much as you like, once the files are written to hdd.

all other complexity is not hard (pulling wires out of vcr, linux to capture, muxing and processing) but you're making it hard to begin, because of hardware requirements for signal digitizers ie this habit of adding hardware just to capture audio too.


there's much confusion, also stemming from less of detail on your wiki:
https://youtu.be/pEzmbw_Y-Tw?t=628

nope, cx card alone is surely not enough to capture synced audio and video. that should be something you start wiki with and put it on top of every page.

i mean one could do something simillar to what the guy in that yt video did, capture rf video, while capturing audio in wav file, sync it later.
if it wants to be synced, ie if there's no timing jitter in audio and video file.
but there will be error because nothing is locking audio to video.

and at that very moment vhs-decode becomes rabbit-hole exploration.

quite incredible that linear (mono) audio didn't cross the mind of misrc creator.
esp. given that most of my tapes are precisely mono, done long before hifi vcrs were cheap enough.

[dellsam34]

The capturing steps from A to Z should be unified in one process, The biggest problem with this is relying on the computer CPU, While the concept is great since almost everyone wanting to capture analog video certainly has a computer and a VCR, But to have a computer process all the tasks on the fly, it has to be one of the fastest and most expensive computers. A task like this should be self contained in a single system and does all the processing inside the box, Capturing RF video, RF audio, linear audio and other data, process everything together and output lossless YUV via USB or into an internal storage, Other tasks can then be later done in computer, such as de-interlacing, resizing and encoding to a lossy format.

The way it is now is a mess in my opinion, Sure it's a fun task for tech savvy hobbyists but as I said numerous times, it is not for the masses out there trying to capture their childhood memories made by mom and dad's camcorder.

[lollo]

nope, cx card alone is surely not enough to capture synced audio and video

The whole concept of vhs-decode is seductive to many of us, but the concern about audio/video synch is sound.

You well summarized the case where capturing with separated audio and video was causing troubles 20 years ago, and VirtualDub tried to solve them across its many releases and its side activities like VirtualDub-Sync.
(BTW VirtualDub today still has problems with audio/video synch even with modern cards featuring integrated audio/video ICs and with modern OSs).

But let's see what the vhs-decode developpers can propose.

[oln]

The audio inputs on the MISRC are put on a sub board to allow for different configurations - it's not there as an afterthought - the design is still being worked on. vhs-decode is a community project that is continuously evolving, not a commercial offering with capital backing it, so you shouldn't treat it as one. I feel you are talking as if we're intentionally making it complicated - it's just a community project with limited resources so the software and hardware still needs a lot of work yet. I agree that audio sync is an issue currently, of course some of that also comes with the nature of capturing the raw undecoded signal and having up until now having to use capture solutions that haven't really been designed for this use case that have just had a single input.

while most pcs have perfectly functioning audio inputs, that you can resample at will and match to video you're capturing.
it's so unthrifty, so unprotestant.

You can't easily do it that way and have it work properly, the audio capture needs to be on the same clock as the video capture to be synced to it properly in post unless you have some other reference point like say doing a conventional capture with audio. It's not the same as syncing audio to already decoded video that virtualdub does, one would need to be able to reliably decode the video faster than realtime to be able to do something like that which we are not anywhere close to at the moment. And no you don't have to capture head switch to be able to sync audio.

As for making a self-contained system, it seems SingMai looked into this this as a commercial solution judging by the thread they made but gave up and went with just a composite/YC capture thing instead and even that comes with a pretty hefty price tag so I guess it's not so simple. And, if you are decoding on the fly and outputting a finished YUV signal you also lose the ability to refine the process and tweak parameters later which is also part of the point of this project.

[lollo]

It's not the same as syncing audio to already decoded video that virtualdub does, one would need to be able to reliably decode the video faster than realtime to be able to do something like that which we are not anywhere close to at the moment.

Yes, that's the difficult part I assume. I wonder how you'll be able to solve the problem (video in its raw format to be synched with audio, no clean common reference available). I'll follow the vhs-decode channels about this topic with lot of interest!

[dellsam34]

You well summarized the case where capturing with separated audio and video was causing troubles 20 years ago, and VirtualDub tried to solve them across its many releases and its side activities like VirtualDub-Sync.
(BTW VirtualDub today still has problems with audio/video synch even with modern cards featuring integrated audio/video ICs and with modern OSs).

This is why I think this task should be done away from the computer CPU, If you look at devices that convert and process analog video to digital with embedded audio outside the computer CPU such as a analog to SDI converter or a firewire capture device (lossy or lossless) you'll find that they don't have audio sync problems.

@OLN, I'm not saying you guys are doing this intentionally or you are lazy, What I'm saying is see if you can expand the hardware side to include more tasks by using FPGA route instead of computer CPU, After all the concept of capturing RF in a box has already been started by SingMai, so I know it is not impossible.

[nicholasserra]

What's best path for support on the hardware side? Trying to get my first capture going. I have a duplicator. But i'm running windows 7 on my transfer machines. Is Windows 10 a requirement? Duplicator shows up with missing drivers and the windows GUI program for capture crashes immediately with an error. I don't see any open issues on the duplicator repo (fork) and I don't see any common debug FAQ for the GUI app either.

A little lost in docs at the moment. Thanks!

[oln]

I wouldn't expect the application builds to run as is on windows 7 as they are built with an up to date version of visual studio with default settings. Technically I think all the dependencies it's using (qt5 and libusb) still support it so it may be possible to make the ddd app work on win7 with the right build settings but don't think anyone's tested or looked into it or if libusb setup works the same way on win7.

[nicholasserra]

Thanks! Sounds like i'll need to switch to my Windows 10 PC or my Mac to keep moving forward.

[i4004]

[QUOTE=lollo;2731825]

(BTW VirtualDub today still has problems with audio/video synch even with modern cards featuring integrated audio/video ICs and with modern OSs).

never really had such issues, with cheap bt8x8 and philips saa713x capture cards....

except when i'm making trouble for resampler by capturing vhs with many "quasi-cuts", ie panasonic vcr recordings where you have white noise between recordings (video segment<->0.5sec noise<->video segment<->0.5sec noise etc.)
but in that case i don't need sync anyway, because that content was not recorded for the sake of sound....

on continuous recordings there's no issue.
but if i turn off resync in vdub i can clearly see it drift....

dellsam34, that mechanism looks like my nv-hv60 vcr, and that's a lost cause....better to have that board near something with discrete rf preamp and decent video-heads....

oln, a slight misunderstanding, perhaps: while speaking of "finding headswitching in rf file" i was mostly trying to say you probably can't do it on-the-fly.
ie do this

We actually have two options:
One is with the clock gen which does not only capture dual channel audio from the PCM1802, but also the "head switch" signal on a 3rd channel.
And the head switch on VHS (and other formats) happens to be exactly in sync with the video fields (because one sweep across the tape for one head is exactly one field).
As all streams (RF video, RF audio, PCM1802, head switch) are in sync with each other we now know when fields start and end.
The other option is from the tbc.json which will actually record the field start offset from the RF capture.
And again because all stream are in sync this also tells us when fields start and end.

(the bolded option)
from
https://gitlab.com/wolfre/vhs-decode-auto-audio-align

i was writing that before prior knowledge of how you actually do it, but good to see i'm along right lines, because there are really no 100 ways to achieve sync.
that's what i ment when i said

(which you can derive from the number of full lines you've captured, you don't need headswitching signal to do that...then again, you probably can't do that, as you're choking on too much data as processing speeds suggest)

you indeed are deriving framerate or better to say field-rate based by counting lines of video...when you don't have headswitching info, that is.

audio was afterthought in a sense everything is derived from laserdisc ripping (domesday), where everything is read by one laser, not more than one magnetic head like in vhs. domesday duplicator is clear example of such hardware. no audio inputs.

I feel you are talking as if we're intentionally making it complicated - it's just a community project with limited resources so the software and hardware still needs a lot of work yet.

in a sense, yes you are making it look even more complicated than it needs to be, for example:
https://github.com/oyvindln/vhs-decode/wiki/Diagram-Visuals

while in reality you could make separate hardware and software block diagrams and make it 10x easier to grasp. first one needs to solve hardware, software comes later and it's easier to do because one can take it in small steps.
but without hardware you don't have files to work on.

esp. this one
https://raw.githubusercontent.com/wiki/oyvindln/vhs-decode/assets/images/graphics/VHS-...ow-16-by-9.png
where one can't actually see audio (hardware) recording path. what's the device that's recording linear audio there? it's not listed.
the audio recording portion there is actually the 4 board solution from here:
https://github.com/oyvindln/vhs-decode/wiki/assets/images/Hardware/External-Clock-CX-C...sma-marked.jpg
four.
pcbs.
come on.

when it comes to misrc, he should just assign that 2nd rf channel (ie 2nd ADC) to capture linear audio if there's no hifi audio on tape.....and then do above mentioned auto-align.

he never mentions linear audio:

Possible capture examples:

Capture 2x CVBS
Capture 1x S-Video (Y & C)
Capture Video RF and HiFi RF simultaneously
Capture Video RF and CVBS simultaneously

https://github.com/Stefan-Olt/MISRC/

so it's an afterthought.

on the bright side, you seem to have video quality on your side. this is very important detail.
you deserve some commendation for that even if you never do anything else.

dellsam;

This is why I think this task should be done away from the computer CPU, If you look at devices that convert and process analog video to digital with embedded audio outside the computer CPU such as a analog to SDI converter or a firewire capture device (lossy or lossless) you'll find that they don't have audio sync problems.

well, not really:
https://forum.grassvalley.com/forum/converters/advc/36528-advc-300-audio-sync-problem

the very same issue i describe in the begiining of this post.

[dellsam34]

That's when not using locked audio during transfer, This is DV related, not port related, it offers the option to transfer audio de-clocked from the video stream, I forgot what was the intention behind that, I've owned few firewire device in the past and I never had audio sync issue whether capturing from analog sources or D8/DV tapes.

[lollo]

I confirm on my side. Never had audio/video synch problem when capturing analog tapes with old ADVC100