VHS Capture via Canon HV40

[lordsmurf]

Also,

Just make sure you get a model that

plays Video8 and VideoHi8 tapes. Not all Digital 8 camcorders do.

Most don't. Some do. There are few options models in total.
Most of those also degrade the V8/Hi8 to DV before output, it doesn't pass unmolested from source to output.

[Traderbam]

Just to confirm - HV40 HDV/DV out via firewire works fine (I used HDV Split for the HDV capture). The HV40 also is detected fine in WinDV when using in A->D mode. DV out doesn't work on the TR7000E using WinDV so I'm assuming the port is broken.

TR7000E does allow me to capture other tape types as well as the Digital8. Don't have access to them right now to tell if they are Video or Hi8, but when hitting play on the camcorder, there is a logo that appears to suggest some sort of playback mode change.

[Alwyn]

Try Scenalyser. I have had success with it when WinDV wouldn't detect any camcorders. My quick-start guide is on my website.

TR7000E does allow me to capture other tape types as well as the Digital8. Don't have access to them right now to tell if they are Video or Hi8, but when hitting play on the camcorder, there is a logo that appears to suggest some sort of playback mode change.

Yes, the logo that pops up indicates the system is changing from D8 to 8/Hi8 playback. The swap should be automatic but it can be forced in the menu.

[lordsmurf]

Are you finding the DV 4:2:0 acceptable here, or too many blocks, too much color loss?

PAL can be a toss-up. Sometimes it's harder to see issues on it. (Again, it's not NTSC, that 4:1:1 loss is often obvious.)

Though TBC can be the wild card, as all DV tends to lock the wrong luma with out TBCs (referring mostly to frame, not line, but both matter).

[Traderbam]

I've tried Scenalyser this morning but no luck so the DV OUT must definitely be broken.

Here are some samples I've uploaded from some amateur footage from some Video8 tapes - this is via the Digital8 TR7000 into the HV40 into PC via firewire. To the untrained eye it looks pretty naff but I'm sure there is a more technical description. Initial thoughts?

https://1drv.ms/f/s!AoYVwYm0qHh9lq5RJiQNC6vn-TB0dQ?e=nL0bdu

[oln]

Most don't. Some do. There are few options models in total.
Most of those also degrade the V8/Hi8 to DV before output, it doesn't pass unmolested from source to output.

Where have you experienced that? Never seen a Sony d8 camcorder do that. Afaik some DV VCRs like the DSR-11 can do that but that's a totally different beast. The output is pretty much identical to the late model Hi8/Video8 only Sonys (though be aware are 2-3 models like the DCR-TRV110 that lack TBC, the TR7000 might actually be one of them, and the TRV480 lacks S-video).

[Alwyn]

To the untrained eye it looks pretty naff but I'm sure there is a more technical description. Initial thoughts?

Yeh, nah, a bit naff.

You would do better either with direct Firewire (ie another D8 camcorder) or S-Video to a digitiser. With another camcorder, you run the risk of getting a lemon, whereas the digitiser would be new and could be used for VHS transfers.

@OLN, I have a TRV110, 130 and 330, all D8. Only the 330 has a TBC. All have S-video out and the 130 doesn't play 8/Hi8. The 7000, by the looks of the manual, doesn't have a TBC either. Lots of traps for the uninitiated!

[lollo]

Here are some samples I've uploaded from some amateur footage from some Video8 tapes

Sample 2 suffers from color loss in frames between 360 and 380 and damaged frames around frame 400.





Try to recapture to check if the problem is on the tape.

[oln]

@OLN[/B], I have a TRV110, 130 and 330, all D8. Only the 330 has a TBC. All have S-video out and the 130 doesn't play 8/Hi8. The 7000, by the looks of the manual, doesn't have a TBC either. Lots of traps for the uninitiated!

Yup! The DCR-TRV1xx models other than the first one (TRV110, which has d8 but no TBC as noted) are digital8 only. The DCR-TRxxxx without the V are models with no flip out LCD. Ofc the analog-only models can also be a bit confusing with some lacking s-video and/or stereo audio as well. Not sure if there are any that are any from the last era that were Hi8 but lacked TBC (older ones up to around 96-97 have no TBC and uses different video chips.)

[Bwaak]

Feel free to contribute: https://en.wikipedia.org/wiki/Digital8#Analog_recordings

[lordsmurf]

Sample 2 suffers from color loss

Nothing this canbe
(a) in the footage, so SOL
(b) due to bad player/camera
(c) due to lack of TBC

All are equal chance here, 33/33/33.

[Traderbam]

Managed to get the lend of a USB Live2 - I don't know if it is a pure coincidence but my Digital8 also seems to have died. Camcorder wasn't powered up when connected to S-video.

Is there a hot-wiring risk with these cards similar to the firewire port challenges?

Not the best start

[Alwyn]

Never heard of S-video frying anything. Things only get fried when people try to jam a 6-pin (ie powered) firewire cable into the socket the wrong way round and then connect a camcorder to the 4-pin end.

My guess is that your trusty 7000E has expired.

[Traderbam]

Up and running again with a different camcorder. Looks to be good captures via S-video out to USB-live with line TBC enabled in the camera. Only several inserted frames at the start of footage as the digital 8 mode swaps to hi8 playback.

I notice a narrow bar down the right hand side of the footage, with red or green hue depending on the scene. Anything I could be misconfiguring in the capture perhaps? I've followed some of the VirtualDub guides on here and digitalFAQ sites.

Other than a visual inspection is there anywhere else I should be verifying the capture success beyond the dropped frame/inserted frame counts, and verifying the codec info in something like VLC?

https://forum.videohelp.com/attachment.php?attachmentid=71752&stc=1&d=1686932320

[lollo]

Looks to be good captures via S-video out to USB-live with line TBC enabled in the camera.

Excellent! Post a small portion of your capture, we can investigate more about your workflow.

Only several inserted frames at the start of footage as the digital 8 mode swaps to hi8 playback.

That's probably expected.

I notice a narrow bar down the right hand side of the footage, with red or green hue depending on the scene. Anything I could be misconfiguring in the capture perhaps?

I do not think so. I found stange it only affects the orange machine but not the background. Eventually, you can mask/crop that portion in post-processing.

Other than a visual inspection is there anywhere else I should be verifying the capture success beyond the dropped frame/inserted frame counts, and verifying the codec info in something like VLC?

Run the basic AviSynth check, i.e. fields architecture check, histogram, levels, etc. If you capture with AmarecTV, remember to enable the writing of the log file, which will tell you some details about the capturing process.

[oln]

You can manually select Hi8/analog mode on the camcorder to avoid it having to detect every time you put in a tape. The colors being wrong at the rightmost few lines of the image is normal (a known design flaw) for the newer PAL Sony 8mm camcorders.

[Traderbam]

Thanks lollo, look for the file "Edinburgh" in this directory - https://1drv.ms/f/s!AoYVwYm0qHh9lq5RJiQNC6vn-TB0dQ?e=nL0bdu

Good to know oln, everything looks fine on the viewfinder during playback but consistently noticing this on all captured tapes so far. Will crop it out later.

Keen to understand how this looks and if I should be looking at any tweaks via the Levels settings in VirtualDub. Everything in the video settings for "capture filters" that refer to the Hauppage card are not editable so assume the Levels control is the way to change the proc amp settings.

Another thing I need to work out is can I cut these huffyuv avis with lossless cut (Github solution), and can I fire this format into Staxrip for a QTGMC deinterlace. I used Staxrip previously for deinterlacing to a ProRes output file which I could then import into Resolve for editing. I don't think Resolve will like a huffyuv avi as an import source but will test.

[lollo]

This is an excellent capture.

The picture is clean, detailed and sharp. TTF interlaced fields architecure. The levels do not show evident crush of the blacks nor clipping of the whites You may need to reduce the range to 16-235 for processing involving RGB conversion, or at the end of the processing.


There is some accumulation of the whites at the beginning (clear sky in the background), probably normal because the shot.


If in other captures you experiment crush/clipping, tune the input levels with the procamp of the USB-Live 2. There are several topics in the forum about it.

For restoration a simple QTGCM, light denoise and very light sharpening is maybe just enough

[Alwyn]

Keen to understand how this looks and if I should be looking at any tweaks via the Levels settings in VirtualDub. Everything in the video settings for "capture filters" that refer to the Hauppage card are not editable so assume the Levels control is the way to change the proc amp settings.

Aha! Do I have something for you. Take control, in real time, of your levels! This uses the Virtual Dub Histogram and a program called Graphstudio.

I have a guide for using it on my website. Also there is a guide on using the Histogram in Virtual Dub to set the brightness and contrast.

I use it them set up my capture levels, even when I'm using AmarecTV.

[Traderbam]

This is an excellent capture.

The picture is clean, detailed and sharp. TTF interlaced fields architecure. The levels do not show evident crush of the blacks nor clipping of the whites You may need to reduce the range to 16-235 for processing involving RGB conversion, or at the end of the processing.

[Attachment 71779 - Click to enlarge]

There is some accumulation of the whites at the beginning (clear sky in the background), probably normal because the shot.

[Attachment 71780 - Click to enlarge]

If in other captures you experiment crush/clipping, tune the input levels with the procamp of the USB-Live 2. There are several topics in the forum about it.

For restoration a simple QTGCM, light denoise and very light sharpening is maybe just enough

[Attachment 71781 - Click to enlarge]

Thanks, what tool is used to assess the captured avi file? Any useful guides or docs around how to perform a capture validation/verification would be great.

For the deinterlace, denoise etc. is there any particular recommended output file format? Previously I've deinterlaced dv-avi to prores (advised in some tutorial I read ages ago). I don't think I'll be able to import the Huffyuv-encoded avi to editor so is ProRes a good shout?

Keen to understand how this looks and if I should be looking at any tweaks via the Levels settings in VirtualDub. Everything in the video segs for "capture filters" that refer to the Hauppage card are not editable so assume the Levels control is the way to change the proc amp settings.

Aha! Do I have something for you. Take control, in real time, of your levels! This uses the Virtual Dub Histogram and a program called Graphstudio.

https://drive.google.com/file/d/1DYxxRMdaVWF4nJpN_5_mbBKsnXcCoBlZ/view?usp=drive_link

If you don't know how to use the VDub histogram:

https://drive.google.com/file/d/1Tk9CHXNnfHgBJxCbQz4NeApfW0ZguSt2/view?usp=sharing

I use it to set up my capture levels, even when I'm using AmarecTV.

Thanks, these guides look great. So far I think my only VirtualDub sync issues are due to pressing Capture which the camcorder is still on the "blue" screen. May try Amarek later if I cannot get anywhere.

[lollo]

Thanks, what tool is used to assess the captured avi file? Any useful guides or docs around how to perform a capture validation/verification would be great.

Basic AviSynth scripts involving field operations, cropping, histograms, levels, etc.

To understand the nature of the video start from here: http://web.archive.org/web/20111119181706/http://neuron2.net/faq.html, to understand levels and histogram

To understand histograms start from here: https://www.cambridgeincolour.com/tutorials/histograms1.htm and https://www.cambridgeincolour.com/tutorials/histograms2.htm

Then search the forum for many threads about these concepts.

[Traderbam]

Thanks will do some reading. On the editing format, is a deinterlace to ProRes a reasonable option or should I be considering something else?

[lollo]

Thanks will do some reading. On the editing format, is a deinterlace to ProRes a reasonable option or should I be considering something else?

It should be good enough, but not completely lossless. Some sort of frameserving to Resolve can be possible with VapourSynth, but I never tried. Master poisondeathray may help here...

[Traderbam]

So I've got some captures done but struggling on the deinterlace part. I've used Staxrip in the past but with the configuration here I am getting quite jittery, jerky results compared to the original. Does the mediainfo capture or the Staxrip config show any obvious issues or settings I have missed? I'm outputting to ProRes for my "editing" format as I cannot seem to retain the avi.

Here is the Staxrip session showing more details on the parameters...

[lordsmurf]

Use Hybrid, not Staxrip.

[Traderbam]

Got this one sorted. Needed to modify the Staxrip script to use AssumeTFF() - it seems to assume BFF as the default. This has much better results so I am now moving on to try to work out best workflow for cutting out the scan lines at the bottom and do some denoising in the same script.

Is there an advantage of masking the scan lines as part of the same workflow, or can I just crop in the editor before rendering out to delivery format?

[Traderbam]

Update:
I noticed in Staxrip that there is a "ConvertoYUV420()" command inserted by default under the source file selection section. My source footage is 8-bit 422 HUV interlaced so I don't think this is needed or accurate - will it do harm to keep that in there, especially considering interlaced=true isn't specified?

My process for now is...

AssumeTFF()
QTGMC(preset="Medium", InputType=0, sourceMatch=3, sharpness=0.2, tr2=3, ediThreads=8)

# This extra crop on the right bar was due to strange colours due to a known Sony PAL camcorder issue
Crop(0,0,-28,-12)
AddBorders(14,6,14,6)

# Upsizing to 1440 x 1080 (YouTube is the target)
Spline64Resize(%target_width%, %target_height%)

Any obvious concerns or comments on this flow? I am outputting to ProRes MOV. Any better format I should be looking at to preserve detail?

[Brad]

ConvertToYUV420() without interlaced=true right after the source filter will mangle your chroma.

Instead of cropping, this thread has some alternative scripting ideas to make the edge color issue less-bad: https://forum.videohelp.com/threads/354425-Hi8-capture-using-Digital8-camcorder-Edge-c...e2#post2557188

[lordsmurf]

Replying to some earlier comments from pg1 in the thread...

Is it daft to consider a capture card like ATI/Hauppage etc, without a standalone TBC?

Yes.

If your tapes and in good shape

Noting this is misunderstood. It's not about visual quality, but signal integrity. Consumer analog is chaos on mylar, and "good shape" is mostly a myth. Which you noted...

If needed add a (frame)TBC (always useful because the case of pristine tapes is rare,

However...

but it introduces a lossy A/D and D/A conversion

This is vastly overblown, and in fact has only been mentioned in recent years as an excuse to not get a TBC. The supposed "loss" in a TBC it tiny compared to loss by capture cards, wrong capture settings, etc. Or loss by not using TBC at all.

If you plan no state-of-the-art color correction

I often use ColorMill in VirtualDub, though sometimes to chase lazy Avisynth corrections (autowhite, etc).

All this if you are not happy with your DV flow

PAL 4:2:0 is far more tolerable, but the loss is still noticeable, especially viewed "large" (normal TVs, not phones or tiny capture preview windows). It's really about use case more than anything else, with DV-allowable cases becoming preference.

[lollo]

This is vastly overblown, and in fact has only been mentioned in recent years as an excuse to not get a TBC. The supposed "loss" in a TBC it tiny compared to loss by capture cards, wrong capture settings, etc. Or loss by not using TBC at all.

I agree. My point was that if a (frame)TBC is not needed, you also save lossy A/D and D/A conversions.

Also using a high-end card like a BrightEye 75 having an internal (frame)TBC remove this lossy A/D/A conversion, as testified by user dellsam34.