How to transcribe voice memos and phone recordings

Somebody recorded a call, or held up a phone and hit record, and now that file is the only version of what was said. It is a good recording to have and a slightly awkward one to work with, for a reason that has nothing to do with the phone: by the time you receive it, most of the decisions that determine how much detail survives have already been made.

This guide is about those decisions, and about the handling steps afterwards that quietly make things worse. It is not about whether or when a conversation may be recorded, which is a legal question that a transcription guide is the wrong place to answer.

The extension is the weakest fact about the file

A phone recording usually arrives as .m4a. That tells you less than it appears to. An .m4a is an MPEG-4 container — structurally the same family as .mp4, with the extension used by convention to signal that there is no video track. It is a box. What matters is what is in the box, which is normally AAC, a lossy codec, but the container does not guarantee that.

Recordings from older handsets, and from some carrier and handset recorder apps, turn up as AMR narrowband instead — the 3GPP speech codec built for GSM voice, sampled at 8 kHz. That is a genuinely different starting point from a wideband recording, and it is not something the file's name reliably tells you either.

So the useful move is the boring one: look. An extension is a label somebody typed, and a container is a fact about the bytes, and the two disagree more often than people expect — a renamed file, an export from a tool that changed the encoding without changing the name, a download that arrived with a generic suffix. Most players and file inspectors will report the container and the codec inside it. If the recording is going to matter, that is worth knowing before anything else happens to it.

It is already compressed speech

Phone recorders compress as they record, and unless somebody deliberately chose a lossless setting, they do it lossily. A lossy encoder does not store the sound; it stores a model of the sound, and discards what it judges you will not miss. That judgement was made once, at capture, by an encoder tuned for listening rather than for later analysis, and nothing downstream puts back what it removed.

This is worth internalising because it inverts the usual instinct. The file you have is not a rough copy of a better one sitting somewhere — for a voice memo, it is the recording. There is no higher-fidelity original to go back for. What there is, is the chance not to lose any more.

Three ordinary steps that make it worse

Each of these is something a careful person does with good intentions, and each of them is a second lossy pass over audio that has already had one.

• Converting it, so it opens everywhere. Re-encoding to MP3 decodes an approximation and then approximates that. Choosing a high bitrate makes the output bigger without putting anything back. Converting to a lossless container avoids adding new loss but does not undo the old loss, and leaves you holding a much larger file that is not the one the recorder wrote.
• Trimming it, to cut the dead air at the start. Shortening a compressed file generally means decoding it and encoding it again, unless the tool goes out of its way to cut on frame boundaries and copy the stream through untouched. The trim is not the cost; the re-encode is, and it lands on every second you kept.
• Sharing it through an app. Chat and mail clients routinely transcode attachments to keep them small. The copy that arrives in someone's inbox may be a generation removed from the copy that left the phone, and nothing about it announces that. Whether a given app does this on a given day is a fact about that app, so the safe assumption is that an attachment is a copy of unknown provenance until you check.

Renaming a file is free. Re-encoding one is not. The two look identical in a folder listing, which is exactly why the distinction gets lost.

When the recording is evidence

The whole of the advice is one sentence: get the original off the device by a route that copies bytes rather than one that re-encodes them, keep it somewhere it will not be edited, and work from copies of it.

Two things follow from that which are easy to skip. First, do the copy early — the longer a recording lives only on the handset that made it, the more chances there are for an app, a backup, or a well-meaning cleanup to be the last thing that touched it. Second, if what you have already came to you through a share or a conversion, that is not a disaster, but it is worth knowing and worth asking whether the original is obtainable. The original is simply the version with the fewest hands on it.

As for whether a particular file can be read at all: that is answered by the probe rather than by the extension, and it is its own guide — including what has actually been driven through the media path, which is a narrower list than the set of things people upload.