Converting written Morse code into text is relatively straightforward.
If the input is:
... --- ...
a program can simply split the symbols and map them to letters.
But decoding Morse code from an audio recording is a very different problem.
The browser does not receive dots and dashes.
It receives a waveform containing frequencies, noise, silence, timing variations, and sometimes imperfect recordings.
So how can a browser turn that audio into readable text?
Here is a simplified look at the process.
1. Get the Audio Into the Browser
The first step is obtaining an audio signal.
There are two common sources:
- An uploaded audio file
- Live microphone input
Modern browsers provide APIs that make both possible without requiring desktop software.
Once the audio is available, it can be represented as a stream of samples that can be analyzed over time.
The important point is that at this stage the application still does not know anything about Morse code.
It only has audio.
2. Find the Morse Tone
A Morse recording may contain more than the signal we want.
There might be:
- background hiss
- voices
- electrical hum
- room noise
- recording artifacts
The decoder therefore needs to identify the frequency region containing the Morse tone.
A bandpass filter can help reduce energy outside the frequency range of interest.
Instead of analyzing every sound equally, the decoder concentrates on the part of the spectrum where the signal is expected.
This makes the next stage much more reliable.
3. Decide When the Tone Is On or Off
Once the useful frequency range has been isolated, the application needs to answer a simple question repeatedly:
Is the Morse tone currently present?
This sounds easy, but audio levels constantly fluctuate.
Using one fixed threshold can cause problems.
A quiet signal might fall below it, while background noise might occasionally rise above it.
A more useful approach is to estimate the noise level dynamically and adjust the detection threshold.
Hysteresis can also help.
Instead of using exactly the same level to switch both ON and OFF, separate thresholds can reduce rapid false switching when the signal is close to the boundary.
The result is a cleaner sequence such as:
ON
OFF
ON
OFF
ON
OFF
Now the problem is no longer primarily about audio.
It has become a timing problem.
4. Measure Tone Duration
In International Morse code, timing determines whether a signal represents a dot or a dash.
A dot is the basic timing unit.
A dash lasts roughly three dot units.
So after detecting a tone, the decoder measures how long that tone remained active.
Conceptually:
short tone -> dot
long tone -> dash
For example:
short short short
can become:
...
which represents the letter S.
And:
long long long
becomes:
---
which represents O.
But tone duration is only half of the problem.
5. Silence Contains Information Too
The gaps between signals are just as important as the beeps.
Different silence durations separate different parts of the message.
A short gap occurs between elements of the same character.
A longer gap separates letters.
An even longer gap separates words.
So the decoder also measures every OFF period.
Conceptually:
short silence -> same character
medium silence -> next character
long silence -> next word
Without this step, a stream of perfectly detected dots and dashes could still be impossible to divide into meaningful text.
6. Estimate the Sender's Speed
Real recordings are rarely produced at exactly the same speed.
One sender might transmit slowly while another sends much faster.
That means a decoder should avoid assuming that every dot has one fixed duration such as 100 milliseconds.
A better approach is to examine the timing of the detected signal and estimate the basic timing unit.
From that estimate, the decoder can classify:
- dots
- dashes
- character gaps
- word gaps
This also makes it possible to estimate the approximate sending speed in words per minute.
7. Convert the Detected Pattern Into Characters
Once the signal has been converted into dots, dashes, and spacing, the final stage becomes much easier.
The decoder can build patterns such as:
...
---
...
and look them up in an International Morse Code mapping.
That produces:
SOS
The complete pipeline therefore looks something like:
Audio
↓
Frequency filtering
↓
Tone detection
↓
Timing measurement
↓
Dot / dash classification
↓
Character separation
↓
Morse lookup
↓
Text
8. Why Real Audio Is Harder Than Generated Audio
Computer-generated Morse code usually has perfect timing and a clean tone.
Real-world recordings do not.
Possible problems include:
- background noise
- changing volume
- weak signals
- clipping
- echoes
- inconsistent keying
- multiple frequencies
- incorrect spacing
This is why decoding a typed string such as ... --- ... is much easier than decoding the same message from a noisy recording.
Signal preprocessing and adaptive thresholds can make a large difference.
9. Experimenting With It in the Browser
I built a free Audio Morse Code Decoder to experiment with this process directly in the browser.
It can work with uploaded Morse recordings or live microphone input and converts detected signals into Morse code and readable text.
The interesting part for me was that what initially looks like a simple “beeps to letters” problem quickly becomes a combination of:
- Web Audio
- frequency filtering
- threshold detection
- timing analysis
- pattern recognition
It is a nice example of how browser APIs can be used for more than conventional UI work.
Final Thoughts
Audio Morse decoding is a good reminder that the difficult part of a software problem is often not the final mapping step.
Mapping:
... -> S
is easy.
Determining that a noisy waveform actually contained three correctly spaced short tones is the interesting part.
Once the audio has been reduced to reliable timing events, the Morse translation itself becomes relatively simple.
For developers interested in Web Audio or small signal-processing projects, Morse code is a surprisingly useful system to experiment with because its rules are simple enough to understand while the real-world audio introduces plenty of interesting engineering problems.
Top comments (0)