PAL to NTSC using pulldown excessive judder

[mistateo]

I am converting a DVD from PAL to NTSC. This DVD was only ever released as PAL, I'm not buying another dvd player, I have already gone through the hassle of designing all of the menus and creating art for the dvd jacket and printable disc (yes I'm old). My process was: rip entire source dvd, create a d2v file (and demux the ac3 audio files) using dgindex, re-encode in tmpgenc to non-interlaced at 25 FPS while resizing to 720x480, then running the result through dgpulldown for 25 -> 29.97. I followed this guide here, to the T: https://forum.videohelp.com/threads/241000-How-to-convert-a-PAL-DVD-to-a-NTSC-DVD-usin...GEnc-Plus-2-5x.

I authored the dvd in dvdlab pro2 and watched on my standalone dvd player. What I noticed is that the judder is noticeably more severe than watching regular "film" content shot at 24 FPS and using pulldown to make 29.97. When credits are scrolling, the judder is so bad it's hard to read the words. When I watch the original dvd on my computer, of course it looks great. The effect is much more dramatic with fluid movement scenes (like camera panning up/down, side/side, or especially with rolling credits). I have no issue with audio sync, so that's good.

So I am trying to figure out if the 25->29.97 pulldown technique is just limited (with bad judder as a natural consequence) and there are better methods, or if I did something wrong during the encoding process. About the content: it is a Japanese anime series that was later dubbed in the US. The original source was shot on film, 24FPS, originally released in NTSC format on dvd in Japan. Due to licensing rights, the American dubbing company never released the first volume in the US to complete the series (that is the one I am converting because it WAS released in Australia in PAL format). Eventually when the American dubbing company obtained the rights, rather than finally releasing that ONE volume, they decided to make a whole NEW box set for the entire series that included more zoom (cropping) and excessive DNR filters to remove all of the grain (charm).

When I compared the length of episode 1 from the "new box set" to the length of episode 1 of my encoded video, I determined they did NOT use the "PAL speedup" technique, more bluntly: the length is the same. This means they used a different (and currently unknown to me) method to create the 25 FPS PAL version from the 24 FPS source material. When I was in the encoding phase, I could definitely see what appeared to be "interlacing artifacts" (the telltale lines on some frames) when looking through the video. Since it was present, I used the deinterlace filter in tmpgenc (animation adaptation). From all the information I have read, my source video (PAL 25FPS, looks interlaced, created from 24FPS content without duration change) is not truly interlaced BECAUSE the original source was 24FPS and not 25FPS. It is more likely to be either field blending, or adding in duplicate frames etc. If that is true, than possibly the 25->29.97 pulldown I did on my video was not the judder culprit, but it was the method I chose to "deinterlace" the source video. Is that a reasonable statement? If so, what is a good method to reliably determine how they went from 24 FPS to 25 FPS (without duration change) so I can "undo" it?

I am looking to get the best possible conversion I can achieve, and am totally willing to use avsynth or other tools if there is a benefit to doing so. I am happy to figure out how to upload short clips, or try things and report back. I won't be "that guy" who gets an answer and just disappears forever.

[ConsumerDV]

re-encode in tmpgenc to non-interlaced at 25 FPS while resizing to 720x480, then running the result through dgpulldown for 25 -> 29.97.

I would slow it down from 25p to 24p, then author a DVD. An authoring program should re-encode it to MPEG-2 and add pulldown flags as needed. I see that you don't want to slow it down because it has not been sped up in the first place.

Well, actually I would do nothing, as my OPPO player can play PAL DVDs.

Is this a rare anime that cannot be found on torrents?

[jagabo]

Irip entire source dvd, create a d2v file (and demux the ac3 audio files) using dgindex, re-encode in tmpgenc to non-interlaced at 25 FPS while resizing to 720x480, then running the result through dgpulldown for 25 -> 29.97.

I used to do it that way (I don't make DVDs anymore) and always go results that didn't have significantly more judder than normal NTSC DVDs.

they used a different (and currently unknown to me) method to create the 25 FPS PAL version from the 24 FPS source material.

It most likely was made from an interlaced NTSC source (studio video tape) run through a standards converter, and digitized in real time on a PAL tape recorder and later digitized. Hence no change in running time. But those standards converter blend fields together and decimate to change the frame rate. These require special unblending procedures which usually require AviSynth or VapourSynth to unblend and create smooth results.

You should upload a short sample of your source -- without reencoding. Use DgIndex to extract a clip (include some character animation and a medium speed panning shot from the body of the episode, not the intro) and upload it here. Open VOB source, mark-in, mark-out, Save Project and Demux Video. Upload the resulting m2v file.

[Sharc]

.... The original source was shot on film, 24FPS, originally released in NTSC format on dvd in Japan.

..... I determined they did NOT use the "PAL speedup" technique, more bluntly: the length is the same. This means they used a different (and currently unknown to me) method to create the 25 FPS PAL version from the 24 FPS source material.

They may have used 2:2:2:2:2:2:2:2:2:2:2:3 "Euro-pulldown" to convert 24FPS film to 25FPS PAL. When you step through the frames do you see something like 13 progressive frames followed by 12 interlaced (combed) frames? If so, it can be converted back from 25FPS PAL to clean 24FPS progressive film, and then apply standard 3:2 telecine to convert it to 29.97 NTSC, using AviSynth.

Upload a sample of the unprocessed 25FPS PAL original; select a scene with motion or horizontal panning.

[mistateo]

Hey guys, thank you for the reply! Here is a horizontal panning shot that I got straight from dgindex. I feel like it may be relevant to say that I had "honor pulldown flags" checked.

https://files.videohelp.com/u/301071/SidePan.demuxed.m2v

[Sharc]

It is not Euro-pulldown as there are blended fields.
You can try something like this to restore the 24FPS progressive frames:

assumeTFF()
QTGMC(preset="fast") #or a bobber of your choice
srestore(frate=24.0)

From here onwards you can use standard telecine (or soft-pulldown) for converting to 29.97FPS NTSC.

e.g. Script for hard-telecining:

assumeTFF()
QTGMC(Preset="Fast")
srestore(frate=24.0/1.000,mode=2) # 24FPS progressive
spline36resize(720,480) #NTSC framesize
SelectEvery(2,0,0,0,1,1).SeparateFields().SelectEvery(4,0,3).Weave() #30FPS hard telecined
assumefps(30.0/1.001) #29.97 FPS

[mistateo]

The concept of "field blending" is a new one to me as I previously heard most 24-25 fps conversions were just sped up. But it has landed me some very interesting search results. Apparently Madman anime DVDs (like my source DVD) are notorious for field blending. Seems like srestore is my only hope of getting back to a 24fps progressive output. I just installed avisynth and did a good bit of reading. This seems like a much better way to go rather than relying on TMPGEnc exclusively (even when not dealing with a field blending problem).

[Sharc]

Yes, Avisynth is a good investment of your time.
Here the pulldown variant.
There are still some weak blends in both variants.
Maybe someone proposes a better solution.

[mistateo]

I am quickly finding that avisynth is a game of dependency hell. One error message after another. I think I went wrong with installing avisynth 2.6 (x86) instead of avisynth+. I will try again tomorrow.

[jagabo]

Yes, it's the usual analog NTSC to analog PAL field blended conversion process. There's still a little mild blending after converting back to NTSC film (I don't think there's any way to avoid that):

Mpeg2Source("SidePan.demuxed.d2v", CPU2="ooooxx", Info=3) 
QTGMC()
SRestore()
Spline36Resize(720,480)

That restores the original 23.976 fps without any change in running time. Encoded as 24p with soft pulldown with HCGUI:

[jagabo]

I am quickly finding that avisynth is a game of dependency hell. One error message after another.

Yes. And QTGMC is one of the hardest filters to get set up because it requires a lot of other filters be installed too.

I think I went wrong with installing avisynth 2.6 (x86) instead of avisynth+. I will try again tomorrow.

Yes, use AviSynth+. 32 bit if you are using a 32 bit editor/encoder, 64 bit with a 64 bit editor/encoder. 32 bit filters go in AviSynth's plugins+ folder. 64 bit filters go in AviSynth's plugins64+ folder. As you download and install all the required filters check the instructions for those filters -- some require other filters too. And some of them are system dll files that go in C:\Windows\SystemWOW64 (32 bit dlls) or C:\Window\System (64 bit dlls) -- I think it's only libfftw3f.dll and fftw3.dll.

[mistateo]

I will get avisynth/plugins/etc reinstalled and give another whack at this all when I get off work tonight.

I do have some other questions in the mean time:

1. Any idea if I would get better results encoding with HCGUI instead of my usual TMPGENC Plus 2.5, or if there are other benefits, compromises etc?

2. Regarding GOP length for encoding: it seems like my source is 15, the guide I was following (referenced in first post) recommended 12, maximum for NTSC is 18. What to choose?

3. So it seems Srestore is the most critical (required), but about the others like resizing for example, is Spline36Resize the "preferred" method over say "LanczosResize"? Or QTGMC vs Yadif1 etc? I haven't looked at dvd authoring/encoding for nearly 20 years so I'm not up to date on best practices and newer methods.

4. Once I get back to 24 FPS progressive video, is there a preferred method between hard telecine and pulldown to achieve 29.97 FPS since I am looking for best possible quality? My Dvd players are capable of progressive scan output, so does that make pulldown an easy choice?

[jagabo]

1. Any idea if I would get better results encoding with HCGUI instead of my usual TMPGENC Plus 2.5, or if there are other benefits, compromises etc?

It's been ages since I really used either. I seem to recall that HcEnc gave a little better quality. But TMPGEnc has some filtering abilities that many people used. Even back then I was using AviSynth for filtering so that didn't matter to me.

2. Regarding GOP length for encoding: it seems like my source is 15, the guide I was following (referenced in first post) recommended 12, maximum for NTSC is 18. What to choose?

With MPEG 2 encoders the quality of the encoding decreases with the length of the GOP (other limitations aside). So the shorter the GOPs the higher the quality. But you also get less effective compression with shorter GOPs (I frames are biggest of all, P frames are smaller, B frames smallest). So you have to consider the running time that will fit on a disc -- some compromise settings of GOP size and bitrate.

3. So it seems Srestore is the most critical (required),

Yes, SRestore is needed here to preferentially remove the blended frames (which were fields before deinterlacing). Other decimation techniques don't have special algorithms for dealing with blending.

but about the others like resizing for example, is Spline36Resize the "preferred" method over say "LanczosResize"?

Spline36 is less sharp but produces less oversharpening halos as Lanczos. Which resizer you use depends on how sharp your source is and your personal preference. Use whatever resizer you think looks best for the particular video. Sharper isn't always better. Also keep in mind that the sharp resizers increase noise. And noise makes video less compressible.

Or QTGMC vs Yadif1

QTGMC is usually much better (and slower) than Yadif. It includes motion estimation techniques to help determine what the missing field should look like. It also applies post processing filters to reduce aliasing artifacts and the buzzing edges they produce.

I haven't looked at dvd authoring/encoding for nearly 20 years so I'm not up to date on best practices and newer methods.

Either have I. I don't think there's much new in DVD encoding. What happens before the encoding is what matters here.

4. Once I get back to 24 FPS progressive video, is there a preferred method between hard telecine and pulldown to achieve 29.97 FPS since I am looking for best possible quality?

Encoding progressive with soft 3:2 pulldown flags gives the best quality. Progressive encoding gives better results than interlaced encoding. Having fewer frames to encode (24 per second vs 30 per second) gives better encoding.

My Dvd players are capable of progressive scan output, so does that make pulldown an easy choice?

Soft pulldown allows the player to skip the pulldown and send progressive frames to the TV. This gives better results than having the player or TV trying to deinterlace or IVTC interlaced video during playback.

[mistateo]

Thank you for answering all of my questions! I removed avisynth and installed avisynth+ and got the newest x86 versions of the filters/scripts required for QTGMC and Srestore. I was then finally able to open up the avs file in virtualdub so avisynth appears to be happy now. I was able to do an encode with TMPGEnc using my avs script as the video source. I still need to figure out how to use HCGui to compare results. For whatever reason, no matter what I set the encode button was grayed out and there was a warning about the video being the wrong framerate, but I will try to figure out what went wrong there.

Either I am blind or it really isn't listed anywhere easy to find, but is HCEnc/HCGui 32 or 64 bit? Also, I am now a little confused on colorspaces. I noticed in several other threads, when people were encoding with TMPGENC, they had "ConvertToRGB" or "ConvertToRGB24" at the end of their scripts (but not always). Some people using HCEnc had "ConvertToYUV12" at the end, but not consistently. Given that my source is a PAL DVD (not sure if it matters if it was an NTSC tape before that or not), do I need to run any color space conversions before serving to TMPGEnc or HCEnc like those guys did, and if so, which method is correct for each encoder?

[davexnet]

Post your script and also some screen shots of the HCenc Gui
setup screens.
You would normally have

ConvertToYV12()

as the colorspace for HCenc

[jagabo]

HCGUI supports YUY2 and YV12 as input. You want YV12 for DVD. Your AviSynth script is probably putting out YV12 already. Unless you changed it yourself. You can check by adding Info() at the end of the script and viewing the result in VirtualDub2 or Avspmod. That will also show you the frame rate -- which should be 23.976.

[Sharc]

For whatever reason, no matter what I set the encode button was grayed out and there was a warning about the video being the wrong framerate, but I will try to figure out what went wrong there.

HCenc expects 23.976 or 29.97 as valid framerates for NTSC, rather than 24 or 30. So set SRestore(frate=23.976) and/or add AssumeFPS(24.0/1.001) to the end of your script.
Your DVD source is already in colorspace YV12, so you need not to convert it, but it does no harm to add ConvertToYV12() to be on the safe side.

[mistateo]

Post your script and also some screen shots of the HCenc Gui
setup screens.
You would normally have

ConvertToYV12()

as the colorspace for HCenc

Not sure what my problem was the first time I tried. Had no issue with it today. Maybe it was something as trivial as not specifying the output file, not sure.

[mistateo]

So I want to thank everyone for their help so far. I haven't done a full encode and put it on disc for a tv test yet, but I am pretty confident this new approach with avisynth,QTGMC and Srestore will look WAY better and smoother than the last approach of deinterlacing the pal frames and then using pulldown to go from 25 (blended) fps -> 29.97 fps. Having said that, I am hoping there is a little more juice to squeeze.

For comparison sake, I made a 30 second clip from the intro of the show from the pal disc, and the same 30 second clip from an ntsc disc of the same series (same exact intro). For the NTSC test I kept it as simple as possible just to get to 24 fps:

LoadPlugin("....dgmpgdec\DGDecode.dll")
MPEG2Source("...\Experiment\NTSCIntro.d2v")
Telecide()
Decimate()

For the PAL Intro the script was:

LoadPlugin("....dgmpgdec\DGDecode.dll")
MPEG2Source("...\Experiment\PALIntro.d2v")
assumeTFF()
QTGMC()
Srestore(frate=23.976)
Spline36Resize(720,480)
Crop(6,4,-6,-4)
AddBorders(6,4,6,4)
ConvertToYV12() #HCEnc (optional as it should already be YV12)

I then went through the two in virtual dub frame by frame and the ntsc one appears to be a perfect conversion back to 24 fps, with NO blending/ghosting (not sure if those words are interchangable). The PAL one was PRETTY GOOD. I know for sure it is Top Field First, because it was horrific when trying Bottom Field First. However, there are still SOME frames with blending/ghosting. I didn't notice any mathematic relationship between the frame numbers that it happened on. They seem to mainly be on parts with rapid object movement and scene changes. However the amount of these blended frames are FAR less than my first attempt (not using avisynth), so it may end up being totally watchable. But since I am here, I figured I would ask if anything further can be done (short of manual frame fixes) to try and reduce the number of blended frames. Perhaps arguments for QTGMC or Srestore I might try etc.

Here are some example frames: PAL vs NTSC

[mistateo]

To answer my own last question, it appears QTGMC and Srestore is about as good as it gets for this source at this time. I was able to mess around with various things to reduce the (already comparatively low) amount of blended frames, but at the cost of losing motion fluidity. It didn't even work in all cases. Then when I was stepping through the untouched individual source fields during "rapid motion" scenes, it became clear to me that there were not enough "non-blended fields" to actually create enough "non blended frames", no matter what tools I have. It appears to be a consequence of the original NTSC -> PAL conversion method to make the source DVD. Kinda makes me wish they had either gone with euro pulldown or speedup. Each would have been easier to deal with (only 2 channel audio). However, I am pretty sure this result with minor residual blends at 24 fps (or 30 with pulldown) will look a hell of a lot smoother than the 25 fps constantly blended mess pulled down to 30 fps using a more complex pattern...

Anyway, I am going to run a test encode for a couple episodes to burn a couple single layer dvd-r discs. One with TMPGEnc and one with HCEnc and see if I can even tell a difference, and how they look in progressive vs pulldown mode on my standalone player and tv. I am fishing for any last minute critique on either my encoder settings, or if it's bad to do the crop before resize etc. FWIW, the analysis log for TMPGEnc showed average bitrate of 4800, is my 6000 average overkill? This is my avisynth script for both, with the only difference being the ConvertToRGB24 when using TMPGEnc:

LoadPlugin("...\dgmpgdec\DGDecode.dll")
MPEG2Source("...t\IntroPAL.d2v")
assumeTFF()
QTGMC() #Magical bobbing stuff
sRestore(frate=23.976) #Convert to progressive
Spline36Resize(720,480,3,2,-3,-2) #Crop 3 from each side 2 from top and bottom before resize
#ConvertToRGB24() #TMPGEnc Only

Here are the screenshots for HCEnc (I didn't touch anything outside of the Main tab, along with a warning during encoding):




Here are the screenshots for TMPGEnc:

[Sharc]

I would say that you are on the right track with your conclusions and planned tests. Let your eyes decide eventually

Cropping/resizing:
The frame size for NTSC DVD compliance must be 720x480 or 704x480. Usually it is 720x480, so your cropping before resizing is basically correct, unless you pad the cropped picture with new black borders for 720x480 overall frame size. Just keep in mind that cropping horizontally and vertically incorrectly may distort the aspect ratio of the picture, assuming that the cropped picture is played as 4:3 by the playback device. But as you did the cropping and resizing now looks correct to me.

Edit:
As you want to author DVDs later I would recommend to press the "make DVD compliant" button in HCencGUI as a sanity check, and see what it reports in the info.

[jagabo]

Then when I was stepping through the untouched individual source fields during "rapid motion" scenes, it became clear to me that there were not enough "non-blended fields" to actually create enough "non blended frames"

Exactly. If there was an equal amount of blending in all frames it would be possible to remove it. But that's not the case with this type of frame rate conversion. There is a filter called AnimeIVTC. I've never used it but it may work better.

http://avisynth.nl/index.php/AnimeIVTC#I.29_About_anime_telecining

makes me wish they had either gone with euro pulldown or speedup. Each would have been easier to deal with

Both of those require going back to the original film (which may not even exist anymore). Or at least IVTC of an NTSC tape. It's much easier (cheaper) to stick the tape into an analog standards converter. So this type of conversion is all too common.

The analysis log for TMPGEnc showed average bitrate of 4800, is my 6000 average overkill?

How much you plan to put on each DVD should be your guide. At 6000 kbps you can only put about 90 minutes on a DVD. At 4800 you're looking at 112 minutes. That may be the difference between 3 and 4 episodes per disc.

[mistateo]

I would say that you are on the right track with your conclusions and planned tests. Let your eyes decide eventually

Cropping/resizing:
The final frame size for NTSC DVD compliance must be 720x480, so cropping before resizing is basically correct, unless you pad the cropped picture with new black borders for 720x480 overall frame size. Just keep in mind that cropping horizontally and vertically incorrectly may distort the aspect ratio of the picture, assuming that the cropped picture is played as 4:3 by the playback device. But as you crop it now it looks correct to me.

Edit:
As you want to author DVDs later I would recommend to press the "make DVD compliant" button in HCencGUI as a sanity check, and see what it reports in the info.

Yeah, the crop was just to remove that soft edge. When I originally cropped, I chose 3 for left/right and 2 for top/bottom since 720/480 = 3/2 and it was enough to get clean lines. That being said, since my source material is 720/576 = 5/4, maybe that would be more correct, I don't know. Speaking of resizing from 576 to 480, since neither 720x480 or 720x576 are 4/3 ratios, I am guessing there is no crop involved in the resize, and that the height/width ratios for the tv pixels are different between PAL and NTSC.

I clicked on the dvd compliant button and it didn't change anything. However, when I manually set DC precision to 11 (not dvd spec), or uncheked pulldown (since source is 24fps for all hcenc is concerned), clicking the dvd compliant button changed those settings back. Guessing it would also change non compliant resolutions etc.

[mistateo]

Then when I was stepping through the untouched individual source fields during "rapid motion" scenes, it became clear to me that there were not enough "non-blended fields" to actually create enough "non blended frames"

Exactly. If there was an equal amount of blending in all frames it would be possible to remove it. But that's not the case with this type of frame rate conversion. There is a filter called AnimeIVTC. I've never used it but it may work better.

http://avisynth.nl/index.php/AnimeIVTC#I.29_About_anime_telecining

makes me wish they had either gone with euro pulldown or speedup. Each would have been easier to deal with

Both of those require going back to the original film (which may not even exist anymore). Or at least IVTC of an NTSC tape. It's much easier (cheaper) to stick the tape into an analog standards converter. So this type of conversion is all too common.

The analysis log for TMPGEnc showed average bitrate of 4800, is my 6000 average overkill?

How much you plan to put on each DVD should be your guide. At 6000 kbps you can only put about 90 minutes on a DVD. At 4800 you're looking at 112 minutes. That may be the difference between 3 and 4 episodes per disc.

AnimeIVTC was one thing I experimented with. Messing around with it, I DID achieve a slightly lower blend count, BUT it made the motion less fluid. For my final output I am using double layer discs, so I know the framerate and duration for all movies, along with the size for all combined audio and subtitles etc. So I know how to pretty accurately calculate the average bitrate to fill up the dual layer disc (leaving a little wiggle room for layer break selection). I just didn't know if there was much point in going with an average bitrate 20% larger than the source average bitrate.

[Sharc]

Speaking of resizing from 576 to 480, since neither 720x480 or 720x576 are 4/3 ratios, I am guessing there is no crop involved in the resize, and that the height/width ratios for the tv pixels are different between PAL and NTSC.

Yes. The PAR (Pixel Aspect Ratio) for 4:3 PAL DVD is 16:15, while for 4:3 NTSC DVD it is 8:9.
Cropping does not change the Pixel Aspect Ratio, while resizing does.

[Skiller]

I would not use TMPGEnc 2.5(ish). In all of my years (~17) of encoding MPEG2 I never found it to beat any of the other common encoders (well, maybe except QuEnc, but that one should not be used anyways, imo). It's only decent encoding mode is CQ. It has issues in 2-pass VBR.


In HCenc:

• Do not use closed GOPs (it's for special applications and reduces quality)

• Assuming there is one or two stereo audio tracks, max video bitrate of 8000 is unnecessarily low and will limit quality.
HC is very cautious of the max bitrate entered and will almost always barely even touch it. With 1 stereo audio track I would use 9400, with 2 tracks I would use 9200.

• LumGain 1 or 2 is probably a good idea for Anime to prevent blocking in dark flat areas.

• Matrix "MANONO3" is better for Anime than MPEG (less mosquito noise).

[jagabo]

• Do not use closed GOPs (it's for special applications and reduces quality)

While that's true, if you ever think you might want to edit the video in the future use closed GOPs. Many editors don't work well with open GOPs. Quality won't suffer much at the kind of bitrates being used here.

[mistateo]

I would not use TMPGEnc 2.5(ish). In all of my years (~17) of encoding MPEG2 I never found it to beat any of the other common encoders (well, maybe except QuEnc, but that one should not be used anyways, imo). It's only decent encoding mode is CQ. It has issues in 2-pass VBR.


In HCenc:

• Do not use closed GOPs (it's for special applications and reduces quality)

• Assuming there is one or two stereo audio tracks, max video bitrate of 8000 is unnecessarily low and will limit quality.
HC is very cautious of the max bitrate entered and will almost always barely even touch it. With 1 stereo audio track I would use 9400, with 2 tracks I would use 9200.

• LumGain 1 or 2 is probably a good idea for Anime to prevent blocking in dark flat areas.

• Matrix "MANONO3" is better for Anime than MPEG (less mosquito noise).

After comparing the two output files, it seems like HCEnc wins, hands down. TMPGEnc froze after analysis, wouldn't encode. Restarted and it worked. Both videos showed the same number of frames in Virtualdub, at 24 DF. In my dvd authoring program, it was convinced that the TMPGEnc video was 2 seconds shorter. HCEnc video was correctly identified as 2:3 pulldown DF, where TMPGenc showed 3:2 pulldown (without DF). DUring DVD compilation, TMPGEnc file gave several warnings about VOB length mismatch, the HCEnc one was clean. Bitrate for TMPGEnc file was reported as 7k, where HCEnc file was reported as 6k (correct). Both files were almost identical in size.

Regarding closed GOPs, after doing additional research, it seems like it's a tradeoff between compressibility and fault tolerance (defects being limited to one GOP length). I will experiment.

The video bitrate choice was what I calculated to utilize almost all of the double layer dvd (leaving a small gap for layer break placement), containing all of the same episodes, bonus feature, and trailers of the original disc. Yes, the trailers are a waste of 2 min of video time, but practically inconsequential to the quality of the episodes. The source bitrate is also pretty low to begin with. You helped me crack that overlapping button (invisible button highlighting) feature I wanted in another thread a little while ago, this is that same project.

I will try out the Lumgain, I have identified a perfect area of the video to test.

Thank you for the tip about the matrix. I looked up video mosquito noise because I am still learning the terminology. This website has some great visual examples of compression artifacts: https://blog.biamp.com/understanding-video-compression-artifacts/

[mistateo]

Speaking of resizing from 576 to 480, since neither 720x480 or 720x576 are 4/3 ratios, I am guessing there is no crop involved in the resize, and that the height/width ratios for the tv pixels are different between PAL and NTSC.

Yes. The PAR (Pixel Aspect Ratio) for 4:3 PAL DVD is 16:15, while for 4:3 NTSC DVD it is 8:9.
Cropping does not change the Pixel Aspect Ratio, while resizing does.

Plenty of new topics for me to go research. This seems to confirm my suspicion of non-square pixels in TVs. Though a quick google search would have told me also, I'll learn someday. This also led me to the debate on 704x480 vs 720x480. Since I own no CRT TVs, I think 720x480 should be fine.

[Sharc]

Speaking of resizing from 576 to 480, since neither 720x480 or 720x576 are 4/3 ratios, I am guessing there is no crop involved in the resize, and that the height/width ratios for the tv pixels are different between PAL and NTSC.

Yes. The PAR (Pixel Aspect Ratio) for 4:3 PAL DVD is 16:15, while for 4:3 NTSC DVD it is 8:9.
Cropping does not change the Pixel Aspect Ratio, while resizing does.

Plenty of new topics for me to go research. This seems to confirm my suspicion of non-square pixels in TVs. Though a quick google search would have told me also, I'll learn someday. This also led me to the debate on 704x480 vs 720x480. Since I own no CRT TVs, I think 720x480 should be fine.

The non-square pixels are part of the DVD format. Non-square pixels of digital video and the various aspect ratios and "frame resolutions" are a subject of its own, and you risk to open a can of worms when you dive deeper into the subject.
When you find confusing numbers, definitions, standards and tools it is always helpful to remember the basic concepts of cropping and resizing
But what you have done so far for your PAL DVD to NTSC DVD conversion is correct.