Reconnect File means timecode change in FCP 6

I am just starting on a new project and we've run into this issue.

We're using multiple stations to capture DVCProHD (from tape and P2) and miniDV. Everything for one episode is eventually copied to one 1.5 or 2 terabyte FW800 drive for editing.
The problem we're running into is that when we copy the media to the destination drive and relink the clips it throws up a warning about changing the media start and end TC. Sometimes the start and end TC do change and sometimes just the end TC and sometimes nothing changes and sometimes there is no warning and nothing changes.
I am trying to track the problem as it seems to be independant of specific drives (mix of LaCie and Elephant) and CPU (mix of G5 towers and intel MBPro).
Anyone run into this before?
Our next round of tests involves a recapture of clips that have been changed by FCP to see how it has affected our ability to redig in case of drive failure.

We're doing a partial offline/online in that we're dumping out DVCProHD quicktimes of the final sequences for CC/packaging at an outside facility.

thanks

ak
Sleeplings, AWAKE!

Yeah, I've seen that problem before and it baffles me as well -- and in my case, sometimes it's even the same station after I've moved some media files. What happens if you just re-import the clips into a fresh project file rather than reconnecting? How do the timecodes look?

I'm wondering whether it has anything to do with how DVCPro HD clips work (60i but flagging for 24p, etc.). Or it could be an FCP5 bug? I've never seen it happen to my FCP4.5 station (just recently upgraded to FCP5 -- yes, yes, been dragging my feet).


www.derekmok.com

Thanks Derek. At least I know we're not crazy, and we're finding it on v6!
There are a lot of vaiables to eliminate for us to track this down. I am not doing any of the actual handling of the files so I am trying to find out what I can when I am not actually editing.

After reading up on the Firestore (urgh!) for a totally different project at a different facility, I remember getting the sense that even though one could be importing files as P2 there was some correlation with what was set in the Sequence and Capture preset. This harkens back to the AVID method of all imported footage being processed into the "Project Setting" and away from the FCP model of bring it in however you like and deal with it in the timeline. I hope this has nothing to do with that, we're just relinking files. I need to test a reconnect with different Sequence and capture presets.

If this is an issue beyond our system it would seem to me to be a big one. FCPs handling of TC is tenuous at best and inscrutable machinations like this don't help.

Anyone else seen this?

ak
Sleeplings, AWAKE!

Quote
ak
After reading up on the Firestore (urgh!) for a totally different project at a different facility, I remember getting the sense that even though one could be importing files as P2 there was some correlation with what was set in the Sequence and Capture preset. This harkens back to the AVID method of all imported footage being processed into the "Project Setting" and away from the FCP model of bring it in however you like and deal with it in the timeline. I hope this has nothing to do with that, we're just relinking files. I need to test a reconnect with different Sequence and capture presets.

This could be a reason. Check your launch or project settings and try some variations. and see what happens

Andreas

This maybe a little laymen, but i have had the same error come up with reconnecting media:

I have been under the impression that this was due to in and out points set in the logged clip in FCP. So when It does re-link, it has a "different duration" due to the in/out points.

this was just my impression of the error. but who knows for sure?everything always stays in sync within the timeline, so none to fret too much.

J-

If at first you don't succeed, keep ****ing it up 'till it works!

Still haven't nailed this down and it's putting a cramp in our plans to use all the available systems.
I was wondering if anyone who has seen this behaviour uses "capture now" or lets FCP make new clip on timecode break?
I am just following some hunches so if anyone who has seen this behaviour could respond I would appreciate it.

ak
Sleeplings, AWAKE!

Have you guys tried to nail down the results of the problem rather than the cause? For example, if you just put together a "dummy edit" using those clips that gave that warning, then you ditch and recapture those clips, is there a tangible problem -- edits get changed, etc.?


www.derekmok.com

Yeah Derek I have tried a few things like that. Just getting the time code change to happen took some time, what with digitizing some test footage, moving it and relinking, all the while taking note or screen grabs of the media start and ends to see what is causing the change and by how much. And checking to see if the actual start and end frames change somehow.

One test involved digitizing some footage, making a dummy edit and rendering out a QT. Moving the media, relinking, getting the TC change message, rendering out another QT and comparing them. There didn't appear to be any change. Which is good I guess, but the online editor in me says that mysteriously changing TC is going to bite us in the end somewhere unless we can figure out why, and trying to figure out if the problem scales up over longer clips also adds to the difficulty of designing a test.
That some footage changes both ins and outs when reconnecting makes me even more nervous but I haven't seen that particular occurrence myself but have been told it has happened. Spending time trying to force a problem to appear to learn how to fix on behalf of 2 assistants and 2 interns it is an effort in itself. Eliminating the variables is tough.

Tomorrows test is to make a fresh log and capture of some footage, make an edit, try to get the change to happen on reconnect and then re-capture the footage and see what happens.

Either way it's not a desirable behaviour, even if it ends up being non-destructive. FCP shouldn't be this cryptic about why it's changing something that shouldn't change.

ak
Sleeplings, AWAKE!

Hey guys

You should definitely be very careful after getting this message.

We got it when we accidentally tried to shift clips from 23.98fps timelines to 24fps or vice versa.
When it was video, the problem was obvious: a missing frame at the end of each clip. But with the audio, FCP actually interpreted the media file differently, reading a different part of the file than before!

So check all the clips for which you had this message to make sure they're still in sync.


Even though all our machines are working in 23.98 now (including all capture settings etc.), we are still experiencing this problem when sending projects back and forth (our production takes place in different studios). Some sound files (but not all of them) reconnect with this problem, which makes it almost impossible to transfer the exact sound edit.

If anyone has more information about this "Media Start and End" alert, please let us know. I saw other people having this problem in other forums, but no solution for the moment.

Thanks

Gilad

Not to sound cruel but it's good to hear that we're not the only ones having this problem.

A few questions for you then.

Do you merge audio with video using the merge clips function or in the timeline?
Are you using double system sound recording? What format? DAT, Deva, 744T or ?

Are you using multiclips?

It certainly is a major workflow killer and a source of great insecurity if you can't be sure that something that was in sync can go out of sync without any editing actually taking place. It's a foundation level issue and needs to be addressed, but seeing as it doesn't seem to affect everyone and workflow like this is not widespread (how many people have a capture set-up and an edit set-up) it's hard to get noticed.

ak
Sleeplings, AWAKE!

The project we're doing is animation, so there are separate video (or still images) and audio (dialogue, effects, music) files.

We don't merge any clips, nor do we use multiclips.

Plain old video (QT) and audio (WAV and AIFF) files. We don't capture any media from tape.


From our 23.98/24 problems earlier on, we feel that all this is related to frame rate and/or TC issues. But off course non of our media has real TC (it all comes from files) and all our timelines and settings are 23.98.

Interesting though: about a year ago we've worked on 4 computers at the same time (sharing media through a server), we had other problems (render files mostly) but never this one.

Then, for more than 6 months, we've worked on 2 computers, keeping them mirrored for data (meaning opening projects on a different computer all the time), but never had that problem.

Only when changing a studio in July we started having this proble, in spite of keeping the exact same machines and exact same configuration.


This was accompanied by 2 other problems: FCP not recognizing files without extensions anymore (it has before) and files with special characters with their names being truncated when copied between macs.

We haven't upgraded our FCP (it's still 5.1.4), but maybe all this is related to an upgrade in QT or in the MAC OS itself?


At moments like this I wish so much to have started this project on AVID....

From the concept of QuickTime AV movies created with FCP there can't be a timecode change at least with any codec which doesn't use GOP.
If the timecode is integrated into the DV signal there might be misinterpretations like the way of the rounding.

With captured AV tracks both using standard transfer or any direct to disk there can be (sometimes) both long and SHORT video frames which are kept in sync by a "continues" audio track. Editing such a clip might get it into a state which is slightly out of a "real" video frame. Removing the audio may lead to the same result.
These "abnormal" frames normally only happen at the start or the end of the clip (in the video/film world).
With a little knowledge about AppleScript for QT Player you can check that.
We had that years ago that a "silent" play out was shorter than the play out with sound.

A totally different thing is audio. Audio does NOT have a timecode track like a FCP created QT file (and it doesn't have a reel because of that) - so it can be interpreted in any way you want it to be interpreted.
It is a global misunderstanding of many editors using whatever NLE.
There are formats like BWAV which allow to set a time stamp, but this time stamp can be interpreted in many ways.
It is stored as "samples since midnight" which is a little bit like "time of day". So 4800048 "samples since midnight" will be seen as 100.001 seconds real world time if the file is interpreted with 48 kHz.
Using any given frame rate the smpte start timecode could be slightly different. The bigger problem is the end timecode.
So depending on your version of FCP and the current settings of FCP you can get the message of non matching timecode and reel quite often and if you got it you should take it serious.

In any case when using NTSC with NLEs there is no real world time (in most of the cases) and 100.001 seconds NTSC DF/NDF want match a real world 30/60 TC when working with the given 48 kHz. This means audio will drift with longer clips.
To avoid this you can set either the audio recording to a NTSC matching sample rate or apply a "virtual" sample rate later. The other option is to put the audio data into a QT wrapper so that TC, duration and tape are fixed - this can also cause a "virtual" resampling of the audio in NTSC world but it will allow a reliable workflow on FCP systems.

Andreas

Gilad,

I forgot to press "post message" last night and just did a few minutes ago. So I had not be aware of your post.

Quote

Only when changing a studio in July we started having this proble, in spite of keeping the exact same machines and exact same configuration.

This maybe the same reason as I described above. Everything on the machines maybe identical, but if there is a slightly different preset with FCP the seen TCs might be different.
It always a good idea to put everything into a QT wrapper.

Andreas

Andreas


thanks for that info about TC, some of it was definitely new to me and was very interesting.

I did know that audio don't have a real TC, but what I found out with FCP (and some Protools experimenting) was that it can be interpreted to be played in different frame rates.

For example, when copying and pasting our sound from a 23.98 timeline to a 24 timeline, FCP re-interpreted each audio media file, resulting in a change of the part of the file it's playing.

The "in" and "out" that we fixed for the clip on the timeline was the same, but as the speed in which FCP was interpreting the audio file was different, that "in" point was not set anymore in the place we wanted it to be.

The best example: a take of dialogue is cut into the timeline. After copying that clip to a timeline in a different frame rate, the "in to out" part on our timeline is not on that take anymore, rather 2 seconds before or after.


That's exactly the problem we're experiencing when connecting files which get a "different Media Start and End" message.
Only catch: we're opening the exact same project with exact same timeline in a different system, but which has the exact same configuration and settings (and even the same folder structures, because they're mirrored).

Haven't found a way around it yet.


Can you quickly explain what a "QT wrapper" means?


thanks


Gilad

Quote

The best example: a take of dialogue is cut into the timeline. After copying that clip to a timeline in a different frame rate, the "in to out" part on our timeline is not on that take anymore, rather 2 seconds before or after.

That is exactly is what I was saying above, as there is no timecode the IOs are dependent on the project setting or the the setup you used when launching FCP.
With FCP it's even more tricky as you can have multiple (and different) projects open at a time. This can screw up a lot if you don't know how it works.

I'll try to explain again (I did this already several times and this is a "basic" for FCP).

Here the prior to 6 version:
When you launch FCP it will use the setup (rate, NTSC, DF/NDF) you used when you quitted FCP.
You can create whatever new sequence or project it will always use these settings until you quit next time to interpret footage without timecode.

Here the after 6 version:
Before creating a new project you can do a new setup (rate, NTSC, DF/NDF) and this setup will be used when you import footage without timecode (for all other projects as well).

So here the good thing with the 23.98/24 (or any other NTSC stuff). If your external audio runs out of sync in a 23.98 project (with FCP 6) just create a new 24 fps project and import the external audio, then open your 23.98 project and drag or copy those files to your 23.98 project and it will run with different timing and will probably be in sync.
The drawback is that you won't be able to re-link the stuff at a later state with correct timing.

Now the "QT wrapper" stuff ;-)
Let's say just look at it like a wrap in a mexican diner. you can take a lot of different things and put into a wrap and and from outside it looks like the same wrap.
There are also QT compatible files - these are NOT QT files. These are like ingredients for the wrap. There are a whole bunch of them, but some won't work.
If without the wrap you take some "compatible" roasted chicken you can do a lot of things with it and will look different each time. If you put it into your wrap everything is ordered in the wrap not spread around on a dish or whatever.

Back to serious.
QT is some kind of container where you can drop in a lot of data and/or information - some could be video/image, some could be sound, some could be timecode, etc. You can also add data which will give instructions.
One of this latter ones is TC track. A TC track is similar to a video or audio track and it has a size and duration as well, there can be several TC tracks which can be attached to several functions: Source, Aux1, Aux2.
The TC can control the behaviour of applications how to handle the other components.
So if for example you add a TC track to a QT container which contains an image sequence the TC values will tell how the images are played - without control 30 images could be 1(real) second in NTSC, 1.25 with film, 1.2 with PAL and so on. The TC track will manage that they play as they should play.
Somehow same with audio. It will behave the same and the audio will never have a message displayed that something is not matching. But there is a little glitch with FCP as FCP makes you believe that your audio file has a TC when you use "Modify Timecode". FCP tells you that you will modify files on disk - but it doesn't do since those files don't have TC track FCP can send instructions to.
While you can use QT Player to "wrap" an image sequence you use it to make the same with audio.
One way out of the dilema would be to write QT components which have a look at some of the QT compatible data and tell FCP what to do using the QT framework.
Another more painful for the user is to import the audio with the right setup into FCP, then export as QT and setup the TC track.
That's why I developed my BWF2XML which automatically creates a QT wrapper with TC track for BWF and SD2 files - it maybe a good idea to extend that app for all sound files.

Hope that helped and didn't confuse

Andreas

Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

>>This was accompanied by 2 other problems: FCP not recognizing files without extensions anymore (it has before) and files with special characters with their names being truncated when copied between macs. <<

FCP should recognise files without extensions. Something's not right with your system there.

Unix gets upset if you include symbols like / in your file names, because this is basically an instruction to look to a different folder level. Did you change your naming conventions recently? This could be causing some of you problems too.

Maybe a good 'ol preference trash will clean up a bit and let you start from a fresh base.