Are there "correct" dividend/divisor for 23.976?

[shae]

Are there specific dividend and divisor for 23.976fps that are considered correct, or will anything do? Are there cases where problems arise because of these values? I've seen the following used:

2997/125, 23976/1000 (=23.976)
24000/1001 (=23.976023... [period of 6])
10000000/417083 (=23.976043...)

I tend to go with 24000/1001.

[Blue_MiSfit]

I would probably agree, considering that the correct NTSC frame rate is 30000/1001

~MiSfit

[shae]

I think different tools end up using different values. Assuming /1001 is the real rate, what is the reason for the other options? I can see where 23976/1000 might originate, but 10000000/417083? (Maybe a some algorithm that tries to get close to the fractional?)

Should I start manually editing files to 24000/1001, or is there no reason to bother?

[foxyshadis]

SMPTE uses 2997/100, but you shouldn't unless you're syncing with a tape deck. (You'll have to take drop frames into account then anyway.) Broadcast rate is always 30000/1001.

The last one comes about because a lot of software will use 100ns as a standard base tick rate for timecode formats (mov,mp4,mkv,mpg,etc), and each frame will last 41ms or 417083 ticks, but it's only an approximation.

All of these are "close enough" to be useful for anything but frame-exact syncing in a long recording, though. Just calculate what the error would be after a given amount of time if you're interested, you'll find it's usually only a couple of frames duration even for major perversions of the rate (like 23.978). (seconds*(24000/1001 - fps2) = frames off of true)

[shae]

So DVD sources would be /1001 I guess? What about HD broadcast (and is it different depending on the flavor?)? And HDDVD/BR, wouldn't they finally be true 24 fps?

[ChiDragon]

"Film" DVDs are definitely 23.976. HD DVD and Bluray support both 23.976 and 24, and I believe the HDTV standards do as well. So for those it just depends on how it was encoded.

[shae]

"Film" DVDs are definitely 23.976.Yes, but which one, /1001? :)

HD DVD and Bluray support both 23.976 and 24, and I believe the HDTV standards do as well.If that's really the case, it's sad. I'd hoped all the analog baggage would finally be dropped.

What's the point of having both? If NTSC output is needed, just have the decoder shift it a bit. Same as I initially expected DVDs to be...

[ChiDragon]

Yes, but which one, /1001? :)

Well 24000/1001 is the correct fraction, so yes. DGDecode uses it explicitly since a few versions back.

[mp3dom]

I've read by some specs that BluRay support 24p but HD-DVD support only the 29.976. 24p Films to HD-DVD need the same work as DVD (24->23.976->Pulldown 3:2). Dunno if it's really true....

[shae]

I've read by some specs that BluRay support 24p but HD-DVD support only the 29.976.I don't think that's correct. Where did you see it?

But even with 24p allowed, I wonder if any of the current titles actually use it.

[mp3dom]

On Wikipedia and other sources, you can read that BluRay support native 24p (storing 24p) while HD-DVD store the 24p as 60i with software pulldown (flag). The decoder can discard the flag to output a true 24p.
It's a bit different from what I remember, sorry for that.

[Manao]

The last one comes about because a lot of software will use 100ns as a standard base tick rate for timecode formats (mov,mp4,mkv,mpg,etc), and each frame will last 41ms or 417083 ticks, but it's only an approximation.No, it's not the standard base tick for those formats. It's actually the standard base tick for directshow.

mov certainly wouldn't like a timebase of 100ns, since QT supports only 32 bits timestamps ( no more than 4 minutes of video ... )

[IanB]

And the cleverer DirectShow apps "DITHER" the timestamps to make up for any cumulative arithmetic rounding error so the /1001 can still thought of as most optimal.

[Manao]

Since avisynth can't do VFR, the dithering is lost though.

[IanB]

Since avisynth can't do VFR, the dithering is lost though.Since avisynth can do /1001 the dithering is unnecessary.

[shae]

You mean despite "dithering", /1001 is still better? And how does this dithering work?

[Manao]

/1001 is exact, so it's necessary at least as good as anything else.

The dithering works like this. Instead of saying each frame has a duration of 1001*10000000/30000=333667, you say the timestamp of the first frame is 0, of the second frame is 1001*10000000/30000=333667, of the third frame is 2002*10000000/30000=667333, of the fourth frame is 3003*10000000/30000=1001000, ...

That means the duration of the first frame is 333667, of the second is 333666, of the third is 333667, of the fourth is 333667, and so on, and so forth.

In average, the duration of a frame will be 333666.66666/10000000 = 1001/30000.

Of course, you've created a VFR video, but in the DirectShow framework, everything is VFR anyway.

[IanB]

I think to appreciate why the correct divisor is 1001 a little background may help.

Interlaced NTSC Colour TV uses a vertical scan frequency of 60000/1001 Hz, which is the repeated decimal 59.9400599400... This is the field rate.

As an interlaced image has 2 fields per frame the frame rate is half this or 30000/1001, which is the repeated decimal 29.9700299700...

To show a 24 FPS film on TV some processing is needed. They first slow the frame rate down slightly and then distribute the frames across the fields in a 3:2 pattern. Thus 2 Film frames become 5 TV fields.

Working backwards, each field has a duration of 1001/60000 seconds. The duration of 5 fields is thus 5*1001/60000 = 1001/12000 seconds which is the duration of 2 film frames. So the duration of 1 frame would be 1001/12000/2=1001/24000 seconds. As the rate is the reciprocal of the period the film frame rate must be 24000/1001 FPS which is the repeated decimal 23.9760239760... which is a 0.1% slowdown.

We humans with our decimal arithmetic are slack! We approximate! We use 29.97! and 23.976! which of course when you convert back to a ration pair gives 2997/100 and 23976/1000 which we normalize by removing the common factor 8 to 2997/125.

So 24000/1001 is the correct value to use. In the first post Shae is correct. All other values are approximations caused by conversions back and forth between decimal and rational representations of this value.