logo Sign In

Star Trek Deep Space Nine - NTSC DVD Restoration & 1080p HD Enhancement (Emissary Released) — Page 6

Author
Time
 (Edited)

Joel Hruska said:
Alright. Now I see it. If that’s what you call a major anti-aliasing problem, I strongly suggest you never watch the NTSC credits. I cannot upload them to YouTube in SD because the YT algorithm utterly destroys SD content, so I have to give you screenshots – but take a look.

Looks like shifted fields. Can you upload the credits, or a few seconds of it, without conversion somewhere?
I do not understand where the problem realy lies?

Look at the degree of aliasing in those images, and I think you’ll understand why I’m experimenting with TR2=4 or TR2=5. TR2=3 creates a ripple across the front of the station that TR2=4 (at least) helps fix.

Seems not the right way to handle this, but let me see it first - maybe I will have to admit it IS that horrible. But hard to believe.

The reason to write an article telling people how to deal with PAL is so that PAL people know how to best convert the show. I am not advocating for some kind of code of honor. I want to produce the best overall version of Deep Space Nine. But the goal is to provide a “Best-in-class” improvement method to everyone, which means I’m also interested in the best way to handle PAL.

Not much difference to NTSC. After you made NTSC sources progressive and the anti-aliased possible rest of aliasing which came from reordering fields it should be pretty much the same procedure plus a slowdown at the very end.

Doom9 is correct that IVTC is complicated. The only way to perform it perfectly, as far as I know, is to hand-comb every scene and manually tune the frame order method via a TFM OVR file.

It is even better not to write a file for TFM, but to IVTC completely by hand. Not very complicated, I do this all the time, if the pattern doesn’t change too often. With the amount of episodes it is quite a job, though, but writing files for TFM also… If you like, I can post a typical script for by-hand-IVTC.

However – it turns out that the following actually works pretty damn well:

TFM()
TDecimate()

Would be easy then, but if you do so with native 29.97(i or p) content there will be missing frames and skipping (is that the right word?) all the time.

I have also developed a secondary method of creating a 60 fps method of the show that matches the quality of what I’ve shown you.

No good idea, because it doesn’t remove stuttering from telecine-double-fields. That is the whole problem with content like this. Progressive 30, 60 will stutter with originally film=24fps. How could this be avoided? There have to be double frames, at least fields, or can you divide 60 through 24?

Still searching for a way to automate it perfectly (the commands above are automatic, but not perfect).

Don’t exactly know, what’s your goal. But simply the first necessary, to IVTC, is not perfectly automatically possible. That’s why we do it by hand if ever possible.

Initial evaluation of naive implementation of AniMaxx’s algorithm suggests it’s oversharpening in my case. I like the overall output otherwise. Going to adjust some variables, then toss in the rest and see what it looks like. 😃

I wouldn’t sharpen at all, only a bit unsharpmasking, but that’s another question… 😉

Author
Time

Some valid points there. It all boils down to this: Hybrid materials with baked-in properties are “The Stuff from Hell” …

Author
Time

Artan42 said:

I’m enjoying all this technical detail. I have no bloody clue what is being said (it may as well be in Klingonese for all I know) but it looks like there’s several people who really know what needs to be done here.

As for CBS, every time somebody uploads a test video, I go watch a couple of episodes on Netflix. I think it’ll be the viewing figures for DS9 and VGR that make the case to CBS that they might have to pull their fingers out eventually as they’ll be the only two of the nine produced TV shows without a HD release.

As for CBS, every time somebody uploads a test video, I go watch a couple of episodes on Netflix.

I uploaded 16 videos this week. (I’m not actually shamelessly pumping my channel, so feel free to ignore it. But I’m also not kidding).

https://www.youtube.com/user/Dputiger

If you’ve already seen my story from earlier this week, apologies, but if you didn’t: I rendered out major scenes from the show, both dramatic and combat-oriented, using a variety of different models and presets from Topaz Video Enhance AI. The scene with the largest number of available presets (to compare various AI Upscale models) is “Second Fleet.” Gaia-CG is the most common model I use. Do not use the Artemis models on DS9, ever. You don’t actually have to watch 32 episodes of DS9 in exchange for watching. 😉

Author
Time
 (Edited)

FrankB said:

Joel Hruska said:
Alright. Now I see it. If that’s what you call a major anti-aliasing problem, I strongly suggest you never watch the NTSC credits. I cannot upload them to YouTube in SD because the YT algorithm utterly destroys SD content, so I have to give you screenshots – but take a look.

Looks like shifted fields. Can you upload the credits, or a few seconds of it, without conversion somewhere?
I do not understand where the problem realy lies?

Look at the degree of aliasing in those images, and I think you’ll understand why I’m experimenting with TR2=4 or TR2=5. TR2=3 creates a ripple across the front of the station that TR2=4 (at least) helps fix.

Seems not the right way to handle this, but let me see it first - maybe I will have to admit it IS that horrible. But hard to believe.

The reason to write an article telling people how to deal with PAL is so that PAL people know how to best convert the show. I am not advocating for some kind of code of honor. I want to produce the best overall version of Deep Space Nine. But the goal is to provide a “Best-in-class” improvement method to everyone, which means I’m also interested in the best way to handle PAL.

Not much difference to NTSC. After you made NTSC sources progressive and the anti-aliased possible rest of aliasing which came from reordering fields it should be pretty much the same procedure plus a slowdown at the very end.

Doom9 is correct that IVTC is complicated. The only way to perform it perfectly, as far as I know, is to hand-comb every scene and manually tune the frame order method via a TFM OVR file.

It is even better not to write a file for TFM, but to IVTC completely by hand. Not very complicated, I do this all the time, if the pattern doesn’t change too often. With the amount of episodes it is quite a job, though, but writing files for TFM also… If you like, I can post a typical script for by-hand-IVTC.

However – it turns out that the following actually works pretty damn well:

TFM()
TDecimate()

Would be easy then, but if you do so with native 29.97(i or p) content there will be missing frames and skipping (is that the right word?) all the time.

I have also developed a secondary method of creating a 60 fps method of the show that matches the quality of what I’ve shown you.

No good idea, because it doesn’t remove stuttering from telecine-double-fields. That is the whole problem with content like this. Progressive 30, 60 will stutter with originally film=24fps. How could this be avoided? There have to be double frames, at least fields, or can you divide 60 through 24?

Still searching for a way to automate it perfectly (the commands above are automatic, but not perfect).

Don’t exactly know, what’s your goal. But simply the first necessary, to IVTC, is not perfectly automatically possible. That’s why we do it by hand if ever possible.

Initial evaluation of naive implementation of AniMaxx’s algorithm suggests it’s oversharpening in my case. I like the overall output otherwise. Going to adjust some variables, then toss in the rest and see what it looks like. 😃

I wouldn’t sharpen at all, only a bit unsharpmasking, but that’s another question… 😉

Would be easy then, but if you do so with native 29.97(i or p) content there will be missing frames and skipping (is that the right word?) all the time.

There isn’t.

While I have self-identified as a noob, I need to ask you to trust me to some extent. I am not always right about what I am seeing, or why I’m seeing it, and I don’t always understand how to fix a problem I encounter, but I have spent thousands of hours staring at this show in the last nine months. I have accelerated it to every single frame multiple between 23.976 and well above 1000. I have interpolated it with at least six different filters. I have tested source derived from MakeMKV, Handbrake, and DVD Decrypter. When I decided I wanted to test the impact of using Handbrake to process the DVD, I ripped the same DVD more than 250 times in a several-day period. I ran every single potential combination of filters, frame rates, and output file types that I was interested in, and then I started watching them – at between 3-5 minutes per watch – to evaluate the impact of various settings.

I won’t tell you that I watched the entire set of videos, because I didn’t. Once I was able to start predicting what output would look like, I was able to speed through my testing more quickly. Eventually I realized these methods would not serve me, and I quit after looking at ~120 videos of the 250 or so I rendered.

I’m not explaining this to boast or brag or to come off as thin-skinned. You don’t know me from Adam, and you don’t have any specific reason to think I know what I’m talking about, especially when I openly identify as being very new to this work. I figure it’s on me to explain the level of detail and rigor with which I have approached the process.

Here is what it means when I say that the TFM / TDecimate combination works. It means that I’ve run it against multiple episodes with a high film percentage, but have seen only very isolated incidents of motion judder. I’m comfortable asking people to accept 3 seconds of bad motion in a 45-minute episode of TV. If I have to ask for 5 seconds, I’ll wince, but I’ll do it. If I have to ask someone to tolerate 10 seconds of bad motion, total, in one 45 minute video, I will do so only after I have made every effort I can make to fix it. If I had to ask someone to tolerate 60 seconds of bad footage in an episode, I’d refuse to publish my methods. That’s why I didn’t publish my methods in April or May. They weren’t worth publishing.

Here. If you want to see the difference between my old methods and my new ones, watch this other version of the DS9 credits that I did (I’m going to give you the time codes in the episode to show you the differences directly):

Watch the following: https://www.youtube.com/watch?v=YbjqaVHZvAA

0:21 - 0:48
0:59 - 1:14
1:27 - 1:36

Now, compare those exact same sections to the credits I gave you this morning. Ignore any differences in image quality and just look at the motion.

https://www.youtube.com/watch?v=zMaMHT4skn0

The first video shows you what my original approach looked like. It’s very nearly as pretty in terms of achieved image quality, but the motion is jerky and poor at multiple points. Too many points.

The video I sent you this morning is the video created when you use my script and preface it with: TFM() / TDecimate()

After the blue flash, the credits are in 29.97 until the end. And I’ve tested the method in more than just the credits.

I’m basically willing to tolerate less-than-great motion in a small portion of one scene, maybe two scenes tops. So far, that TFM / Tdecimate approach has hit that quality level. It might prove unable to do so in certain places. Where it can’t, I’ll find a different method and publish it, or nudge people towards Orinoco.

No good idea, because it doesn’t remove stuttering from telecine-double-fields. That is the whole problem with content like this. Progressive 30, 60 will stutter with originally film=24fps. How could this be avoided? There have to be double frames, at least fields, or can you divide 60 through 24?

Here’s how my method of doing this works.

We create two files, not just one. First script, for first file:

TDeint(mode=1, type=2, tryweave=true, mtnmode=3, full=false, ap=10, aptype=2, slow=2)

This script orders TDeint to produce doubled frame output, to perform kernel interpolation, to attempt to repair a frame by weaving if the result is fewer combing artifacts than deinterlacing would create, and to only deinterlace interlaced frames. This preserves the progressive frames baked into the NTSC source. Type=5 was the only option that came close to Type=2 in overall image quality, and the bi-directional blending Type=5 introduces causes more frame blending issues at scene boundaries. Type 5 occasionally fixes a problem in Type 2, but it causes them far more often than it repairs them.

Now we set this clip aside and turn our attention to the other. We run QTGMC against the second clip with the exact same processing steps I use otherwise except, we don’t use progressive repair mode. We use interpolation mode, and we take the frame rate up to 59.94 fps.

Here’s why we do this: The deinterlaced clip created by TDeint will have perfectly smooth motion thanks to the frames it interpolates. Those frames will be well-blended because the script above performs very good blending during the same scene. Scene boundaries, however, present a problem. It is not unusual to find a character with a fireball blowing out of her forehead at a scene boundary because the previous scene was an explosion.

But there’s a way to fix this: Repair.

We now take our two files and write the following script:

clip1=FFVideoSource(“C:\DS9S6D2\Sacrifice-TDeint.mkv”)
clip2=FFVideoSource(“C:\DS9S6D2\Sacrifice-QTGMC-ToPairWithTDeint.mkv”)
Repair(clip1, clip2, 9)

This process repairs the broken frames that had bad interpolated data in them.

This method – which I nicknamed Orinoco – is motion-perfect and quality-identical to the episode videos you have already watched. I do not have footage to show you straight to hand, though I could get some with a bit of processing time, but I have no reason to lie. I have published my methods and staked my reputation on them.

I was going to go to press with Orinoco, and only Orinoco, before I found my 23.976 fps solution at the last second. When I say the image quality is identical to what you have seen with perfect motion, I do not mean “Except in the places I don’t want to admit exist.” I mean “In every single instance I am aware of thus far.”

I have high quality standards. I don’t like to compromise on them.

Author
Time

Just tried to help. I also do this for 20 years, professionally for more than 12 years. And I do not have to boast somehow either. And 60/24 makes 2.5. Good luck, and high respect for what you’re doing!

Author
Time
 (Edited)

FrankB said:

Just tried to help. I also do this for 20 years, professionally for more than 12 years. And I do not have to boast somehow either. And 60/24 makes 2.5. Good luck, and high respect for what you’re doing!

I’m not saying you aren’t helping. I’m saying that when I say the output is smooth, I’m not wrong about it. In TDeint’s case, we’re interpolating frames to get there. I said as much, at multiple times. That’s why I gave you an extensive explanation for what scripts I run and how I process the file.

The reason the method works is because the interpolated frames are near-duplicates of the originals. The reason they don’t get noticed is because we repair the frame boundary issues that make them noticeable. The end result is an image that maintains the same smoothness as the original.

All data is stored on an NTSC DVD as 59.94 interlaced fields, including these DVDs. We keep the three progressive frames and repair the interlaced ones, either by weaving them, repairing via the “Repair” command, or outright borrowing them from a second file. These methods can be used to eliminate the distorted frames at frame boundaries.

Because all data is stored on these NTSC DVDs in 59.94 interlaced fields, 59.94 fps is not a problematic target as far as motion is concerned. A D2V file, processed in this method, runs at 29.97 fps not 23.976 fps by default. Progressive frames are retained, interlaced frames are deinterlaced, and new frames are interpolated.

https://www.extremetech.com/wp-content/uploads/2020/09/Sacrifice-Correct.jpg

This is what a proper Staxrip file looks like before you run a program like TDeint. That’s what you see when you pull a D2V file into the application for editing. Then you run TDeint against this file and you double the output rate to 60 fps. There is no invocation of the 2.5x multiplier. At 60 fps (having used TDeint for interpolation), the video remains perfectly synced with the audio and neither 23.976 nor 29.97 fps content moves too quickly.

I will upload you video clips if you would like to see it.

EDIT:

Seriously, Frank. In no way am I trying to either imply you are unhelpful or crap on your expertise.

Author
Time

Animaxx said:

You guys know when I was satisfied? When I was finally able to see the freaking Aztec-Pattern on the ships hull (last shot) - I know, I am so ready for the looney bin, but I used to/still do build starship models, so details are a point of obsession for me …

Just wanted to let you know: I’m definitely getting a quality boost off some of these changes. I need to tweak them to fit the somewhat different characteristics of the DVD source, but you have meaningfully boosted my project along. 😃

Author
Time

Joel Hruska said:

Animaxx said:

You guys know when I was satisfied? When I was finally able to see the freaking Aztec-Pattern on the ships hull (last shot) - I know, I am so ready for the looney bin, but I used to/still do build starship models, so details are a point of obsession for me …

Just wanted to let you know: I’m definitely getting a quality boost off some of these changes. I need to tweak them to fit the somewhat different characteristics of the DVD source, but you have meaningfully boosted my project along. 😃

Glad to hear it. Since I had worked for month with the NTSC and didn’t find a pleasing enough solution for motion issues, I know what you mean by adapting to the source.

Author
Time

Joel Hruska said:
Seriously, Frank. In no way am I trying to either imply you are unhelpful or crap on your expertise.

Never mind, so didn’t I with yours. Maybe my English is not that good, and you feel wrong subtle “vibrations”, not meant. It is not really easy to help, if someone of high intelligence like you is in the job for months, already did hundreds of experiments a. s. o.
But in spite of this you - sorry - seem not to really understand what really happens with the original 24fps-film when being pulldowned.
Ok, you see RELATIVE smooth motion in your 60fps result, because you use interpolated frames, but this artificially extended motion cannot be really smooth, it’s sometimes faster, sometimes slower. This can’t be called “stutter”, ok, but it is not the original smooth motion, where one frame of the original celluloid-film is one frame (or at least a multiple of one for EACH frame) in the end result. This is simply not possible, if you have 24fps film and 60fps end result.
Pulldown is done by doubling several fields (several ways to do so, doesn’t matter here). These have to be decimated to get back the clean progressive, original content, which is necessary to fill the AI upscaler, and to get really smooth and good results.
Your interpolated frames are not really good anyway concerning picture quality, but make also motion slower and faster.
Just the portions where you might have native 29.97fps, (interlaced or not, not important because you deinterlace), will work, because there you have simply doubled frames, when going to 60 (59.94)fps. This is smooth, ok.
I don’t think, it’s the way to go, to keep any double frames, and even worse to add interpolated frames to make it a bit(!) smoother. So your decision to get to 23.976 was the only way to go.

Again: If you like to see a IVTC-by-hand-script, send me some portions of the NTSC-DVDs. Also the opening credits are interesting for me - is this field-shifted? Interlaced? Pulldowned AND field-shifted?

Author
Time

Man, you guys (Frank and Joel) have so much technical knowledge, I salute you. I am beginning to feel small, very small.

😃

Author
Time

This is not a creative art, as one could think sometimes. It’s just preservation of something others created, and which is worth to be preserved the best possible way. The result counts, that’s all!
The real big thing is to create something like Star Trek, compared to this, we are all small, but it’s always fun and very rewarding to somehow do something good for this worthy content, I think Joel feels it similar.

Author
Time

FrankB said:

This is not a creative art, as one could think sometimes. It’s just preservation of something others created, and which is worth to be preserved the best possible way. The result counts, that’s all!
The real big thing is to create something like Star Trek, compared to this, we are all small, but it’s always fun and very rewarding to somehow do something good for this worthy content, I think Joel feels it similar.

Frank,

I will get you some samples made today. Do you have a Microsoft OneDrive account or do you prefer Google Drive?

Author
Time

FrankB said:

This is not a creative art, as one could think sometimes. It’s just preservation of something others created, and which is worth to be preserved the best possible way. The result counts, that’s all!
The real big thing is to create something like Star Trek, compared to this, we are all small, but it’s always fun and very rewarding to somehow do something good for this worthy content, I think Joel feels it similar.

I agree with you that it is fun and rewarding to do some good for this worthy content, no question. I think of the people who do this kind of work – amateur and professional, provided you really care about it – as being in the field of “art restoration” if you wanted to call it that.

A person who paints paintings is not the same as the person who restores them, but you cannot restore art if you do not understand something of the artist. The creativity in restoration comes in choosing which techniques to apply, and maybe in finding / inventing new techniques that handle something better than a previous solution did.

Author
Time
 (Edited)

FrankB said:

Joel Hruska said:
Seriously, Frank. In no way am I trying to either imply you are unhelpful or crap on your expertise.

Never mind, so didn’t I with yours. Maybe my English is not that good, and you feel wrong subtle “vibrations”, not meant. It is not really easy to help, if someone of high intelligence like you is in the job for months, already did hundreds of experiments a. s. o.
But in spite of this you - sorry - seem not to really understand what really happens with the original 24fps-film when being pulldowned.
Ok, you see RELATIVE smooth motion in your 60fps result, because you use interpolated frames, but this artificially extended motion cannot be really smooth, it’s sometimes faster, sometimes slower. This can’t be called “stutter”, ok, but it is not the original smooth motion, where one frame of the original celluloid-film is one frame (or at least a multiple of one for EACH frame) in the end result. This is simply not possible, if you have 24fps film and 60fps end result.

I am preparing some clips to show you final output of the method. I want to make sure I am clear about what I expect you to see:

1). Recovery of the same progressive frames as in the 23.976 fps Rio Grande version.
2). Interpolated frames that provide the smoothness required to make the 59.94 version move smoothly in places where the 23.976 fps version fails to recover ideal motion.

The 60 fps motion of Orinoco is smoother than the 119.88 fps conversions that I’ve tested (I tested 119.88 as a way to equalize the 23.976 fps and 29.97 fps content). The motion is less irregular. There are still absolutely interpolated frames being used to smooth out the presentation and I won’t claim there aren’t, but the subtle, hitching jerking that I spent so many months trying to repair has vanished. I’ve messed around with changing the frame rate from 23.976 to 29.97, 47.952, 59.94, even 71.9128 (a little) and 119.88 (a lot).

The encode method I call Orinoco is the best 59.94 conversion method I have found. I’d prefer not to use it. It takes a very long time to upscale 59.94 content. But it does solve problems in the places where Rio Grande leaves bad motion – and it does so without causing visible frame rate stutter. Are the interpolated frames still there? Absolutely. Do I want them there? No. I’m just willing to tolerate them if I have to.

Pulldown is done by doubling several fields (several ways to do so, doesn’t matter here). These have to be decimated to get back the clean progressive, original content, which is necessary to fill the AI upscaler, and to get really smooth and good results. > Your interpolated frames are not really good anyway concerning picture quality, but make also motion slower and faster.

Just the portions where you might have native 29.97fps, (interlaced or not, not important because you deinterlace), will work, because there you have simply doubled frames, when going to 60 (59.94)fps. This is smooth, ok.
I don’t think, it’s the way to go, to keep any double frames, and even worse to add interpolated frames to make it a bit(!) smoother. So your decision to get to 23.976 was the only way to go.

I will show you Orinoco in sections that are originally 29.97 and originally 23.976. That’ll be the easiest way to compare.

Again: If you like to see a IVTC-by-hand-script, send me some portions of the NTSC-DVDs. Also the opening credits are interesting for me - is this field-shifted? Interlaced? Pulldowned AND field-shifted?

I am going to send you the credits and the first part of an episode with multiple 23.976 --> 29.97 transitions in it. About 7:30 worth of footage. This will be a direct copy of the DVD. Prepping these today.

Author
Time

Joel Hruska said:
I will get you some samples made today. Do you have a Microsoft OneDrive account or do you prefer Google Drive?

Thank you, but please try to keep it SMALL. I live on the flattest country 😉

A person who paints paintings is not the same as the person who restores them, but you cannot restore art if you do not understand something of the artist.

No question. You have to know a lot and if you do your best, it’s not easier than to create something like a tv-series, where they also do their best.

The creativity in restoration comes in choosing which techniques to apply, and maybe in finding / inventing new techniques that handle something better than a previous solution did.

Yes, you are right, this is a creative, sometimes VERY creative process, too.

I am preparing some clips to show you final output of the method. I want to make sure I am clear about what I expect you to see:

1). Recovery of the same progressive frames as in the 23.976 fps Rio Grande version.
2). Interpolated frames that provide the smoothness required to make the 59.94 version move smoothly in places where the 23.976 fps version fails to recover ideal motion.

Ok, ok, thanks, but: This is a possible way to go, BUT:
If you go to 59.94fks, then:

  1. you get smoothest motion in the parts, that were 29,97fps originally
  2. you get somehow smooth motion but with slightly variing speed for all the parts that were pulldowned from 23.976 (originally 24)fps.

The parts with 2. are MUCH larger than 1.
So it’s the only way to go to do FIRST the best you can do for these large parts, and that means:
Decimate.
If you do this right, you get 100% smooth, progressive frames 1:1 of the original film material.

THEN you can think about what to do with the original 29.97 parts. You have to slow them down to 23.976
This is only possible with motion flow. If you decimate somehow you get big jerky junk. As I said above: We did this with Alchemist, that did a quite good job, not perfect though. In Avisynth there are also several ways, one is a larger script called “framereatconverter”, another, that is used by the first, is using MVTools.
There are also AI possibilities, f. e. Resolve, which makes use of GPU / CUDA - but I am not very good in this.
I tried it several months ago, but was not very pleased with the results.

Bringing everything to 120 (119.88)fps is not good, too. Ok, you can take the smooth, ready IVTCed 23.976 and “enlarge” it with a ratio 4:1, that is, repeat each frame 5 times. For the 29.97 portions, also smooth, repeat each frame 4 times. Everything 100% smooth, ok, BUT: The speed ratio of both won’t be correct, the latter ones (29.97) will play 4/5 slower than the others.

The 60 fps motion of Orinoco is smoother than the 119.88 fps conversions that I’ve tested (I tested 119.88 as a way to equalize the 23.976 fps and 29.97 fps content). The motion is less irregular. There are still absolutely interpolated frames being used to smooth out the presentation and I won’t claim there aren’t, but the subtle, hitching jerking that I spent so many months trying to repair has vanished. I’ve messed around with changing the frame rate from 23.976 to 29.97, 47.952, 59.94, even 71.9128 (a little) and 119.88 (a lot).

These experiments are not new to me. I did similar things some years ago, and I fear, everyone who has to work with these things had to do so once. I also can remember how frustrating this can be - and how many fallacies you make…

The encode method I call Orinoco is the best 59.94 conversion method I have found.

I believe you, and also that the method is intelligent! But the results cannot be “correct”… That is
-progressive AND
-smooth AND
-always have the same speed
Just because you can’t divide 60 through 24… 😉

I’d prefer not to use it. It takes a very long time to upscale 59.94 content. But it does solve problems in the places where Rio Grande leaves bad motion – and it does so without causing visible frame rate stutter. Are the interpolated frames still there? Absolutely. Do I want them there? No. I’m just willing to tolerate them if I have to.

As I said, you have to decimate for the pulldowned sections and then take care of the real 29.97 material in a different way.

Author
Time

FrankB said:
Bringing everything to 120 (119.88)fps is not good, too. Ok, you can take the smooth, ready IVTCed 23.976 and “enlarge” it with a ratio 4:1, that is, repeat each frame 5 times. For the 29.97 portions, also smooth, repeat each frame 4 times. Everything 100% smooth, ok, BUT: The speed ratio of both won’t be correct, the latter ones (29.97) will play 4/5 slower than the others.

Just did it again… myself a victim of the mentioned fallacies… 😉
After combining the different portions to 120fps as mentioned above, everything will of course play in exactly the same and correct speed. So 120 would really be an option, if done right.

Author
Time

Guys, I have done it. The 4K-pilot is finished. It was rendered at 15 Mbps in 4:3 format at a display size of 2846x2160p (4:3).

I also used the original NTSC audio and adapted to the PAL-running time while maintaining the original pitch; also, I have pitch corrected the german audio so the PAL-Speedup has been taken care of (no more high pitched voices).

The motion is nice and smooth (as it is at 25 FPS).

There are only minor imperfections: Slight block artefacts with explosions and fast moving scenes (barely noticeable), sometimes the added grain is more visible but also adds nice detail, so I will keep that for it looks less “oversmoothened/arteficial”. There is still some minor rainbowing and there is that one frame were the deinterlacer couldn’t handle it all, but it’s again minor. Unfortunately with the pilot, there is a sort of “double border” on top/bottom, but that is only present with the pilot and I didn’t want to crop further to avoid losing parts of the image.

Overall, I am happy with the result. I think it is a really nice compromise between upscaled/enhanced quality, retained detail and filtered image properties.
The 1080p-version is being rendered right now and should be done in 12 hours. I will then upload that as well.

Finally, I will do comparison shots and write the text for the release topic. I will invite you guys and then you can get your hands on the pilot.

As for specs: The 4K-Version will have a size of roughly 10 GB (9,9) and the 1080p-Version will have about 6 GB. Since the pilot (double episode) runs 87 minutes (PAL) and the single episodes clock in at about 43 minutes (PAL) we can assume that the size for the singles will be about 5 GB at 4K and 3 GB at 1080p.

I think size-wise those figures would be ok, since a complete 26 episode season at 4K would take up 130 GB and at 1080p it would take 75-80 GB. In comparison, if I were to copy the DVD-files with original sizes (1,8 GB for singles at SD-Resolution) I would end up with a season count of 45-50 GB, so that appears reasonable to me.

I hope you’ll agree.

Author
Time
 (Edited)

Animaxx said:

Guys, I have done it. The 4K-pilot is finished. It was rendered at 15 Mbps in 4:3 format at a display size of 2846x2160p (4:3).

I also used the original NTSC audio and adapted to the PAL-running time while maintaining the original pitch; also, I have pitch corrected the german audio so the PAL-Speedup has been taken care of (no more high pitched voices).

The motion is nice and smooth (as it is at 25 FPS).

There are only minor imperfections: Slight block artefacts with explosions and fast moving scenes (barely noticeable), sometimes the added grain is more visible but also adds nice detail, so I will keep that for it looks less “oversmoothened/arteficial”. There is still some minor rainbowing and there is that one frame were the deinterlacer couldn’t handle it all, but it’s again minor. Unfortunately with the pilot, there is a sort of “double border” on top/bottom, but that is only present with the pilot and I didn’t want to crop further to avoid losing parts of the image.

Overall, I am happy with the result. I think it is a really nice compromise between upscaled/enhanced quality, retained detail and filtered image properties.
The 1080p-version is being rendered right now and should be done in 12 hours. I will then upload that as well.

Finally, I will do comparison shots and write the text for the release topic. I will invite you guys and then you can get your hands on the pilot.

As for specs: The 4K-Version will have a size of roughly 10 GB (9,9) and the 1080p-Version will have about 6 GB. Since the pilot (double episode) runs 87 minutes (PAL) and the single episodes clock in at about 43 minutes (PAL) we can assume that the size for the singles will be about 5 GB at 4K and 3 GB at 1080p.

I think size-wise those figures would be ok, since a complete 26 episode season at 4K would take up 130 GB and at 1080p it would take 75-80 GB. In comparison, if I were to copy the DVD-files with original sizes (1,8 GB for singles at SD-Resolution) I would end up with a season count of 45-50 GB, so that appears reasonable to me.

I hope you’ll agree.

Are you using actual 3840x2160, or are you using 4K loosely? (Meaning, like, a 4x upscale instead of a true 4K upscale) Assuming you mean it literally – have you compared the quality gain from jumping that high?

The reason I’ve stuck to 2560x1920 is because I don’t get any benefit from going higher. I do get a benefit from using Topaz in 4x mode, because the 2x modes seem to blend poorly, but I don’t see an improvement from anything more.

I have also found that using x265 with a CRF=19 is pretty solid. I can barely see the smallest difference between CRF=6 and CRF=20, while I can’t see a difference at all, really, at CRF=19.

Running H.265 in “Slow” or “Very Slow” will also improve your compression. Compression is much more improvable than I ever believed. But this is also why I ask about the benefits of 3840x2160 – because if you get the same quality at, say, 2560x1440 than you do at 3840x2160, you could save yourself a lot of bandwidth just by getting rid of pixels people don’t actually meaningfully benefit from.

If you do benefit from 4K, I recommend trying H.265 with Slow encode speed to see what kind of compression boost you get.

Author
Time
 (Edited)

Are you using actual 3840x2160, or are you using 4K loosely? (Meaning, like, a 4x upscale instead of a true 4K upscale) Assuming you mean it literally – have you compared the quality gain from jumping that high?
The reason I’ve stuck to 2560x1920 is because I don’t get any benefit from going higher. I do get a benefit from using Topaz in 4x mode, because the 2x modes seem to blend poorly, but I don’t see an improvement from anything more.
I have also found that using x265 with a CRF=19 is pretty solid. I can barely see the smallest difference between CRF=6 and CRF=20, while I can’t see a difference at all, really, at CRF=19.
Running H.265 in “Slow” or “Very Slow” will also improve your compression. Compression is much more improvable than I ever believed. But this is also why I ask about the benefits of 3840x2160 – because if you get the same quality at, say, 2560x1440 than you do at 3840x2160, you could save yourself a lot of bandwidth just by getting rid of pixels people don’t actually meaningfully benefit from.
If you do benefit from 4K, I recommend trying H.265 with Slow encode speed to see what kind of compression boost you get.

I am using Topaz 4K-mode but switch to custom settings to avoid black bars left/right, so I end up with an automatic display size of the values I had specified.

I am not enocoding with a CFR as you suggested, I use Adobe Premiere Pro with a CBR of 15 Mbps in x264; while I know x265 could increase compressibility, I ran into issues with that in the past, so I need to stick to x264 for now.

As for the display size itself, I will let the automatic setting do that, for it scales up while maintaining the aspect ratio.

By the way, since the rules here do not allow for link posting to complete material, please send me a private message to get the link for the current 4K-version of the pilot (Joel and FrankB).
It will be the same as in the release topic I am preparing right now, but this way you’ll get it sooner, since the topic will take a little bit.

Author
Time

Animaxx said:

Guys, I have done it. The 4K-pilot is finished. It was rendered at 15 Mbps in 4:3 format at a display size of 2846x2160p (4:3).

First: Congratulations!

I also used the original NTSC audio and adapted to the PAL-running time while maintaining the original pitch; also, I have pitch corrected the german audio so the PAL-Speedup has been taken care of (no more high pitched voices).

Critics: (as always…)

  1. For the German sound there is no pitch to correct if you leave it at 25fps. Or do I misunderstand? It is originally made for 25fps, and your result is also 25fps. Why correct?
  2. As I said before: You should simply slow down Video to 23.976, and the English audio will fit.
  3. IF you do so, THEN the German audio you would have to slow down, too, and in this case you should pitch correct it about 1/4 to 1/2 tone up.

By the way: These pitch corrections always produce a quality loss, even with the best algorithms, be aware of that fact.

Author
Time

FrankB said:

Animaxx said:

Guys, I have done it. The 4K-pilot is finished. It was rendered at 15 Mbps in 4:3 format at a display size of 2846x2160p (4:3).

First: Congratulations!

I also used the original NTSC audio and adapted to the PAL-running time while maintaining the original pitch; also, I have pitch corrected the german audio so the PAL-Speedup has been taken care of (no more high pitched voices).

Critics: (as always…)

  1. For the German sound there is no pitch to correct if you leave it at 25fps. Or do I misunderstand? It is originally made for 25fps, and your result is also 25fps. Why correct?
  2. As I said before: You should simply slow down Video to 23.976, and the English audio will fit.
  3. IF you do so, THEN the German audio you would have to slow down, too, and in this case you should pitch correct it about 1/4 to 1/2 tone up.

By the way: These pitch corrections always produce a quality loss, even with the best algorithms, be aware of that fact.

Strangely enough, the tv broadcasts and dvd versions are higher pitched around germany than the original vhs tapes, which had lower pitch. It also sounded better, because music and sound effects now match the original ntsc music and sound effect pitch once lowered.

As for the speed down to 23,976 FPS: That would cause motion stutter again, which I was happy to have avoided with PAL at 25 FPS.

Author
Time
 (Edited)

Animaxx said:
Strangely enough, the tv broadcasts and dvd versions are higher pitched around germany than the original vhs tapes, which had lower pitch.

Interesting, I didn’t know that. That means:
By the time the series was brought to Germany it was often practised technique to convert from NTSC to PAL in a mix of blending and keeping the original interlacing, especially with such mix-content of pulldowned and native 29.97 material.
So they seem to have dubbed it in its original length. This is what is also on the VHS cassettes.
The newer masters for the DVDs were carefully IVTCed (and the 29.97 portions brought to 23.976 in I-don’t -know-what-way), and then sped up to 25fps. Then they sped up the sound without correcting the pitch to its lower original. So you are damned right when you pitch down - even better would have been to slow down to 23.976 and then simply resample the German dub down, pitch would be corrected automatically and everything fine!

As for the speed down to 23,976 FPS: That would cause motion stutter again, which I was happy to have avoided with PAL at 25 FPS.

That’s an error. Slowing down does not at all cause any stutter, if you do it right - that means the very simplest way. Try it with avisynth with, as I said:
new=assumefps(old,24000,1001)
This will just change the SPEED, no t one frame will be added or dropped.

Author
Time
 (Edited)

The newer masters for the DVDs were carefully IVTCed (and the 29.97 portions brought to 23.976 in I-don’t -know-what-way), and then sped up to 25fps.
Are you sure they did this?

From what I found it was suggested that they used a method called DEFT to convert it to 25 fps. It does produce some combing artifacts but it works 99% of the time and that’s why I haven’t touched the PAL discs since then.