[Tangier Clarke]

The video file is in the mulitcam are there in the library package when looking at the Finder level.

The multicam clip itself is perfectly fine in the the browser (same event as the project). It’s only greyed on the storyline. Double clicking it on the storyline will not reveal the clip components and as I mentioned above you cannot “Reveal in browser” on any of these clips.

The disk (HFS+/ GUID Partition Map) seems to check out without problems, both in Disk Utility and in LaCie’s RAID software.

I tried exporting an XML of the edit and then importing that XML. The resulting edit is even worse. The grey clips have been reduced to two huge blocks like FCP X gaps and they have no clip name, nor the edits in the mutlicam clip I made.

I also tried opening several backup files with no success. Backup files that were created before this happened still resulted with the multicam clips being dark grey and unusable.

It’s too bad I can’t find a way to replace all of these bad clips on my timeline with the same points of the browser multicam clip that exists.

Fortunately the edits was final and I happened to export a Quicktime right before this happened, but this type of problem gives me a lot of concern; particularly since there’s not a lot of meaning error reporting in FCP X to help me figure out what’s going on.

[Tangier Clarke]

I am using X-FX Handler to figure out what’s going on. It’s odd that everything showed as “true” in X-FX handler, but there were still some titles missing. I seemed to have gotten it to work though.

There were several copies of the title generator at the computer’s library level and in the user account. I am going through the XML and cleaning it so it points to only one set – the computers’s library level so that the generator isn’t bound to any user.

[Tangier Clarke]

Andrew it seems like your problem may be just syncing the correct pieces of video with the correct pieces of audio. Since you have start and stop situations my suggestion would be this:

• In icon view identify each interviewee and give them separate angles. So you may have Angle A for all clips of person A, B for person B, etc.
• You won’t be able to visually identify audio the same way so quickly, but hopefully your clocks were close on the camera and audio recorder. So switch to list view and sort by date created. and you should see some sort of a pattern where you’d be able to identify which audio goes with the appropriate interviewee.
• Select those audio pieces for one person and give them an angle (A-Audio perhaps)
• Repeat for isolating person B audio, person, C, etc.
• Once you’re done you should be able to select all of the elements for one person and create a multicam. Repeat for each person.

This is all assuming you’re trying to break down your interview clips this way. When I first read your post I thought, there should be no problem if you’re just looking for a multicam of everything. Just make all the video angle A and all of the audio angle B and FCP X shouldn’t have any issues figuring it out. I’ve done this many times, thought I do tend to break my own down into separate interviews like above.

I’ve never had too much success with multi cams from PluralEyes. Not a big fan of it. It tend to give me a timeline of everything when what I actually need are individual multicam clips in the browser.

[Tangier Clarke]

Interesting find per your suggestion Jeremy. Here’s the same file from the transfer library you suggested. Notice it matches my online copy, but when the editor exported an XML I got something that won’t relink. This image is offline simply because it’s transfer library without the media so this is normal.

Clip in transfer library:
screenshot2018-02-25at2.40.33pm.png

[Tangier Clarke]

Waiting for that transfer library to get back to me. This isn’t the first time this has happened. Here’s a much earlier image of the same situation except here, both clips have the same start, end, and duration and still would not be relinked. If I recall, the only difference between my original clip and the clip in the XML sent back to me were certain channels were off. I can’t imagine relinking would be halted because channels are on for one editor, but channels were turned off for the other editor despite them being from the same source audio.

Again, I’ve never seen so many relinking issues like this prior to 10.4

[Tangier Clarke]

I realize that certain computers are purpose built and the generally the MacPro will run circles around other Macs in other tasks, but oh boy. When one considers the saying ‘time is money’ in this regard the MacPro is too costly for such [comparably] poor results. I would at least hope there’s a trick to get these Xeon processors or GPUs to get close to QuickSync performance, but it’s not even in the same ball park and honesty that’s kind of unacceptable when you’re buying a computer like the MacPro; new or used.

I wonder if you have several machines on a network for distributed rendering/processing/transcoding, etc, if Compressor is smart enough to identify the computers with QuickSync first. Imagine a network with several Mac Pros and one or two iMacs. It would make sense just to offload to the iMacs or in my case (and sadly) my 2012 rMBP.

[Tangier Clarke]

Thanks Craig. I wondered if Quicksync may be the culprit, but I was just dumbfounded that the difference would be that staggering between the MacPro and the MacBook Pro. Unbelievable to have a machine like the Mac Pro and have to offload to another computer to get the performance I want.

[Tangier Clarke]

Addendum: changing the sampling rate in WaveAgent changes the BWAV header. Anyone who reads this thread may be thinking that if I changed the sampling rate, then it must have been something else to begin with. That’s not the case. Changing the header essentially causes the playback interpretation to be correct and aligned with the sampling rate the file really was-48.048kHz.

[Tangier Clarke]

No problem. I hope it helps in the case you need the reference.

[Tangier Clarke]

As an aside, something that I just noticed: The syncdrift-corrected audio from PluralEyes boiled all of the channels from the original audio file into one. Definitely not something I’d want it to do. So now I have correctly synced multicam clips but without the character, MixL, MixR, and boom channels.