Re: Low precision on time remap
Re: Low precision on time remap
- Subject: Re: Low precision on time remap
- From: Bruce Sharpe <email@hidden>
- Date: Mon, 16 Feb 2009 12:09:12 -0800
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 <email@hidden> wrote:
> [Re-sent to the whole list.]
>
> Comments below.
>
> On Mon, Feb 16, 2009 at 9:52 AM, Ky Hopwood <email@hidden> 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 <email@hidden> 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 (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)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden