Apple

On Sep 2, 2009, at 7:31 PM, Bruce Sharpe wrote:

Eryk, thanks for the confirmation. Is there any value in re-submitting it as a bug just to emphasize that someone cares about it?

For posterity, here are some more details about this. Suppose you have a project element (clip, sequence, etc.) that is longer than 1 million frames. What happens if you export via XML and then re-import?

The good news is that FCP will re-import the XML without crashing. So it is not counting on frame units being expressed in fixed-point notation. As expected though, big numbers lose precision so the imported project will not be identical to the project that was exported.

More good news: if the XML contains seven-digit integers, they get imported without any problems.

One real-world consequence of all this is that if you are working on a project with a long timeline and you do something via XML to modify the project, various project elements could end up being out of sync with each other by up to five frames.

Bruce

On Wed, Sep 2, 2009 at 6:38 PM, Bruce Sharpe <email@hidden> wrote:
Frame counts are inherently integers, so there's no reason for using real numbers at all. Even with 24 hours of video at 60 fps, the number of frames is well under 10 million. It fits comfortably into a 32-bit integer and needs only seven digits.

What we are seeing is probably just a consequence of FCP code using a C++ default string formatter for a double.

Bruce

On Wed, Sep 2, 2009 at 6:03 PM, Marshall Eubanks <email@hidden> wrote:

On Sep 2, 2009, at 8:29 PM, Bruce Sharpe wrote:

I have just discovered that if a project contains a clip that has more than a million frames (4.6 hours at 60 fps would do it), then numbers like duration, in, out, etc. will be exported in the XML in scientific notation.

Example:
Expected value: <duration>1234567</duration>
Exported value: <duration>1.23457e+06</duration>

Aside from the fact that it messes up everyone who is expecting an integer there is a loss of precision. The difference between 1234567 and 1234570 frames could be important in some contexts.

Is this a known bug?

Single precision has 24 bits of precision, or about 6 x 10^-8 fractionally. So, that would be 0.07 for your example, and should be marginally OK. However, in dealing with Julian Dates (about 2,500,000 days since the initial epoch, or an error of 0.15) we found that this is dangerous. With even a little bit of manipulation (subtract this value from that, and add to a third), you run the risk of being off by a day (or, in this case, a frame).

So, in my opinion, these really should be double precision if they are going to be real numbers.

Regards
Marshall

Bruce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)

This email sent to email@hidden

References:
	>Big integers exported in scientific notation in XML (From: Bruce Sharpe <email@hidden>)
	>Re: Big integers exported in scientific notation in XML (From: Marshall Eubanks <email@hidden>)
	>Re: Big integers exported in scientific notation in XML (From: Bruce Sharpe <email@hidden>)
	>Re: Big integers exported in scientific notation in XML (From: Bruce Sharpe <email@hidden>)
	>Re: Big integers exported in scientific notation in XML (From: Eryk Vershen <email@hidden>)