You dictate a note in the kitchen and the words appear instantly. You climb into the crawlspace, hit the same button, and it freezes or returns nothing. The first instinct is that the microphone is bad or the phone is choking. Neither is true. The microphone in a crawlspace works exactly as well as the one in the kitchen. What changed is whether your phone could phone home.
Why does dictation stop working with no signal?
Because browser dictation usually does the actual speech recognition on a server, not on your phone. The Web Speech API's recognition side is the feature most "tap to talk and watch text appear" web tools use, and in major browsers the audio is sent to a remote service to be turned into text (MDN, Using the Web Speech API). No connection, no server, no transcription. The MDN reference notes that recognition is handled by the browser's speech service and behavior depends on that service being reachable (MDN, Web Speech API). So the basement does not break the mic. It breaks the network round trip the transcription secretly depends on.
That is the whole illusion. It felt like on-device magic upstairs because the round trip was fast. Underground, the round trip never completes, and the magic was never local to begin with.
So is the microphone ever the problem?
Almost never, in this scenario. The mic captures audio fine regardless of signal; capturing audio is a local operation. The failure is specifically in the recognize-this-speech step that needs a server. You can prove it to yourself: a plain voice recorder app records perfectly in the same dead spot where live dictation fails, because recording is local and recognition is remote. Different jobs, different dependencies.
This is why "just use the phone's voice typing" is unreliable field advice for inspectors. The exact places you most need hands-free notes, crawlspaces, basements, slab foundations, steel-framed mechanical rooms, are the places signal dies.
Why this is an inspector problem specifically
Your worst signal and your most note-heavy moments line up perfectly. You are on a ladder, in a respirator, looking at the actual finding, and that is when you want to talk instead of type. It is also frequently where there is no signal. Live, server-dependent dictation is built for someone sitting in a coffee shop on Wi-Fi, not someone in a sealed basement. If your capture method assumes connectivity, it will fail in the precise conditions inspection work is made of.
The fix is to separate capturing the audio from transcribing it. Capture has to work offline. Transcription can wait.
Record locally, transcribe when you have signal
Record the audio locally first, then transcribe later when there is a connection. Browser recording via the MediaRecorder API captures audio to a file on the device without any server in the loop (MDN, MediaRecorder API; MDN, MediaStream Recording API). The voice memo is safely captured in the crawlspace, and the speech-to-text happens once you are back in signal, with no lost notes and no frozen screen mid-finding. The companion question — what actually happens to that memo with no cell signal — covers where the captured audio lives until it syncs.
That record-now, transcribe-later split is exactly how MoldMind handles field voice. Memos are captured offline with MediaRecorder, queued on the device, and transcribed server-side when you reconnect, then reformatted into report-ready findings you review. It does not assume the basement has bars, because basements do not. The sample report shows what those reformatted findings look like in a finished document.
Sources
- MDN, Using the Web Speech API: browser dictation sends audio to a remote service for recognition in major browsers.
- MDN, Web Speech API: recognition behavior depends on a reachable speech service.
- MDN, MediaRecorder API: captures audio to a local file with no server in the loop.
- MDN, MediaStream Recording API: recording is a local operation, independent of network connectivity.