DEV Community

Kalana Wanniarachchi
Kalana Wanniarachchi

Posted on Originally published at morsecodecreator.org

How Browser-Based Morse Audio Decoding Works: From Beeps to Text

 Converting written Morse code into text is relatively straightforward.

If the input is:

... --- ...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

short short short
Enter fullscreen mode Exit fullscreen mode

can become:

...
Enter fullscreen mode Exit fullscreen mode

which represents the letter S.

And:

long long long
Enter fullscreen mode Exit fullscreen mode

becomes:

---
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

...
---
...
Enter fullscreen mode Exit fullscreen mode

and look them up in an International Morse Code mapping.

That produces:

SOS
Enter fullscreen mode Exit fullscreen mode

The complete pipeline therefore looks something like:

Audio
  ↓
Frequency filtering
  ↓
Tone detection
  ↓
Timing measurement
  ↓
Dot / dash classification
  ↓
Character separation
  ↓
Morse lookup
  ↓
Text
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)