For example, take a look at this:
You can see that clip 6 has the exact same duration as clip 10. Only it shouldn't. And FCP will still treat it as if it's that length by playing black past that point. What happened here is that clip 10 used to be named clip 06.
An editor came along and simply renamed clip 10 to clip 06 and for some reason FCP still thinks it's the duration of it's former self. I don't know if this editor used FCP's renaming function or did it in the Finder, however.
Either way, you can highlight the clip in the bin and then goto Tools>Analyze Movie>Clip and see that FCP knows the actual duration of the clip, but in the bin, in multiclips and in the timeline it will seemingly forever play it back with the wrong duration.
The solution is to treat the clip as if it were symlinked. So you have two options:
01) Delete the errant clip from the Bin. Then either...
02) Copy the clip in the Finder to another place or folder or drive, then copy it back to where it should be, overwriting (or after tossing out) the original file. Then drag it back into your Bin. Or...
03) Simply, (after deleting it from the Bin) move it to another location, drag it back into the Bin, confirm the duration is okay, then delete it from the Bin, move it back to where it should be, then drag it back into the Bin.
For me for one particularly stubborn clip step three was completely necessary. FCP kept thinking it was the wrong clip until I told FCP it was now here, then there in the Finder.
While I'm not sure what causes this behavior, it seems likely it's the result of a multiclip project going from Leopard to Snow Leopard with a renaming session in between.
Posts
2 comments:
heh - told you it might have something to do with the Leopard/Snow Leopard move. ;)
Some quick googling indicates that you aren't the only person experiencing problems with applications that use symlinks, at least for people who've upgraded from Leopard to Snow Leopard. Take a look here:
http://trac.macports.org/ticket/21852
Apparently the 'file' utility that ships with Snow Leopard has been brain damaged in some way. 'file' is an old-school Unix command, and I bet you could find a normal copy of it somewhere. If this were Linux we were talking about I'd recommend that, but I don't know how to get Snow Leopard to use it instead of the default version. You might bork your system up completely if you choose to do surgery at that level.
I just ran into a similar issue. I had a project with several audio files with the same filenames - thanks of course to my H4n which resets the file numbers back to zero whenever you clear the card.
After a recent shuffling of data between several drives I needed to reconnect all the media in the project. Every file reconnected properly except the three that were named the same as the others - trying to reconnect these crashed the app every time. Renaming them and then attempting to reconnect resulted in the same thing, as if FCP still was confusing them with the originals. I finally had to remove every reference to those files from the project and import the newly renamed ones - which meant some re-syncing and re-editing because I had linked those audio files into about a dozen video clips after syncing with pluraleyes.
This is the first time I've run into this, so I don't know if it has anything to do with snow leopard or not. In any case I'm adding the additional step of renaming audio files from the H4n before import to make sure they all have unique names.
Post a Comment