TOPIC:

DaveM wrote:

I may have been a bit unkind towards Filmic Pro (and other apps) for not recording with a constant frame rate.

I did a bunch of tests, using different frame sizes and frame rate settings, with the built-in Camera app, Filmic Pro, Moment, and MOVI.

I imported all of the clips into FCP and didn't have any issues with any of the files. My files used both AAC and PCM audio, 44.1 and 48 kHz sampling rate, different recording quality (bit rates), and HD and UHD/4K frame sizes.

Since you mentioned that other files seemed to work (if I recall correctly), I am left wondering if some setting in the app(s) you used had been changed. I'd suggest you review your phone settings and app settings for the microphone used (if more than one option), as well as auto gain control. My recordings were set to use auto gain control.

Since your sample files seemed to have pretty loud audio levels, I wonder if the levels were too loud at certains spots and the "limiter" in the app may have resulted in the clicks/pops in the recordings. Having the "auto gain" function turned off could make this more likely. Usually, when recording audio you don't want levels to go above -12 dB max, and often people record so that the average is around -20 dB, or thereabouts. Proper microphone placement can help with keeping ambient noises as low as possible.

So, it seems I was somewhat wrong about the variable frame rate aspect of the issue, since I couldn't replicate things in my test recordings (most of which used variable frame rate settings). I apologize for going a bit astray focusing on the files once transferred to the computer, instead of considering the actual recording part of the process.

Dave, reading this it came to my mind it can actually as well maybe be the audio recording.

What I did with some videos before is use just an actual in-built Huawei P40 Pro microphone while with newer ones - I was focused on using the Deity D4 Duo.

However - I couldn't find way by just plugging it into my phone and making it work without any configuration.

I've actually had to download the Lesser AudioSwitch to actually tell the phone the plugged in USB should be used as a microphone.

- so, logical thinking now could be referring just to this

However: I'm unsure about the 'auto-gain' functionality that you've been mentioning as I couldn't find the one inside Filmic Pro 😅

Joema, I can definitely agree on the speed of the FCPX and the enjoyable workflow you get there.

The best I've seen throughout CapCut, Premiere Pro, Sony Vegas and now DaVinci.

Definitely - for what it offers and what you can get - it's the simplest, straight to the point, but still - so much to offer.

However - I'll give some time to test how far I am able to go with DaVinci on my maxed out Late 2017 MacBook Pro

zhincic , at least on my iPhone with current versions of Filmic Pro and Filmic Legacy, I have an "automatic gain control" under the Audio section of the apps' Settings.

Filmic Legacy:



Filmic Pro:



If you're using an external microphone, like the Diety, the settings may appear differently in Filmic (or not). The Diety D4 Duo doesn't have its own power. It seems to be made for DSLR and action cameras. I wonder if an iPhone can provide a consistent or adequate level of power to the microphone. Plus, there's a setting on the mic where both front and rear capsules are used. In that case, in any NLE you use, you should keep track of the audio configuration and turn off the second channel (or switch between channels) to avoid phase issues.

But, overall, it doesn't seem to be an FCP problem, as I had no trouble recording on my iPhone any number of apps and playing back in FCP. If the mic is a new part of the workflow, then that is definitely something to consider.

DaveM wrote:

... overall, it doesn't seem to be an FCP problem, as I had no trouble recording on my iPhone any number of apps and playing back in FCP...

I've been looking at this, and I'm not so sure. It's not just a playback issue -- if you export it from FCP as a .wav file, the noise induced by FCP is baked into the file. See attached. Several customer have been complaining about this for years, regarding certain "consumer" formats such as TikTok videos, OBS captures, etc.

No other NLE does this, nor does iZotope RX10 Advanced. It might be a grey or non-standard value in the audio encoding metadata spec for certain formats.

At a minimum, I'm currently inclined to take zhincic's files and file it as a bug in Apple's database. At least it will be documented.

Joe,

I would agree with you about reporting this issue to Apple.

You might want to look at the details of the files in Invisor. It seems to me that the files originated on an Android 10 device. I failed to notice this earlier and this fact sort of renders my iPhone testing moot (though I believe my advice about checking HW and SW settings used for recording, along with audio levels, is valid).

I wonder if the encoding library used creates a file that FCP isn't handling properly, or well enough. I recall one of the cardinal rules for writing file importers or exporters is to be conservative (strictly follow standards, as much as possible) when creating an exporter, and then be as flexible or "liberal" as possible when creating an importer.

It is curious that other applications don't seem to have an issue with importing and playing back the files.

I opened "first.mp4" in both Amadeus Pro and Logic Pro. Neither had an issue with the file playing back properly.

Thanks for providing input on this issue and for contacting Apple. A fix for this should help out lots of people.


Cheers.

Dave, I thought that file was mostly OK, it was supposedly "problematic.mov" (white shirt video) that best demonstrated the problem?

Thanks for the help with Media Composer and Mathematica. However I am not sure it's a clipping problem or anomaly in the source file. I imported it to iZotope RX10 Advanced and I can't see or hear the problem -- even using "problematic.mov".

When I play it in FCP I can hear it. So here is what I did:

1. Export problematic.mov from FCP to H264 which "bakes in" the noise so it's consistent and can be studied. This should display how FCP originally decoded the audio component of the file.

2. Import that H264 file to FCP, detach the video, move it to a gap clip so I could delete that and leave the audio. Purpose of that was to enable View>Zoom to Samples, which won't work if video component is attached or even in the project. (In theory I could have just exported a .wav file but I wanted the same AAC LC audio encoding as the original file.)

3. Zoom to samples (which are 1/80th of a frame). This shows an apparent data dropout exactly where the noise happens. The duration is three 1/80th subframes of a 29.98 frame, which is (1/29.98)/80 = 0.000417 sec, or 0.4 mS.

4. Importing the same file to iZotope RX10 Advanced and viewing the spectral display shows a noise pulse at the same location.

My current guess: for unknown reasons, the encoding pattern and/or metadata in that and a few similar files causes the FCP audio decoder to misinterpret certain values. I did some tests with FFmpeg earlier today to produce modified versions of the file and to overwrite the metadata with different values. My goal was see whether it was the audio encoding itself or the associated metadata. I still have more work to do on that.

This is really difficult because we may not find anything clearly abnormal in the original file. There are some commercial media validation tools, but they are expensive and I don't have them.

I will continue this tomorrow. Thanks for your help.

Joe, a quick update. I deleted my other post where I mentioned Media Composer (MC).

It turns out that the audio was okay in MC. Sorry about that misfire (meters in MC are a bit different). I thought I heard some noise but I listened again after a break and the playback was clean. I've been having some issues with the latest version of MC.

Looking at the audio files in Mathematica didn't yield any suggestion of bad samples, etc.

So, yes, it seems to be isolated to FCP. Thanks for mentioning your test process.

I selected the problematic.mov and first.mp4 files in FCP and exported Computer, Audio and Video, Faster Encode H.264 for both of them.

I then opened both in Izotope RX Advanced (yup, you can open most video files --- the audio is imported). Here are some instructive screenshots. The spectrogram plot makes it easy to see where the "glitches" are:

first.mp4 (exported from FCP):


problematic.mov (exported from FCP):


That was a good thought about checking metadata, instead of just focusing on the data. It's a good sanity check to be able to point to the spots where the noises are audible and see it, as well. Hope this helps.


Cheers.

Many thanks Dave M Ill give that a go I'm also going in and giving the timeline a thorough clean out its full of old stuff switched off stuff and stuff that doesn't need to be there so I'll keep you posted
Thanks again Ian

Hey Dave & Joe, - thank you for taking so much of your time!

I've gone through Filmic once again and couldn't find the option you have.

It might be either in the newer version of the app or limited to iOS.

I am using v7.1.1 and don't have the automatic gain control.

---

I am still truly unaware of why the issue persist inside FCPX as I as well haven't been focusing on trying to find a solution inside Final Cut.

I've decided to finish these clips inside of DaVinci.

---

However - if there was a way to maybe get it sorted - I'd definitely like to find out about it.

I guess the gist of things is that you could transcode the clips with Compressor (or some other tool), leaving video to "pass through", if you want to edit in FCP and avoid issues.

It is a bug, it seems. I'm not sure if Joe submitted it to Apple.

Using Resolve or another NLE would also work, as it seem you're doing...

Joined this forum to confirm this issue exists, and it's a very annoying one.I've found a few workarounds.

1. The issue started appearing after optimized/proxy transcodings are created. Removing the transcoded files, dropping the rendered file cache, so that the originals are used for rendering, then re-exporting the final video helped.

2. I had another case with a vp8+opus webm source file I used had weird a/v timings that I converted to HEVC+aac mp4. The HEVC played fine, but the optimized version started crackling. I blamed myself (before I knew normal files as described in item 1 are affected too) and spend a lot of time trying to reconcile the a/v mismatch length, and make a mp4 that wouldn't crackle. Nothing helped. Until I just on a whim cut out the audio into a separate aac file, and then put it back together with the mp4. Surprisingly, this helped. Even the optimized transcoding didn't have crackles.Here's what I did:

Not sure if cutting out the audio, then stitching it back would help would help in different situations, but I'll try and report back later.

Just confirmed the fix with stitching the audio worked.

I had another video fixed. During the stitching, ffmpeg noted this:

And the resulting file turned out to be a bit smaller

But then the file works fine, even when using the optimized render.
Tip: the source file can be replaced in FCPX with the fixed one using File->Relink Files->Original Media.