Rate my Setup - Capturing Digital8 and Analog

[johnmeyer]

If you're in PAL land, little will be gained by using a analogue-lossless process. One of the respected commercial digitising outfits, video99uk, allegedly uses the DV route: playing the V8/Hi8 tapes in the D8 camcorder and capturing the DV. My own experiment showed the two methods yield the same result.

I suggest you do a couple of test runs to assess for yourself.

For the analogue process, yes, connect as per your note.

100% agree. What's more, if any of your tapes are DV or Digital8, then capturing them as analog rather than transferring them as DV will actually degrade the video because DV and Digital8 are already digitized using the DV codec, and the "capture" via 1394/Firewire is actually a copy operation, not a transfer.

Also, when you start with VHS or analog 8mm, the video is so lousy that the DV artifacts are not your biggest problem. What IS the big problem for most people is getting the analog capture working correctly, without screwing up the levels (which most newbies seem to do). The DV digitizing in camcorders does a great job getting that right.

I just helped a woman going through a year-long battle with breast cancer who wanted to digitize all of her videos, just in case, well, you know. They were 1/3 VHS, 1/3 8mm, and 1/3 DV. I set her up with a passthrough from her 8mm camcorder, using her DV camcorder as the encoder, into one of my old 1394 laptops. She proceeded to digitize 50+ tapes of 2-6 hours each. Do the math on that; it was a LONG project.

The key thing: she got though ALL of the tapes without a hitch, with zero capture learning curve. The videos look just fine.

DV capture just works, even for newbies. The same cannot be said of analog capture.

Will analog capture produce a better result? In most cases, yes. Will anyone be able to see the difference? Probably not, especially when starting with 1980s or 1990s consumer video.

[Alwyn]

I'm not sure whether @Sharc would agree with MY quote there, John (from post #3)!

In fact, I suspect he's probably having an apoplexy about it!

[Sharc]

I'm not sure whether @Sharc would agree with MY quote there, John (from post #3)!

In fact, I suspect he's probably having an apoplexy about it!

I agreed with your conclusion, please re-read my posts#4, #6 and #7.
However, the incident which almost caused an apoplexy was when viewing your "own experiment" comparison example which you linked to in your post #3. I put a question in post#4 which you apparently didn't have the answer for. I then took a second look and provided the answer myself in post#7. Your comparison is perhaps well meant but it is pretty useless IMO as it really doesn't prove anything, especially not the subtle differences which might exist between the 2 methods. That's my critism. I hope having clarified this now.

[Bermuda1]

@johnmeyer: thankfully, I am in no rush to digitze. Thanks to this forum I start seeing the difference between DV and S-Video (analog) capture, so while it would agree that a lot of people won't notice a huge difference unless directly addressed, I want to get the best possible result for myself using the hardware and methods that I have .

@Alwyn just making sure I understand correctly:

I basically have to crop AT LEAST 6 pixels from the bottom (resulting in 6 x 1.3333 = 7,99998 so almost 8, an even number) to get an even number to crop from the sides?

If it's still Interlaced, yes. But if it has already been deinterlaced you can crop to the pixel.

My workflow is: create script to deinterlace eg QTGMC, open script in VDub, crop as required (and apply other stuff as necessary), resize to desired, then "Save video". There's only "one step" because the act of opening the AVS in VDub isn't actually an encode, even though, as far as VDub is concerned, the video is deinterlaced.

Re your script, if the video is already deinterlaced/progressive, I don't see the need to use QTGMC.

What's not clear to me from your post is whether you deinterlace and crop using one avisynth script (as I did in post #57) or whether these steps are separated.
Also, would I not be able to crop to the pixel using my above mentioned script, even if the base file was an original, interlaced, video, given that it would FIRST deinterlace (lines 1-5) and then only crop (lines 6-8)?

@Sharc: same question here:

An easier workflow for your interlaced capture would be
- deinterlace
- crop as you like
- encode x264 using SAR 12/11 in its settings, in .mp4 container.

In this case no need for resizing at all as very most players or TVs etc. will do it automatically (by evaluating the 12/11 flag).
Try it.

But all of this in separate steps, yes? 1. Deinterlace using avisynth. 2. Crop using another script WITHOUT resizing though, and 3. saving video in VirtualDub to x264 using SAR 12:11. Again, same question as above, this is not possible by just using my script from post #57 (excluding the resizing)?

[Alwyn]

What's not clear to me from your post is whether you deinterlace and crop using one avisynth script (as I did in post #57) or whether these steps are separated.

What I do is set up an AVISynth script to do the deinterlacing (via QTGMC) and then open the AVS (script) in VDub for cropping, resizing and export. The act of opening the script, I suppose you could say, is one "step" but nothing has actually happened, encoding-wise. AVISynth has "served" to deinterlaced file to VDub. As far as VDub is concerned, it is looking at a deinterlaced file. You can inspect it with VDub and you'll find it is Progressive.

Then I crop it, resize it, do other stuff such as colour adjustments, maybe apply stabilisation with the Deshaker filter, or noise reduction with Neta Video (paid), edit it (chop out the bits I don't want) and then export it either as an AVI for use in my video editing programs or to H264/MP4.

It is, of course, possible to do most of that in one go as you have in your script, except that you still have to export it.

[Sharc]

@Sharc: same question here:

An easier workflow for your interlaced capture would be
- deinterlace
- crop as you like
- encode x264 using SAR 12/11 in its settings, in .mp4 container.

In this case no need for resizing at all as very most players or TVs etc. will do it automatically (by evaluating the 12/11 flag).
Try it.

But all of this in separate steps, yes? 1. Deinterlace using avisynth. 2. Crop using another script WITHOUT resizing though, and 3. saving video in VirtualDub to x264 using SAR 12:11. Again, same question as above, this is not possible by just using my script from post #57 (excluding the resizing)?

Yes; 1. Read the file in avisynth, deinterlace, crop using one single avisynth script, then 2. open this script in Vdub2 and encode using x264 SAR 12/11 and select .mp4 as container.
So you could say 2 steps in your terminology.

Edit:
You can also do everything in one single Vdub2 call (no need for avisynth) if you accept the inferior (means not as good as QTGMC) deinterlacer(s) available for Vdub2.

Edit2:
If you want a 1 step solution try this using ffmpeg and your crop values of post#57:

ffmpeg -i "your_source" -c:a aac -c:v libx264 -preset slow -crf 17 -vf "crop=696:570:12:0, bwdif=mode=1, setsar=12/11, format=yuv420p" "out.mp4"

Personal note:
Usually I don't even deinterlace but encode inerlaced video as interlaced and let the player/TV do the deinterlacing on the fly. Most users seem to
follow the deinterlacing route though, as it makes life for cropping and filtering easier and independent from the (inferior, compared to QTGMC) deinterlacers of players/TVs. That's a personal decision though rather than a general recommendation.

[Alwyn]

All, we're talking about semantics. All the options presented here have only one "encoding" or "processing" step.