Where is guide to frame rate "reduction"

[Anetic]

Is here somewhere guide how to change framerate 25 to 23.9?

[killingspree]

just download the decomb filter package from Dg and read the tutorials in the package...

furthermore
http://www.doom9.org/decomb.htm
http://www.doom9.org/decomb-params.htm
might help too

cheers
steVe

[stephanV]

isnt decomp used to go from 29.97 to 23.976 fps (3:2 pulldown removal)?

if you have a progressive 25 fps source the best thing to do would be:
- demux the audio
- slow down the video framerate to 23.976
- stretch/slow down the audio to the correct length/rate
- remux audio

[starwarsandrisk]

decomb can do that too... just read the tutorial... it'll let you know what you have to do step by step

[stephanV]

then how? using 'assumefps' is way easier and is how it is actually is done the other way around. (24 fps to 25 fps). in the two links provided by killingspree only the conversion from 30 to 24 fps is being dealt with.

moreover, if you do the sourcerate adjustment in VDub you dont even have to re-encode the video.

[killingspree]

difference between decimate and assumefps:
let me quote:
from avisynth.org (http://www.avisynth.org/index.php?page=FPS)

AssumeFPS

AssumeFPS(clip clip, float fps [, bool sync_audio])

AssumeFPS(clip clip, int numerator [, int denominator, bool sync_audio])

The AssumeFPS filter changes the frame rate without changing the frame count (causing the video to play faster or slower). It only sets the framerate-parameter. If sync_audio (which is false by default) is true, it also changes the audio sample rate to match the duration of the video, the pitch of the resulting audio gets shifted.

This is also a method to change only the sample rate of the audio alone.


from doom9.org (http://www.doom9.org/decomb-params.htm#decimate):

Decimate parameters

Decimate(cycle, mode, threshold, debug). The default settings correspond to Decimate(cycle=5, mode=0, threshold=0, debug=false) or simply Telecide().

cycle (0-25) indicates to remove 1 frame in n frames where n is the number you enter as parameter. The default is cycle=5 and removes one frame in 5 which is what we need to restore a telecined 29.97fps source to 23.976fps.

mode (0-1) determines what to do with frames determined to be most similar to their preceding frame in each cycle. The default mode=0 discards that frame, mode=1 the frame would be blended with the previous frame. This can be useful if you have a hybrid 30/24fps source and don't want the 30fps parts to be jerky by discarding some of the frames. Usually, movies/series that contain both live action and CG stuff are hybrid (for instance Andromeda and Babylon5).

threshold (0-99) can help prevent blended frames on 30fps content when using mode=1. If the difference between frames is larger than this threshold a frame will be be passed through untouched whereas if the threshold is lower than the value you've set the frame will be blended. The default threshold=0 will let all frames pass through untouched. This parameter has no influence when you use mode=0, and if you use mode=1 a value between 25 and 50 is reasonable.


this should explain it...

cheers
steVe

[stephanV]

yes, i know the difference between them.

but dropping or blending frames to go from 25 fps to 23.976 fps doesnt seem a wise thing to do... if im correct you cant even use decimate in this way. you could set it up to drop 1 frame of every 25 frames which would mean youd end up with 24 fps.

i really do believe that adjusting the video framerate with VDubMod and resampling the audio is a better way to do this conversion. but each to his own of course :)

[killingspree]

Originally posted by stephanV

but dropping or blending frames to go from 25 fps to 23.976 fps doesnt seem a wise thing to do... if im correct you cant even use decimate in this way. you could set it up to drop 1 frame of every 25 frames which would mean youd end up with 24 fps.


well probably i wasn't clear enough...
of course you cannot get to 23.976 with decimate! But imho it is better to first do decimate(25) and then add assumefps(23.976) as this will only involve a speed change of .024 fps - which shouldn't be noticable at all. maybe a fps change of 1.024 isn't really noticable either - but it's still changing the length of an 2 hours movie by almost 5 minutes!!

anyway, there's a lot of discussion been going on about the best way to change the framerate as part of a general NTSC to PAL (and vice versa) discussion, so i think it's not really necessary to do it all again ;)

cheers
steVe

edit "but each to his own..." - and that is of course true! whatever one likes better!