However, Final Cut Pro has a design flaw which causes data loss. You see, Final Cut Pro never merely copies the files. It extracts their audiovisual contents and puts it into a new file. You might have noticed this already from the fact that Final Cut Pro’s copied version of the files is always a MOV container, whereas your inputs are more likely an MP4 container.

This would be annoying enough in itself – it means you can’t do simple bitwise comparisons of the files to e.g. ensure the imported copy is actually valid and not corrupt, before you erase the original from your memory card. But it gets worse.

Final Cut Pro doesn’t copy all the contents. It only copies some types of tracks – i.e. audio, video, and timestamp tracks. It does not copy tracks such as GoPro’s metadata track (GPMD). Final Cut Pro just silently discards those.

Those tracks can contain important information. GPMD tracks, for example, contain a whole host of telemetry from the GoPro including its location during recording, rotation & movement data, and much more. Even if you think you don’t care about things like geotagging, consider this: that rotation & movement data can be used to enhance image stabilisation. By losing the data at import, you’re losing the ability to ever utilise that enhanced image stabilisation.

So never let Final Cut Pro “copy” your files – always copy them yourself first, as needed, and then import them into Final Cut Pro by reference only (the “Leave files in place” option). Thankfully Final Cut Pro doesn’t mangle the files when you use them that way (underlining the question: why does it force a lossy conversion to MOV to begin with, since it clearly works just fine with MP4 originals).

I was originally doing something like:

ffmpeg -ss 00:07 -t 00:03 -i "IMG_0164.MP4" -async 1 -c copy "IMG_0164_TRIMMED.MP4"

The resulting trimmed MP4s play just fine in Quicktime, the Finder – anywhere that uses Apple’s decoding libraries (though I didn’t test iOS).

However, in VLC, or Lightroom, the audio is completely corrupt – just incoherent noise.  In Lightroom the video doesn’t even play correctly, because of Lightroom’s stupid habit of re-encoding the video & audio into internal caches – apparently their video decoder is somehow thrown off by the audio channel issues, too.

After much trial and error and many dead-ends (thank you completely bogus & wrong Stack Overflow threads… sigh) I eventually realised that the problem is apparently simply that Lightroom, VLC, etc get offended when you include pcm_s16le audio in an MP4.  ffmpeg itself says that’s not a valid audio codec for the MP4 container, iff you explicitly tell it to use that as the codec.  If you’re just copying from an existing audio / video file, however, it makes no mention at all of the concern.  Sigh.

So the apparent solution is simply to switch to the MOV container format instead.

ffmpeg -ss 00:07 -t 00:03 -i "IMG_0164.MP4" -async 1 -c copy "IMG_0164_TRIMMED.MOV"

The encoded bits remain identical, but the MOV container apparently accepts PCM audio where MP4 does not.  VLC, Lightroom, etc are now happy (and Quicktime et al remain happy).

(another possibility is that the ‘incompatibility’ is related to MP4 levels or some other such junk… I didn’t try deciphering or exploring that)

It’s frustrating that VLC & Lightroom can’t handle this when clearly it’s technically possible (witness Quicktime), and worse they don’t even properly recognise that they’re not handling it properly – they just play completely corrupt audio that’s literally painful on the ears.

It’s also very curious that the trail camera uses PCM audio if that’s not valid in an MP4 container.  It’s downright bizarre that VLC & Lightroom can play the unmodified MP4s straight from the trail camera, even though they use the same purportedly invalid audio codec… somehow something ffmpeg is doing during its transmutation is making them angry.  I was unable to determine what that might be, though, through trial-and-error with ffmpeg command line options & rudimentary examination of the input & output files.

P.S.  An alternative is to bitwise-copy only the video stream (i.e. change -c copy to -c:v copy), and let VLC transcode the audio into its default AAC for the MP4 container.  That probably wouldn’t be a problem for me in my case – the audio from trail cameras is pretty crappy to begin with – but at the same time the audio tracks in these files are insignificant in size, so re-encoding them (and lossy as AAC) is pointless to saving disk space.