[Matt Lyon]

I wanted to add: when I say that I like to “keep file names short,” I DON’T mean 8 characters short. I used to try to stick with 31 characters or less + 3 digit extension for ultra backwards compatibility. But these days, I really just want file names that fit neatly within a standard open/save OS X dialog box.

And by simple names, I mean: only use letters and numbers and also underscores instead of spaces (no symbols or punctuation).

Alf, I hope I’ve answered your question … I may be drifting off point here 🙂

Matt Lyon
Editor
Toronto

[Matt Lyon]

Very interesting! Thanks for running the test Rafael. I can’t argue with your conclusions. I probably mis-remembered my facts about my earlier tests.

Matt Lyon
Editor
Toronto

[Matt Lyon]

[Alf Hanna] “I agree with your theory but when you end up using A) AVCHD and it’s “PRIVATE” naming convention, along with B) using an OS that supports long naming conventions (why not use long file names if they are supported? We aren’t going back to DOS anytime soon!) and C) that I am managing only my media and not some collaborative team’s media, then it doesn’t make sense that those issues should be an issue with media management.

I’m willing to be convinced I’m missing something here. Help me understand what you meant…”

Fair enough, Alf. Every situation is unique, so it’s up to each user to figure out what works for them.

AVCHD is outside my experience, so I can’t really comment on that.

But as far as naming conventions goes: It’s true that OS X supports long file names. But I take a “worst case scenario” approach. Maybe some esoteric piece of shareware I need for a certain job relies on some old code that breaks if you feed it really long file names. What if I have to send an EDL to a post house, and their system breaks if the reel names contain more then 8 characters? Playing nice with FCP is only part of the equation, I have to think about the rest of the tools and technology I’m going to interface with.

But just within the realm of FCP, having used it day in and day out since v1.2.5, I feel that keeping things simple just seems to make things more reliable (I guess you could say the same for most software). I have no hard evidence, just an intuitive feel of what works best. I am happy to admit that my approach is uber-paranoid. But part of my approach is keeping file names UNIX friendly (no DOS for me, please)

For instance, when it comes to the meat-grinder that is Media Manager, it seems that the less oddball bits you stuff into it, the more likely you are to end up with something useable coming out the other side.

Having experienced a couple total meltdowns of projects, where every piece of media got disconnected, and the file paths wiped out (in the FCP project), I can say that it is MUCH easier to manually reconnect files when the filenames are short. Additionally, having my clip names in the project match their source media file names EXACTLY was critical. It allowed me do relatively quickly work through the horrible task of manually reconnecting each clip, one at a time.

I hope these late night ramblings make sense and aren’t too academic 🙂 At the end of the day, you gotta decide what way of working fits your needs the best. If you aren’t working in a collaborative environment, I could see how some of my rationales wouldn’t apply, but I hope I’ve explained my thinking clearly at least!

Matt Lyon
Editor
Toronto

[Matt Lyon]

ha ha, yes I hope I’m not mis-remembering too! 🙂

This statement was based on my memory of an old bug I remember dealing with. It used to be that if you “sent to compressor,” then the final output would sometimes give strange results with certain kinds of generators. The font size and placement, for example, would not match the FCP viewer. But if you pre-rendered the timeline, then it wouldn’t be a problem (if memory serves me correct). So my conclusion was that Compressor was reading the render files, not generating new renders on the fly.

Matt Lyon
Editor
Toronto

[Matt Lyon]

For what its worth Bret, I believe FCP has behaved this way since the beginning. Definitely it has worked this way since the “send to Compressor” option was added (v4? v3? — I don’t remember).

Using the “Send to Compressor” option has the added benefit of auto-generating “I” frames on every edit point, which can lead to nicer looking encodes.

In the past I’ve done a lot of tests comparing encode times via different export methods (using FCP v4). This was pre-virtual clusters. The rendering times using “send to compressor” were basically identical to encoding stand-alone via Compressor. In a sense, they were faster, since you could skip the “export self contained quicktime” step. BUT, these were on SD timelines with minimal effects, graphics, overlays, no resizing or field order conversions, etc.

Of course, running an encode on a virtual cluster will generally smoke the “send to Compressor” option.

[Rafael Amador] “If you are converting to a “Double Pass MPEG-2 this doesn’t happens. The sequence is rendered in 444 and send for the first pass, but this files doesn’t get stored nowhere; it gets lost and needs to be rendered again for the second pass.”

Rafael, I get what you are saying about having FCP re-cache your frames for every step, but you are describing a worst case scenario.

For example, if you’ve “Force rendered” your timeline and then you “send to Compressor,” your machine will just reference the render files on disc. The time it takes to cache these files into a 444 image buffer will be trivial. But you’ve also lost the benefits of rendering in 444 space, since your sequence is already rendered at the compression settings of your timeline.

Now, if you’ve left your timeline unrendered, its a different story. Your render times are going to be highly dependent on the source material. If it’s a simple timeline, with little or no effects, then your render will be relatively efficient; the amount of time it takes to cache your frames to a 444 image buffer will be trivial compared to the other steps of the process. BUT, if you have lots of effects, then this may no longer be true.

So, like lots of things in FCP, I don’t think a definitive answer is possible. There’s a lot of variables going on here. In the end, I think each user needs to test for themselves and decide when each encoding approach is appropriate.

Matt Lyon
Editor
Toronto

[Matt Lyon]

Having the VFX artist work on the entire 20 min clip only makes sense if all the greenscreen shots are getting the EXACT same treatment. Is that the case? But you also have to decide if that approach is going to be the most cost effective. If your effects person is working on a 20 minute clip for what is only going to be 3 minutes of screen time, that might be a waste of resources.

But if you elect to split up your master clip into individual shots, you could just duplicate your timeline, then delete all the footage that is NOT the greenscreen shot. Then change your sequence setting to the r10k codec and reconnect your clips to the original r10k file. Then you can media mange, with handles, using the “copy” mode (this preserves the format of the original media — so in fact, the sequence settings probably don’t even matter in this case).

Hope this helps,

Matt Lyon
Editor
Toronto

[Matt Lyon]

[Rafael Amador] “About the differences QT/QT Conversion, what refrains me of using QT Conversion, is the lack of control on any process (Bit-depth, scaling, de-interlacing,..). You really never know what’s going on inside.”

True enough Rafael … but a flip side of that argument is that you always know what’s going on inside : not very much! 🙂

It’s true that it is always recompressing your video, but my understanding is that everything is rendered on demand, in a 4:4:4 image buffer, so the processing precision is theoretically very high. (If I’m mistaken here, someone please correct me). At the very minimum, the processing precision is equivalent to your timeline settings.

I think it is a matter of knowing when it is appropriate to use this tool. I use it all the time for certain kinds of h264 encodes, AIFF files for sound mixers, still images, plates for VFX artists (when a format conversion is needed), etc…

Matt Lyon
Editor
Toronto

[Matt Lyon]

I don’t know if this has been mentioned on the board, but here’s a trick I like to do for these “good” producer preview mixes:

Lock your picture — creatively, that is; don’t lock your video tracks in FCP 🙂

duplicate your timeline

unlink all audio and video (but don’t destroy your stereo pairings)

select all the clips in all your dialog tracks (hopefully you’ve been keeping them organized!)

nest your selection

repeat for your SFX tracks and your music tracks

Now you have three pairs of stereo nests. You can easily add global filters to each, and it is much easier to do ducking.

That’s my “quick n’ dirty” version of bussing. I usually lay the compression pretty heavy on the dialog, so I don’t get notes about “illegible” dialog 🙂 You can also razor blade the nests for “per scene” treatments, like reverb, etc…

A similar effect could be achieved by exporting stems and bringing them into a new timeline, but you obviously lose the ability to “open the nest” and make tweaks.

Once your screening is done, open up your old copy of the timeline and start editing again!

As for adding more “pro” audio features to FCP, I have to say that I’m on the fence. Part of me thinks it would be really handy, but part of me thinks that it could lead to feature bloat and instability.

I really want a “convert cross dissolve or fade to rubber bands” tool, so I can turn those audio fades into keyframes.

Matt Lyon
Editor
Toronto

[Matt Lyon]

That’s a good point Paul, but I’d still want the files delivered in the best format possible. Then you can convert them in-house to a lower bandwidth version if necessary — and retain control of the process.

Matt Lyon
Editor
Toronto

[Matt Lyon]

Might be good to start a new thread for your question, Shane.

If you post some screenshots of the zebra issue, you might get more useful advice.

I don’t generally do “mpeg4 with h264” outputs, so I don’t have much experience with this, but I think what you want is to make an h264 with an “m4v” container?

In Compressor, you can set the “File Format” to “H.264 for Apple Devices.” Maybe that is what you are looking for?
Hope this helps,

Matt Lyon
Editor
Toronto