Horizontal Red and Green Lines (GV-USB2)

[WhiteboyUltima]

Just briefly: I don't find the time now to verify your QTGMC attempts.
I suggest to remove the QTGMC denoising and sharpening tweaks and make a test with the separate noise filter like the suggested (slow but high performing) Temporaldegrain2(...) or the fast but less strong MCDegrainSharp(frames=3,...). Also, KNLMeansCL(...) or SMDegrain(....) should perform reasonably well with your birthday party clip. You should readily spot the difference in denoising quality.
AvsPMod is an excellent tool for experimenting with filters and their settings. Switching between Tabs or using Avisynth StackHorizontal(clip1,clip2) or Interleave(clip1,clip2) makes the differences more eyecatching.

Thanks, I've been using AVSPmod for a few days now to preview everything.

I removed the QTGMC denoising and sharpening as you suggested. I've now tried TemporalDegrain2 and it's amazing.

As for as sharpener (LSFmod)... I barely notice any difference unless I put the value up from the recommended 100-120, to something crazy like 500 or more. And then it looks artificial anyway. I did play with many of its settings. To me, I get a better result just doing Sharpen=0.1-0.3 in QTGMC and forgetting about LSFmod, but am I crazy? I tried both sharpening types on at the same time too, again barely any result unless I put values way up. To me there is almost zero difference between strength=0 and strength=120 for LSFmod.

Overall, it seems to me there's no real way to 'unblur' the natural softness of VHS after upscaling as it's SD at the source anyway and is analogue. Beyond using AI to basically re-create the footage, I think it's normal to have soft looking VHS footage as that's what it looks like on the tv anyway. So I'm not sure what I was expecting.... but why do people bother sharpening VHS footage at all? Kind of like polishing a turd...


Here is my code in its current state by the way. I changed from the Fast preset to Slow after some tests (fast seemed to blur things a bit more). I had to convert to YUV420 earlier than I thought, to get TemporalDegrain2 to work. Hopefully I did that in the right place (after deinterlacing). In fact, I hope everything is in the correct order in my code... please let me know if it all looks good Google AI certainly seems to think so

QTGMC(Preset="Slow", SourceMatch=3, Lossless=2, MatchEnhance=0.75,Sharpness=0.0) #De-interlace

ConverttoYV12() #Convert colour space to YUV 4:2:0 so TemporalDegrain2 works

TemporalDegrain2(degrainTR=3,grainLevel=1,postFFT=0) #Remove noise, at a light/medium strength

Crop(8, 0, -8, -0) #This crops the video to 704x576, removing black borders on sides and giving a more accurate final aspect ratio when upscaled to 1440x1080. Always crop in even numbers.

Spline64Resize(1440,1080) #Upscale

LSFmod(strength=120, Smode=3, Lmode=1, secure=true, Szrp=16, preblur="ON") #Sharpen slightly

#Letterbox(0, 15, 0, 0) # Masks bottom 15 pixels with black to hide head noise - Optional

And this is the comparison so far. Captured video on left (screenshot from VDub), and screenshot from AVSPmod on right after running my script (I temporarily commented out the upscale for this screenshot). How's it looking to you guys? Good detail/denoising/sharpness etc.?

If you zoom in/go close to your screen, you'll see that the processing has introduced these diagonal coloured lines for some reason (look at the child's right arm and pillow) - what could this be? Just a natural part of QTGMC? (they are gone if I comment out QTGMC, but obviously I still want to perform deinterlacing). Closest I can get to replicating it is playing the original capture in VLC and turning on 'Linear' deinterlacing which gives similar diagonal lines.


[Attachment 90340 - Click to enlarge]

[Alwyn]

Be careful with screenshots of VDub. If it is not the "in-focus" app, the image will be more blurred than the real image. If you want to use the VDub image output, do a File>Export>Single image...

It's too blue. Lower the blue in Colormill in VDub or experiment with the colour temperature.

[WhiteboyUltima]

Be careful with screenshots of VDub. If it is not the "in-focus" app, the image will be more blurred than the real image. If you want to use the VDub image output, do a File>Export>Single image...

It's too blue. Lower the blue in Colormill in VDub or experiment with the colour temperature.

Noted about screenshots (not that it matters much for this comparison).

Ignore the blue hue please - it's exactly the same on the tape itself. The rest of the video is fine, it's just the lighting in that scene. I don't plan on 'fixing' that.

What's your thoughts on my code, my comments about sharpening, and final output image (ignoring the blue)? And the weird diagonal stripes that QTGMC has introduced? (I can get more output images of different scenes later)

[Sharc]

Well done. Yes, agree re. sharpeners. Be careful. VHS is VHS.

Here a few minor modifications to your script:

AssumeTFF() #set the field order to prevent jerky playback
ConverttoYV16(interlaced=true) #converts to planar and keeps 4:2:2 intact
QTGMC(Preset="Slow", SourceMatch=3, Lossless=2, MatchEnhance=0.75,Sharpness=0.0) #De-interlace
TemporalDegrain2(degrainTR=3,grainLevel=1,postFFT=0) #Remove noise, at a light/medium strength
Crop(10, 0, -8, -0) #This crops the video to 702x576, removing black borders on sides and giving a more accurate final aspect ratio when upscaled to 1440x1080. Always crop in even numbers.
Spline64Resize(1440,1080) #Upscale

#converttoYV12()  #required for LSFMod only
#LSFmod(strength=120, Smode=3, Lmode=1, secure=true, Szrp=16, preblur="ON") #Sharpen slightly

cas(0.5)  #alternate sharpener you may want to try, works in 4:2:2
#Letterbox(2, 15, 6, 6) # Head switching noise and fuzzy border masking - Optional
converttoYV12() #preferably do the 4:2:2 -> 4:2:0 conversion at the end

[Sharc]

For what it's worth here a script which you can use for comparing 2 versions (v1, v2). Open it in AvsPod and step through the frames.

AVISource("David's 5th Birthday Capture Preview No Audio.avi")
AssumeTFF()
ConverttoYV16(interlaced=true)
v=last

v1=v.QTGMC() #De-interlace
v1=v1.Crop(10, 0, -8, -0) #This crops the video to 702x576, removing black borders on sides and giving a more accurate final aspect ratio when upscaled to 1440x1080. Always crop in even numbers.
v1=v1.Spline64Resize(1440,1080) #Upscale
v1=v1.subtitle("before filter",align=5,size=28)


v2=v.QTGMC(Preset="Slow", SourceMatch=3, Lossless=2,MatchEnhance=0.75,Sharpness=0.0) #De-interlace
v2=v2.TemporalDegrain2(degrainTR=3,grainLevel=1,postFFT=0) #Remove noise, at a light/medium strength
v2=v2.Crop(10, 0, -8, -0) #This crops the video to 702x576, removing black borders on sides and giving a more accurate final aspect ratio when upscaled to 1440x1080. Always crop in even numbers.
v2=v2.Spline64Resize(1440,1080) #Upscale
v2=v2.cas(0.5)  #sharpening
v2=v2.subtitle("after filter",align=5,size=28)

view1=stackhorizontal(v1,v2) # side-by-side
view2=interleave(v1,v2)  # interleaved

return view1 #view1 or view2

[Sharc]

... and now stepping through it I discoverd some glitches, e.g. frames#139...142, frames#2826...2828, frames#3054... 3058 (is this what you meant by diagonal lines?).
I think these glitches are tape errors rather than due to the capture process.


[Attachment 90347 - Click to enlarge]

[WhiteboyUltima]

Well done. Yes, agree re. sharpeners. Be careful. VHS is VHS.

Here a few minor modifications to your script:

AssumeTFF() #set the field order to prevent jerky playback
ConverttoYV16(interlaced=true) #converts to planar and keeps 4:2:2 intact
QTGMC(Preset="Slow", SourceMatch=3, Lossless=2, MatchEnhance=0.75,Sharpness=0.0) #De-interlace
TemporalDegrain2(degrainTR=3,grainLevel=1,postFFT=0) #Remove noise, at a light/medium strength
Crop(10, 0, -8, -0) #This crops the video to 702x576, removing black borders on sides and giving a more accurate final aspect ratio when upscaled to 1440x1080. Always crop in even numbers.
Spline64Resize(1440,1080) #Upscale

#converttoYV12()  #required for LSFMod only
#LSFmod(strength=120, Smode=3, Lmode=1, secure=true, Szrp=16, preblur="ON") #Sharpen slightly

cas(0.5)  #alternate sharpener you may want to try, works in 4:2:2
#Letterbox(2, 15, 6, 6) # Head switching noise and fuzzy border masking - Optional
converttoYV12() #preferably do the 4:2:2 -> 4:2:0 conversion at the end

Thanks, going to install cas() now and maybe try your other script that compares versions.
I noticed you changed my crop so it's 702x576 - is that just a personal preference or any specific reason you did that?

That pic you just posted with the tape error is right at the start of the footage - baked into the tape, the first 15 seconds or so seem damaged and full of glitches like that, the other 38 minutes are pretty great though. So not much I can do about that, plus it kind of adds to the charm, haha.

Here's those diagonal lines up close. They only appear when I perform any kind of QTGMC (tried with just one setting, and tried with my current settings, still there. And they are not in every scene, seems to be no pattern, e.g. I thought they might only be in bright areas but they are not in every bright area. It's something I can live with tbh, as it's better than my raw capture. Just thought it'd be a common problem with an easy fix.


[Attachment 90348 - Click to enlarge]

[Sharc]

I noticed you changed my crop so it's 702x576 - is that just a personal preference or any specific reason you did that?

- to show that it is working without throwing an error
- to remove 2 more pixels of the black bars on the left
- doesn't damage the resizing accuracy
- my stubbornness/obstinacy
- however you name it .....

[Sharc]

Just thought it'd be a common problem with an easy fix.

Not a common problem.
You could try adding after the resizing

KNLMeansCL(d=1,a=2,s=4,h=0.8)  #play with the settings

[WhiteboyUltima]

I noticed you changed my crop so it's 702x576 - is that just a personal preference or any specific reason you did that?

- to show that it is working without throwing an error
- to remove 2 more pixels of the black bars on the left
- doesn't damage the resizing accuracy
- my stubbornness/obstinacy
- however you name it .....

Right... fair.. well I accept your change because I respect your experience

I tried these settings which actually worked really well and has now done a good job at reducing those lines - they wouldn't be obvious at all now unless you put your eyes up to the screen

KNLMeansCL(d=3,a=2,s=4,h=1.6) #Denoiser that fixes diagonal stripes on some areas

Before and after:

[Attachment 90349 - Click to enlarge]
EDIT: The pic shows the denoise strength setting h=1.8 but I've since changed it to 1.6 as it was overblurring a tiny bit in some scenes.

In fact, doing that has meant I was able to turn down the grainLevel of TemporalDegrain2 to it's lowest setting (from 1 to 0). So yes, I am essentially using 2 denoisers now, since I have now added KNLMeansCL after the upscale (but before the ConverttoYV12() which must be at the end right?). Is it normal to use 2 de-noisers like that?

For sharpening, cas(sharpness=0.8) actually worked much better than LSFmod but ultimately I've decided to go with no sharpening at all, I just prefer that soft more original look. Anything else just looks artificial or just looks like you're adding grain.

[Sharc]

Is it normal to use 2 de-noisers like that?

Maybe not "normal", but doing some filtering after an upscale will reduce upscaling artifacts as well. Also, the various denoisers fight the noise differently.
As you have seen there is a lot of experimenting when denoising. And what is good for one clip may not apply the same for the next clip (or scene). Simple answer is "it depends....".

For sharpening, cas(sharpness=0.8) actually worked much better than LSFmod but ultimately I've decided to go with no sharpening at all, I just prefer that soft more original look. Anything else just looks artificial or just looks like you're adding grain.

I am also very hesitant with sharpening. My experience is that many TVs are oversharpening by default, means they thend show some "moiré" for fine textures or test sources. I had to turn it down as well.
Colors, sharpness, noise and tolerated artifacts (e.g. halos) are subject to personal preference - unless something is - more or less obviously - off the kilter.

[WhiteboyUltima]

Alright, thank you guys. This is my final script (for now). It's slow but I'm only doing 3 tapes and this was the trickiest - now that I've learned so much, I can do the other 2 without help I reckon. Please let me know if anything is looking off in the script (at this stage it's really just the order I've done things that I want to check).

AVISource("G:\Video\David's 5th Birthday Capture (Pana ES35V S-Video GV-USB2).avi") #Load AVI File

AssumeTFF() #Set deinterlacing field order to top first

ConverttoYV16(interlaced=true) #Convert colour space to planar while keeping 4:2:2 pixel format intact

QTGMC(Preset="Slow", SourceMatch=3, Lossless=2, MatchEnhance=0.75,Sharpness=0.0) #Deinterlace while retaining as much original details as possible (creating less artificial details)

TemporalDegrain2(degrainTR=3,grainLevel=0,postFFT=0) #Remove some noise. I did have grainlevel =1 before I used KNLMeansCL  later, which removes more noise

Crop(10, 0, -8, -0) #Crops the video to 702x576, removing black borders on sides and gives a more accurate final aspect ratio when upscaled to 1440x1080. Can also crop to 704x576 with Crop(8, 0, -8, -0) which is my usual preferred method and gives slightly narrower faces, but this birthday video had a larger black border on the left that needed removing to make the image appear centred. Always crop in even numbers.

Spline64Resize(1440,1080) #Resize (upscale) to 144x1080 (a HD format), which changes aspect ratio to 4:3. Alternatively consider Lanczos4Resize(1440, 1080)

KNLMeansCL(d=3,a=2,s=4,h=1.6) #Pattern-based denoiser after upscaling that fixes diagonal stripes on some areas of video that appear as a result of using QTGMC

#cas(sharpness=0.8) #Optional: Post-upscaling sharpening
#Letterbox(2, 15, 6, 6) # Optional: Mask the bottom 12 pixels with black to hide VHS head switching noise

ConverttoYV12() #Convert pixel format to YUV 4:2:0 for better compatibility

#Final output render to H.264 MP4 (via x264 encoder) should have colour space also converted to 709 as it is HD.
#The final file will be 8-bit, YUV 4:2:0 in 709 colour space, 1440x1080 50fps H.264 MP4 with AAC audio at 128Kbps bit rate and 48KHz sample rate.

I plan to run this script in VDub and convert to 709 colour space there, and save to HuffyUV for now, so I can observe the full results before worrying about x264 encoder settings in VDub. That will create a 'processed master' file that I'll keep.
I'll then save as a compressed MP4 using x264... unsure whether I should do that straight from my capture file + script processing again, or if I can save time and not run the script again and just re-encode that 'processed master' file?

Also with the final audio compression, is AAC 128Kbps bit rate and 48KHz sample rate pretty standard/acceptable?

[Sharc]

I would keep the original capture file(s) and the script.avs file.
Some time later you might change your mind, find better filters, want to remove halos, apply some chroma sharpening, add color tweaks etc. so it's better to start from the original YUV 4:2:2 capture to avoid irreversible losses.

Also, when you would store your intermediate "master" file in HUFFYUV it will convert (upsample) the current 4:2:0 script output back to 4:2:2, which will for the final encode be converted (downsampled) to 4:2:0 again. Avoid unnecessary color format back-and-forth conversions. They introduce losses and rounding errors. *)

I would directly encode the script using x264 in .mp4 container, using a crf 18 for example as a reasonable compression compromise.

P.S. You can play your script.avs directly in most SW players for checking. It will play terribly slow though, mainly because of the TemporalDegrain2(degrainTR=3) denoiser.

AAC 128kbps is fine.

*) I just noticed that FFMPEG Huffyuv codec variant can encode as 4:2:0 and 4:2:2. But my first point still stands.

[WhiteboyUltima]

So I'm processing the video now in VDub, to HuffyUV (for my intermediate checks) and it's going to take 12 hours...is that normal for a 40min video? 2.68 fps. I'm worried I'll wreck the CPU at this rate.

I have a powerful computer (but average graphics card). How do I make sure it's using all my CPU cores? Is that a VDub setting or in the script? I haven't changed my settings regarding CPU/graphics card settings.

[Sharc]

So I'm processing the video now in VDub, to HuffyUV (for my intermediate checks) and it's going to take 12 hours...is that normal for a 40min video? 2.68 fps. I'm worried I'll wreck the CPU at this rate.

I have a powerful computer (but average graphics card). How do I make sure it's using all my CPU cores? Is that a VDub setting or in the script? I haven't changed my settings regarding CPU/graphics card settings.

It is "normal". I told you before that TempralDegrain2() is very slow.
You can try
- adding Prefetch(x) as last line to your script, with x being ~the number of cores of your CPU, e.g. Prefetch(8) to begin with.
- Reduce the temporal radius of TemopralDegrain2() to 1 or 2, like TemporalDegrain(degrainTR=1). Of course this will have an impact on the denoising.
- Substitute TemporalDegrain2() by the much faster MCDegrainSharp(frames=3) and see what you get.

And your intermediate Huffyuv just for inspection (for the full length of the video) doesn't make much sense IMO. Encode directly as x264.

P.S.
In post#125 I suggested a script which you can use to compare different filtering variants in AvsPmod.

[wcndave2]

You're going to have to get @sharc and @Alwyn something nice for christmas! Talk about helpful!

[WhiteboyUltima]

You're going to have to get @sharc and @Alwyn something nice for christmas! Talk about helpful!

They deserve major kudos, I agree! I've learned so much here so far.

[WhiteboyUltima]

So I'm processing the video now in VDub, to HuffyUV (for my intermediate checks) and it's going to take 12 hours...is that normal for a 40min video? 2.68 fps. I'm worried I'll wreck the CPU at this rate.

I have a powerful computer (but average graphics card). How do I make sure it's using all my CPU cores? Is that a VDub setting or in the script? I haven't changed my settings regarding CPU/graphics card settings.

It is "normal". I told you before that TempralDegrain2() is very slow.
You can try
- adding Prefetch(x) as last line to your script, with x being ~the number of cores of your CPU, e.g. Prefetch(8) to begin with.
- Reduce the temporal radius of TemopralDegrain2() to 1 or 2, like TemporalDegrain(degrainTR=1). Of course this will have an impact on the denoising.
- Substitute TemporalDegrain2() by the much faster MCDegrainSharp(frames=3) and see what you get.

And your intermediate Huffyuv just for inspection (for the full length of the video) doesn't make much sense IMO. Encode directly as x264.

P.S.
In post#125 I suggested a script which you can use to compare different filtering variants in AvsPmod.

I did generate that HuffyUV video, but I see what you mean that it was kind of pointless because I can always preview in AVSPmod. Won't be doing that again! At least adding Prefetch(8) reduced the time taken from 12h to 10h.

What I ended up doing is addressing why the diagonal lines were appearing in the first place, since I wasn't happy with just using a fairly aggressive second denoiser after upscaling (KNLMeansCL()) - it had the side effect of making everything blurrier and at lower intensity it didn't remove the lines.

I noticed that if I changed QTGMC from 'slow' to 'fast', the diagonal lines were 99% gone. But, that did introduce less accurate motion frame-to-frame, so I kept 'slow' and instead set SourceMatch and LossLess to 0. That retained the good motion, and slightly lessened the intensity of those diagonal lines. ('medium' had the same motion inaccuracies as 'fast'). So I am putting up with a small amount of diagonal lines to benefit the rest of the tape; they are very hard to see and really only in 1 short scene. In fact, maybe 'fast' only got rid of them because QTGMC is doing some extra smoothing/denoising in the background; that's hard to notice elsewhere though.

I am still using TemporalDegrain2() for my main noise removal before upscaling, which is working really well and I've now reduced that to degrainTR=2 and increased grainLevel from 0 to 1. So it will process faster but also has that sweet spot for TR I believe - TR=3 was a bit much. No need to use the suggested MCDegrainSharp now I think.


So now my script is this:

AVISource("G:\Video\David's 5th Birthday Capture (Pana ES35V S-Video GV-USB2).avi") #Load AVI File

AssumeTFF() #Set deinterlacing field order to top first

ConverttoYV16(interlaced=true) #Convert colour space to planar while keeping 4:2:2 pixel format intact

QTGMC(Preset="slow", SourceMatch=0, Lossless=0, Sharpness=0.0) #Deinterlace with 'slow' for best motion, introduces faint diagonal lines in some areas

TemporalDegrain2(degrainTR=2, grainLevel=1, postFFT=0) #Remove some noise.

Crop(10, 0, -8, -0) #Crops the video to 702x576, removing black borders on sides and gives a more accurate final aspect ratio when upscaled to 1440x1080.

Spline64Resize(1440,1080) #Resize (upscale) to 144x1080 (a HD format), which also changes aspect ratio to the correct 4:3 (PAL was stored at 5:4 to be displayed on 4:3 CRTs).

ConverttoYV12() #Convert pixel format to YUV 4:2:0 for better compatibility.

Prefetch(8) #Use all 8 processor cores

How's it looking? I will encode to MP4 and report back. Note I am not using any sharpener or injecting any film grain, personal preference there (not sure what the 'norm' is here).

[WhiteboyUltima]

Sorry for triple post but, are these settings ok for the video compression? Starting with CR18, and I chose 'Film' for tuning as per some google recommendations. My video is currently processing - this time with 1hour 40 mins estimated time instead of 10h!


[Attachment 90419 - Click to enlarge]

[Sharc]

- this time with 1hour 40 mins estimated time instead of 10h!

Are you encoding your script or your intermediate huffyuv file?

[WhiteboyUltima]

- this time with 1hour 40 mins estimated time instead of 10h!

Are you encoding your script or your intermediate huffyuv file?

My script. It just finished: 2GB file size compared to the original 18GB. It looks good, compared to the uncompressed one I made there's very little difference when I look at the same freeze frame. I might try CRF16 though, since I'll be taking screenshots of some parts to keep and I can definitely spare more disk space

Weird thing is the audio keeps saving at 254kbps instead of 128kbps like I tell it to...
Also, was 'film' the right tuning option for x264?

[Sharc]

Also, was 'film' the right tuning option for x264?

There is no right or wrong here. Same with many other optimizations. I would probably set it to none.
For info see the "tune" section in the x264 wiki which also lists and explains all the other x264 settings.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm

[WhiteboyUltima]

Merry Christmas!

I compared the x264 encoder with tuning set to 'film' and also set to 'none', and the difference is incredibly small. 'Film' seems to retain a microscopic amount more unwanted grain during encoding, including a tiny bit more of the unwanted diagonal lines. Not sure if it's keeping more genuine detail. It's such an insignificant difference that I'm second guessing myself. The resulting video bitrate is about 400kbps lower in the file with no tuning applied (I assume because it's keeping less grain/detail).

I'm going to stick with no tuning for that ever so slightly smoother look in areas where you can see those diagonal lines, but it's really not much diff. In either case I've been using the 'veryslow' preset and CRF16. Very happy with the overall results.

I still can't figure the audio bitrate out though. It keeps the 48000 KHz I specify just fine. But no matter what I set the bitrate, the final result is not what I set it to according to MediaInfo and Windows Properties. e.g. if I set 128Kbps, the result is 258Kbps, and if I set 192Kbps, the result is 257Kbps... strange.

[Alwyn]

Try this:


[Attachment 90437 - Click to enlarge]

[WhiteboyUltima]

Try this:


[Attachment 90437 - Click to enlarge]

Thanks Alwyn - appreciate you replying on Christmas! I reckon the audio bitrate being 257kbps in my final file doesn't really matter, unless for some reason it won't play on some devices/software? And setting it to 96k doesn't guarantee a result of something 'standard' like 128kbps. Seems like there's no way to actually set it to something where you'd get a reliable desired output number - it's a bit random. I'd have to experiment for quite a while and wait 2-4 hours in-between each attempt, which isn't the best use of my time!

That's my way of saying I think I'm actually done now with this tape (assuming my 257kbps file can still play on most devices)

[Alwyn]

And setting it to 96k doesn't guarantee a result of something 'standard' like 128kbps. Seems like there's no way to actually set it to something where you'd get a reliable desired output number - it's a bit random.

No it's not. 96 per channel will give you exactly 192 total every time, unless your source file is corrupted or something is awry with your system. Merry Christmas!

[WhiteboyUltima]

And setting it to 96k doesn't guarantee a result of something 'standard' like 128kbps. Seems like there's no way to actually set it to something where you'd get a reliable desired output number - it's a bit random.

No it's not. 96 per channel will give you exactly 192 total every time, unless your source file is corrupted or something is awry with your system. Merry Christmas!

If that's the case then why did it result in 257kbps when I set it at 192kbps per channel? That's not double.

I will try setting it to 96 per channel and see what happens...

[Alwyn]

Did another test, setting 192 per channel. I got:

Bit rate mode : Variable
Bit rate : 265 kb/s
Maximum bit rate : 384 kb/s
Channel(s) : 2 channels

Setting 96 per channel, I got this:
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels

Must be a changeover at some point from Constant to Variable. That'd be why you're getting the "odd" bit rate.

I've read anything over 192 total for VHS is overkill.

[WhiteboyUltima]

Did another test, setting 192 per channel. I got:

Bit rate mode : Variable
Bit rate : 265 kb/s
Maximum bit rate : 384 kb/s
Channel(s) : 2 channels

Setting 96 per channel, I got this:
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels

Must be a changeover at some point from Constant to Variable. That'd be why you're getting the "odd" bit rate.

I've read anything over 192 total for VHS is overkill.

I can't find any way to change it to CBR or VBR, looks like it's doing VBR by itself and the final bitrate just depends on the audio of the tape in question. No worries, as long as it plays on most devices that's the important part!

[Sharc]

My best guessing is that Vdub uses the "native" FFmpeg AAC Encoder.

Excerpt from the ffmpeg wiki:

The native FFmpeg AAC encoder. This is currently the second highest-quality AAC encoder available in FFmpeg and does not require an external library like the other AAC encoders described here. This is the default AAC encoder.

By default, the native encoder produces AAC-LC, which is a "low complexity" profile of baseline AAC. It actually supports the more powerful "main" and "long-term prediction" profiles (documentation), but these are less tested.
.....
This VBR is experimental and not guaranteed to give better results than the CBR. Native FFmpeg AAC Encoder does not really do CBR audio encoding. For Bluetooth Headphones an option was added to force CBR but that instead makes quality subpar (-bit_rate_tolerance 0).

=> If you want full control over the encoder parameters (CBR, VBR etc.) you would have to use commandlines or a script.
In practice one most probably won't notice any quality difference for 1 or 2 channel VHS audio sources though.

P.S. Device/playback compatibility: What "most devices" are and accept I don't know. Depends on the time axis as well. In general, the lower the profiles (settings) the more devices (including ancient) will support it......