Is my process for converting Hi8 tapes correct?
 

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.

Attachment 19758

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?

Attachment 19757

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?

Welcome. :)

Well, let's see how you're doing. Replying as a I read...

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.)

- 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. :noworry:

- 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. :congrats:

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.

Probably overkill, but QTGMC is all I care about. Exact choices are part preference, part source needs.

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).

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.

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.

- 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.

^ 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.

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.

Attachment 19760

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.

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. :)

Thanks for the prompt and thorough replies! :) really appreciate the help. Now I know what adjustments to make.

Yes it does have a TBC option in the menu which is set to on.

ah that explains the black bar! The 0+16 crop does the trick removing it.

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.

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?

That sounds like a great way to have both the compatibilty of 4:2:0 and not lose image quality, thanks!

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.

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.

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?

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)

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.

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.

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.

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.