Sequence In/Out Precision Problem

[skymonkies]

Hi All,

I recently noticed that sometimes when I set the in/out points in a sequence they'll actually be off by a frame. For context, I want to render a portion of a sequence so I mark the in/out points to be precisely the end of a particular clip. In one example, this is at 4.004s. However when set this as the in point, it's actually set at 4.00397916666s which causes premiere to start at the previous frame. This looks like some sort of a floating point problem, is there a way to get more fidelity (maybe use ticks)?

Thanks!

[e_d_]

Hi,

this rounding issue seems to have the same background as mentioned here:

Clip Marker: Different start/end time in seconds

So the solution might be the same.

[skymonkies]

Hi, thanks for the suggestion. I think this is a slightly different problem in that I need Premiere to internally store the correct time since I want to call a render based on the in/out times. I could perhaps make a time canonicalization function and feed that into setInPoint but I think I'd still be unsure if the time I'm canonicalizing (from the clip) is correct to begin with.

===== Edit

On closer inspection it looks like

setInPoint(4.004) => getInPoint() = 4.00397916666

while

setInPoint(4.00400000001) => getInPoint() = 4.0039999999

This seems odd, if it’s a representation problem why would 4.0039999 be skipped over when setting to 4.004? How is it actually set behind the scenes?

[e_d_]

This is a problem with precision when converting between floats and integers.

When you enter 4.004, this should be passed to Premiere as 1,017,080,064,000 ticks. But when this integer is converted to a float, the actual value being stored is 1,017,080,053,760 which when converted back to seconds gives you 4.003999959687....

This is what happens when using single-precicion floats, so the effect should not be as dramatic when using double precision, but that's just guessing...

[skymonkies]

Ah you're right, single precision stores the ticks as 1.01708005376e+12 while doubles can store 1.017080064e+12. However wouldn’t this imply that it’s not possible for Premier to store the correct ticks if it’s using single precision? And if it is using double precision behind the scenes why use single precision to do these conversions? It seems like technically if Premier can handle ticks with high precision then it should also be possible to set the ticks with high precision (whether using seconds as a proxy or not).