Video8 restoration advice

[kerryann]

FMP437, sorry for the waste of time I had to put an end to ; and as such I will now look at your videos tomorrow.

Yet it seems Jagabo has witnessed some clues . As for my words "keep it simple" , well (from memory while writing) your script
adresses chroma in some way almost in 4 or... 5 occasions .If so there should be a very meaningful reason for it

[jagabo]

Well this is really weird, I thought I forgot to make an explicit assumption in the first script that the file was BFF, and it assumed TFF. But having done so and also assuming BFF in the second script after deshaker is the background that becomes jerky. I have to assume TFF in the second script to have a smooth background movement but the man remains with a jerky movement.

Analog video is just an alternating sequence of top and bottom fields. It's only when those fields are woven together into digital frames that the frames take on a field order. It's the capture device that determines the field order. If the device starts with a bottom field, then adds the next (top) field to complete the frame you have BFF frames. If the device starts with a top field then adds the next (bottom) field to complete the frame you have TFF frames. DV devices always capture BFF. Other devices may be TFF or BFF depending on the device and/or drivers.

[FLP437]

@ kerryann
Thanks, I have not forgot your request even if I think that at least with this particular camcorder the results would be marginal better with DNR=off but I like to hear all versions of a situation. However give me 2 days or so as I have to finish a professional work and to capture takes a little more time than to write these lines. I will probably do it again with dnr=off and on as I have a better shielded and shorter cable that I can use ( even if I think it will not make any difference as it´s a digital signal ) but just in case and also due to weird problem discovered by jagabo that I think is from something I have in the script that inverts field order or some other strange situation script related.

I think my 26 years old Sony CCD-F500E was not a prosumer camcorder it was more likely a midrange see service manual

[johnmeyer]

I no longer have any idea where you are coming from, and why you insist on being so insulting to me. Why are you doing this??? No one is making you write these posts. You can choose to ignore me or, if you want to address my posts directly, you could choose to challenge my ideas politely. You have done neither.

I really am trying to be helpful to the OP, and I think I have been.

you always ridiculously "twist" other people messages

Always?? I went back and re-read my previous post several times and cannot find any place where I twisted your meaning to make it sound like you were saying something else.

If I did it inadvertently, I apologize.

However, I did not do it repeatedly, and certainly not "always."

To the main point about whether better results will be obtained with the hardware noise reduction enabled, perhaps there is a language issue causing confusion as to what each of us means by "video noise." Your more recent posts have been focusing on chroma noise, whereas your earlier posts in this thread -- and all of my posts -- have been mostly talking about how to reduce the small noise dots that look like film grain. Thus, when I said that a comb filter was not going to provide any "noise reduction," I was talking about that type of noise.

More importantly, this type of noise is what the OP was asking about in post #1. He listed seven issues with which he wanted to get some help, and the very first one was:

"Noise- in general , grain in low light conditions"

In that first post, he did not mention chroma noise, nor did he describe anything that sounded like dot crawl. So, I have simply been trying to answer his questions, as he himself asked them.

you quite 'brillantly' copy/paste very very basic things

I wrote every word myself. Nothing was copied from someone else.

As for my post being basic, if that is true, what is wrong with that? Advice given at a basic level is, I think, what is needed here.

I plead guilty to giving basic advice. That is actually a compliment.

let me friendly give you one old and simple link ( in English) related to this matter of *comb filter* applied to separation between luma and chroma

There is nothing particularly friendly about your tone. Yes, I was sloppy and could have worded better my one-sentence description of a comb filter. You are correct: the luma signal is not a subcarrier. Instead, the chroma is a subcarrier, in exactly the same way that the second channel in an FM radio broadcast is carried on a subcarrier channel.

But, what difference does it make to the OP, or to this discussion?? It seems to me that you went to considerable effort to be nasty, when a much more polite reply would be to simply say, "I think, perhaps, you meant to say that chroma is a subcarrier, multiplexed on the luma carrier." I would have thanked you for the correction, and that would be it.

And in the end you admit ....not having experience with a D8 ! nore D8 transcode !! which does not stop you from advising to by-pass its CNR since "it will ruin the video"

Yes, I "admit" that I do not own a Digital 8 deck (touché). More to the point, I do not own his deck. I am therefore still allowing for the possibility that he may get a better capture with noise reduction turned on. All I have ever tried to do in this thread is to suggest that he compare his capture with, and without, this circuit enabled, and decide for himself which is better.

I also wanted to make sure he studied the result to look for degradation caused by the noise reduction. This is why I kept posting that he should try capturing with it turned off.

Why do I think this is important?

Well, one issue that hasn't been brought up in this thread, but which I try to constantly remind people about, is that we all often look at the results of noise reduction (however you define that), and because the noise is reduced or eliminated, we initially feel good, and think we have produced a result that is better than the original. But, while admiring the lack of noise, we may not notice that the details in the girl's hair are gone, or the texture on the sweater has been reduced.

"Less is more" is a quote that I use all the time when helping people with restoration work. Noise reduction should be subtle, and the artifacts it creates should be minimal to non-existent. Better to leave some noise than to lose details.

you almost 'stupidly' also come hard on "stone age" analog video technology. Why not ? but not from you now ! I am no name droper as you seem to be but regarding analog technology I once (almost 30 years ago) attended a private demonstration of analog TVHD known as D2 MAC and you know what ...it was brilliant tech which came too late indeed .

Calling me "stupid" is abusive, and a violation of forum etiquette and rules. And, I have absolutely no idea what "name dropping" you are referring to. Again, perhaps this is a language translation issue.

As for your specific point that analog technology is great stuff, my electrical engineering training was entirely analog. I therefore have a tremendous appreciation for analog circuitry and still design more analog than digital circuits. However, when it comes to single-ended noise reduction of all types, digital technology runs circles around even the most brilliant analog technologies. As one example, the CEDAR analog noise reduction system for vinyl records was brilliant in its day, but even the free Audacity software blows it out of the water, and iZotope RX does things that analog technology could never possibly do.

In the video realm, all of us were in awe of the original Faroudja line doubler when it was introduced a quarter century ago. However, pretty much any competent AVISynth script will produce better results.

There are very few examples where analog signal processing is superior to digital.

Having said that, there are a few situations where built-in analog circuitry can achieve better results, but only because those circuits have access to signal information that is not present in the digitized video. The time base corrector is the best example of this because all the frame and scan line timing information is stripped when the video is transformed from a raster into pixels, so any horizontal timing offsets from degraded sync signals cannot be corrected in the digital realm with the near perfection that is possible with a TBC circuit that can access, process, and regenerate those degraded signals.

[kerryann]

However I think kerryann is more interested in the raw files perhaps no need to recapture again or try to find what is causing this situation.

@kerryann
Related to my capture workflow I saw some month ago some minor references to this method on digitalfaq forum, after I found a german forum where this type of workflow was being discussed in detail
http://forum.gleitz.info/showthread.php?46713-Zeitgem%E4%DFes-hochwertiges-analoges-Ca...er-HDMI/page55

>>more interested in the raw files

no, not more interested ; well in the first time yes , since I follow your thread with the 'fear" I would have to redo all to gain some possible very minor improvement ; time capture + time for DEINTERLACE , yes DEINTERLACE via qtgmc , so some 300 hours reworking only capture phase

(maybe one day the 'opponent' will understand where DV field motion prediction and QTGMC field interploation 'meet' almost perfectly... )

As started earlier , my first 'guess' was some capture card + lossless yuv . But I was almost 'hard pressed 'with some valuable points (and from trustful guys) to 'keep it simple' . I was yet ready to look for some EV1000b and have it fully reconditionned, transport/drum realigned, etc... but so far only this would yet cost the moon ! So there had to be an obvious bonus quality in the end . Especially if you add the cost for a recent era TBC for impredictable true added improvement ! And as some of these folks had done and payed for that , why would they minimize the benefit for such overcost work flow ...they payed for !

having reviewed the huge number of cards you tested , it is quite impressive of your real involvement that strikes my interest as well

BTW I still have two Osprey 200 Series and it is quite surprising they were the only ones to achieve no lost frames . They are quite very simple devices ! I keep them from the early streaming mad venture period late 90's

So I do take interest in all your trials and results as for capture but not only.

The restore point is the second interesting point. While I doubt of a AOI 'one size fits all' script ...or it will have to stick to some aspects only.

As for over brightness compensation , I will come back to you on this latter , but I don't have a 'one' solution via Avisynth . Either via Premiere or more adequately via AE and scene by scene ... I tried it with good results but I would like to work it over. Well basically it quite simply comes from PS practice , ( I grabbed from others) , no big mystery then.

ps: while I was rather good at German In Gymnasium , still...life is too short to study German ( that's a proverb ! not my quote)

[johnmeyer]

I will probably do it again with dnr=off

Given the kerfuffle between kerryann and me over this issue, I would love to see two captures of the identical section of tape, one with dnr=on, and one with dnr=off. Let that be the only difference. While I have state several times that I think dnr=on will produce a result with fewer details, I would love to be proven wrong, and will have learned something.

[kerryann]

@John

I did not read entirely your post , I just stopped where you say you apologize .

I do as well then . And let's avoid us in the near future at least . I am also quite a very forgiving folk so no problem for the future as well .

Sincerely yours

[johnmeyer]

@John

I did not read entirely your post , I just stopped where you say you apologize .

I do as well then . And let's avoid us in the near future at least . I am also quite a very forgiving folk so no problem for the future as well .

Sincerely yours

I agree.

Done.

[FLP437]

@jagabo
I think I have found the problem it lies in deshaking settings itself as I have to identify if it´s TFF or BFF and I forgot to change it to DV that is BFF. I´m almost sure this must be the problem however it´s impressive how all other things have been corrected only the man movement remained to identify the problem

[johnmeyer]

@jagabo
I think I have found the problem it lies in deshaking settings itself as I have to identify if it´s TFF or BFF and I forgot to change it to DV that is BTT. I´m almost sure this must be the problem however it´s impressive how all other things have been corrected only the man movement remained to identify the problem

PAL DV is BFF, as you say. However, I recommend, just to be safe, that you capture a few seconds of video, and then feed that into this AVISynth script:

AssumeBFF()
Separatefields()

Walk through the video, frame-by-frame, and make sure that the motion does not stutter back and forth. If it does, then the capture is TFF.

The reason I mention this is that you have described several different capture workflows, and have used different codecs. PAL has always been just a little flaky with field order because uncompressed PAL is TFF, not BFF. Certain PAL formats like the PAL D1, are also TFF.

I'm 99% certain that this step is unnecessary, and that your capture will be BFF, but it never hurts to check. I've gotten burned so many times by incorrect field order that I always perform this check.

[FLP437]

Thanks for the tip.

However in this specific case I just confirmed that the captured DV was BFF and that the problem detected by jagabo was indeed in the field order settings in deshaking . Problem solved.

However now that I have used again a dv file the sound ( not the video ) appears to be better that the one I got from svideo / analog audio captures , it could be only that it´s recorded at a higher level and seems to sound better. If really it´s better , I have to see how to confirm this , I could demux and remux with the video captured from svideo ( however the number of frames captured in different captures are not always exactly the same and this could generate a desynchronization ). Something to think about in the coming days.

I forgot to say that I use cedocida DV codec I think it works better then the standard dv codec ( microsoft ? ) I tried also to capture, to see eventual differences with the mainconcept reference capture utility tool ( it uses the mainconcept dv codec ) but even if the main application is working correctly the capture utility tools gives an error on microsoft visual c++ redistributable library . I tried to unistall and reinstall almost all the versions of visual c++ but it continues to give the same error , so I gave up.

[johnmeyer]

Yes, louder often sounds better, as long as the S/N isn't too bad.

To really know which is better, take the quieter capture and use the volume control in a DAW to bring it up to the same level as the other capture. Then, sync them up in your NLE and A/B back and forth while playing. Listen for background noise, hum and, most of all distortion.

Even this may not entirely give you a final result. One problem with the audio portion of an analog capture chain is that your hardware may be applying AGC to the audio. If one capture chain does this, but the other does not, it will make comparison a lot more difficult. The "professional" thing to do when capturing is to turn off AGC. However, when capturing a lot of video where the audio is all over the place, you might find that AGC provides some utility by letting you go do something else while the tape captures, while the hardware adjusts the levels so you maintain some consistency.

[jagabo]

However now that I have used again a dv file the sound ( not the video ) appears to be better that the one I got from svideo / analog audio captures , it could be only that it´s recorded at a higher level and seems to sound better.

Capture from a high quality audio source like a good CD including some silent portions. Then compare the DV and raw captures after normalizing the volume levels. Also use a spectrum analyzer to compare the original and the two recordings. The actual audio on your old tapes probably won't be as the CD but this test should give you an idea of the inherent quality of the two methods -- ie noise levels, high frequency roll-off, etc.

[Brad]

my main very first concern was indeed that DV compression @25Mbps could bring some minor but yet visible issues @5:1
...
So it is what I was interested to look for having made the final bet ( for my own captures) it would not improve other than stay simple straight D8 transcode even as DV compression . In the past I did advocate the opposite option , that 'at first glance' I would be keen to think DV transcode would "fail" versus more sophisticated procedure .

https://forum.videohelp.com/threads/360804-DV-vs-lossless-capture-of-VHS?p=2394218&view...=1#post2394218 (thread title is VHS, but the sample was FLP437's Video8)
https://forum.videohelp.com/threads/376837-DV-conversion-vs-lossless-capture-comparison...uto-load%21%5D

To avoid more OT, please respond in one of those threads if they spark your interest.

[kerryann]

The thread is actually a mixed bag of issues , some being related to the capture procedure itself with almost a need for'first-aid' restore points to conteract what happened at that time and soon after . As such it is more complex than a plain question about some nice performing filter . Avoiding here what DOES STILL belong to capture issues in the first place would be an error imho.

For instance since I early stayed focused on DV vs lossless capture alone I did not look at all 'restore' other files since otherwise doing so it was -immediatly- obvious ( in VDub as usual) that frame jerkiness was present ; to start with !

now in a rush...While I still have all these screen captures in mind, here is what "corresponds" to what :


01__DV_raw_vs_QTGMC_huffy_FLP437

it is the recent plain vanilla D8 straight export as DV (and not to forget...CNR=off) which faces on its right the very same sequence , so again regular 25fps interlaced , as captured via the Panasonic setup and then saved as 'lossless' Huffyuv





01b__DV_raw_vs_QTGMC_huffy_Kerryann

it is the recent plain vanilla D8 export as DV (and not to forget...CNR=off ) which faces on its right a 'matching' QTGMC deinterlaced version exported as Huffyuv





02__D8_DV_restore_New__vs__QTGMC_huffy_Kerryann

there it now comes to oppose a recent 'restored_new' QTGMC version provided by FLP437 to the above (01b) simple QTGMC export as Huffy I made , no filter, nothing





03__D8_restore_last__vs__QTGMC_huffy_Kerryann

there it comes again to oppose recent 'restored_last' QTGMC versions provided by FLP437 to the always same above (01b) simple QTGMC export as Huffy , no filter, nothing





04__DV_raw_Huffy_vs_QTGMC_raw_Cineform

As anecdotical as it maybe here is some confrontation of the always very same (01b) Huffy version to a 'visually lossless' Cineform (wavelet) version which is almost half the file size vs Huffy ; it will keep this 'visually lossless' characteristic even after quite a few generations ( preset here is 'Film Scan 1 " and 4:2:2 10bit since it is yet almost overkill there was no reason to select 4:4:4 12bit ) and being very very low cpu hungry you can scroll in realtime a multi layer timeline and keep fluid motion





having made the introduction , let's comment :

in the interlaced footage I looked for the few frames that would keep the best possible vertical resolution since " blabla , you know" ; and first of all since it is much more simple to compare clean pictures indeed !! there are a few and frame 33 is a good first candidate . And so it was ...


01)

Both files are FLP437's from above links.

There is some trouble here : frame n°33 is almost nearly clean full V res as DV (right) while it remains scrambled interlace as the Panasonic version (left) ! There are almost half a dozen nearly "clean" frames as DV and only one as Panasonic Huffy . As for other issues on this frame , one is chroma (stairs, fence,..)

so far for the interlaced step.


01b)

I made a simple regular QTGMC deinterlaced 50fps file saved as Huffyuv. And I looked for frame 33 again. So here on the left a' DV source' frame almost full V static and on the right the matching QTGMC frame (66) . I do not notice any loss in vertical resolution (..) while it is a case where DIDEE comments as not that simple due to the loss of 50% amplitude at the time of QTGMC process

ihmo QTGMC succeeds here brilliantly with no chroma issue at all , all details remain as well while they almost look even more natural like acquired through some less sharpen-harsh , not to mention the welcome cure of some halos (fence) , etc...well success overall : KUDOS to DIDEE and ViT .


02 and 03)

it now comes to witness what happens actually as the 'restore' process files ; so 02 and 03 is a confrontation of the above simple QTGMC deinterlace ( no other filtering of any kind) versus "restore_New" and "restore_last" movie versions

it is quite "severe" imho and I do feel sorry for FLP437 considering all his hard work and long time commitment. While I also feel in the same boat as him as for this 'video8 restore' query.


04)

it is simply for those who would like to compare Cineform vs Huffyuv ; it is free now but there may be some confusion among versions (freely) available . Here it was 9.0.5 and it does face Huffyuv fearlessly .

ps : you gave me a lot of work , FLP437 , mostly writing in vernacular web english , I better write in Latin or Esperanto

[kerryann]

@FLP437

to precise things a bit further ...no misunderstanding here : as said before I find inner pictures quality pretty neat for vintage video8 . The lighting conditions are very good , the mid-shot option is quite favorable for shooting with Video8 , etc..

Considering the obvious overall important jerkiness I find the AGC does its job pretty well, since on one or two occasions when the camera is ,say, 'wandering' up/down there is enough bright sky part to put these vintage cam in trouble with instant brightness fluctuation. For instance the Canon VM-E2 would be quite easily affected by this .( I had to wait to lay my hand on a BetaSP to be able to shoot in adverse backlight condtions with no fear ; even the quite superb prosumer Canon XL1 would be put in trouble too easily as well)

So it remains to try and succeed in the best output possible here ...

[FLP437]

Sorry for the long absence but I got completely overwhelmed by my job work and needed to recover some project delay´s, so I had no other alternative then to stop playing with my videos as this “hobby” can take really a lot of time.

I will try to resume. One month ago I was interested to try a magewell card that I bought about 3 months ago and see if for VHS and Video8 it could do any difference and yes it seems it does.

I tried to capture with the same “complex” workflow that I have been using ( cam/deck ->svideo->Pana DVD rec->hdmi-> startech -> Pc (usb)-> Vdub) and exchanged only the startech with the magewell , the difference was minimal but eventually still visible, however both were doing hdmi captures so I was expecting identical results , but eventually a better hardware and or driver , pcie2 vs usb3 and one less usb3 cable and less interfaces perhaps resulted in the minimal difference identified.

However when I tried a direct capture CAM -> Magewell card via svideo I found that I got a more visible image improvement. I used also the MSU video quality measurement tool and the results were consistent with what I seemed to have visually detected, less blur , less noise better in general quality metrics. Also the audio is better it seems to have a better S/N .

The interesting part is the magewell card seems to be foolproof in what drop and inserted frames are concerned. I have not done a lot of captures for now only 2 full video8 k7 and one VHS but no drop or inserted frames at all and these always happened with all the other cards I tried ( and I tried a lot of them , only the osprey didn´t drop or inserted to much all the other dropped or inserted frames significantly). It seems that the “Advanced time-base correction (TBC) with frame synchronization and 256 MB on board memory “ included in the ADV7842 chipset in the card are usefull. I will restrain about more detailed information about the capture and magewell card as this is a restoration thread I will give eventually more detail related to the capture and card itself on a capture thread.

I tried also a new capture with the video8 deck using svideo and the magewell card , I used also the MSU video quality measurement tool to compare against the capture made with the camcorder / magewell and the results were mixed some better some worst . In general more blur and less noise . The deshake resulted better over this capture. Applying my script gives a more clean image but with less detail I think I still continue to prefer the captures made using the video8 camcorder mainly due to the extra detail it provides .

Related to denoizers to use within the script I tried the ones with QTGMC ( EZdenoize and DFTTest ) and MCTD and Neat Video. All of them work well, however I think I got the best results from MCTD and Neat video ( even with 2 additional color space conversions). The MCTD seems to provide results slightly more crispy and the neat video a more clean result but both are very similar . However even with the very slow settings I have used in QTGMC and with Neat Video I get a general script speed of about 9-10 fps vs less then 1 fps with MCTD ( no MT avisynth ) so I probably will stick with neat video. Also neat video is not yet 100% optimized if I can find a better frame to do a better noise profile and test some preset´s I will probably get from the Neat Video the best results from them all.

neat video additional code

LoadVirtualDubPlugin("C:\Program Files\VirtualDub 1.9.11\plugins\NeatVideo4.vdf", "NeatVideo4", 3)
ConvertToRGB32()
NeatVideo4("C:\...........\Neat Video v4 for VirtualDub\Profiles\video8.dnp", "C:\..............\Neat Video v4 for VirtualDub\Presets\video8.nfp")
ConvertToYV12()

I have also tried the SSSharp instead of UnsharpHQ but the results seem clear better with UnsharpHQ

1 - Cam_svideo_magewell_raw - Raw camcorder svideo magewell capture
2 - Cam_svideo_magewell_restored - Restored version 1 ( script with MCTD )
3 - Cam_svideo_magewell_restored2 - Restored version 2 ( script with neat video )
4 - Deck_svideo_magewell_restored - Restored deck svideo magewell ( script with neat video)
Files have been converted from UTVideo to Huffyuv to ease preview

[Brad]

exchanged only the startech with the magewell , the difference was minimal but eventually still visible, however both were doing hdmi captures so I was expecting identical results , but eventually a better hardware and or driver , pcie2 vs usb3 and one less usb3 cable and less interfaces perhaps resulted in the minimal difference identified.

I mentioned before how the USB3HDCAP doesn't accurately capture HDMI, at least for 480i: https://forum.videohelp.com/threads/376473-Lossless-HDMI-capture-devices-comparison-screenshots

The interesting part is the magewell card seems to be foolproof in what drop and inserted frames are concerned. ... It seems that the “Advanced time-base correction (TBC) with frame synchronization and 256 MB on board memory “ included in the ADV7842 chipset in the card are usefull. I will restrain about more detailed information about the capture and magewell card as this is a restoration thread I will give eventually more detail related to the capture and card itself on a capture thread.

Where'd you pull the chip info from? 256 MB (megabytes) would be an insane amount to use with a video processing chip. The ADV7842 data sheet mentions that 128 Mb (megabits) is the minimum requirement to provide 3D comb + frame sync at the same time.

Comparing D8_raw.avi to Cam_svideo_magewell_raw.avi, the Magewell shifts the image up and masks the top with black. I don't see the improvement you have indicated.

Still, if the TBC is at least as good as the ADV7840 in my Denon AVR, the card could be useful for some. I anxiously await your separate thread.

[Leo E. Backman]

Audio- I am thinking to demux and use iZotope RX for audio cleaning using included modules like Declip, Declick, Decrackle, Hum Remove, Denoise (Spectral, Dialogue),Leveler,… ).

Hello,

I think we've been in contact before.

I am using the RX 5 for most of my audio rest. work. The RX 4/5 include some truly revolutionary tools for filtering any type of constant or occasional background noise. Most things can now be done visually (via graphic interface), almost without having to listen to the sound at all. If you care to post a sample of your original audio, I can process it and give some suggestions about the RX tools and capabilities with video soundtracks.

Best Regards,

LeoB

[FLP437]

HI Leo,

I think we've been in contact before.

Yes you are right you have helped me to recover some very problematic video8 cassettes.

The audio soundtracks from my VHS, Video8, MiniDV videos are not spectacular but most of them are also not that bad considering the technologies involved, however they could benefit at least from some background noise filtering and sometimes some voice boosting to make voice easier to be understood , other problems can also be addressed but for me these are the first ones to solve.

I already tried with RX4 and got some improvements, on page 2 post #33 I have posted a small example where I tried to clean hum and applied a spacial denoiser, but much better results can certainly be obtained. However I´m not a sound expert and also I don’t fully master RX so all advice's are welcomed.

As you can see I have stopped to contribute to this thread for more than a month as in recent times I have had a lot of work to do and little time to “play” with my tapes but I´m still interested to improve capture workflow and restoring approaches if I still can get any additional improvements and I will try to resume as soon as I will have again enough free time.

I have also pending a workflow test with a magewell card which vaporeon800 was also interested but as this takes a little more time I have not been able to do it so far but it´s in my agenda .

To post a new video soundtrack sample is easier and fast so I´m including them, however to try after your advice's ( I hope you can provide them ) will take perhaps some more time due to my lack of free time. However I am very much interested to get your advice's and I will try them after as soon as I can.As I don´t know if you want a soundtrack with any specific characteristics I´m for now posting standard one´s demuxed from captures already made.

I´m posting two samples of a video8 soundtrack both from the same cassette but from different footage zones ,captured using two different workflows
1- cancorder -svideo-panasonic dvd-hdmi-magewell
2- video8/hi8 deck-svideo-magewell

[johnmeyer]

You didn't say what sort of problem you are hearing in those two clips. Nothing jumps out at me: no hum; no buzz; no cell phone going off in the middle of a wedding; etc. The frequency response seems pretty decent for a camcorder.

I too do lots of work with iZotope and know what sort of things can be done, but there is nothing in those audio clips that screams out (at least to me): "fix me!" Instead, the audio seems pretty decent.

[FLP437]

As I have said

“audio soundtracks from my VHS, Video8, MiniDV videos are not spectacular but most of them are also not that bad considering the technologies involved”

So I don´t really have very specific or very problematic audio problems to try to solve or restore, however in my opinion I still think there is some residual hum and cleaning it seems to improve the audio a little , also I believe that boosting voice and or front end events related to environment noise can also improve the quality perception. Some tests I have done in this context seem to provide small benefits but could just be a matter of personal taste .

Specific audio problems I do have with super8 videos with audio tracks that are about 45 years old , but these are another story.

Related to the type of samples I provided I also think they are relatively normal and the only objective is to improve them in general, a little if possible . I think I have already done some minor improvements with hum filtering and for instance a spatial denoiser and some type of voice boosting, so I don’t real have here a problem .However as I am not an audio expert and also I don’t master iZotope RX at 100% I´m always open to hear advice's from others than know more than I do and even more if they are offering to do so.

[FLP437]

If anyone is interested in tests and data related with the Magewell card that I referred in post 107 please go to captures section, thread “Conventional analog capture workflow vs alternative methods - comparison” I will put there the data related to the Magewell.
I still intend when I have enough time to resume my restorations ideas but for now I will be “ on Hold” for some more time .

[FLP437]

Back in business,

I´m satisfied with the Magewell Pro HDMI card bought some time ago, as I have been able to get better results from most of my video8 and VHS tapes with this capture card ( with 12 bit ADC ,full frame synchronizer and 256 Mb in board memory, besides other interesting characteristic’s ) so I’m recapturing again part of my tape stock, however for some tapes the previous workflow using the Panasonics DVD recorder as ADC / TBC provides similar or even marginally better results and half a dozen old tapes with terrible jitter problems seems to give best results with a workflow based on a DVD/VCR combo with RGB output to the Panasonics and from there via hdmi to the Magewell card (however in this case I have a problem whit super whites clipping).

Related with restoration and with the advice given by johnmeyer on post 2 related to videotape workflow I'm likely to withhold with his advice with some minor personal adjustments .
However I still have some doubts about how to address some processes namely to and from Premiere

1. Capture, im my case direct capture via s-video to a Magewell HDMI pro card or through svideo to a Panasonic Dmr-Eh65e and via hdmi to the Magewell card
2. Put video in the NLE in my case Premiere Pro cs6 to cut bad stuff and to do color correction and exposure adjustment.
3. Send audio segments that need restoration in my case to Izotope for correction and subsequent reinsertion.
4. Stabilize using Deshaker.
5. Frame serve from Premiere to VirtualDub/avisynth restoration script
6. Final Format X264 / X265
7. For DVD output frame serve to for instance TMPGenc/ Mainconcept for MPEG2 encode to DVD ( restoration script without deinterlacing)
8. DVD authoring using in my case Sony DVD Architect

doubts/questions

2 - I think, but I am not sure, that if I only cut bad stuff and use only YUV filters/plug-in´s that Premiere will work natively in YUV2 and I will be able to avoid color space conversions and I can simply save the final result to YUV2 lossless or frame serve ( if I can get a frame server from premiere to virtualdub working fine).

4 - Is there a Premiere , virtualdub script to automate this task ( deshake) . If not perhaps I will have to frame serve from Premiere to Virtualdub (Deshaker or avisynth script) using Debug mode frame server or advanced frame server.It seems the first will probably work with CS6 and the seconds perhaps not, it seems to be for cs5.x However I have read good and bad thinks related to these frame servers. Have anyone tested them with CS6 with good and stable results?

5 – generate a lossless intermediate format or frame serve

This process is still not very clear for me

Premiere ( color correction ) -> deshaker ( can be done with a script to virtualdub inside premiere or do I have to frame serve to virtualdub or create an intermediate lossless file)-> apply the restoration script ( frame serving from premiere if I could use a script to automate deshaking between Premiere and VirtualDub or otherwise probably using an intermediate file )

I have been adjusting the previous script discussed for video8 for VHS use so far this is my actual script . It seems to give reasonable results for tapes in medium/ good conditions however it can be probably improved. However For some very old , multiple copy or simply in very bad condition I will have to do something more specifically including using addicional filters like deJitter, DePulse ,DeBarrel, etc.

#SetMemoryMax(1024)  # Multithreading
#SetMTMode(5,4)  # Multithreading
AviSource("E:\New Captures\TEST_12.avi")
loadplugin("C:\Program Files (x86)\AviSynth\plugins\DePanEstimate.dll")
#SetMTMode(2)  # Multithreading
AssumeTFF
Crop(16, 8, -8, -12) 
autolevels(autolevel=true, autogamma=false)
Cnr2("xoo",4,2,64)
ChromaShift(C=-2 ,L=-2) # align chroma over luma 
ConvertToYV12(matrix="PC.601",interlaced=true)
Stabmod()  # only YV12
QTGMC( Preset="Slower", EZDenoise=1.5, NoisePreset="Slow", DenoiseMC=true, SourceMatch=3, Sharpness=0.5, TR2=2, Lossless=2, MatchEnhance=0.75, NoiseProcess=1, NoiseRestore=0.5, Sigma=2.5)
SelectEven()
Stabmod()
santiag(strh=2,strv=2)
MergeChroma(Spline64Resize(width/4, height).aWarpSharp(depth=10).Spline64Resize(width,height))
UnsharpHQ(THRESHOLD=20, SHARPSTR=3.0, SMOOTH=0.5, SHOW=false)
Spline64Resize(720, 576)
#SetMTMode(1) # Multithreading
#GetMTMode(false) > 0 ? distributor() : last  # Multithreading

This code doesn´t include footage deshaking and even if it seems simple it´s relatively heavy doing only about 4 fps in a fast machine .

MT use as been complicated as the settings I used yesterday did not work today ( the values presented are working now) .And it´s difficult to find out what the correct values will be for a given configuration/script .I do have for instance an i7 6700k 4GHz overclocked with 16 GB memory, is there better and more stable settings ( yesterday it worked with SetMTMode(2,14) and SetMemoryMax(2048) as I have read somewhere these were adequate values for 8 logical cpu´s ). Also the difference I found is minimal for a clip like the one included, processing time decreases from 1:09 to 1:04 I don´t know but I think it should be expected a better performance.
related to the filters included in the script I do have problems to select the right values of chromashift is there any trick to ease the task and facilitate identifying the right pixel shift to use?
I thought I would use CCD instead of CNR2 as usual is considered better however as it works over RGB I didn´t used it to avoid an additional color conversion

Edit: I have to confirm but avisynth info () gives the footage as BFF if so I will have to adjust the assume line to BFF

[FLP437]

I forgot the video clips, here they are