site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=BLeOaQDrzO2vIlWAng68ERMBYDtkqXlLUoOxNeZSkis=; b=bCIQe+DQvWiVAn/bTvD27Qsh2r5LpQXD0PqOokuJAcI/PIEkXcNrtOKvQ5+yuMyE7i FZMvrB85rRbCjnQI7hl4zpQUuUYeMm5BrqjrbPgAJDP2bdnpURdBY6w2ngabpIkZtZuU L4wajqftKRQEgAucLmFc64V1lud+52cMWHNrw= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=XyUBMrOjU5MsusDRrJ7c60RANyf7zqks35FpxzTnKBYtSvPpJPCH2mR+NkIdnYuGG5 w8DT0NYCQ+ED09GhWkLqn6mGYV0MQpUgz4fWhpiMKLY4bGcBCNGWm5CzRp08RLGJ9DyG PvgRvP2BxZ7tr+hOBfUeGhktDJPjo8hwLy6Rk= The situation looks better than I thought at first. Summary: FCP does respect the high-precision parameters in the XML, and they are preserved when the project is saved. Some details: When you do Modify > Speed on an audio clip, it affects a couple of things in the XML. The speed <value> element gets the value that the user entered (with some mangling of precision). And the keyframe <when> element gets updated to reflect the new number of frames. Experiments indicate that keyframe <when> takes precedence over speed <value>. The Modify > Speed dialog lets you adjust the Duration field to the precision of a frame, but the Speed field mangles the entered value. This seems like a bug to me and I will report it. For my needs, as long as my users don't mess with the Modify > Speed dialog everything should be OK. Bruce On Mon, Feb 16, 2009 at 11:10 AM, Bruce Sharpe <bruce.sharpe@gmail.com> wrote:

[Re-sent to the whole list.]

Comments below.

On Mon, Feb 16, 2009 at 9:52 AM, Ky Hopwood <khopwood@apple.com> wrote:

...

You have audio that is not in sync with video and are trying to adjust the speed the video to match the audio?

That's about right, but more often I want to adjust the speed of the audio rather than the video.

...

Is you audio fine at the start, and then drifts linearly , or is completely ok and then at some point goes off?

It has a linear drift that I know to a high degree of precision.

...

In addition, I gather from what you are saying that you are not really using xml is this workflow, but rather you are using that simply to display the values of the speed keyframes. Is that correct?

XML is in the workflow. I am writing a plugin that helps with synchronization. It retrieves the project XML, analyzes the clips to determine the drift and writes back XML with a time remap speed parameter to compensate. My concerns are that (1) FCP may not respect the full precision of the speed parameter in the XML, (2) even if it does, it may not persist when the project is saved, and (3) if the user looks at the speed in the UI, its value will be corrupted.

I'm pretty sure about #2 and #3, but I'm doing an experiment to assess #1 right now and will let you know shortly.

Bruce

On Mon, Feb 16, 2009 at 9:52 AM, Ky Hopwood <khopwood@apple.com> wrote:

...

I am not certain I have your scenario correct, so a few questions to verify.

You have audio that is not in sync with video and are trying to adjust the speed the video to match the audio? Is you audio fine at the start, and then drifts linearly , or is completely ok and then at some point goes off?

In addition, I gather from what you are saying that you are not really using xml is this workflow, but rather you are using that simply to display the values of the speed keyframes. Is that correct?

ky

...

I want to overlay clips from recording devices that are free-running (not jam-synched). Even though most of the clocks are pretty accurate, these are clips of live events that last a long time and over the course of many minutes it is not unusual for them to drift apart from one another by an amount that needs to be corrected. Time remap seems like a good mechanism to adjust things back into sync. But the speed value only seems to be able to retain numbers up to a precision of two decimal places. For example, enter 100.12345 in the user interface and 100.133 is what gets stored in the XML, which is not even rounded properly. The residual error over the length of an hour can be hundreds of milliseconds, which is not acceptable for many synchronization purposes.

I can't figure out if this is an artifact of the user interface or some fundamental limitation. Is there a sneaky way to specify a remap speed with greater precision?

Bruce

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/bruce.sharpe%40gmail.com

This email sent to bruce.sharpe@gmail.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... This email sent to site_archiver@lists.apple.com