ffmpeg can produce pseudo-corrupt audio when ‘copy’ing to an MP4 container

I’ve been using ffmpeg to trim clips from a trail camera, as most of the time there’s only a few seconds of anything interesting in frame out of the 30+ seconds of video it records each time, but I don’t want to re-encode them and lose video quality as a result (or balloon file sizes tremendously with a lossless video coding).  Keeping the whole 30 seconds is not just unnecessary and makes viewing the videos much more tedious, but wasteful of storage space as the encoding quality from the trail camera is very inefficient (file sizes are many times larger than they should be for the quality – clearly the H.264 encoder used in the trail camera is very cheap and very bad at its job).

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.

iMac Pro first impressions

10-core w/ Vega64.  Upgrading from a 2014 Retina iMac.

Relatively briefly, and in no particular order:

  • I don’t see why the very slightly different colour scheme, vs the regular iMacs, is such a big deal to some people.  Yes, it’s fairly obviously a different colour.  No, it doesn’t really look any better (nor worse) than the regular iMac’s colour.
  • It’s disappointing that it comes with such crappy input devices (the mouse & keyboard at least).  They’re the usual ergonomic & general usability disasters that Apple’s infamous for as of recent years.
     
    Digression:  I also recently got a new MacBook Pro 13″ with Touch Bar for my work machine, which has an even worse keyboard than the iMac Pro, if such a thing is possible.  It’s literally painful to type on.
  • According to Intel’s Power Gadget tool, it basically sits at 3.6 GHz permanently.
     
    On the upside, it doesn’t seem to ever drop below that, despite nominally having a 3.0 GHz base frequency, even under the heaviest loads I can throw at it (including heavy, concurrent GPU use).
     
    On the downside, it’s supposed to turbo up to 4.5 GHz, but I’ve never seen the tool report that.  It does get up above 4.0 GHz if you only have one or two threads actually active, but only barely.  Intel’s tool only has 20ms sampling resolution, so it’s quite possible it is bursting to 4.5 GHz in very short stints.  In fairness, the regular iMacs exhibit basically the same behaviour – my 2014 Retina iMac nominally boosted up to 4.4 GHz, but in reality rarely if ever hit that.  Under load, that iMac struggled to reach 4.0 GHz.  Unless the ambient temperature was uncomfortably cold, it’d easily fall down to not much more than 3.0 GHz under any kind of sustained load, and sometimes even further, into the 2.x GHz range.
  • The fan is quite audible under any real load, even though I have some loud Thunderbolt disk bays and other things even closer to me than the iMac Pro.  I have no idea what some reviewers have been talking about w.r.t. the fan being “whisper quiet” or outright “inaudible”, because it definitely is not quiet.  It’s not loud, to be sure, but you can’t miss it.
     
    Under basically no load, there is indeed very little fan noise, but that’s both an unrealistic use case and certainly no better than the regular iMacs.
  • It does feel dramatically faster than a non-Pro iMac.  I did not expect this.  Certainly I expected significant objective improvements in parallel workloads – mainly batch photo & video editing in my case – but in fact the speed improvement is very noticeable even in single-threaded workloads.  I’m not sure why yet… the internal SSD is faster than the SATA SSD in my prior iMac, but the difference I’m seeing doesn’t seem plausibly explained by that [alone].
     
    I’m also seemingly seeing it perform significantly better under load, w.r.t. user interaction.  Even with all CPU cores completely busy, and the GPU likewise, interactive use remains basically as fast as when it’s idle.  This is a pretty big difference – and very pleasant improvement – over the non-Pro iMacs.  It’s really nice to not have to just walk away while CPU-intensive tasks are running.
  • The screen doesn’t immediately appear much different – in terms of colours, contrast, brightness, etc – to my old 2014 Retina iMac.  But it’s very clear which is which, because the iMac Pro has no image retention issues, whereas the 2014 iMac has pretty severe ones.
     
    Though when specifically looking at sRGB vs Display-P3 examples, the difference is quite a bit moreso than I expected, which is of course a pleasant discovery.
  • It’s so much better to have a proper, native VESA mount vs the hacks you had to do with prior iMacs.
  • iStat Menus can’t read any sensors (except CPU frequency, once Intel’s Power Gadget is installed), though I expect this is going to be fixed fairly soon, in a future version.
  • The ports on the back aren’t properly aligned with the case where they protrude, unlike non-Pro iMacs.  Meaning when you plug a cable in, it doesn’t align relatively flatly against the curved case, but rather tilts upwards a bit.  This is a really odd change – though obviously minor and practically insignificant.
  • I don’t yet understand why, but Lightroom Classic CC is noticeably snappier.    Particularly in the Develop module as you make edits and then wait for the results to appear on screen.  In some cases it’s an order of magnitude faster – e.g. less than a second instead of 5-10 seconds.  It’s still not consistently fast by any means, but it’s no longer always infuriatingly slow.
     
    I’m unconvinced, regardless, that the laws of physics will allow creation of a computer upon which Adobe’s software won’t run agonisingly slowly.
  • Officially it’s quite a bit heavier than the non-Pro iMacs, but I was surprised to find that it’s actually lighter for me… though that’s because with the stand removed – replaced by the VESA mount – it of course under-weighs the regular iMacs with their fixed stands still stuck in them plus a VESA mount adapter.

Lightroom “Classic” doesn’t play well with others

So far the new “Classic” Lightroom looks & feels mostly identical to the prior version(s), which isn’t really a compliment, but could be worse.  There’s no apparent performance improvements, that’s for sure, so as expected Adobe’s promises to suddenly learn how to write efficient & performant software, well… at least their marketing department gave it the college try.

One thing I have very quickly discovered, however, is that Lightroom “Classic” deliberately chooses not to perform some functions if it is le tired.  Or it thinks your computer is le tired.  By which I mean, if there is pretty much anything else running and consuming CPU time (and/or RAM?), it refuses to even attempt some operations.  HDR merges is the first one I hit.  I was a bit flummoxed by it just happily queuing up a number of HDR merge operations, and them just sitting there in its queue, with no indication of error – just never executing.

Only after I quit or disabled a bunch of other processes – any and all that were using any measurable CPU time – did it finally, about ten seconds later, decide that it was now willing to consider my ‘requests’.

#%@!ing fussy little turd.

It’s worth noting that it’s not the only popular app, on macOS, that does this same bullshit.  Time Machine is another big one.  At least in Time Machine’s case I can see a more plausible line of reasoning behind it, even if it is misguided – the user’s probably not explicitly waiting for a Time Machine backup to complete.  As in, not all the time.  Sometimes they are. And they certainly expect backups to happen at all, which on a consistently busy machine simply doesn’t happen.  So Time Machine’s reluctance to function on a working machine is still stupid overall.  But Lightroom refusing to complete a user initiated, user-interactive, and user-blocking operation, is just patently stupid by its very notion.

Update:  Worse, now it doesn’t work at all.  And a quick web search shows many other people having the same problem, and Adobe as usual doing nothing about it.

Incidentally, I tried to log in to Adobe’s forums in order to ‘Me too’ those issues, only it won’t let me log in anymore, falsely claiming my password is invalid.  Good job, Adobe, good job.