You have a recording full of beeps. Maybe it is a clip from a game, a video, an old radio recording, or a signal you captured off the air.
You feed it to a Morse code audio decoder and it hands you back a flood of E's and T's, or letters that run together into nonsense, or nothing at all.
The decoder is probably not broken. Morse code audio is simply less forgiving than it looks, because Morse is not really about pitch or beeps. It is about timing. Once you understand how the timing works, most decoding failures stop being mysterious: each one leaves a recognisable fingerprint, and each one has a fix.
First, work out what kind of Morse you actually have
Not every beeping recording is the same problem, and the right approach depends on which one you are holding.
Clean, machine-sent Morse — from an app, a computer, or a radio's built-in keyer — is the easy case. The timing is regular and almost any decoder will copy it well. Hand-sent Morse from a straight key is harder: a human "fist" stretches some gaps and squeezes others, and software struggles with it far more than your ears do. A recording pulled from a busy radio band is harder again, because your signal may be fading, drifting, or sharing the frequency with other stations.
Two cases deserve a warning before you start. If the Morse in your clip is flashing light rather than sound, an audio decoder cannot help you at all; you need to read the flashes as timing instead. And if the audio has no gaps between the symbols, just one continuous stream of dots and dashes, it may be mathematically ambiguous. Morse is not prefix-free: the same stream can be split into letters in thousands of different ways, so a gapless puzzle clip sometimes has no single right answer, no matter what tool you use.
The 60-second timing model that explains almost everything
International Morse timing, standardised in ITU-R M.1677-1, is built from one unit:
A dot is 1 unit.
A dash is 3 units.
The gap between symbols inside a letter is 1 unit.
The gap between letters is 3 units.
The gap between words is 7 units.
Speed in words per minute comes from the word PARIS, which is exactly 50 units long, so one unit lasts 1,200 ÷ WPM milliseconds. At 20 WPM a unit is 60 ms; at 5 WPM it is 240 ms.
This is why decoding fails silently. A decoder measures durations and gaps and turns them into letters. Anything that corrupts the durations — noise, echo, a wandering hand on the key, a wrong speed setting — corrupts the text, and the decoder usually cannot tell you it is guessing. When your output looks wrong, one of the five numbers above is almost always being misread.
Read the failure: a symptom-to-fix guide
Different problems leave different signatures in the output. Find yours here before you change anything.
A flood of E's, I's and T's. The decoder thinks the signal is slower than it really is, so dashes get chopped into dots and gaps get promoted into letter breaks. Fix: raise the assumed speed, or let the decoder re-estimate it from a clean stretch of the message. If the first characters are wrong and then it settles down, that is the same problem — the speed estimate was still converging.
Letters run together, or words come out as one long string. The letter gaps are being read as symbol gaps. This is the classic signature of hand-sent code with squeezed spacing, and of Farnsworth sending, where characters are sent fast but the gaps between them are stretched on purpose. Fix: if your decoder has separate settings for character speed and overall speed, use them; if you are practising by ear, this is a reason to learn characters at full speed from the start.
Extra marks appear in the silences. The detection threshold is too sensitive, so background clicks, static crashes or room noise are being counted as dots. Fix: clean the audio first (see below), turn the volume of the recording up so the tone stands further above the noise, and if the tool offers a threshold or squelch control, raise it slightly.
Nothing is detected at all. Three usual causes: the tone sits outside
the decoder's listening range (most expect a sidetone somewhere around 400 to 1,000 Hz, with 600 to 800 Hz typical), the app does not have microphone permission, or the sound is playing into headphones the app cannot hear. Fix: check the tone's pitch, check permissions, and play the audio out loud or feed the file directly.
It works, then falls apart halfway through. The signal is fading in
and out (on-air operators call this QSB), or the sender's speed drifts mid-message, which hand senders do constantly. Fix: decode the message in sections, re-checking the speed setting on each part, instead of expecting one setting to survive the whole recording.
The output is tidy but meaningless. This one may not be a failure at all. Real radio traffic is callsigns, abbreviations and number groups, not plain English. A perfect decode of a contest exchange can look like gibberish. Check the Morse itself before you assume the tool invented it.
Clean the audio before you decode it
Most garbage decodes are audio problems, not decoder problems. A few minutes of hygiene beats an hour of settings:
Use the original audio. Extract the sound from a video rather than re-recording it through speakers and a microphone; a re-recording adds echo and room noise that smear the gaps.
Trim the ends. Leading seconds of noise teach an automatic decoder the wrong speed and the wrong noise floor.
Prefer a lossless file. WAV keeps edges sharp; heavy compression softens them.
Keep one signal only. If two stations or a music track overlap your Morse, no setting will separate them reliably. Cut the cleanest section you have.
Keep the level steady. A tone that fades to near-silence will be read as gaps, and a clipped, distorted tone reads as noise.
Too fast is normal: a word about speed
Beginners are often shocked by real Morse, because real Morse is quick. Data from the Reverse Beacon Network, which records thousands of real on-air CQ calls, puts the average calling speed at about 25 WPM, and contest stations run closer to 30. Most experienced operators live somewhere between 15 and 25 WPM. The slow, perfectly even Morse in beginner apps is the training-wheels version.
So if a recording defeats you at first, the honest answer may be that it is simply fast. Two things help. As a listener, slow the playback down to half speed to check your copy; the timing ratios survive slowing down, so the decode stays honest. As a learner, keep character speed high (15 to 20 WPM or more) and stretch the gaps instead — that is Farnsworth timing, and it trains your ear for real signals without teaching you habits you later have to unlearn.
Why your ears beat the machine on hand-sent code
Software decoders are at their best on machine-sent Morse and their worst on a human fist, because people do not send metronome timing. One operator's letter gap is another's word gap; dashes swell when a sender leans on the key. Your brain handles this gracefully because it recognises the rhythm of a letter as one sound. A decoder, which can only measure durations against fixed thresholds, cannot be so forgiving.
That is also the secret to copying by ear yourself. If you count dots and dashes and translate each letter in your head, you will hit a ceiling around 10 to 13 WPM that no amount of practice removes — the counting itself becomes the bottleneck. The way past it is to stop counting and learn each character as a single rhythm, the way you recognise a knock at the door. The Koch method builds exactly this: start with just two characters (K and M) sent at full speed, and add one new character each time you are copying the set at about 90% accuracy. Most learners also trip over the same mirror-image pairs — A and N, D and U, G and W, B and V, F and L — and one-element neighbours like S and H or D and B. Drill the pairs, not the alphabet, and the confusion fades.
Three myths worth dropping
"A dash is twice a dot." No — a dash is three units, and decoders are built on that. Audio stretched or squeezed away from the 1:3 ratio is a common hidden cause of bad output.
"SOS stands for Save Our Souls." It does not stand for anything. ···−−−··· was chosen as a simple, unmistakable pattern and adopted in 1906 (in force from 1908) as a single prosign, sent as one continuous character with no letter gaps — which is why decoders that split it into S-O-S letters are technically misreading it. The famous backronym came later, and the Titanic is famous for the older CQD call, not for inventing SOS. Ships stopped keeping a Morse watch in 1999 when the GMDSS satellite system took over.
"If the output is gibberish, it must be encrypted." Almost never. Work through the symptom guide above — speed, gaps, noise and thresholds explain nearly every strange result, and plain radio traffic often looks like gibberish even when decoded perfectly.
Watch the audio translator in action:
https://www.youtube.com/watch?v=Q4Jx4o9mCJI
A reliable way to decode your recording
Put it together and the workflow is short. Get the cleanest copy of the audio you can, trim it, and feed the file itself — not a speaker re-recording — to a Morse code audio translator (https://translatorcodemorse.com/morse-code-audio-translator/) that decodes in your browser. Read the raw dots and dashes it detected, not just the final text; if the Morse looks wrong, the problem is in the audio or the speed, not the alphabet. Sanity-check by turning the decoded text back into Morse and comparing the rhythm with your recording. If the message matters, verify it a second way: slow it down, decode it in sections, and glance at a Morse code alphabet chart (https://translatorcodemorse.com/morse-code-alphabet/) for any character the tool flags as uncertain.
Decoding Morse audio stops being frustrating the moment you treat it as a timing puzzle instead of a beep puzzle. Get the timing right — clean audio, honest speed, real gaps — and both the software and your own ears will surprise you.
Built by Mir Labs. The translator, charts and decoders mentioned here are free at translatorcodemorse.com