[Bill Russell]

I may see one confusion: When I say “graphics are coming in at the wrong sizes” I’m refering to the keyframed motion attributes – scaling — not as if the graphics media files themselves have changed size. No, no transcoding here. Or relinking. Or media management 🙂

“THE LOST SKELETON OF CADAVRA” –

And more…

[Bill Russell]

I guess I’m not understanding the question. Are you asking in regards to the issue of FCP6 corrupting my FCP5 project? If so, no, media management was not any part of the equation this time, before, during or after. Or…

… are you asking me if I have ever media managed before on other projects? Yes, tons of times over many years. Media management in my experience results in the very same kinds of errors we are now seeing with this trans-version corruption. Seems one linking / relinking fault lies at the core of both, as well as the problems people see in XML and OMF creation — all these flows seem to be tripped up by the same linking miscalucation, one that often manifests when speed changes are encountered (or more generally, when keyframes are encountered — even static speed changes happen to be registered across the clip extent with keyframes). Fix the bug, then Apple will finally fix the linking problem in all these areas, that seems pretty clear to me. Or…

Are you wanting me to try to media manage the FCP5 project first before opening it in FCP6, as a possible solution?

I apologize! I guess we are both missing the other’s gist…

[Bill Russell]

Import —

Well, you know: I just open the project with FCP6. FCP 6 of course alerts you that it needs to update the project (and you click “Yes,” do it.)

Graphics

Seems some graphics that are sized small jump back to their huge sizes. I’ve seen this before with XMLs. I’m not doing any relinking or transcoding — they are already linked after the XML import into 6, I didn’t need to relink anything.

[Bill Russell]

Well, that’s interesting. I tried making sequence clips independent in 5 and that did nothing to improve things on FCP6 import.

HOWEVER, your suggestion to try exporting and importing as XML 3 DID work… on the speed changes. That is a BIG improvement. However, interestingly enough, a bunch of clips are now scaled to 133% and at the wrong aspect (33%) — seemingly treating my anamorphic footage as if it is 4×3 letterboxed, then scaling up to fit. These clips are 100% and correctly marked anamorphic in the FCP5 program. Only some clips got scale and distorted, not all — but it is still like a fourth of my feature length project.

There are also some graphics and video with keyframed motion-tab animation that are messed up in the XML import. Mostly graphics are coming in at the wrong sizes. This option may serve me well though — if I keep a timeline of each available (one from straight import, and one from XML import) then whenever I come across a Final Cut Oops, I’ll just cut and paste from one or the other in to my new master sequence and continue working. Heh.

Of course, this is all wrong, but hey, it’s new — never seen anything like this before!

“THE LOST SKELETON OF CADAVRA” –

And more…

[Bill Russell]

Yes, I may be have confused folks a little because I’m talking about two separate problems. My immediate problem is that opening this FCP5 project in FCP6 causes the speed changes to go wacky.

That is of course, though, what also happens with the infamous media management. (I assume that the root cause is the same thing that manifests also in XML exports / re-imports, relinking and OMF creation). It is a huge problem for me to receive clients’ documentary projects and pretty much count on spending days fixing things after media management — or more often than not (when I’m lucky) I send clients a “tutorial” on how to media manage their shows, then create a reference and reserve days for fixing things themselves, so that we won’t take time in online. I have used FCP since version 1, believe it or not. I have been involved in the MM’ing of probably forty, fifty, sixty shows, who knows how many.

Anyway, I remember that Ken Stone article — that was all the way back maybe even to FCP3? Anyway, I’ll look through it again. I’ll try making sequence clips independent in the FCP5 project and import again to FCP 6, just to see if it makes any difference. I’ll report back.

“THE LOST SKELETON OF CADAVRA” –

And more…

[Bill Russell]

Okay, it took me a day to check this it, but I finally tried opening the project on someone else’s FCP 6.02. Indeed, the problem is there — opening an unadulterated copy of the 5.1.4 project is 6.0.2 = speed changes messed up. Any ideas?

Also, getting back to the media management issue (which is not the case here, but is a big problem usually for me too, and others it seems), you say, “The Media Manager has a horrible reputation, but it does work if used properly.” Could you share what needs to be done to have it work properly? I may be missing the key — It could change my life. Thank you!

[Bill Russell]

Hmm, thank you, okay, two comments then. One is, in this case, I am not media managing the show. I am simply opening it up in 6. No relinking, no MMing, nothing. Instant open. It’s not the render file on the clip, its the hard editorial state of the clip itself in 6. It has a linear speed change of 8% on it, instead of 67%, and its in and out points are in a different place.

The second is — really? I agree with Shane’s comment that speed changes and media management are the “bane”. Is there a thread or the like perhaps that talks about how to use it properly? That would be helpful.

We (well, I’m freelance but I often work at CGPost) online clients’ shows, and that usually means MMing their projects. The projects are usually documentaries that have been a year or many more in the making — think dense and full of speed changes and motion tab keyframing. I always advise clients to reserve a week for prepping their shows and fixing FCP errors after MM. For every client, errors during MM happen pretty much guaranteed. If I do the prepping myself, likewise, I reserve a week before online to do all the sound and picture prepping including a day at least to fix errors. One project (just this year in fact) I worked on was so bad I literally spent weeks rebuilding the show “peeled” into three MM passes. It was so disheartening. That one, I admit, involved transposing the show to a 24p timeline. But man, give FCP a keyframe on that one and it went to town in a cruel way.

ANWAY, I’m telling stories now. Point is…. is this avoidable, short of having the ability to time-travel to the beginning of the each client’s process, and the force of authority to convince editors to do a speed change one way versus another? And hey, FCP always messes up simple LINEAR (apple-J) speed changes, so what am I missing? Insight craved.

BTW — thank you HUGELY for these replies, they’re great. I’m frustrated by FCP, but I’m grateful for this.

[Bill Russell]

Hi there

“First, before upgrading any project ina new version of FCP, duplicate it, then open the duplicate in the new version.”

I have copies as well as archives of the original project file.

“Second, do you have FCP 5 and 6 on the same drive or are you moving your project to new computer? ”

Same machine. No changes, no migration, no relinking nothing. Open the project with 5, it’s fine. Open with 6, keyframed /speed clips messed up.

[Bill Russell]

Thanks guys!!!

“Video is RGB (16-235) and computer is 601 (0-255)”

Must actually mean:
VIDEO = a subset of RGB
COMPUTER = 36 more bits than VIDEO

Is that right? I think so. Here’s why. Certainly in the graphics world, when you are working in 8-bit RGB (or CMYK, or Grayscale) you have 0-255. Period. True white is 255, true black is 0, and you have a full 256 extent per channel to work with. (16 bit gives you a whopping 65,536. 10-bit RGB image, for that matter, would be 1024.) Just open any graphics program (like Photoshop) and look at the levels you can work with per RGB channel. Graphics world does not know of any “601” where dark gray (16) is black and light gray (235) is white.

When creating titles in the 8-bit RGB graphics world to give to the video world (like when working in After Effects), I make whites slightly “gray” — darken them to about 229 or so — so they do not go over 100 IRE in the video world — I often shoot all the way down for close to 90 IRE. So it seems video world recognizes my 0 black, and (ah ha! I get it now) also recognizes my 255 white — it just puts that 255 white at IRE superwhite (above IRE 100). I think I get it — the video world is squeezing my black and white into video’s more limited 16-235 extent, video’s full black to SUPERwhite spectrum (0 to 105 / 110 IRE, whatever the digital above legal max is).

If I told Avid to import my graphic as 601, it would clip off the first 16 levels of my black and the last 20 levels of my whites? Just chops ’em off, throws ’em away from each end, that detail gone forever. But it keeps the middle level detail intact, one for one. Thus 601 is some weird 220 digital level space carved out of RGB. So in order to not lose end-to-end detail (but instead evenly diffuse the detail loss in downconversion from 256 steps to 220) I tell Avid to import as RGB, which causes it to squish 0 to 16, and 255 to 235 such that my RGB video “safe” of 229 white becomes, oh, something like level 208 of 601’s extent inside Avid.

The video world uses fewer steps between black and white than RGB. Thus Avid will scrunch an RGB image to within 16 to 235 (235 being well above 100 IRE).

So, the labels quoted at top confuse me, but Chaz and you are on in the description of the results. Video seems to throw out 36 bits from the “ends”. Here’s a description:
https://www.digitalvoodoo.net/products/10bit/

> -When you import as RGB it will push the Whites and Blacks together to fit into the 16-235 range for video use.
> -When you import as 601 it will leave your colors alone.

I get it. This is from Video’s perspective.

Not because Computer is 601, but rather, VIDEO is 601, right?

So then, when EXPORTING video to a DV stream, or to an uncompressed movie, whatever, where color bars would be correct in a straight video import to any system (like FCP, which doesn’t offer a 601 / RGB distinction) — one should use 601 or RGB? In other words, how to export video so that the exported DV (or uncompressed or whatever) is identical to the very original DV (or uncompressed) stream before it went in? Like say, I capture color bars from a DV tape, then I want to export back to a file as a DV stream or DV Quicktime movie. Which is “unfiltered” / “undistorted” export — 601 or RGB? (I mean, I could test this if I had a deck!)

What does Avid do with each of these options on export? My brain hurts.

[Bill Russell]

Makes sense, except… why do they scope too low in Avid’s internal waveform when brought in as 601?