Apple

On Sep 26, 2011, at 5:57 PM, Jon Chappell wrote:

I thought I understood this but then FCP produced values like this and I got confused again:

                    <marker start="8193/2s" duration="100/2400s" value="Marker 14"/>
                    <marker start="98573/24s" duration="100/2400s" value="Marker 13"/>
                    <marker start="4117s" duration="100/2400s" value="Marker 12"/>
                    <marker start="12377/3s" duration="100/2400s" value="Marker 17"/>

This is a sequence containing two clips of less than a minute each for a total running time of 00:01:15:00. 4117s is obviously far too large and dividing by 2400 or 24 doesn't get me anywhere near the actual location of the marker which is 00:01:06:08. Is this a bug or am I doing it wrong? The XML guide is very vague on this.

Regards,
Jon Chappell.
CEO, Digital Rebellion LLC.
http://www.digitalrebellion.com

On Wed, Sep 21, 2011 at 2:39 PM, Jon Chappell <email@hidden> wrote:

Thanks Andrew. That's very helpful.

Regards,
Jon Chappell.
CEO, Digital Rebellion LLC.
http://www.digitalrebellion.com

On Wed, Sep 21, 2011 at 1:27 PM, Andrew Demkin <email@hidden> wrote:

Hi Jon,

There are cases where Final Cut "reduces" time values into a different timescale even though the values are already frame-aligned. This behavior could change later (by converting the values back to the timescale of the parent clip at export time), but we don't guarantee this behavior one way or the other. A parser will work best if it can handle arbitrary timescales.

(I'm not suggesting it applies to the case you mentioned, but sometimes a reduction in timescale might be warranted to avoid overflow, e.g.).

Related to this, the FCP XML format does not specify whether time values need to be frame-aligned. Certain audio data, for example, will be aligned to samples that do not align with video frame boundaries. A parser should be prepared to accept these values, even if it ultimately has to change the value into something more appropriate for its own use.

In summary, it's recommended that a parser be prepared to handle arbitrary time values. But, any tool (including FCP itself) always has the freedom to adjust time values as it deems necessary.

I hope that helps,
Andrew

On Sep 21, 2011, at 12:06 PM, Jon Chappell wrote:

Thanks Greg and Rainer. Seems like it's easy enough to work around.

But I'm interested to know if it's deliberate and if so, what advantage it offers over encoding them the expected way.

Regards,
Jon Chappell.
CEO, Digital Rebellion LLC.
http://www.digitalrebellion.com

On Wed, Sep 21, 2011 at 11:28 AM, Gregory Clarke <email@hidden> wrote:

To "decode" those start times I've been using Spotlight a lot: copy the fraction, paste it into spotlight and you'll get it converted into "human readable" seconds.

So your first 3 markers are 7.3333333333, 9.2083333333 and 9.4166666667.

Hope this helps,

Greg

On Sep 20, 2011, at 7:01 PM, Jon Chappell wrote:

I was playing around with a test project and exported an XML file. The duration and offset timebases of the media are predictable: 2400, 48000, 50, etc.

However, the marker start times seem to have bizarre timebases. Why is the timebase for the start position not inherited from the clip or project timebase like the duration?

Here's a sample of the XML file. You can see that the marker durations are all "100/2400s" but the start times all have different and seemingly random timebases. Is this by design or is it a bug? The FCP XML guide doesn't mention it.

          <clip name="90-8+_ProRes_Proxy" duration="37s" audioStart="0s" audioDuration="90000/2400s" format="r2" tcFormat="NDF">
                    <video ref="r4" duration="90000/2400s">
                        <audio lane="-1" ref="r4" duration="1800000/48000s" role="dialogue"/>
                    </video>
                    <clip lane="1" offset="67700/2400s" name="90-8+_ProRes_Proxy" duration="28700/2400s" start="42000/2400s" tcFormat="NDF">
                        <video ref="r4" duration="90000/2400s">
                            <audio lane="-1" ref="r4" duration="1800000/48000s" role="dialogue"/>
                        </video>
                    </clip>
                    <clip lane="-1" offset="76500/2400s" name="90-8+_ProRes_Proxy" duration="28700/2400s" start="42000/2400s" tcFormat="NDF">
                        <video ref="r4" duration="90000/2400s">
                            <audio lane="-1" ref="r4" duration="1800000/48000s" role="dialogue"/>
                        </video>
                    </clip>
                    <marker start="22/3s" duration="100/2400s" value="Marker 1"/>
                    <marker start="221/24s" duration="100/2400s" value="Marker 2"/>
                    <marker start="113/12s" duration="100/2400s" value="Marker 3"/>
                    <marker start="21/2s" duration="100/2400s" value="Marker 4"/>
                    <marker start="34/3s" duration="100/2400s" value="Marker 5"/>
                    <marker start="277/24s" duration="100/2400s" value="Marker 6"/>
                    <marker start="151/12s" duration="100/2400s" value="Marker 7"/>
                    <marker start="305/24s" duration="100/2400s" value="Marker 8"/>
                    <marker start="27/2s" duration="100/2400s" value="Marker 9"/>
                    <marker start="109/8s" duration="100/2400s" value="Marker 10"/>
                    <marker start="113/8s" duration="100/2400s" value="Marker 11"/>
                </clip>

Regards,
Jon Chappell.
CEO, Digital Rebellion LLC.
http://www.digitalrebellion.com

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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:
	>Random marker timebases (From: Jon Chappell <email@hidden>)
	>Re: Random marker timebases (From: Gregory Clarke <email@hidden>)
	>Re: Random marker timebases (From: Jon Chappell <email@hidden>)
	>Re: Random marker timebases (From: Andrew Demkin <email@hidden>)
	>Re: Random marker timebases (From: Jon Chappell <email@hidden>)
	>Re: Random marker timebases (From: Jon Chappell <email@hidden>)
	>Re: Random marker timebases (From: Gregory Clarke <email@hidden>)