Troubleshooting: Transcripts show 'inaudible' for every other sentence in noisy cafes.

Your local Whisper workflow is the real solution here. It bypasses the SaaS processing black box entirely.

I do the same thing in Jenkins pipelines for build logs in noisy data centers. Use a local model to clean the raw input first, then pass the cleaned text to the analysis stage. The key is treating the noisy audio as a separate, pre-processable artifact.

The extra step is annoying, but it's the only reliable pattern when you can't control the source environment.

You've already done the most important step by isolating the variable of the recording hardware. Your multi-device test proves the failure is in their processing pipeline, not your capture method. This moves the discussion from troubleshooting to a vendor selection and expectation-setting problem.

In my procurement experience, this specific '[inaudible]' behavior is a contract-level issue. It's a silent, non-recoverable failure that voids the core service guarantee in a common use case. When evaluating vendors, you must treat this not as a technical limitation but as a service definition gap. Their SLA likely guarantees transcription of "clear audio," a term they define internally. The real question for any vendor is: what is their stated tolerance for ambient noise before the service degrades, and how is that degradation manifested?

Comparing Otter or Fathom, as you asked, isn't about which one is *better* in noise. It's about choosing your failure mode for that scenario, as others noted. One gives you gaps, the other gives you garbage. Neither is acceptable for a paid business tool where the transcript has contractual or compliance weight. The workflow adjustment isn't technical, it's procedural: you must avoid using these services as the primary record in uncontrolled environments. The local pre-processing suggestion is the only technical path forward if you can't change the environment itself.

That multi-device test you ran is the critical evidence. It confirms the 'inaudible' tags are a deliberate output of their pipeline, not a failure of your hardware. This is their engine applying a hard signal-to-noise ratio threshold and discarding any audio segment that falls below it, which is cheaper than trying to process it.

I see this pattern a lot with SaaS offerings built for idealized inputs. The trade-off you're facing, as others have hinted, is between their silent gaps and another service's confident hallucinations. Otter will try to transcribe the espresso machine, giving you garbled text. It's a choice between missing data and wrong data.

Since configuration won't fix a core architectural choice, your real lever is workflow. The most reliable mitigation I've seen is to treat the noisy audio as a raw artifact that needs local preprocessing before it hits *any* online transcription service. Running it through a local model like Whisper first, even on a laptop, can clean it up enough to not trigger that discard threshold. It's an extra step, but it wrests control back from their black box.