This IS the Avid L2: Re: [Avid-L2] Re: AMA Clip duration issue

And to add further annoyance smoke 2012 does it the avid way while smoke 2013 has adopted the FCP way.

Nice and confusing for 20 year Autodesk users like me :(

The world is changing, edls are on borrowed time, personally I think it's almost time to abandon timecode completely and revert to frame numbers given that we rarely shoot sync speed anymore in tvc land.

Best regards

Mike

On 4 Jun, 2013, at 7:38 PM, "craigacm" <CraigACM@aol.com> wrote:

> One thing I noticed in researching my issue may help explain what you see in an Avid-FCP roundtrip: FCP and Avid express the timecode Out-point of a clip differently. Avid uses the traditional EDL method where the Out timecode is one frame beyond the actual last frame of the clip. This creates an accurate duration when the In is subtracted from the Out. For example, if you had a 1 frame duration clip whose In was 00:00:00:05, the Out would be expressed as 00:00:00:06. FCP displays the Out as the actual timecode of the last frame - in a 1 frame clip the In and Out would appear to be the same number, but the duration is still calculated as :01.
>
> This discrepancy in the OUT timecode might somehow mess up the file in a Roundtrip and give you the shortened clip on reimport back into Avid.
>
> But as you suggest, I don't think that's my issue because I'm seeing differing results within Avid itself with the same clip.
> Craig
>
> --- In Avid-L2@yahoogroups.com, "johnrobmoore" <bigfish@...> wrote:
> >
> > I have consistently found exporting a same as source Avid QT in HD and SD 1:1 and then manipulating the file in FCP7 and reexporting results in a clip that is one frame shorter than the original. This is exporting an in to out section of an avid timeline and getting back a clip reexported from FCP and losing the last frame. The solution was to start exporting a clip one frame longer out of avid. Even if that went past a camera cut the round tripped file would not have the extra frame of the next shot and would fit perfectly.
> >
> > This may not be related to your problem but it sure sounds similar.
> >
> > --- In Avid-L2@yahoogroups.com, "craigacm" <CraigACM@> wrote:
> > >
> > > Here's an issue with ProRes AMA files that I haven't seen discussed before... Has anyone encountered AMA linked clips having a different duration than the source file?
> > >
> > > I have an entire doc that was shot on ProResHQ. (1920/23.98 project on both an MC6.5 and Symphony 6.) We AMA-linked the camera files and transcoded to DNx36. For finishing, we knew that AMA ProRes clips have incorrect video levels (which Source Settings adjustments do not fix), so we did a 709 Fast Import of the camera files (which maintain proper levels). The edited sequence re-linked to the Imported ProRes Avid media without an issue.
> > >
> > > However, we found that the full DNx36 clips would not relink to the same ProRes Avid media, and discovered that the AMA clips are 1 or 2 frames longer duration than the 709 Fast Imports! The AMA clips show an extra frame or two at the tail that is a duplicate of the very first frame of the clip. This occurs in 1000s of files that were AMA/Transcoded over the past year on MC6.5.
> > >
> > > I did some more testing on these and with other camera files and got varying – and maddening! – results:
> > > * Sometimes, the AMA clips are 1 frame shorter than the 709 Fast Imports – the last frame is missing.
> > > * I've also seen the same camera file AMA-link with extra frames at the end, and then, at another time, AMA-link with no extra frames.
> > > * A standard RGB Import of the same file (neither fast, nor accurate for video level) adds an extra frame at the end.
> > > * DNx imports of the ProRes files also seem to add an extra frame… most of the time.
> > >
> > > I suspected that the camera files were corrupt in some manner – they all come from an Atomos Samurai. However, opening the same files in FCP7 does not present any such issues. And, I believe the 709 Fast Imports of the ProRes camera files are perfect – have not found any extra or missing frames in any of them.
> > >
> > > This duration mis-match leads to all sorts of workflow issues with relinking, batch importing, etc. that I've been trying to work out. More about that at another time! When I get a handle on it, I'll provide more details that might be of interest to the list.
> > >
> > > Thanks in advance for an feedback or insights!
> > > Craig Mikhitarian
> > > ACM Productions, Ltd.
> > >
> >
>
>

[Non-text portions of this message have been removed]