Five minutes of some trivial testing shows that this is just not true.

Noise is still affected by input gain

Here’s a composed recording of four 3-second clips recording the room tone in my office. They are (in order): Auto gain, 57dB, 35dB, 0dB:

As you can hear, auto and maximum input gain in this case have very similar noise levels (which is to say, perceptually none), but as you reduce the recorder’s input gain (and instead apply the gain in post) the noise increases substantially and becomes very noticeable.

Granted this is a very big gain application – 57dB – which you would hopefully never need to apply to a real recording, but nonetheless it demonstrates that Tascam’s claims are exaggerations at best; if you actually had the Portacapture X8’s input gain set to 0dB and recorded quiet sounds, you would in fact have problems with noise – problems that would be avoided with a correct input gain setting.

Clipping still happens if input gain is too high

The recorder clearly applies actual analog amplification and can still saturate its ADCs, as shown in this composite of three gain levels. They are (in order): Auto gain, 35dB, 57dB.

Warning: annoying, distorted sound.

It only went over by about 3dB (at 57dB input gain), but that was enough to destroy the input signal and make the recording unusable.

Auto Gain still affects the recording

In the above tests I included the Auto Gain setting, even though it doesn’t exhibit particularly high noise nor does it clip in these simple sound environments (basically constant sound levels). And it worked pretty well (not optimal input gain levels, but close enough for my taste).

But, I was curious if it had any effect at all – again, reading about 32-bit floating-point recording online, you’d be forgiven for thinking Auto Gain has no impact on the actual recorded data. Many people liken the format to camera raw files, and some explicitly state that Auto Gain has no impact on the bits that get written to disk.

This is completely false, at least in the case of this Tascam Portacapture X8. It’s trivial to see why:

Auto Gain still does exactly what it always does – it changes the gain in response to the input. That change is baked into the recorded audio track(s).

So in a nutshell, 32-bit floating-point recording might provide slightly more flexibility in some situations, but it does not mean you can ignore your input level settings, it does not mean you can use Auto Gain in every scenario, and it does not mean you cannot clip.

Addendum: Technical details

I tested post-production gain changes in Final Cut Pro, Logic Pro, & Audacity. All produced the exact same results (to my ears). I had read that Final Cut Pro sometimes ‘bakes in’ clipping with 32-bit float inputs, as if it’s pre-rendering them down to some smaller dynamic range, so I wanted to rule out some Final Cut Pro-specific stupidity. It’s possible that all these editors are doing that, but I’d be flabbergasted if that’s true.

The “industrial noise” sample I used was my dehumidifier, which is about 66dB according to DecibelX on my iPhone 14 Pro. My office room tone is about 42dB according to the same app.

I used Sennheiser K6 modules with an ME65 and ME66 attached, plugged into the Tascam Portacapture X8 via 3′ Cable Matters XLR cables.

I recorded at 96kHz because that’s what I’ll use most often. I like the aliasing headroom above 48kHz (even though of course my final outputs are almost always 44.1kHz or 48kHz), but don’t see evidence that 192kHz provides meaningful additional benefit (and it also hurts the frequency response significantly, compared with 48kHz and 96kHz, according to Tascam).

var someArray = ["Foo", "Bar"]

if let foo = someArray.popFirst() {
    print("Who cares, we never get here anyway.")
}

That yields, on the popFirst() method:

Cannot use mutating member on immutable value: 'someArray' is immutable.

No it’s not.  It’s simply not.

For whatever reason, if you instead call popFirst() on ArraySlice – ostensibly indistinguishable from a real Array – it works just fine.

var someArray = ["Foo", "Bar"][0...]

if let foo = someArray.popFirst() {
    print("Yet this works correctly.")
}

Sigh.

I presume it’s trying to tell me something stupidly obscure about Swift’s byzantine type system.  Good luck finding out what.  Good luck even finding the definition of the popFirst() method, since Xcode claims it doesn’t exist if you Command-Control-click on it.  But Xcode can’t find most things, so that in itself says very little.

I hate this dialog with the fire of a thousand suns.

When this appears, it basically means one (or both) of two things:

1. Some application went nuts and chewed through all your memory and/or disk space.
2. macOS got itself into a darkly comical & embarrassing deadlock.

Quitting any of the listed applications is rarely the correct move.  It’s often enough the case that none of them are the root cause, and you can kill all of them if you want, but it won’t fix the problem.

One important thing to clarify first, though, is that this dialog does not necessarily use the term ‘memory’ in the conventional sense – i.e. RAM.  It can also refer to disk space.  Unfortunately it doesn’t bother to distinguish between the two, which is particularly stupid of it since any possible resolution of the issue is highly dependent on which of the two cases it in fact is.

Thank goodness for iStatMenus, though, which in the most recent incident showed that I had ~20 GiB of RAM completely free (not even inactive, actually outright free).  So immediately that rules out what the daft bloody dialog’s actually saying.

The worst thing about all this is when it’s #2 the occurs.  For example, I had Lightroom do a 63-image panorama merge.  As Lightroom is a gross memory pig when doing panorama merging, it consumed something like 40 GiB of memory.  Which caused a bunch of stuff to page to disk.  Which consumed all the disk space.  Which led to that obnoxious dialog.  Which further led to macOS in its infinite fucking wisdom ‘pausing’ (SIGSTOPing) almost all running programs, including evidently whatever daemon actually handles paging.  Thus when Lightroom actually completed the panorama merge and released all that memory, I now had 20 GiB of free memory and the system refused to use any of it to page back in all that memory it’d paged out.  Because it was out of disk space.

The only solution – short of hard rebooting and hoping it resolves itself – was to delete a bunch of files I actually do still want, but which will now have to be recovered from a backup.  Great job macOS, thanks for all your help.

Of course, even once you do that and recover the system from the derpeche mode it put itself into, it won’t actually unpause any of the shit it broke.  You have to do that manually.  It pretends you can do that via that dialog that started the whole thing – assuming you left it open the entire time, blocking your view as you actually help the situation – but that only shows user-visible applications, not all the other system & background processes that it also rudely halted.

So, simple tip for resuming everything:

sudo killall -CONT -m '.'

Elegant, after a fashion.  Though every time, it reminds me that whomever named it ‘killall’ was either not very friendly or not very wise.

Note that the system will probably still be a bit broken in places, as despite what macOS thinks, you can’t just blindly pause random system tasks and not have things get really, really confused.  A reboot is always wise after seeing this dialog, to properly undo its fuckery.

Nikon have released the SnapBridge app so that the much-touted Bluetooth+Wifi capability of the D500 can actually be used.  A mere eight months after it was announced.  Fuck you too Nikon.

However, as I’d clearly forgotten, it’s not very useful anyway.  It doesn’t work with raws, you see.  Doesn’t even acknowledge that they’re in the camera, on the card.  It took me twenty minutes of screwing around with the app, wondering why it was so completely broken and dysfunctional, before I stumbled upon a tech support article for it buried half a dozen layers deep inside Nikon’s website (yes, there’s essentially no documentation within the app itself).

It does appear to at least work for geotagging & time sync, which is something.  Something Nikon could have put in natively for a $1 GPS receiver, and then not have to kill my iPhone battery to accomplish rudimentary tasks.

The almost saving grace of the D500 is its speed – specifically the UHS-II support, which helps it clear out its buffer extra snappy, given a decent SD card.  That means I can turn on NEF+JPEG without much concern about slowing down burst shooting, and only marginal concern about the wasted SD card space.

But it’s only almost saved by it.

The problem, you see, is that even if you abuse the NEF+JPEG option to yield little JPEG turds on your SD card – and even though those JPEGs can be surprisingly decent quality, even on ‘Small’ and ‘Basic’ settings – in NEF+JPEG mode the camera insists on using the JPEG version for all in-camera playback.  It becomes completely impossible to view the actual NEF.

Now, granted when ‘viewing’ NEFs in-camera you’re only getting the JPEG preview that’s built into them anyway, but still – it’s at least a decent quality, full-size preview.  You can at least zoom all the way in.  Not so if your JPEG turds are not full-size.

Which might be a good enough option, if one is willing to waste up to 50% of your space saving full-size JPEGs alongside the NEFs.

But, SnapBridge transfers the images via Bluetooth only.  Even when you’ve configured it to bring over the originals, at up to 10 MB each.  It can take minutes to transfer a single image of that size at Bluetooth speeds – I know, I accidentally proved it empirically.

Now, you can limit the transfer to 2 MP versions of those JPEGs, but 2 MP is tiny, even by Shitagram standards.  The ‘Small’ JPEGs the D500 saves natively are 5.2 MP, for point of reference.

So the 2 MP transfer option – call it “Thumbnails only” – is not a practical or useful option.

So we’re back to having to use full-size JPEGs, alongside the real photos (the NEFs).

And remember the prior point about abysmal Bluetooth transfer speeds?  To make SnapBridge’s auto image transfer plausible to use with any frequency – let-alone leave on permanently – you need tiny file sizes.  Even on the highest compression setting (vanilla ‘Basic’) the 21 MP JPEGs are several megabytes.  Only by using the ‘Small’ image size – which is frankly still good enough for Instagram types – can you get the sizes into the sub-MB range, and transfer times down to ‘merely’ a few seconds per photo.

So you’re stuck between a rock and a hard place.  The net result is that the whole image download thing’s kinda horrible and useless to me.  Which makes me sad, because it could easily have been implemented much better.

The CamRanger remains a significantly better experience in almost every respect – the main detractor being the additional monetary cost it imposes.

I was quite disappointed to see that APFS isn’t even trying to provide data integrity.  Data integrity is kind of step 0 of any file system, and checksums or use of ECC is pretty much standard in modern & leading-edge file systems.  APFS doesn’t want to be one of those, it seems.

Case in point why this matters:

I have a bunch of old backup drives, because drives are cheap and until recently I could just buy a new one once the current one filled, instead of ever deleting a backup.  Periodically I go back through these old backup drives and do some basic integrity checks (S.M.A.R.T. bad block scans, file system checks, etc).

I also run a comparison of key data between those backups and the current versions on my computer, for files which generally shouldn’t change nor disappear – e.g. photos, videos, key documents, etc.

And today I found that at least half a dozen valuable personal videos (and a few photos) were corrupt, in the versions on my computer.  Luckily, the versions in the ancient backups were still good, so I could replace the corrupt ones.

This corruption was completely silent, until my ‘paranoid’ and time-consuming checks discovered it.

It’s far from the first time.  A failing drive years back corrupted a huge portion of my music library – silently, as far as the file system & OS were concerned.  Periodically I’ve discovered photos (of which I have huge numbers – the majority of my data) which have become corrupt at some indeterminate point.  And I’ve of course had file system [metadata] corruption occur many times, sometimes requiring complete erasure of the disk, and recovery or rebuilds from backup (a few times I’ve had to use data recovery software, where backups weren’t available).

Most, if not all, of these issues would have been discovered by even the most trivial file integrity protections, in the file system.

The notion that modern disks somehow magically protect against all silent data corruption is abject poppycock.  They’re more likely to suffer from it than older disks – a byproduct of higher densities and market demand for cheaper, crappier storage products.

And the implicit assertion that Apple’s file system driver, and kernel overall, are somehow completely free of bugs… is just batshit crazy.

Addendum

Since Apple aren’t interested in protecting anyone’s valuable personal data, I’m on the look-out for other options.  Manual use of shasum is one, for now, but a more streamlined and fool-proof system would be better.  Alas, none seems to exist[1. There is chkbit, but it relies on MD5… probably acceptable for this use case, but needless in the face of decades of better hash algorithms.  And it’s written in JavaScript.  Ew.].  Yet.

A few hours later, Gandi.net was working again, but my site wasn’t.  Sad panda.

Long story short, I used up all the disk space – and by “I”, I mean something – still haven’t figured out what, yet.  Apparently when you use up all the space, that simply kills the VM without any notification (their dashboard for my VM still claimed it was running just fine, no problems detected, which was obvious crap).

That said, their tech support identified the problem quickly and were ultimately able to rectify things for me (after first suggesting I delete some stuff myself, which I tried only to find that when your Gandi VM is wedged in this state, you can’t log in via SSH nor delete anything via SFTP, and those are your only two means for deleting any files…).

As far as I can recall, this is the first time my site’s actually been down in the ~four years I’ve hosted with them (other than a few errors on my part when messing with WordPress etc).

For the additional context – the restore failure I alluded to was basically that:

1. Over the course of more than a week and repeated attempts, they were unable to restore 99.7% of my data.
2. They sent me 685 spammy emails telling me the restore failed.  Six hundred and eighty five.
3. Their tech support was at least fairly open, and admitted to the problem without fuss, but were unable to actually do anything to get the data back.  Which is, after all, the most important thing.

So, the departing ‘support’ ticket I filed with them (#167833):

This test, of the coolest names built-in dictation.) Nope, not important.

If you’re..Reasonably built night, That was true Samaritan and settle.

Go ahead, try to figure out what I actually said.

24/09/13 6:54:08.457 PM PhotoStreamAgent[305]: Transaction forbidden. Code: 403.
24/09/13 6:54:08.457 PM PhotoStreamAgent[305]: MSPublishStreamsProtocol - XXXXX Put connection has failed. Error: __NSCFError:
Domain : streamsProtocolCoreErrorDomain
Code : 3
Desc : The Photo Stream server has rejected the user's request.
UserInfo: {
 NSLocalizedDescription = "The Photo Stream server has rejected the user's request.";
}
24/09/13 6:54:08.457 PM PhotoStreamAgent[305]: MSPublisher - XXXXX Received a quota error.
24/09/13 6:54:08.457 PM PhotoStreamAgent[305]: MSPublisher - XXXXX Quota error code: 4033

Thanks iCloud. Screw you too.

Long story short, it’s far worse than even I thought.  I wish I could believe it’s just a bad joke, a prank, and we’ll get the real thing in a few months, but I just doubt it.  It looks deliberate.  It’s depressing.

You have to actually use it for a while to really appreciate how badly it’s broken.  It’s just hard to explain otherwise – you wouldn’t believe some of it, for a start.

There may be a careful-what-you-wish-for moral here.  I’ve long disagreed with Apple’s domineering focus on iOS over all else.  The Mac is still what gets the work done in the end, and it’s been horribly neglected.  It was a small part of why I left Apple.  Yet when I look at OS X Mavericks, aside from the dumb name it is actually a very promising release.  Both from an end-user and a developer perspective.  I’m actually looking forward to it (but, since as noted I actually need my Mac, unlike my iOS devices, I’m not putting the beta on it).

It appears that all the Mac engineers that were stolen by iOS over the last few years were put back on the Mac, and then some.  iOS 7 is superficial, crass, styleless and boring.  Mavericks isn’t a correspondingly revolutionary upgrade, but it’s at least some kind of solace.

Vivitar Professional Metal Macro Automatic Extension Tube Set of 3 for Nikon (13mm, 21mm &  31mm)

I suppose I should have caught on that something was wrong by the fact that the description for the same item stated that the tubes were actually 12mm, 20mm & 36mm.

When they arrived, I was surprised to find they were not metal at all.  Just plastic, like all other budget extension tubes (well, as I now know).  They were also broken.

I contacted the fulfilling company – Cameta Camera – and eventually ended up talking via phone to Rich, who was very east-coast – very aggressive, blunt, and more than once insisted on talking through some stream of conciousness even after I already told him I understood, or I agreed, or I just didn’t care.  The kind of person who’s not finished talking until they’re finished talking.

I’m not really inclined to that sort of personality, which I guess is why I much prefer the west coast.

Anyway, incompatible as our personalities are, he was mostly helpful and as I write the broken tubes are somewhere on their way back to him, to be replaced.  He even offered to pay the return shipping cost (albeit without  the California sales tax part).

It happens that things are broken from the manufacturer, so while it’s annoying I’m still reserving judgement.

But an interesting thing did come out of my discussion with him.  I had pointed out that the listing on Amazon was blatantly wrong, and I suggest deliberately misleading & misrepresentative.  He was lightning fast to point out that he doesn’t set the product descriptions, that they have no control over them, and that dealing with Amazon to try to get them fixed – despite the millions of dollars of business they do through Amazon every month – is “worse than dealing with the government”.  I assured him I understood, and would pursue the matter with Amazon separately.  He told me not to bother; that I’d be wasting my time.

Nonetheless, I did use Amazon’s website to issue a correction for the issue.  I included two photos of the box, as it requested.  I fixed the product title, fixed some grammatical errors in the description, and added in a bullet point describing them as “Plastic with metal bayonet mounts”.

A few days later I got an automated rejection notice from Amazon, stating that “The image provided does not appear to pertain to, or otherwise does not verify, the following suggestion(s).”.  They then quoted the entire description, without any indication of which specific changes they took issue with.

But nonetheless, now I go to the product page and the title has “mysteriously” been fixed to no longer make false representations:

Vivitar VIV-EXT-N 3 Set Extension Tubes for Nikon

They also rearranged the bullet points in the description, and oddly changed one that was actually accurate, from:

Extension tube set for Nikon AF digital SLR cameras

To:

For use with Nikon F SLR cameras

So it appears that some reviewer at Amazon rejected my corrections – which were indeed 100% correct – and instead substituted their own, sight unseen of the actual product (besides the photos I sent, I suppose).  They also rejected my suggested title change (which was basically dropping the “Professional Metal” bullshit and fixing the quoted sizes), going instead with the slightly awkward one quoted above.

The whole experience has been kind of flabbergasting.  In a nutshell, Amazon used blatantly false advertising to push a product, and when called on it claimed that nothing was wrong, but then quietly tweaked the product listing anyway.  Ostensibly the point of buying from Amazon instead of eBay, Craigslist, etc, is that you can trust their listings.  Abjectly false.