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.

Adobe Photoshop Lightroom doesn’t support Adobe Photoshop files

I need a ‘facepalm’ category apparently.  There’s been a lot of that lately.

You cannot import, let-alone work on, Photoshop files (“PSB” file extension) in Lightroom.  It flat-out doesn’t support them.  That’s such a weird limitation & oversight, for a program that Adobe now officially names ‘Adobe Photoshop Lightroom’.

See also this six year old thread on Adobe’s website, asking for this feature.

iOS Family Sharing users cannot mix authentication schemes

Apple supports two styles of two-factor authentication, that they call (and distinguish as) “two-step” vs “two-factor”.  “Two-step” is their older method, though functionally they’re basically equivalent.

If you have multiple accounts on a Family Sharing arrangement, and some use “two-factor” while others use “two-step”, you’re in for a bag of hurt.

For example, any time you change the password on any of the non-master accounts, you’ll have to reauthorise all devices on that account with the master purchaser.  You’ll be prompted, when trying to download apps or purchase anything etc, with a dialog saying “Your Family Organizer, [foo], must enter the security code for their payment method”, asking for some kind of input.  There is literally nothing you can enter there that will make it work.  Not the password for any of the relevant Apple IDs, not any security codes for any credit cards, nada.

The problem is that it’s asking for a verification code that you can only create on a device which has “two-factor” authentication enabled.  Compare for example what you see with “two-factor” authentication enabled on your iDevice:

Screenshot of two-factor authentication enabled in iOS account settings

Versus what you see with “two-step”:

Screenshot of two-step authentication enabled in iOS account settings

That “Get Verification Code” “button” is what you’re looking for.  As you can see, it simply doesn’t exist with “two-step” authentication enabled.

The only solution – to allow your family members to download apps, purchase music / videos / books / etc, or pretty much do anything else on their iDevices – is to force the master account over to “two-factor” authentication.

To do this, you have to go to https://appleid.apple.com/ and turn off “two-step” authentication (which will require you to complete some stupid ‘security’ questions).  You cannot turn off “two-step” authentication from any of your actual iDevices’ Settings apps.

Then, stupidly, you can’t actually enable “two-factor” authentication from that same website.  That can only be done in the Settings app on one of your iDevices – by (in iOS 10.3 or later) going into Settings ➜ <your name at the top of the list> ➜ Password & Security.

There’s no way to enable “two-step” authentication anymore.  And not having any form of two-factor authentication enabled is a very bad idea.  So if any of your family’s accounts have “two-factor” authentication enabled, you basically have to switch to “two-factor” on all of them.

Which would be broadly fine, if Apple hadn’t made it so needlessly complicated, and the two systems so incompatible that their own software can’t figure out what’s going on.