Applying 3:2 to 23.98 source - Different Length

[speedyrazor]

I am applying the below script to an HD 23.98 source file to get to 29.97 with 3:2 pulldown, but the resulting files are about 3.5 seconds longer than the original, I thought they should be exactly the same length as the original. The source is 54 mins long. What am I doing wrong?


QTInput("Source.mov", quality=100, audio=2)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Spline64Resize(720, 480)
ChangeFPS(60000,1001)
AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave()

[wonkey_monkey]

What's the exact framerate of the source? Is it 23.98? 23.976? 24000/1001?

What happens if you replace


changefps(60000,1001)


with:


selectevery(4,0,0,0,1,1,2,2,2,3,3)
assumefps(60000,1001)

[speedyrazor]

The source is 23.976.
So my new script will look like this?:

QTInput("Source.mov", quality=100, audio=2)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Spline64Resize(720, 480)
selectevery(4,0,0,0,1,1,2,2,2,3,3)
assumefps(60000,1001)
AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave()

[speedyrazor]

The source is 23.976.
So my new script will look like this?:

I just tried the above on a 90 second clip and there was a few frames difference between source and target, so I don't think that is correct.

Regards.

[creaothceann]

The source is 23.976

Just for the record: When you add "Info" after QTInput, does it say "Frames per second: 23.9760 (24000/1001)"?

[Desbreko]

There's an example of how to apply 3:2 pulldown to 23.976 fps video on the wiki's page for Select (http://avisynth.nl/index.php/Select).

You should really encode it as progressive and apply soft pulldown with DGPulldown or something if possible, though.

[Katie Boundary]

You should really encode it as progressive and apply soft pulldown with DGPulldown or something if possible, though.

^this

[johnmeyer]

How many frames are in the original? How many frames are in the video that results from your script? That ratio will help determine what is going on. It eliminates having to know the fps of your original, and will help verify that your script is doing what you think it is doing.

Your 54 minute video is 3,240 seconds long. If your original video is 23.976 fps instead of 24 fps, then using the wrong frame rate will give you a discrepancy of:

3,240 - [ (23.976 / 24.000) * 3, 240 ] = 3.2 seconds

This is more or less the number you gave for the time discrepancy and since you didn't specify the exact time of the original video, it's close enough to be considered (by me) correct.

[colours]

Regardless of all the other suggestions thus far, if the script containing ChangeFPS has a different duration, the fault clearly lies not in ChangeFPS or SeparateFields or Weave or whatever.

It lies in QTInput.

Solution: try another source filter, like FFMS2. If using another source filter doesn't solve your problem, there's something else you're doing wrong, in which case you should provide as much information as possible.

[speedyrazor]

How many frames are in the original? How many frames are in the video that results from your script? That ratio will help determine what is going on. It eliminates having to know the fps of your original, and will help verify that your script is doing what you think it is doing.

Your 54 minute video is 3,240 seconds long. If your original video is 23.976 fps instead of 24 fps, then using the wrong frame rate will give you a discrepancy of:

3,240 - [ (23.976 / 24.000) * 3, 240 ] = 3.2 seconds

This is more or less the number you gave for the time discrepancy and since you didn't specify the exact time of the original video, it's close enough to be considered (by me) correct.

So what you are saying is that it is correct. If is assume 24 fps (speed up to 24 fps) then do the 3:2 pulldown, I then should end up with exactly the same length?

[johnmeyer]

I can't answer your question until you answer the one I asked.

[speedyrazor]

How many frames are in the original? How many frames are in the video that results from your script? That ratio will help determine what is going on. It eliminates having to know the fps of your original, and will help verify that your script is doing what you think it is doing.

Your 54 minute video is 3,240 seconds long. If your original video is 23.976 fps instead of 24 fps, then using the wrong frame rate will give you a discrepancy of:

3,240 - [ (23.976 / 24.000) * 3, 240 ] = 3.2 seconds

This is more or less the number you gave for the time discrepancy and since you didn't specify the exact time of the original video, it's close enough to be considered (by me) correct.

Hi, Here is the info I have found:

00:54:16:22 - 23.9760 fps - 78165 frames - source
00:54:20:06 - 29.97 DF fps - 97707 frames - destination

[colours]

78165 frames in 54 minutes and 16.22 seconds (assuming that's what you meant by the third colon because who uses a freaking colon as a decimal separator) works out to 24.005 fps, not 23.976 fps.

How are you getting the frame count and duration of the source, and what makes you so sure that the original is supposed to be 23.976 fps rather than 24 fps?

Edit: disregard my colon comment; apparently, taking the last number as a frame count in the current second and solving for the frame rate gives 23.99969 fps. Or exactly 24 fps if QuickTime is retarded and counts the frames starting from 1 instead of 0.

[speedyrazor]

78165 frames in 54 minutes and 16.22 seconds (assuming that's what you meant by the third colon because who uses a freaking colon as a decimal separator) works out to 24.005 fps, not 23.976 fps.

How are you getting the frame count and duration of the source, and what makes you so sure that the original is supposed to be 23.976 fps rather than 24 fps?

I am on a MAC, open up the source in quicktime pro, which is showing me frame count, duration and frame rate, should be accurate.

[wonkey_monkey]

I am on a MAC, open up the source in quicktime pro, which is showing me frame count, duration and frame rate, should be accurate.

Ah, well, yes, should be - but what if it's showing not the actual playback direction, but instead showing the timecode of the last frame?

Thanks to the whackiness of NTSC, there are two different types of timecode used - drop frame (which will give you approximately the same timecodes on a 29.97fps video as if it was actually 30fps) and non-drop frame. And over one hour the accumulated difference works out to...

...3.6 seconds!

Solved?

[kolak]

Yes, with NTSC drop frame timecode gives your "real duration". NDF will be out as it's counted at 30fps.

[johnmeyer]

Ah, drop frame. Good catch.