FCP 3D Procedure

[Tom Gleeson]

I have a project shot 3D with two Red Cameras and being posted in FCP. A rough off line has been completed using one channel but we now want to construct the second channel. Rather than manually finding the second camera footage and manually syncing is there a way of using the EDL from the first channel thats been cut?

Both cameras were timecode locked together so both channels should have identical TC.
The left camera have all the clip's names starting with L and the right camera clip's names start with R.
The cameras were master and slaved so I hope the clip names are related?

The editor has also reported that even though the cameras were in USB master/slave mode the two cameras did not start together so the all the matching clips are different lengths.

[Alister Robbie]

Hey Tom,

Apart from the L & R, are the clip names synced as well?

Just thinking of a way to do a little XML hack to use the first track of video to generate a second timeline with the R channel, but it woud require the names being the same.

Cheers

Alister

[Alister Robbie]

just had a quick look at the XML. My idea should work as long as you remove the UUID reference from the XML so that it doesn't think it is looking for your L files. once done, you should be able to put together a few text find and replace that will change your L to R. obviously you cant just replace everything L with R as that will mess up pretty much everything. you will need to be searching for things like
<clipitem id="L
<name>L
<masterclipid>L
etc...

the other, more manual option is to create a copy of the project, and then just manually reconnect everything to the R version. once done, copy it back into the L project and line it up. if your project is short, this could be the easiest way home. if its long, then it will be :mad2:

Hope this helps.

Cheers

Al

[Jason Goodman]

XML or otherwise, doing this completely automatically is likely to be problematic. RED ONEs are notoriously bad at keeping timecode synced between two even with a cable connecting them. I can tell you on a feature we shot recently, not one day did the time code match perfectly throughout the day, +/-2 or 3 frames seems to be as good as it got. This is not suitable for doing what you want. Additionally, having different file names could make it tricky as well. Probably your best bet would be to get something like 'A Better Finder Rename' or 'Renamer" and rename all of your right files as Left. IT IS VERY IMPORTANT THAT THE NAMES MATACH IDENTICALLY or this definitely will not work at all. Assuming your right eye file names are identical to left (except for the "R" prefix which you will change to "L") you could attempt the following.

Save a copy of your FCP project under a new name, "FCP_right" let's say. Quit FCP or close your project and rename the folder containing your left eye footage to "left_temp" or something like that. Open the "FCP_right" project you just saved as and direct the software to reconnect all of your footage to the folder that contains the right eye footage renamed as left. This should automatically rebuild your project with all your right eye footage, albeit possibly +/- 2 to 3 frames out of sync with the left eye edit. Save this project and close it down. Go back to "left_temp" and rename it back to its original name. Reopen your original left eye project and verify that everything reconnects as expected. Now you should be able to join your left eye and right eye projects in one timeline. If you somehow figured out how to do what we could not (keep the timecode of your two REDs in sync) you may be good to go. Start and stop record times of the left/right cameras won't matter if timecode is synced. In and out points will automatically match. If you have the same problem we did, which I expect you will, your final step is to go through the entire right eye project and slip each clip one or two frames (or more) fore or aft. It's not so much fun, but this may get you part of the way there.

Jason Goodman
CEO
21st Century 3D New York
505 8th Avenue #1006
New York, NY 10018
212-244-8585

21st Century 3D Hollywood
3450 Cahuenga Blvd W #509
Los Angeles, CA 90068
323-799-1046

http://www.21c3d.com
jason@21stcentury3d.com

[Jimmy Shen]

The last 2 random digits in the Red file name will defeat the find-and-replace method.

I would try the following:
Export an EDL (Left Eye) from FCP, load Right Eye media in Scratch, load Left Eye EDL, match clips only based on timecode, (assuming no duplicate timecode,) conform. Then check again the Left Eye timeline and make adjustment accordingly.

Why don't you bring a short sequnce over and test it on our Scratch, Tom? :)

[Jason Goodman]

Better Finder Rename has some very complex renaming capabilities that may require multiple passes. I agree the approach is not ideal but if you want to stay in Final Cut, you might be able to get it to work.

Jason Goodman
CEO
21st Century 3D New York
505 8th Avenue #1006
New York, NY 10018
212-244-8585

21st Century 3D Hollywood
3450 Cahuenga Blvd W #509
Los Angeles, CA 90068
323-799-1046

http://www.21c3d.com
jason@21stcentury3d.com

[Tom Gleeson]

Thankyou for the kind responses and Jimmy we may take you up on your kind offer. Unfortunately the Post side of this production had not beed decided on by the time shooting started. I assumed the USB master slave setup would sync the clips in a fashion friendly to post :-( Luckily we used a traditional slate as well.

What else should we have done to help post?

We locked both cameras to a TC generator and they were genlocked.
We identified Left and Right channel within the clip names with a L and R at the start.
We used the USB master/slave setup
We used a slate that included the clip number

Is there anything else that should be done?

[jimhare]

I'm editing the project Tom is referring to so I'll chime in with a couple of unique issues:

1. Once in a while the second camera wouldn't fire making the clip numbers out of sync.

2. We have multiple clips starting at 001 in both eyes.

3. We shot over 6 days so there is plenty of duplicate timecode. At the moment the footage is segregated by date but searching timecode only could come up with the wrong clip.

4. The reel numbers between L & R don't always match.


I did a short test and was able to manually relink an L clip to an R EDL and it matched perfectly. We appear to have accurate sync.

But trying to automate the process seems riddled with danger, though it would save a ton of time!

Keep the ideas coming! ;-)

Jim Hare

[Alister Robbie]

Thankyou for the kind responses and Jimmy we may take you up on your kind offer. Unfortunately the Post side of this production had not beed decided on by the time shooting started. I assumed the USB master slave setup would sync the clips in a fashion friendly to post :-( Luckily we used a traditional slate as well.

What else should we have done to help post?

We locked both cameras to a TC generator and they were genlocked.
We identified Left and Right channel within the clip names with a L and R at the start.
We used the USB master/slave setup
We used a slate that included the clip number

Is there anything else that should be done?

given that people are discussing timecode drift, I would recommend you look at an app called PluralEyes. This does syncing of footage based on audio - depending of course on the cameras having similar audio... http://www.singularsoftware.com/pluraleyes.html

If you had done this before the edit, you would have been working with your footage synced. Doing it after the edit, what you might be able to do is create synced set of L & R footage, then manually matchframe using the dupe detection as a guide. (Hope that this is not a long edit...)


I'm editing the project Tom is referring to so I'll chime in with a couple of unique issues:

1. Once in a while the second camera wouldn't fire making the clip numbers out of sync.

2. We have multiple clips starting at 001 in both eyes.

3. We shot over 6 days so there is plenty of duplicate timecode. At the moment the footage is segregated by date but searching timecode only could come up with the wrong clip.

4. The reel numbers between L & R don't always match.


I did a short test and was able to manually relink an L clip to an R EDL and it matched perfectly. We appear to have accurate sync.

But trying to automate the process seems riddled with danger, though it would save a ton of time!

Keep the ideas coming! ;-)

Jim Hare

mmm not good. based on that, PuralEyes all the way. I have had to use the process above for edits where it was cut with one camera, then conformed to multi-camera when the other cameras were available. (Don't ask, it was a flipping nightmare) - but because all cameras ran at least atmost audio, the syncing was quick and simple, and then I used dupe detection to visually conform it back into the edit. Not ideal, but I didn't have time to investigate other workflows.

Any stresses, give me a yell. I am in Melbourne.

Alister
m : 0408 563 846

[Jason Goodman]

reel names are of course manually set at the time the cards are formatted so being very careful and making sure both cameras have the same reel name is certainly important particularly as the scale of your production grows. This conversation seems to be using the term "in sync" interchangeably to refer to genlock and timecode but it is worth mentioning that one of those things being in sync does not mean the other will be. As far as getting the timecode to accurately sync, best bet may be to wait for a new RED ONE software build or to buy an Epic.

Jason Goodman
CEO
21st Century 3D New York
505 8th Avenue #1006
New York, NY 10018
212-244-8585

21st Century 3D Hollywood
3450 Cahuenga Blvd W #509
Los Angeles, CA 90068
323-799-1046

http://www.21c3d.com
jason@21stcentury3d.com

[Detlev Eller]

Hey,

... looks like a multi step challenge ... with an xml parser -> database -> ui to flag and filter -> xml project output -> back to FCP ... having fun ... approach.

without seeing the files and not knowing about your procedures, everything i say is obviously guess work ... but it might help in finding a solution anyway ...

so,
... in order to automate, it needs some form of consistent data - since this is not available by the unequal file count caused by "misfiring", an intermediate step must be created.

Let's say, all files are in FCP and the whole thing will be exported via xml. It goes then into the xml parsing and the database will be created - containing the good and the ugly ...

I assume, the misfiring was detected immediately and the "lonely extra files" could be filtered by length. Else, the "lonely files" must be identified and flagged via some form of UI.

The common denominator after this step, would be the "order of files", as mapped in the database.

Given that there is a L / R folder structure or another clear identifier AND that all files actually sync when BOTH cams where HOT, that would be enough ... (at least in my minds eye simulation ... hhehe)

Having a proper database, all subsequent sequence cuts could then be xml exported, parsed, coupled and reimported ...

How many files / sequences are we talking?





I'm editing the project Tom is referring to so I'll chime in with a couple of unique issues:

1. Once in a while the second camera wouldn't fire making the clip numbers out of sync.

2. We have multiple clips starting at 001 in both eyes.

3. We shot over 6 days so there is plenty of duplicate timecode. At the moment the footage is segregated by date but searching timecode only could come up with the wrong clip.

4. The reel numbers between L & R don't always match.


I did a short test and was able to manually relink an L clip to an R EDL and it matched perfectly. We appear to have accurate sync.

But trying to automate the process seems riddled with danger, though it would save a ton of time!

Keep the ideas coming! ;-)

Jim Hare

[jimhare]

Thanks for the responses. As no audio was recorded to the second camera, Pluraleyes is unfortunately out.

To answer your last question first, we have just under 700 clips (350L/350R) to pair up. L/R always have different reel numbers and often different clip numbers, making automation difficult at best.

We had between 0-4 misfires each day so some days the clip numbers match completely, others could be off by as much as 4.

Corresponding L/R clip numbers could be determined by putting each day into an FCP bin, sorting by Media Start, and writing down all the pairs, but even so, manual relinking is still required.

Since it's a one-off, it seems like by the time you acquired enough information to automated the process, you would have already gone through as much or more effort than to do it manually.

:emote_headwall:

Bit messy in there.

It took me about 4 hours just to rebuild the 2 minute trailer. Though it got faster at the end, it does seem like it would be at least a 60:1 ratio to relink manually, requiring 30 hours to rebuild a 1/2 hour show! Obviously I'm hoping I'm wrong about all of this, but if I had to build it tomorrow, this would be the reality.



so,
... in order to automate, it needs some form of consistent data - since this is not available by the unequal file count caused by "misfiring", an intermediate step must be created.

Let's say, all files are in FCP and the whole thing will be exported via xml. It goes then into the xml parsing and the database will be created - containing the good and the ugly ...

I assume, the misfiring was detected immediately and the "lonely extra files" could be filtered by length. Else, the "lonely files" must be identified and flagged via some form of UI.

The common denominator after this step, would be the "order of files", as mapped in the database.

Given that there is a L / R folder structure or another clear identifier AND that all files actually sync when BOTH cams where HOT, that would be enough ... (at least in my minds eye simulation ... hhehe)

Having a proper database, all subsequent sequence cuts could then be xml exported, parsed, coupled and reimported ...

How many files / sequences are we talking?

[Detlev Eller]

Corresponding L/R clip numbers could be determined by putting each day into an FCP bin, sorting by Media Start, and writing down all the pairs, but even so, manual relinking is still required.


Good news is, THIS could be scripted ...

Do you have the daily bins ready -
Can you send me the FCP project ... ?

... let's test it!

:-)

[Patrick Tresch]

Plural eyes is really slow based on the computer you use... and it will create a fcp time line that you will have to Line up with your edits.

Pat

[Alister Robbie]

Plural eyes is really slow based on the computer you use... and it will create a fcp time line that you will have to Line up with your edits.

Pat

i suspect it is still quicker than trying to manually sync footage where the file names and timecode don't match...

[Detlev Eller]

Jim said, "Media start" time codes do match ...

In his case, that should be all needed to create the timelines procedurally ...

But beware, this is nothing to play around (and loose a lot of time).
It needs proper coding.

FCP XML is very sensitive and breaks if not properly structured and validated ...


I do already have the base code and create FCP sequences procedurally - however to adapt it to this 3d scenario, i would need test data ...

... once the code is tested, it´s a snap.

P.S.
And probably useful to many of us ... :-)