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.

[edit]The above quote is from Alwyn, not Sharc. Sorry!!

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 criticism. 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 "bwdif=mode=1, crop=696:570:12:0, 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.

[johnmeyer]

My apologies to both Alwyn and Sharc for mislabeling the quote!! When I clicked on "reply" there were three cascaded quotes, with three names in brackets, one after the other. I didn't need or want the other quotes, so I deleted them, but I left the wrong quote header. To not screw up the thread, I left my mistake intact (so these subsequent replies make sense), but just added an edit which explains my mistake.

[Sharc]

No need to apologize. I think Alwyn and myself both understood what happened with the labeling
(And the OP has already experienced some of the pitfalls with analog video capturing).

[Bermuda1]

@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 "bwdif=mode=1, crop=696:570:12:0, 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.

Hey Sharc,
thanks for the different methods suggested! Out of curiosity for FFMPEG, I tried your suggestion under "Edit2" first. I used FFMPEG with the following code:

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

For the crop, I used the values from post #57. Not sure about the coordinates part ("12:0") - i just used what you had in there....settings are the same (RF 17.0, Slow, etc.) compared to my AviSynth+ VirtualDub conversion with the exception that I used YUV422p and used the resize with a SAR of 1:1. Attached a comparison on the results (please ignore the mouse pointer...focus on e.g. the hands). The Avisynth+ VirtualDub conversion is cleaner / less noisy in my opinion + the file size is smaller (1.4 GB compared to 1.8 GB).

Also, I see that the FFMPEG output has an aspect ratio of only 3,99:3 - is this because of the not perfect crop (i.e. 6*1.33333=7.99998 and not 8) ?

Next, I will try deinterlacing and cropping to the pixel via avisynth as .avi and then only encode using x264 SAR 12/11 and selecting .mp4 as container. Curious as to what the results will be there too

[Sharc]

Hey Sharc,
thanks for the different methods suggested! Out of curiosity for FFMPEG, I tried your suggestion under "Edit2" first. I used FFMPEG with the following code:

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

For the crop, I used the values from post #57. Not sure about the coordinates part ("12:0")

12:0 are the coordiates of the top left corner (12 from left, 0 from top) of the cropped window of 696x570 as defined by you (720-2x12=696; 576-6=570).

You will see the beauty of the SAR concept: You crop as you like and the objects in the encoded picture remain undistorted (neither squashed nor stretched, and you don't need to do "calculations".

...compared to my AviSynth+ VirtualDub conversion with the exception that I used YUV422p and used the resize with a SAR of 1:1. Attached a comparison on the results (please ignore the mouse pointer...focus on e.g. the hands). The Avisynth+ VirtualDub conversion is cleaner / less noisy in my opinion + the file size is smaller (1.4 GB compared to 1.8 GB).

This is because Avisynth's QTGMC includes a denoising function while bwdiff does not. Less noise gives lower filesizes but may remove details. Denoising is always a compromise.
(You could also use an .avs script with QTGMC as input for ffmpeg btw., or include a denoiser in the ffmpeg commandline.)

Also, I see that the FFMPEG output has an aspect ratio of only 3,99:3 - is this because of the not perfect crop (i.e. 6*1.33333=7.99998 and not 8) ?

Yes. 3.99:3 is actually correct. As said before you can crop as you like and the Display Aspect Ratio of the picture will change accordingly (same as using scissors to cut a paper picture). By using the SAR signalling in x264 the objects remain however undistorted. No fat or slim shaped people. No calculation needed. The player adjusts it for you (provided it respects the SAR).

[Bermuda1]

Hey Sharc,
thanks for the different methods suggested! Out of curiosity for FFMPEG, I tried your suggestion under "Edit2" first. I used FFMPEG with the following code:

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

For the crop, I used the values from post #57. Not sure about the coordinates part ("12:0")

12:0 are the coordiates of the top left corner (12 from left, 0 from top) of the cropped window of 696x570 as defined by you (720-2x12=696; 576-6=570).

You will see the beauty of the SAR concept: You crop as you like and the objects in the encoded picture remain undistorted (neither squashed nor stretched, and you don't need to do "calculations".

...compared to my AviSynth+ VirtualDub conversion with the exception that I used YUV422p and used the resize with a SAR of 1:1. Attached a comparison on the results (please ignore the mouse pointer...focus on e.g. the hands). The Avisynth+ VirtualDub conversion is cleaner / less noisy in my opinion + the file size is smaller (1.4 GB compared to 1.8 GB).

This is because Avisynth's QTGMC includes a denoising function while bwdiff does not. Less noise gives lower filesizes but may remove details. Denoising is always a compromise.
(You could also use an .avs script with QTGMC as input for ffmpeg btw., or include a denoiser in the ffmpeg commandline.)

Also, I see that the FFMPEG output has an aspect ratio of only 3,99:3 - is this because of the not perfect crop (i.e. 6*1.33333=7.99998 and not 8) ?

Yes. 3.99:3 is actually correct. As said before you can crop as you like and the Display Aspect Ratio of the picture will change accordingly (same as using scissors to cut a paper picture). By using the SAR signalling in x264 the objects remain however undistorted. No fat or slim shaped people. No calculation needed. The player adjusts it for you (provided it respects the SAR).

That is indeed awesome! Tried and works great.

Big thank you to everyone that posted / for all the help in getting me this far. Special thanks to @Sharc @Alwyn for always following up and answering my questions/giving feedback!!

I am really happy with the outcome now and will play around a little more with different settings. I feel as well equipped as I can be (for a newbie) thanks to you

Best regards,
Bermuda1

[Bermuda1]

Followed your instruction and cropped to 704x576 - then I changed the display size to 768 to get a 4:3 aspect ratio --> The crop is not sufficient for the black bars on the left, right and bottom to be gone - is that how it should be? Not really noticable on TV but on the PC.

I'll chime in but I do things differently: as early as I can, I set up a square pixel workflow. That is, I take 8 pixels off each side straight away because that's what the experts say to do.

After that, if there are no black edges, I resize it to 768x576 or 1440x1080.

If there are black edges that need to be removed (personal preference, some here mask them), I just crop to the 4:3 ratio. For example, if I need to take off 6 pixels from the top, I'll take 6 x 1.33333 total off the sides. If I need to take 8 pixels off the sides, I'll take 8/1.3 total off the top and bottom.

Make sure all your crops are in even numbers.

Then I'll resize 768x576 or 1440x1080. If you're exporting to H264 in Virtual Dub, for the "Save", leave the SAR on 1 and 1. For an AVI export from VDub into another editor, there is no SAR/DAR/PAR, it is all based on the frame size for AVI. Provided the frame size is the desired display aspect ratio eg 4:3, the next editor will know how to display it.

My flak jacket is now on!

Hi Alwyn,
I am again experimenting with different methods. I am trying to get all of my different avi files into the same size on a square pixel format for creating a longer edited video. I hope that you can elaborate on your post from some time ago as I dont understand one aspect:
Assuming that the initial avi files are 720x576. If you then take off 8 pixels from the side you get 704x576.But when you then RESIZE to 768x576 would that not result in a distorted / stretched picture? 768x576 corresponds to 4:3 but 704x576 doesn't. Kindly shed some light on this for me. Also, would you not need to start taking off pixels from the top and bottom directly when taking of pixels from the sides? Why can you just take of 8 pixels each side without any from the top and bottom?
Thanks!

Edit:
I think I understand now, but please correct me if I am wrong...since 768x576 uses square pixels and 704x576 non-square pixels, we are fine (no distortion/stretching etc. when resizing). BUT, what I still dont get, why do you not need to start cropping in line with the 4:3 format starting from the beginning, meaning that if you take off 8 pixel from the side, you must directly take off pixels from top and bottom as well?

[Alwyn]

I never have got my head around 720/704 but my understanding is you chop off the 2x8 pixels, then resize to 768.

If, after chopping off the 16 pixels, you still have gunge/cr@p you want to crop off eg head-switching noise or more side bars, then you apply the 4:3 rule.

If the combined numbers are too hard to work out in one go, you can just do two separate crops in VDub2 (as I do): the first, 2x8, then another (added) crop, to tidy up.

I've done some experiments with what I think are circles, but have never proven that exactly 2x8 applies in all cases. Most times, some lateral cropping is needed but it seems to vary.

[Sharc]

I've done some experiments with what I think are circles, but have never proven that exactly 2x8 applies in all cases. Most times, some lateral cropping is needed but it seems to vary.

It doesn't apply "in all cases". It applies for analog video (like VHS) which has been captured using a luma sampling rate of 13.5MHz, as standardized by ITU recommendation BT.601, which any decent capture device should adhere to. The exact value would be 702 pixels for PAL with an active picture scanline duration of 52us (acc. ITU recommendation BT.470). 52usx13.5MHz=702 which would require cropping 18 pixels total (left+right) from the 720. These 702 have been adopted to mod16-compliant 704 by mpeg4.
I doubt you really notice a circle distortion due to the 2 pixels deviation in practice.

[Alwyn]

That doesn't explain cropping. To me, "active picture area" implies that the image/video is already being displayed correctly at 4:3 with the side bars in place, and if you want to crop away the side bars, you would also have to crop the top and bottom (for square pixels, that is). But that's not what most people around here espouse: "crop the sides 2x8 then resize to 1440x1080" is one of the mantras.

There's no mention in that document about compensating the picture by stretching to hide the side bars.

I know the 704/702 has been discussed many times but the resizing to square pixels for these videos hasn't. The majority of the discussions have been regarding setting the correct SAR, which obviously is not "square pixels".

[Sharc]

That doesn't explain cropping. To me, "active picture area" implies that the image/video is already being displayed correctly at 4:3 with the side bars in place, and if you want to crop away the side bars, you would also have to crop the top and bottom (for square pixels, that is). But that's not what most people around here espouse: "crop the sides 2x8 then resize to 1440x1080" is one of the mantras.

There's no mention in that document about compensating the picture by stretching to hide the side bars.

I know the 704/702 has been discussed many times but the resizing to square pixels for these videos hasn't. The majority of the discussions have been regarding setting the correct SAR, which obviously is not "square pixels".

What "mantra" to crop 2x8 symmetrically? If there is such a mantra it should be to crop 16 in total (left+right) from the 720 in case the picture is not exactly centered horizontally in the 720 frame (depending on the device drivers).

I give up. So many times explained and discussed.....

[lollo]

I give up. So many times explained and discussed.....

Good choice

And you did not even mention the half horizontal line, nor the 703 number

[Sharc]

And you did not even mention the half horizontal line, nor the 703 number

Better not

[Alwyn]

No such thing as a stupid question, only a stupid answer.

Lollo referenced this document in 2022; the author does address, clearly, the case of a 768x576 capture in Example 1: crop in 4:3 ratio and that's it. What a pity the author didn't cover the normal example of a 720x576 4:3 capture.

So, for a normal capture of 720x576, for a square-pixel output, do I side-crop 2x8, then save as 768x576 or not? Yes/No?

[Sharc]

No such thing as a stupid question, only a stupid answer.

Lollo referenced this document in 2022; the author does address, clearly, the case of a 768x576 capture in Example 1: crop in 4:3 ratio and that's it. What a pity the author didn't cover the normal example of a 720x576 4:3 capture.

So, for a normal capture of 720x576, for a square-pixel output, do I side-crop 2x8, then save as 768x576 or not? Yes/No?

No. Re-read post#77. "2x8 mantra" makes sense only when the picture is nicely horizontally centered, which is more than often not the case. It's just 16 pixels cropping in total (left+right), obeying mod-x cropping rules.

[Alwyn]

Re-read post#77.

You added that last bit well after your initial post. I didn't see it before I made my question post.

In future, if you are adding such an important extra bit, please make a new post.

Thanks for answering.

[lollo]

Lollo referenced this document in 2022; the author does address, clearly, the case of a 768x576 capture in Example 1: crop in 4:3 ratio and that's it. What a pity the author didn't cover the normal example of a 720x576 4:3 capture.

There is nothing to explain, the Rec601 spec is clear: capture 720x576, obtaining a maximum active area of 702x576 (or 703x576 or 704x576 according to what you take into account) inside that frame.

SD video D1 spec is 720x576; DVD and DVB broadcast use that numbers (with rare exceptions).
768x576 simply does not exist! It is a derived display resolution when you apply a 4:3 DAR to a 720x576 frame (576*4/3=768). You like it because is a square-pixel format, but there is no need at all to use it in digital video resizing the capture (the same for a useless 720x540 in NTSC world).

So, for the nth time, crop to 704x576 the 720x576 capture (maybe not in a simmetric way as Sharc pointed out), mask (not crop) the head switching noise and encode with a 4:3 DAR. Or if you do not like black bars at all crop whatever you want and specify the appropriate PAR (but be sure that the player or the TV are able to read this flag).

[Sharc]

768x576 simply does not exist! It is a derived display resolution.....

Sidenote: The mpeg2 sequence header has 4 bits reserved for signalling the "aspect ratio" with 4 predefined values:
1:1, 4:3, 16:9, 2.21:1 (the latter explicitely NOT used in DVD). So "1:1" seems at least to exist in some form. I have however never seen it in a DVD, neither as DAR nor as PAR. If it is the Display Aspect Ratio it would mean a square picture (like 576x576 square pixels). If it would refer to the PAR (Pixel Aspect Ratio) it would mean 768x576 square pixels for the 4:3 DAR (for "PAL").
A complete description should be found in ISO/IEC13818 or in the original DVD spec which probably none of us has ever seen (?).

[Bermuda1]

Lollo referenced this document in 2022; the author does address, clearly, the case of a 768x576 capture in Example 1: crop in 4:3 ratio and that's it. What a pity the author didn't cover the normal example of a 720x576 4:3 capture.

There is nothing to explain, the Rec601 spec is clear: capture 720x576, obtaining a maximum active area of 702x576 (or 703x576 or 704x576 according to what you take into account) inside that frame.

SD video D1 spec is 720x576; DVD and DVB broadcast use that numbers (with rare exceptions).
768x576 simply does not exist! It is a derived display resolution when you apply a 4:3 DAR to a 720x576 frame (576*4/3=768). You like it because is a square-pixel format, but there is no need at all to use it in digital video resizing the capture (the same for a useless 720x540 in NTSC world).

So, for the nth time, crop to 704x576 the 720x576 capture (maybe not in a simmetric way as Sharc pointed out), mask (not crop) the head switching noise and encode with a 4:3 DAR. Or if you do not like black bars at all crop whatever you want and specify the appropriate PAR (but be sure that the player or the TV are able to read this flag).

If I only crop to 704x576, I dont only have head switching noise but would have to keep more noise on the left and right side (distorted colors) that I simply dont want in the footage that I will combine with other clips for a family movie. Cropping how I like will result in different clips with different aspect ratios, which won't be great for combining either. Alwyns approach, resizing to 768x576 seemed logically, to get everything on a common basis. If you say that this is not the "right" way to do it, could you please recommend what I do instead?

@Alwyn: I tested your approach, resizing to 768x576, however switched things up with cropping. I did one version where I directly cropped in a 4:3 (see "Example_Crop4-3.png) manner (taking of from top and bottom directly when taking off from the sides) as well as taking off 16 pixels from the sides, and then only started cropping in a 4:3 manner when taking off more from the width/height (see Example_Crop8_Then-in-line-with-4-3.png). I compared it to the original 720x576 avi (Example.avi.png). See attached. At least in my perception, the first approach looks "more correct" i.e. looks more like the original 720x576 footage (no stretching or so of the image, which seems to be the case when I first take off 16 pixels from sides and then start cropping to 4:3 and resizing). Did I do something wrong then?

[Alwyn]

Did I do something wrong then?

Ha! That's what I'm trying to work out. There's very little in it, but I'm tending to agree with you; of the two cropped pics, the "Crop 4-3" looks closer to the original than the "Crop 8" pic.

Now whether you have done anything wrong depends on your view on the 16 pixels issue, but certainly, if you crop the 16 pixels away, if you're converting to square pixels, you'll be stretching the picture, as you've found.

[Alwyn]

So, for the nth time, crop to 704x576 the 720x576 capture (maybe not in a simmetric way as Sharc pointed out), mask (not crop) the head switching noise and encode with a 4:3 DAR.

No. I don't want to encode with a DAR. I want square pixels, like almost every other video format in the world. With square pixels, none of the DAR, SAR, PAR discussion, 16:15, 12:11, 8:9 etc etc is necessary. All I want is to digitise a video in 4:3 after I crop as I desire. The simplest way IMO is to export it as square pixels. And as Bermuda has pointed out, if you're mixing clips, you can't just encode with a SAR of 16:15 after cropping because you could end up with uneven left and right edges, depending on how much you cropped off.

If you don't want to assist us working out how to export/save as square pixels, then it would be better if you stayed out of it. Your continued repetition of the theory does not help me/us understand the method achieving of square pixels.

[Sharc]

No. I don't want to encode with a DAR. I want square pixels, like almost every other video format in the world. With square pixels, none of the DAR, SAR, PAR discussion, 16:15, 12:11, 8:9 etc etc is necessary. All I want is to digitise a video in 4:3 after I crop as I desire. The simplest way IMO is to export it as square pixels.

Fine, but it's a fact that even when all you want is to resize and export to square pixels and eventually end up with 4:3 DAR you cannot ignore the PAR (Pixel Aspect Ratio) of the original picture. Square pixel is just a special case of the PAR, namely PAR=1:1. Anything else are mantras, believes, tales, stories, narratives, recipies, tinkering .... you name it.
Maybe the OP uploads a snippet of his unprocessed video capture so we can give specific help for his particular case. The very first step would be to agree on the PAR of his capture (should be Rec.601 compliant - but who knows?). Otherwise do whatever you "think looks right" to your/the OP's eyes. That's all what counts at the end.

P.S.

....square pixels, like almost every other video format in the world....

Huh? Counting mobile phones?

[Sharc]

You may find these functions by jagabo helpful:
https://forum.videohelp.com/threads/407467-Vhs-capture-advice/page12#post2682162

Or Excel is your friend.

Edit:
Also, AvsPmod has a nice resize calculator under Tools. Again: no way to bypass the PAR (aka SAR in x264 terminology)

[lollo]

If I only crop to 704x576, I dont only have head switching noise but would have to keep more noise on the left and right side (distorted colors) that I simply dont want in the footage that I will combine with other clips for a family movie. Cropping how I like will result in different clips with different aspect ratios, which won't be great for combining either. Alwyns approach, resizing to 768x576 seemed logically, to get everything on a common basis. If you say that this is not the "right" way to do it, could you please recommend what I do instead?

Are you serious? If you want to remove more than 8+8 pixels on the side because you have defects, you just mask as you do with the head switching noise, for example: crop(16,2,-16,-10).addborders(8,2,8,10).
You do not have to crop "as you like" but as it should be done.

I want square pixels, like almost every other video format in the world.

You must be joking.

If you don't want to assist us working out how to export/save as square pixels, then it would be better if you stayed out of it. Your continued repetition of the theory does not help me/us understand the method achieving of square pixels.

If you absolutely want 768x576 square pixels and you have to crop random numbers then you shoud take into account the 4:3 aspect ratio (ant the PAR). I see now that Sharc already talked about excel files and math, apply it!
But you're right, better for me to stay away from this butchery.

A complete description should be found in ISO/IEC13818 or in the original DVD spec which probably none of us has ever seen (?).

I have it. Costed a fortune to my company in late nineties. If you need any info from there just let me know