Problem with detelecine of old (silent) movie

[citroenfan]

Hello,

I would like to convert old public domain movie to 23.976fps.
It's from NTSC DVD.
DGindex say video type NTSC and frame rate 29.97fps

I tried to detelecine it with tivtc (tfm + tdecimate) but when I open it in VirtualDub, after few good frames with motion, there comes two or more almost identical frames, so I suppose that detelecine patern is different than usual.

Also tried to resolve the problem with Srestore but did not suceed.

Thank you for your help.


http://www.mediafire.com/file/p6xkv88lxj1vax9/sample.mpg/file

[Cary Knoop]

Are you sure the old movie is 24p, because in the old days 18 and even 12 fps was used?

What is the name of the movie?

By the way, your source is flipped horizontally.

[videoh]

Use a different host. I'm not disabling my ad blocker just to see your video.

[manono]

Use a different host. I'm not disabling my ad blocker just to see your video.
MediaFire is pretty harmless.

It's one way to convert 16fps for an NTSC DVD. Try this:

TFM().TDecimate(Cycle=73,CycleR=34)

I would like to convert old public domain movie to 23.976fps

Why, if that's the wrong framerate? You could interpolate frames to bring it up to 23.976fps, I suppose. But you'll create some nasty artifacts in the process. You could duplicate frames with a ChangeFPS command. But unless you need a different framerate, why not keep it the way it is? 16fps does seem to be about the correct speed.

[johnmeyer]

You must first look at the film using Separatefields() so that you can determine the telecine pattern. It can be absolutely anything and will NOT be a simple 29.97 to 23.976 conversion! Some silent film was shot as slowly as 10-12 fps.

Here is what I use for 16 or 18 fps film:

tfm(display=false)
tdecimate(display=false,mode=0,cycleR=2,cycle=5) #18 fps # 3:3:4 field count
#tdecimate(display=false,mode=0,cycleR=7,cycle=15)#16 fps

[citroenfan]

Thank you manono and johnmeyer,

I tried to detelecine the movie with your settings and get 15.984fps (johnmeyer) and 16.011fps (manono).

With both settings motion is OK now, without duplicated frames.

When I tried with detelecine to 18fps, there is one repeated frame with few good frames, so I suppose that right speed for this movies is about 16fps.

Thank you very much once more.

[johnmeyer]

I will repeat: you cannot blindly use my settings (or anyone elses script or settings). Instead, you must use separatefields() and then walk through the video, field-by-field, to determine the actual telecine pattern. It can be any pattern. You need to find the repeats, and you need to walk through enough of the video (a hundred fields is usually sufficient) to determine if there are occasional additional duplicates. Manono suggested a tedecimate setting that included some really large values. This is needed when you have a pattern that has these occasional extra dups which don't happen very frequently. In these cases, TDecimate must be told to evaluate a large group of fields to determine how do do the decimation without removing good fields.

[Frank62]

Now obsolete, but just wrote it, so I post... :)

The pattern is mostly 4 4 4 3 fields, that you want to decimate to 2 2 2 2, so you have to decimate 7 of 15 fields. So johnmeyer's second Tdecimate seems the right one.
73/34 seems even better, but I wouldn't use too high values, you often get long very good, but also now and then short very jerky parts, after my experience.

Strange is the beginning of the sample: 2 4 2 3 4 4, why?

[manono]

...you cannot blindly use my settings (or anyone elses script or settings).
You can use mine. :) For this sample, anyway.

Instead, you must use separatefields() and then walk through the video, field-by-field, to determine the actual telecine pattern.
After bobbing to determine it wasn't field-blended, I removed the bob and put on TFM alone and began counting.
...a hundred fields is usually sufficient..
Usually, but not always and not with this one. the cycle before repeating is 73 frames = 146 fields. And much more counting was necessary to confirm the findings.

The pattern is mostly 4 4 4 3 fields...
Mostly, but not entirely. Therefore your solution is incorrect and will decimate unique frames from time to time. The sample might not be long enough to locate where any of those missing frames are. I don't know and didn't check. It's better to wind up with extra duplicate frames than missing unique frames.

73/34 seems even better, but I wouldn't use too high values...
You wouldn't use the correct values?

...but also now and then short very jerky parts...
Only if the pattern changes. Yes, sometimes (rarely) they do, but not with this one.

[johnmeyer]

I hadn't downloaded the file when I posted earlier. As it turns out, my 16 fps IVTC is exactly the right thing to use.

Here is my complete script. You really don't want to create a 23.976 video. Instead, since the original looks quite natural when played back at 15 fps, the simple and obvious thing to do is to first recover the original progressive frames; then time that to play back at 14.985 fps; and finally duplicate each frame to give you a 29.97 fps video. Just encode that onto DVD, or whatever media you want to use. If you don't need NTSC compliance, change the code to create a 15 fps video and leave it at that.

AVISource("e:\fs.avi").killaudio()
AssumeTFF()
tfm(display=false)
tdecimate(display=false,mode=0,cycleR=7,cycle=15)
AssumeFPS(15000.0 / 1001.0)
ChangeFPS(30000, 1001)

[johnmeyer]

I had a few extra minutes before I shut down the computer for the day, so I did a quick restoration on your film clip. Here's a link to a 15 fps MP4 version. I might have been a little too aggressive with the grain reduction. (I need to switch to a better degrainer.)

Restored Version (http://www.mediafire.com/file/rqfm5c1tmect1xg/Restored.mp4/filehttp://www.mediafire.com/file/rqfm5c1tmect1xg/Restored.mp4/file)

[manono]

cycleR=7,cycle=15)


You're ignoring all the examples of CycleR=6,Cycle=13). They occur after every four instances of CycleR=7,cycle=15 (after every four sets of 15 frames or 60 frames).

Your idea of just slowing it a bit to 14.985 fps before just doubling that to 29.97fps makes sense. If the end result is to be a progressive DVD.

[johnmeyer]

You're ignoring all the examples of CycleR=6,Cycle=13). They occur after every four instances of CycleR=7,cycle=15 (after every four sets of 15 frames or 60 frames).

Your idea of just slowing it a bit to 14.985 fps before just doubling that to 29.97fps makes sense. If the end result is to be a progressive DVD.I just re-read your previous posts, as well as this one. You recommended using a much larger cycle. Did you actually see an interruption in the 4 4 4 3 field pattern in this particular sample, or are you just saying that you've seen this pattern before and that there are usually anamolies every so often?

[manono]

Did you actually see an interruption in the 4 4 4 3 field pattern in this particular sample...?

Yes, that's what I'm saying. And, as I mentioned, I count frames and not fields. You might try it sometime. But perhaps I didn't explain it clearly enough. Maybe to make it more clear:

15, 7
15, 7
15, 7
15, 7
13, 6

That's the "Grand Cycle" (as I call it, made up of 5 "mini-cycles") before it begins to repeat again. Add it all up and you get 73, 34. Just like my script, and it explains the "much larger cycle".

...or are you just saying that you've seen this pattern before...

Well, I have seen the pattern before. It's a fairly standard way to "telecine" 16fps for NTSC DVD. But I didn't go on just that. I spent a lot of time counting.

[Frank62]

@manono
If what you explained is common, I just learned something interesting, what I will try in the future, although we have very less to do with 29,97-->16fps, but it's worth a trial, thanks!

The example is not that straight. After a few odd combinations at the beginning I counted seven times 4 4 4 3 before I stopped. No 13,6 combination.

Let me try to explain why I suggest not to use too high values:
More than once I had this scenario:
-A rather bad PAL source (that we used for the sound)
-A quite good NTSC source, but with awfully inconsequent patterns
I tried to decimate this after a lot of not perfect approaches by doing the following:
-Search a longer scene with no cuts on both sides, so that the decimated result would fit 100% to the PAL source at the end.
-count the frames on both sides
-decimate simply by specifying the difference of the two framecounts (four digits), cancelled if possible.

This resulted in what I said above: Longer very well decimated parts, but every now and then very jerky parts.
We then lowered the values, keeping near to the ratio, but we had to go VERY low to avoid the effect. That's why I suggested not to user higher values. Maybe this was a bit exaggerated, but 3 digits are too high, as far as I remember.
Only if you have a very straight pattern (and as you said this 73-34 often is very straight) it may work perfectly - or it does, after your experience!

My conclusion to mine was: I don't know the exact algorithm the programmer of TDecimate used, but it seems to have not the option to simply discard frames, counts, to start "freely" with the new pattern if changed. There might be some counters that are resetted when getting too high, i don't know.

I experimented a lot to come near to the best possible comprmise. In the end that was, that we used quite small values and repaired the too bad parts by hand. No automatical perfect decimating possible, at least not with TDecimate.
As I wrote on another place: We often had better results with SMARTDecimate, by the way, but also not always.

I wonder why these patterns change so often and odd, never found an answer to this (apart from edits, of course).

[johnmeyer]

Yes, that's what I'm saying. And, as I mentioned, I count frames and not fields. You might try it sometime. Since I was doing this for free for a stranger, I didn't spend much time looking at the pattern. So, once I got 4 4 4 3 a few times I quit and wrote the script. I very much appreciate what you're saying and will, when I'm doing it for myself or a client, spend more time looking for variations to the main pattern. I have used very large "cycle" parameters in the past and the only downside is that it slows things down quite a bit.

My main reason for replying, however, is when you say you count frames, not fields, I don't see how that can work. Since telecine involves repeating fields, not frames, don't you have to at least bob() the original video? I don't see how you can tell anything if you simply walk through the original, unaltered video. I guess if there's enough motion you could look for combing "teeth," but that's not very reliable, and doesn't work with certain types of motion.

So, I'm curious how you can tell anything just looking at the original video. I'd love to know the trick, because it would save me a step when doing the initial analysis.

[manono]

I don't see how that can work. Since telecine involves repeating fields, not frames, don't you have to at least bob() the original video? I don't see how you can tell anything if you simply walk through the original, unaltered video.

As I mentioned in my second reply to this thread:

After bobbing to determine it wasn't field-blended, I removed the bob and put on TFM alone and began counting.

So, I count after applying TFM. Think of standard 3:2 pulldown. You apply TFM you get a dupe frame in every cycle of five frames. Same principle with silent films except that the cycles are often much larger.

[manono]

The example is not that straight. After a few odd combinations at the beginning I counted seven times 4 4 4 3 before I stopped. No 13,6 combination.
As I mentioned in the previous post, I don't count fields. It's sort of apples to oranges, what you're saying. However, I did a lot more counting, and the pattern is more complex than I stated, and it is peculiar at the very beginning. As johnmeyers also mentioned, it's not his project and, like him, I didn't spend as much time with it as I would had it been mine. It turns out there are more of those short patterns than I stated earlier. Thank you for pointing that out. This serves to bring the 'real' framerate a bit closer to 16fps. As I also mentioned, it's better to have duplicate frames from time to time than missing frames. Any 'real' pattern is more complex than I mentioned and much more complicated than you mentioned. However, I have never had any problems using large values, sometimes a cycle of several hundreds of frames.

Let me try to explain why I suggest not to use too high values

Yes, if there is no "grand Cycle", and after counting thousands of frames, about all you can do is to estimate what it should be. I've had to do that on occasion. Again, better to have dupe frames than missing unique frames. However, once you discover a repeating pattern (sometimes larger - much larger - than I used in my earlier script), there's no problem with using it and getting proper decimation and smooth playing video. And even with 'guessing' a cycle and removal, even with large values I haven't encountered any problems other than a duplicate frame every now and then.

I don't know the exact algorithm the programmer of TDecimate used, but it seems to have not the option to simply discard frames, counts, to start "freely" with the new pattern if changed.
With large cycles and if using TIVTC, you should set m2PA=True in TDecimate. By default it looks ahead only 100 frames to figure out what to remove. With m2PA=True it will look ahead as far as necessary.

You can also set a final framerate by using something like:

TDecimate(Mode=2,Rate=16)

but that can be very risky. You should also set a MaxNDL when doing that. That tells the maximum number of frames before a duplicate frame must be removed.

My conclusion to mine was: I don't know the exact algorithm the programmer of TDecimate used, but it seems to have not the option to simply discard frames, counts, to start "freely" with the new pattern if changed. There might be some counters that are resetted when getting too high, i don't know.

There are other filters that can remove duplicate frames wherever they are found. DeDup and MultiDecimate come to mind. Then you can set a framerate using AssumeFPS afterwards.

Maybe you already know these things. You've obviously spent a lot of time working with silent films. If so, I apologize for insulting your intelligence.

[Frank62]

Maybe you already know these things. You've obviously spent a lot of time working with silent films. If so, I apologize for insulting your intelligence.

Thank you, never mind. Indeed I did not work with silent films up to now, so your pattern was new to me, as I said. Thanks for this.

Setting a framerate in TDecimate is not new to me, and I often used it, which of course depends on the case.
m2PA=True is not neccesary if you use logs, which I do for several reasons.

[johnmeyer]

As I mentioned in my second reply to this thread <snip>OK, my bad for not reading that carefully. AFIK, doing a simple bobbob(0.0,1.0)gets you to the same place as separatefields() with both giving you the individual fields and double the frame rate. The seapratefields() does require scaling in VD (which is how I look at the result), but that is minor.

Thanks!

[manono]

I was thinking about it some more myself, decided I had something wrong, and went back to check. I had said:
It turns out there are more of those short patterns than I stated earlier. Thank you for pointing that out. This serves to bring the 'real' framerate a bit closer to 16fps.

But what happens with more of those shorter 13,6 patterns (and a few other oddities) is that the framerate increases. That means there might be missing frames in my original script and more missing frames in the script of johnmeyer. So, I went looking for them, and found at least one. This is a bit tricky because even the sample is missing a few frames. But there's at least one missing frame that the cycleR=73,cycle=34 setting doesn't have. With it set for (Cycle=15,CycleR=7) there's a missing frame between frame numbers 412-413. Using cycleR=73,cycle=34 that missing frame is number 413.

So, rather than the 16.011fps my script gives, I believe it to be a bit higher, maybe around 16.02, something like that. In the past when I worked on silent films a lot and either didn't find a real pattern, or got tired trying to figure it out, I might just look for a combination of Cycle and CycleR that would give the framerate I wanted, check it out looking for missing frames and duplicate frames, adjust it until I was happy and then call it finished.

AFIK, doing a simple bobbob(0.0,1.0)gets you to the same place as separatefields() with both giving you the individual fields and double the frame rate.
Except I don't count bobbed fields. I count field matched frames. Less counting to do.

[johnmeyer]

Two additional notes about dealing with old hand-cranked film.

First, there are always missing frames in these old films. If you view the OP's original, you'll notice quite a few "jump cuts" from those missing frames. So, these films are far from perfect, even before they are digitized and telecined.

Second, you should not get hung up on doing the decimation in order to achieve a given frame rate. In fact, completely ignore frame rate when doing IVTC.

Instead, do everything you can to inverse telecine the film without losing any good frames. You are much better off if your script leaves a few duplicates than if you delete good frames.

Then, use AssumpeFPS() to set a playback speed. Watch the film and see if the motion seems natural. If it seems too slow or too fast, go back and adjust the AssumeFPS().

Remember, all these old movies were hand cranked, and as a result, not only can the speed be pretty much anything, but it can speed up and slow down from one scene to the next. Often this is done on purpose, like you see with the wildly differing speed of the streetcar as it approaches our hero.

As an example of how this works, here is some amateur film I transferred. It was taken in 1928. I'm sure the camera was hand-cranked. Using AssumeFPS(), I kept adjusting the speed and slowing it down more and more until I finally arrived at 12 fps, which I think is roughly the right speed so the motion is the same as what it was in real life.

This was from 16mm film, and for an amateur, the film stock was so darned expensive that many people cranked at really slow speeds in order to be able to capture the action without going broke.

https://www.youtube.com/watch?v=1YekFxBYKNM

[color]

May I ask what movie this is?

And I agree with johnmeyer. I have restored a hand cranked movie before and the spread may vary. I don't remember what program I used before but it had a speedchanger so if it gets to fast or to slow it could be "corrected" but it cost frames. It's better following the advice given and keep all the frames you can. Alternative add frames between with morphing effect, but...the result may very.

Also. Jerky film that has frameloss when paning up and down or sideways can be fixed with deshaking, but not movements like a person walking, but it can give a more natural movement and better to watch. :)

[citroenfan]

Thank you everyone for the contribution, and especially manono and johnmayer on their advices.

I made video processing of the entire movie in your way (both as suggested by monono and johnmayer) and movie is much better looking than before.

I've been following this web site for a long time and I'm using the valuable video processing tips I've learned here and who helped me very much.

This film is "The Lucky Dog" from 1921., the first joint performance by two great comedians, Stanley Laurel and Oliver Hardy. As their first appearance, their way to the movie stardom is just starting and their characters are not developed yet to what we know them today.

With this film I am closer to complete my collection of their movies, and I would like to have it in the best condition. Throughout the time, I bought 5-6 different copies of the film, looking for the best quality. Movie is usually found on Public Domain DVD's so quality is usually bad to very bad. This copy is the best version of them all, and I would like to restore it in the best possible way.

Regarding a comment on a different frame/field pattern at the beginning sample I posted before, I think that's because when I made the sample cut with VideoReDo, maybe I did not cut it in right frames, so VideoReDo recode it.

Attached I'm sending a link for the whole movie. It's original .vob file from the DVD (745MB, 24 minutes), without any processing.


http://www.mediafire.com/file/fdgx7ciepnevqtw/LH_The_Luck_Dog_1921.VOB/file


thank you very much everyone for your contribution.

[johnmeyer]

I'm not sure if you are located in the USA, but if you are and if you have a TV service that carries Turner Classic Movies (TCM), they run silent movies every Sunday evening, and often run them at other times of the week. About 80-90% of the films they show have been restored, and some of the silent film restorations are stunning. Most of the restorations are far more than the digital tricks that some of us do in this forum, and instead involve getting hold of the nitrate negatives, if they still exist, or combining the best available prints from multiple sources.

"The Lucky Dog" appears to be a short, which will make it tougher to find on TCM. They use shorts to fill the gaps between movies and usually don't list them on their program. Also, many of the shorts do not appear to be restored. This might be an exception, since it is one of the first appearances of Laurel & Hardy.

[Cary Knoop]

The restoration of Laurel and Hardy films was for a long time an issue due to the particular position of the rights holders.

UCLA has picked up the tab (by donations)
https://www.cinema.ucla.edu/support/laurel-and-hardy

Earlier and out of copyright films are not (yet?) included.

[StainlessS]

citroenfan
The link in code block at bottom of post 24, dont need to be in code block, just enter link in post, will be entered as clickable web link.

[Cary Knoop]

Lucky Dog fragment at 16p with some denoising.

https://youtu.be/0QBlEtgOvgg