|
09-15-2025, 08:02 PM
|
|
Free Member
|
|
Join Date: Sep 2025
Posts: 3
Thanked 0 Times in 0 Posts
|
|
Hello everyone, I'm currently in the process capturing hi8 tapes to make them available for digital viewing. This is the first time that I’m trying to do anything regarding analog video capture so excuse my inexperience
My end goal is to have decent quality video files that are also widely compatible (Playable with standard mediaplayer on android/windows and shareable over social media like Whatsapp). My current process goes as follows:
-I use a Sony CCD-TRV208E PAL (which the tapes were originally recorded on) and Startech SVID2USB232 as capture hardware. They are connected with an S-video cable.
-Virtualdub2 is used for the actual capturing. The resolution is set to 720x576, framerate to 25fps, the video compression to utvideo yuv422 bt 601 vcm, the audio to no compression PCM. Also the capture dongle (in the capture filter setting) is set to PAL_G.
-I use Staxrip to convert and deinterlace the captured avi files. The output resolution for Staxrip is set to 768x576, resized with GaussResize, QTGMC is used for the interlacing with the following settings: "QTGMC(preset="Placebo", InputType=0, sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=8, AssumeTFF())"
I have however not fully figured out yet what I can use best for the video codec and container. My first attempt was using FFMPEG - x264 with MKV. Everything looks and plays fine but it only does so on VLC or MPC-HC other players outright refuse to play it, it also doesn’t work on whatsapp. Using x264 (without FFFMPEG in front of it) and MP4 does yield me a file that seems to be compatible with it all, however it does force it to convert to 4:2:0. And I wonder if the quality might be worse. Is it my best option or should I try something else?
The audio codec also confuses me selecting AAC in Staxrip sets the bitrate to just 53Kpbs, which seems low to me. Is this normal or should I adjust something? If so what would be the best option? Below is the default config if I select AAC.
Schermafbeelding 2025-09-16 021350.jpg
Also is it wise to use the crop function is Staxrip? There is some noise/lines in the bottom and a green line plus some black space on the right edge of the frame. I can cut that off (crop 0,18/0,14) but i'm not sure if it's wise to do so? The crop results in a resultion of 702x562 which results in the stats below. Is that still fine, or does it hurt the quality of the final results and am I better of doing it some other way or not at all?
| You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community. |
Basically my questions are this:
-Is my current process good (enough)? I don't need the best of the best quality but I would like a decent result and avoid making obvious mistakes. Is there anything I should do differently or is this ok?
-Which video codec and format should I settle on for decent quality but also wide compatibility?
-What should I do with the audio conversion, is the default AAC option correct?
-Should I crop or is better not do that?
|
|
Someday, 12:01 PM
|
|
Ads / Sponsors
|
|
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
|
|
09-16-2025, 12:38 AM
|
|
Site Staff | Video
|
|
Join Date: Dec 2002
Posts: 15,476
Thanked 2,834 Times in 2,403 Posts
|
|
Welcome.
Well, let's see how you're doing. Replying as a I read...
Quote:
Originally Posted by TMCThomas
Hello everyone, I'm currently in the process capturing hi8 tapes to make them available for digital viewing. This is the first time that I’m trying to do anything regarding analog video capture so excuse my inexperience
My end goal is to have decent quality video files that are also widely compatible (Playable with standard mediaplayer on android/windows and shareable over social media like Whatsapp). My current process goes as follows:
|
Simple enough. End goal is probably H.264/x264 as MP4, maybe H.265/x265 if feeling adventurous/experimental. (Tip: Retain lossless captures as pre-compressed masters.)
Quote:
|
-I use a Sony CCD-TRV208E PAL (which the tapes were originally recorded on) and Startech SVID2USB232 as capture hardware. They are connected with an S-video cable.
|
- if 208E is a line TBC model, good.
- lack of frame TBC often poses a problem but continuing on for now.
- Startech "23" is not best, not worst, mid-grade. I'm fine with it for the moment.
So far, top 50%+ of quality expectation, so not a bad start.
Quote:
|
-Virtualdub2 is used for the actual capturing. The resolution is set to 720x576, framerate to 25fps, the video compression to utvideo yuv422 bt 601 vcm, the audio to no compression PCM. Also the capture dongle (in the capture filter setting) is set to PAL_G.
|
- VirtualDub2 can have drop/insert and sync issues, watch meters, spot-test audio sync with timeline scrub
- Ut is not ideal, Huffyuv better
- PAL-G is a broadcast format, your tapes are just plain PAL (B/G/I/etc)
Not to 100% suggestion, but these choices should still be fine.
Quote:
|
-I use Staxrip to convert and deinterlace the captured avi files. The output resolution for Staxrip is set to 768x576, resized with GaussResize,
|
This might be a mistake. The 720x480/576 is not all image data, only 704x. So you have to crop 16 total fro sides (0+16, 4+12, 8+8, etc ... 16 total, even chops). Then resize 704x to 4:3. I'd suggest not 768x576, but rather 720x540. Why? = player support.
Quote:
|
QTGMC is used for the interlacing with the following settings: "QTGMC(preset="Placebo", InputType=0, sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=8, AssumeTFF())"
|
Probably overkill, but QTGMC is all I care about. Exact choices are part preference, part source needs.
Quote:
|
I have however not fully figured out yet what I can use best for the video codec and container. My first attempt was using FFMPEG - x264 with MKV. Everything looks and plays fine but it only does so on VLC or MPC-HC other players outright refuse to play it, it also doesn’t work on whatsapp. Using x264 (without FFFMPEG in front of it) and MP4 does yield me a file that seems to be compatible with it all, however it does force it to convert to 4:2:0. And I wonder if the quality might be worse. Is it my best option or should I try something else?
|
x264, 720x540, 4:2:0, is a standard accepted spec. Save a "better" compressed version, along with lossless interlaced version. Downconvert as needed. I retain not my lossless, but broadcast MPEG version, and 4:2:2 x264 (or H.264 MainConcept), then a compressed-to-snot 4:2:0 version for the video meatgrinders (Youtube, whatever).
Quote:
|
The audio codec also confuses me selecting AAC in Staxrip sets the bitrate to just 53Kpbs, which seems low to me. Is this normal or should I adjust something? If so what would be the best option? Below is the default config if I select AAC.
|
160 kbps AAC is ideal balance, but as far down as 96 kbps can be acceptable. 53 is far too low, unless that's a "per channel" (so 106 kbps), but that seems unlikely. 53 is just an odd number, period. I'd also verify it's not encoding to VBR audio, as that's messy.
Quote:
|
Also is it wise to use the crop function is Staxrip? There is some noise/lines in the bottom and a green line plus some black space on the right edge of the frame. I can cut that off (crop 0,18/0,14) but i'm not sure if it's wise to do so? The crop results in a resultion of 702x562 which results in the stats below. Is that still fine, or does it hurt the quality of the final results and am I better of doing it some other way or not at all?
|
Crop for overscan in 4:3. You'll crop some noise, some image. What you don't want to do is crop only noise, not crop 8x8 edges, and stretch the video to weird aspect (AR). Nor weird resolution.
Quote:
Basically my questions are this:
-Is my current process good (enough)? I don't need the best of the best quality but I would like a decent result and avoid making obvious mistakes. Is there anything I should do differently or is this ok?
|
- Hardware, maybe. Hi8 is a drop-happy format, but you may escape without frame TBC. No evidence either way right now.
- Software needs adjustments, but you had the right idea.
Quote:
-Which video codec and format should I settle on for decent quality but also wide compatibility?
-What should I do with the audio conversion, is the default AAC option correct?
-Should I crop or is better not do that?
|
^ Already answered above.
To add:
- Verify the captures, don't blindly trust (referring to sync and drop/insert frames). Perhaps upload some samples, to get confirmation either way.
- Try to adjust software settings as per above, to get compressed copies for streaming.
You've obviously read up, did research. It shows. You're (probably) mostly fine, just some tweaks to get you where you need to be.
|
The following users thank lordsmurf for this useful post:
TMCThomas (09-16-2025)
|
|
09-16-2025, 06:46 AM
|
|
Free Member
|
|
Join Date: Jul 2023
Location: Michigan, USA
Posts: 1,126
Thanked 215 Times in 193 Posts
|
|
You might end up needing multiple distribution formats. 4:2:2 is more for archiving purposes in the original unscaled archival format. whereas 4:2:0 is more like what online streaming services use because it saves a lot of bandwidth and may not have a visual impact, particularly if you upscale the content. Essentially what that means is that every other line of color information is removed and every other horizontal line is reused for the following line and the same goes for every other horizontal pixel's data is reused from the pixel to the right of it. Basically this means in an 4x2 image (8 pixels), only 2 pixels actually have color information stored.
subsampling.jpg
However, if you double the vertical resolution before subsampling to 4:2:0, you've essentially lost no color information of the output file because every other line being ignored doesn't matter when you've previously doubled the vertical line count. So a simple 1080P upscale in 4:2:0 would not have any color information lost over say a 540P 4:2:2 file is my understanding. It's also nice to upscale for distribution because you don't have to worry about the aspect ratio being wrong and needing to mess with non-square pixels.
|
The following users thank aramkolt for this useful post:
TMCThomas (09-16-2025)
|
|
09-16-2025, 06:57 AM
|
|
Site Staff | Video
|
|
Join Date: Dec 2002
Posts: 15,476
Thanked 2,834 Times in 2,403 Posts
|
|
I don't want to skip ahead too far, but...
Speaking of multiples for distribution, framerate can also matter. So 50fps (p50) is most ideal, sometimes content forces 25fps (p25) deinterlace, or the playback, or the platform/upload.
Some platforms also forces HD resolutions, such as Youtube, where SD is treated like garbage.
I've never liked that color chart, it's not helpful. We should make a new one based on actual animated content.
|
The following users thank lordsmurf for this useful post:
TMCThomas (09-16-2025)
|
|
09-16-2025, 10:10 AM
|
|
Free Member
|
|
Join Date: Sep 2025
Posts: 3
Thanked 0 Times in 0 Posts
|
|
Thanks for the prompt and thorough replies!  really appreciate the help. Now I know what adjustments to make.
Quote:
|
if 208E is a line TBC model, good.
|
Yes it does have a TBC option in the menu which is set to on.
Quote:
|
This might be a mistake. The 720x480/576 is not all image data, only 704x. So you have to crop 16 total fro sides (0+16, 4+12, 8+8, etc ... 16 total, even chops). Then resize 704x to 4:3. I'd suggest not 768x576, but rather 720x540. Why? = player support.
|
ah that explains the black bar! The 0+16 crop does the trick removing it.
Quote:
|
160 kbps AAC is ideal balance, but as far down as 96 kbps can be acceptable. 53 is far too low, unless that's a "per channel" (so 106 kbps), but that seems unlikely. 53 is just an odd number, period. I'd also verify it's not encoding to VBR audio, as that's messy.
|
It's set to default True VBR at the moment, would adjusting it to 160 kpbs CBR be the right call? The tapes/camcorder are mono and just one channel so that might explain the low default bitrate.
Quote:
|
Crop for overscan in 4:3. You'll crop some noise, some image. What you don't want to do is crop only noise, not crop 8x8 edges, and stretch the video to weird aspect (AR). Nor weird resolution.
|
At which point in the process should I do this? My crop currently is 0+16, 0+0 for the black bar on the side, do i just add more crop to that or should I first process it all to a 4:3 resolution and then crop that further? Or something else altogether?
Quote:
|
However, if you double the vertical resolution before subsampling to 4:2:0, you've essentially lost no color information of the output file because every other line being ignored doesn't matter when you've previously doubled the vertical line count. So a simple 1080P upscale in 4:2:0 would not have any color information lost over say a 540P 4:2:2 file is my understanding. It's also nice to upscale for distribution because you don't have to worry about the aspect ratio being wrong and needing to mess with non-square pixels.
|
That sounds like a great way to have both the compatibilty of 4:2:0 and not lose image quality, thanks!
|
|
09-16-2025, 11:05 AM
|
|
Free Member
|
|
Join Date: Jul 2023
Posts: 359
Thanked 111 Times in 95 Posts
|
|
|
You'll want to capture your files as 720x480(NTSC)/576(PAL) and then crop later in post. That's what I do anyway, I don't capture 704x480 by default.
|
|
09-16-2025, 02:04 PM
|
|
Free Member
|
|
Join Date: May 2024
Location: New Jersey, USA
Posts: 192
Thanked 35 Times in 31 Posts
|
|
Quote:
Originally Posted by lordsmurf
The 720x480/576 is not all image data, only 704x. So you have to crop 16 total fro sides
|
Not always. It depends on the capture device and source material. I have plenty of analog captures where the video goes all the way to the edges of the 720 pixels, especially when capturing from things like vintage computers and video game consoles which fill the overscan area with background colors/patterns. In fact, some Sega Genesis games produce graphics so far into the overscan area that it causes some capture devices to falsely detect it as MacroVision encoding!
Of course you can say this is "not standards compliant", but tell that to the manufacturers who used NTSC-J on equipment sold in the American market, because they thought nobody would care, and/or thought consumers would actually prefer the more punchy contrast it produces.
And even if the video ends up with a few pixels of black borders on the sides, there is no harm in leaving them be, rather than cropping them out, especially if the end result is going to be watched on a widescreen display -- so the end result of cropping vs. not cropping will be invisible when abutting the pillarboxing anyway.
|
|
09-16-2025, 05:20 PM
|
|
Free Member
|
|
Join Date: Sep 2025
Posts: 3
Thanked 0 Times in 0 Posts
|
|
Quote:
Originally Posted by Aya_Rei
You'll want to capture your files as 720x480(NTSC)/576(PAL) and then crop later in post. That's what I do anyway, I don't capture 704x480 by default.
|
Yes that's what I do as well, my capture is 720x576. My question was about whether I can do the second crop at the same time or should I first only crop the black bar (so crop it to 704), turn it into a 4:3 resolution and then crop further? Does that matter at all?
Quote:
|
And even if the video ends up with a few pixels of black borders on the sides, there is no harm in leaving them be, rather than cropping them out, especially if the end result is going to be watched on a widescreen display -- so the end result of cropping vs. not cropping will be invisible when abutting the pillarboxing anyway.
|
Correct me If I'm wrong but would leaving that black bar not cause the image to be ever so slightly squeezed? (I thought I read somewhere that it gets cut off with actual hardware and thus is not supposed to be there when digitalizing)
|
|
09-17-2025, 03:55 PM
|
|
Premium Member
|
|
Join Date: Nov 2023
Posts: 109
Thanked 19 Times in 16 Posts
|
|
|
Personally, I have done the cropping on a source-by-source basis. Sometimes, I need to crop more than 16 horizontal, and I often have to crop some vertically as well. This is probably a very horrible/non-standard way to do it, but I try to just barely get the horizontal edge bleed and the head-switching noise out of the frame. Usually, this means I leave the top alone unless I’m cropping the bottom of the frame by an odd number. Since I run the crop in Hybrid along QTGMC during the same x264 render/encoding, I don’t touch the original .avi interlaced master. Final rendered copies for me are always proper 4:3 at 720x540.
|
|
09-26-2025, 02:40 PM
|
|
Free Member
|
|
Join Date: May 2024
Location: New Jersey, USA
Posts: 192
Thanked 35 Times in 31 Posts
|
|
Quote:
Originally Posted by TMCThomas
Correct me If I'm wrong but would leaving that black bar not cause the image to be ever so slightly squeezed? (I thought I read somewhere that it gets cut off with actual hardware and thus is not supposed to be there when digitalizing)
|
No, it's the opposite -- if you're cropping off the left and/or right edges of the frame and then resizing it to fit a perfect 4:3 aspect ratio, you'll be horizontally stretching the image.
|
|
09-26-2025, 02:49 PM
|
|
Free Member
|
|
Join Date: Oct 2024
Location: Canada
Posts: 106
Thanked 19 Times in 18 Posts
|
|
|
I consider processing video during the capture is a very bad idea.
You capture your video as is using lossless encoder and only then you do the post-processing.
This way you can try to post-process as many times as you want without "sawing" the tape.
|
|
09-26-2025, 02:53 PM
|
|
Premium Member
|
|
Join Date: Nov 2023
Posts: 109
Thanked 19 Times in 16 Posts
|
|
|
I personally just do cropping at the same time as the deinterlacing in Hybrid, which is also where the video is rerendered in proper 4:3 as x264. If anything, only crop after a separate 4:3 reframed/resized file is made so the master capture is left alone.
|
| Thread Tools |
Search this Thread |
|
|
|
All times are GMT -5. The time now is 04:33 AM
|