[Scott Houston]

Good advice for sure Bill, but in this case I am 99% sure it is a FCPX issue.

I say that because while testing I created another h.264 file directly from a camera (not captured by ATEM TVS switcher) and purposely set the audio format to ACC and got the exact same response with FCPX introducing the digital noise after importing the file. Everything was identical to the files captured by the ATEM Switcher as far as being able convert the audio, then import, etc… as described above.

So working down the rabbit hole trouble-shooting-wise, that leads me to believe it is some oddity with FCPX’s handling of the AAC stream when importing vs. some oddity with the way the file was captured.

Just trying to add to the KB …

[Scott Houston]

I know this is an older thread, but in case anyone drops by like I did, I have identified the issue…

FCPX seems to have issues with AAC audio in an imported file coming in. My situation involved captures from an ATEM TV Studio that saved h.264 files with AAC audio (no other choices). Even though FCPX is transcoding (optimizing) upon import, something happens and introduces those snaps and pops. The files are fine playing in QT Player out of FCPX, it is only once imported that the snap, crackle and pops are introduced (and they will stay in any export formats.)

I did a bunch of testing and clearly the issue is FCPX not handling the AAC audio correctly and introducing digital noise.

The (somewhat kludgy) workaround I am using to solve it is to drop the h.264 files into Compressor and extract the audio into a separate AIFF file (there is a pre-existing setting under the Audio Formats folder). Then once the h.264 file is in a timeline, I split the audio from the video (expand audio components), delete it, then drag in and snap the .aiff file created in compressor directly below (to keep sync easily) and then turn the vid and the new audio into a new multi-clip so I can edit them together moving forward.

The other simpler option that worked (if space and overhead is no issue to you) was to render the h.264 in Compressor to ProRes. That then changed the audio format and those imported files worked as well. However the ProRes converted files were easily10X larger than the original h.264 + the new .aiff file.

The thing that made absolutely no sense to me however is that if you have FCPX create optimized media upon import (like I do…) it supposedly creates ProRes 422 files. But those automatically optimized in FCPX have the noise, but the ProRes 422 files created first in Compressor, then imported do not. Who knows …

[Scott Houston]

To bring this thread 3 years forward… 🙂

Same thing is still happening using Compressor 4.0.7.

It clearly seems to be a bug as I did an A-B test without restarting any machines (host or clients) in the cluster and tried to submit 8 files by dragging them to the droplet.

Within a few seconds the batch appeared as expected in Share Monitor, but was stuck “waiting.”

After a few minutes I manually created a batch in Compressor using the exact same 8 files, with same settings and same destination and submitted it directly from Compressor.

After a few seconds that batch also appeared in Share Monitor and immediately started processing correctly.

After it was finished successfully I then thought that maybe the “waiting” batch would then start up since things had gotten started in the queue.

No such luck – it just continued to hang with the “waiting” status.

[Scott Houston]

[Jerry Hofmann] “What is the source of the audio, it’s format and recoding process? What are you trying to sync it to video wise?”

The audio was recorded to a DAW (Performer) synced with LTC to the cameras, then sweetened and mastered, then brought into FCP as a Broadcast wav, and it syncs perfectly with the video across over 6 hours recorded that we now a cutting into multiple smaller clips. That worked perfectly.

While recording, in addition to the audio track, Performer was also recoding the MIDI info from the piano performance. Within Performer the audio and MIDI tracks are synced perfectly.

What I now need to do is deliver a midi file that syncs perfectly (i.e. has a frame accurate start point) to the edited, finished vid clip from FCP. To do that I am trying to determine the exact in and out point of the audio clip in FCP so that I can then (back in Performer) use that as the start and end time for the MID clip. That should create a midi file that is perfectly in sync, and exactly the same length, as the vid clip.(in theory I guess…)

When I use (in the example above) a start time of 10:44:05, the resulting midi file is late 15-20 frames (varies from clip to clip using the same technique).

Maybe that “In” point isn’t the correct data to use? I just need to nail down what timecode in the audio file equates to the start (00.00.00.00) of the finished FCP vid clip, and I thought that clip ‘In” point was it.

I sure appreciate the help.

Mooooo ….. 🙂

[Scott Houston]

Thanks Bouke …

I was amused when I realized after some more testing and manual reading today that you are the author of the FCPauxTC utility I am demoing to make sure it will work in my situation. Good to get the advice “right from the source.” I was successful in getting the exported audio from DP synced in FCP. Thanks again!

Now I am tackling one final step unique to my situation I am sure… These finished DVDs contain the ability to control digital player pianos such that the keys on the piano move up and down in synchronization with the piano playing you see on the video. It’s really very cool to see… It all happens through encoded alternate audio files we place on the alternate audio tracks of the DVD.

To produce those encoded files we have to feed the creator software midi files that are recorded simultaneously along with the audio in DP. I’m now tackling getting the same SMPTE code to stay “stamped” on a standard midi file when the start of the file may or not be 00:00:00:00.

As soon as I get that nailed down, I’ll be ready to commit to the workflow and will register your utility.

Thank you for your help.
SH