入力データはサーバーに送信されますか?

いいえ。すべてブラウザ内で完結します。Web Audio API (`AudioContext.decodeAudioData`) で音声をローカル解析するだけで、外部 API も使いません。

ノイズの多い音声 (CW QRM 状態) でもデコードできますか?

**Otsu のしきい値法** がノイズフロア / 信号の 2 クラスを分離するので、信号がノイズより明らかに大きければ大丈夫です。ただし **CW QRM** (混信) や強いノイズで信号が埋もれている場合は誤デコードしやすい。**ヘッドホン → ハム無線 → 録音** で SNR を上げてから読ませるのがコツ。**マニュアルしきい値オーバーライド** はまだ未実装で、必要なら ToolErrorCTA 経由でリクエストください。

ドット (短点) とダッシュ (長点) はどう判定?

**ドット長 D** を on セグメントの **下位 25 パーセンタイル** から推定 (5ms 未満は click ノイズとして除外)。on セグメントが `≤ 2D` ならドット、`> 2D` ならダッシュ。off セグメントは `< 2D` がシンボル間隔 (記号内空白)、`2D 〜 5D` がレター間隔、`≥ 5D` がワード間隔。**標準のモールス比率 (ドット:ダッシュ = 1:3、レター間隔 = 3D、ワード間隔 = 7D)** に概ね沿っていますが、人間の鍵さばきの揺れを吸収するために閾値は緩めに取っています。

WPM (Words Per Minute) ってどう計算?

**WPM = 1200 / ドット長 (ms)**。これは PARIS テストワード (`PARIS` = 50 ユニット) に基づく標準的な式 (1 unit = ドット 1 つ分の時間)。例: ドット 100ms なら WPM = 12 wpm (初心者標準)、ドット 50ms なら 24 wpm (CW コンテスト中速)、ドット 33ms なら 36 wpm (上級)。

和文モールス (いろは) は対応?

**現状は国際モールス (ITU)** のみ対応。和文モールス (いろは順、44 文字 + 濁点・半濁点・長音) は文字数が多くマッピングが複雑なので、別ツール (`morse-code` で和文 ↔ テキストは対応済み) を併用するか、本ツールで `.` `-` 列だけ取り出して `morse-code` の decode モードに貼り付けてください。

音声フォーマットの対応は?

**ブラウザの `AudioContext.decodeAudioData` が読める形式すべて**: WAV / MP3 / OGG Vorbis / FLAC / WebM (Opus) / AAC など。詳細はブラウザの実装に依存しますが、Chrome / Firefox / Safari / Edge ともほぼ全ての一般的なコンテナを読めます。**読めない時** は m4a / wma などの特殊 codec の可能性、別ツール `audio-convert` で WAV に変換してから入力するのが確実。

ファイル長の上限は?

**30 MB まで**。普通の 16-bit 44.1kHz モノラル WAV で約 5 分。実際は **10-30 秒の短い練習音源** が想定されています。長尺の本物の通信録音を解析したいなら別途リクエストください (ストリーミング処理が必要)。

うまくデコードできない時の対処は?

**チェックリスト**: (1) 音声の **音量が均一** になっているか (フェードイン/アウトはしきい値を狂わせる)、(2) **背景ノイズが信号より明らかに小さい** か (SNR > 10dB 推奨)、(3) **ドット/ダッシュの比率が 1:3** 程度になっているか (人手だと崩れることが多い)、(4) **ファイル形式の問題** (WAV や FLAC は確実)。本ツールでは内部の **セグメント情報** (各 on/off の長さ) を表示するので、それを見て「実際に検出されたパターン」をデバッグできます。

SOS のサンプルとは?

国際緊急信号 `... --- ...` (3 短点 + 3 長点 + 3 短点) を 600Hz サイン波で約 5 秒間生成した SOS テスト音源です。サンプル読み込みボタンを押すと自動的にエンコードされた音声がツールに入り、デコード結果が `SOS` となるはずです。**本ツールが正しく動作しているか** の動作確認に。

音声へ戻る

モールス音声デコーダ (WAV/MP3 → ドット・ダッシュ → テキスト)

モールス信号を吹き込んだ **WAV / MP3 / OGG** オーディオファイルをアップロードすると、**音量エンベロープ検出 → 自動しきい値 (Otsu) → on/off セグメント → ドット/ダッシュ判定 → モールス文字列 → テキスト** の流れで自動デコード。**WPM (Words Per Minute) も推定**。CW (Continuous Wave) 練習音源、ハム無線の練習問題、サバイバル/CTF/教育用 SOS 信号の読解で活躍。**完全にブラウザ内** で処理 (Web Audio API)、音声ファイルはサーバーに送信されません。

音声開発

使い方

**WAV / MP3 / OGG / FLAC / WebM** などの音声ファイルをドロップすると、(1) **音量エンベロープ** を 5ms 窓の移動平均で算出、(2) **Otsu のしきい値法** で「音が鳴っているかどうか」の閾値を自動決定、(3) on / off の **連続長 (segment)** に分解、(4) on の中で **ドット = 短い / ダッシュ = 長い** を区別、off の中で **シンボル間隔 (記号内) / レター間隔 (文字間) / ワード間隔 (語間)** を区別、(5) `.` `-` ` ` ` / ` の **モールス文字列** を生成、(6) **国際モールス** (A-Z / 0-9 / 記号) で **テキストへ復号**。**WPM** (Words Per Minute) も自動推定。CW 練習 / アマチュア無線 / CTF / 教材で重宝。**Otsu 自動しきい値** はノイズフロアと信号レベルの 2 クラスを最大分離するので、レベル調整不要。

詳細解説

モールス音声が記録する通信内容の機微性

モールス符号は 19 世紀から電報・無線通信に使われてきた符号系で、傍受による情報収集 (通信諜報) の歴史と切り離せない技術でもあります。現代においても、アマチュア無線の CW 交信、CTF (Capture The Flag) の問題として出題される暗号、教育現場での実習音源などにモールス音声は使われます。復号対象の音声が実際の交信録音であれば、その内容には識別符号 (コールサイン)、交信相手の情報、やりとりのテキストが含まれます。

アマチュア無線のログや交信記録には、どの局とどのような内容の交信が行われたかが残ります。復号目的で音声ファイルをクラウドサービスに送ることは、その交信内容がサーバーに届くことを意味します。受け取った側で誰が送ったものかを特定できなくても、音声に含まれるコールサインや内容は記録されます。プライバシーの観点からは、復号処理がどこで行われるかは重要な問題です。

モールス音声をサーバーに送って復号するサービスのリスク

モールス復号に特化したオンラインサービスは少ないですが、汎用の音声解析サービスや信号デコードツールとして提供されているものがあります。音声ファイルをアップロードして復号するサービスでは、音声とともに復号されたテキスト (元の通信内容) がサーバー側で生成・記録される可能性があります。音声単体では内容が分かりにくいモールス信号も、復号されたテキストはそのまま読めるため、機密度が上がります。

CTF 問題として使われる音源は問題文の一部であり、競技参加者は問題を解く過程で他者に解答を見せたくない状況にあります。練習音源であっても、どのような符号速度・送信スタイルの音源で練習しているかという情報は、技術水準や所属コミュニティを推測させます。

Otsu しきい値 + セグメント分類がブラウザ内で完結する仕組み

このツールは `AudioContext.decodeAudioData` で音声をデコードし、5 ms 窓の移動平均で音量エンベロープを算出します。Otsu のしきい値法はヒストグラムを 2 クラス (ノイズフロア / 信号) に分割したとき、クラス間分散が最大になるしきい値を求めるアルゴリズムで、ゲインを手動で調整することなく自動的に最適な境界を決定します。on / off セグメントの長さからドット長 D を下位 25 パーセンタイルで推定し、`≤ 2D` をドット、`> 2D` をダッシュと判定します。

DevTools の Network タブを開いてファイルをドロップしても、ページロード後の音声関連リクエストはゼロです。Otsu の計算からセグメント分類、モールス文字列生成、テキスト復号までのすべての処理がブラウザのメモリ内で完結します。実装コードは GitHub で公開されており、処理のローカル完結を監査できます。

復号精度を上げるための実践的な準備

復号精度はノイズフロアと信号の分離度 (SNR) に直結します。録音前にイヤホンやスピーカーの出力から直接録音するラインキャプチャ方式を取ると、環境音の混入を防げます。フェードイン / フェードアウトが入った音源は Otsu のしきい値を狂わせることがあるため、前後に一定音量の区間があるとより安定して動作します。

和文モールス (いろは順カタカナ符号) を扱う場合は、本ツールで `.` `-` 文字列を取り出した後、morse-code ツールの和文復号モードに貼り付けると変換できます。round-trip 検証には morse-encode-audio で生成した WAV を本ツールで復号する組み合わせが確実です。WAV (無圧縮 PCM) を使うと MP3 の圧縮ノイズによるエンベロープの乱れを回避できます。

よくある質問

入力データはサーバーに送信されますか?: いいえ。すべてブラウザ内で完結します。Web Audio API (`AudioContext.decodeAudioData`) で音声をローカル解析するだけで、外部 API も使いません。
ノイズの多い音声 (CW QRM 状態) でもデコードできますか?: **Otsu のしきい値法** がノイズフロア / 信号の 2 クラスを分離するので、信号がノイズより明らかに大きければ大丈夫です。ただし **CW QRM** (混信) や強いノイズで信号が埋もれている場合は誤デコードしやすい。**ヘッドホン → ハム無線 → 録音** で SNR を上げてから読ませるのがコツ。**マニュアルしきい値オーバーライド** はまだ未実装で、必要なら ToolErrorCTA 経由でリクエストください。
ドット (短点) とダッシュ (長点) はどう判定?: **ドット長 D** を on セグメントの **下位 25 パーセンタイル** から推定 (5ms 未満は click ノイズとして除外)。on セグメントが `≤ 2D` ならドット、`> 2D` ならダッシュ。off セグメントは `< 2D` がシンボル間隔 (記号内空白)、`2D 〜 5D` がレター間隔、`≥ 5D` がワード間隔。**標準のモールス比率 (ドット:ダッシュ = 1:3、レター間隔 = 3D、ワード間隔 = 7D)** に概ね沿っていますが、人間の鍵さばきの揺れを吸収するために閾値は緩めに取っています。
WPM (Words Per Minute) ってどう計算?: **WPM = 1200 / ドット長 (ms)**。これは PARIS テストワード (`PARIS` = 50 ユニット) に基づく標準的な式 (1 unit = ドット 1 つ分の時間)。例: ドット 100ms なら WPM = 12 wpm (初心者標準)、ドット 50ms なら 24 wpm (CW コンテスト中速)、ドット 33ms なら 36 wpm (上級)。
和文モールス (いろは) は対応?: **現状は国際モールス (ITU)** のみ対応。和文モールス (いろは順、44 文字 + 濁点・半濁点・長音) は文字数が多くマッピングが複雑なので、別ツール (`morse-code` で和文 ↔ テキストは対応済み) を併用するか、本ツールで `.` `-` 列だけ取り出して `morse-code` の decode モードに貼り付けてください。
音声フォーマットの対応は?: **ブラウザの `AudioContext.decodeAudioData` が読める形式すべて**: WAV / MP3 / OGG Vorbis / FLAC / WebM (Opus) / AAC など。詳細はブラウザの実装に依存しますが、Chrome / Firefox / Safari / Edge ともほぼ全ての一般的なコンテナを読めます。**読めない時** は m4a / wma などの特殊 codec の可能性、別ツール `audio-convert` で WAV に変換してから入力するのが確実。
ファイル長の上限は?: **30 MB まで**。普通の 16-bit 44.1kHz モノラル WAV で約 5 分。実際は **10-30 秒の短い練習音源** が想定されています。長尺の本物の通信録音を解析したいなら別途リクエストください (ストリーミング処理が必要)。
うまくデコードできない時の対処は?: **チェックリスト**: (1) 音声の **音量が均一** になっているか (フェードイン/アウトはしきい値を狂わせる)、(2) **背景ノイズが信号より明らかに小さい** か (SNR > 10dB 推奨)、(3) **ドット/ダッシュの比率が 1:3** 程度になっているか (人手だと崩れることが多い)、(4) **ファイル形式の問題** (WAV や FLAC は確実)。本ツールでは内部の **セグメント情報** (各 on/off の長さ) を表示するので、それを見て「実際に検出されたパターン」をデバッグできます。
SOS のサンプルとは?: 国際緊急信号 `... --- ...` (3 短点 + 3 長点 + 3 短点) を 600Hz サイン波で約 5 秒間生成した SOS テスト音源です。サンプル読み込みボタンを押すと自動的にエンコードされた音声がツールに入り、デコード結果が `SOS` となるはずです。**本ツールが正しく動作しているか** の動作確認に。

「送らない」を確かめるには

このツールは入力データを外部に送信しません。仕組み・監査手順・運営方針は以下で詳しく説明しています。

類似のツール

モールス音声エンコーダ — テキスト → 欧文・和文モールス WAV/MP3 (CW)

**テキスト** を **モールス符号 (CW)** の **音声 (WAV / MP3)** に変換します。**欧文 (ITU-R M.1677)** と **和文 (いろは)** の両方に対応。**WPM** (5-50)、**周波数** (300-1500 Hz)、**音量**、**サンプルレート** (8 / 22.05 / 44.1 / 48 kHz) を調整可能。**Farnsworth タイミング** (文字 WPM と実効 WPM を分離して文字間ギャップだけ伸ばす CW 学習用) も実装。**プレビュー再生** で in-browser に確認 → WAV (16-bit PCM mono) / MP3 (lamejs) でダウンロード。**morse-decode-audio** に流して符号化が正しいか相互検証可能。CW 練習音源の自作、CTF 問題作成、アマチュア無線局識別子のテスト送出、レトロ電信教材に。**完全にブラウザ内** で合成、入力テキストはサーバーに送信されません。

音声開発

モールス信号変換

テキストとモールス信号を相互変換します。Mode 切替で「文字 → モールス」「モールス → 文字」を選び、文字セットは欧文 (ITU 国際モールス: A-Z / 0-9 / 記号) と和文 (いろは / カタカナ・濁点・半濁点・長音) を切り替え可能。符号間は半角スペース、語間は ' / ' で区切ります。和文は濁点・半濁点を Unicode 正規化 (NFD/NFC) で正しく分解・合成。すべてブラウザ内で処理され、入力テキストはサーバーに送信されません。

開発変換エンコードデコード

音声主音検出 (チューナー) — FFT autocorrelation で音名 + cents ズレを表示

音声ファイルをドロップすると、ブラウザ内で **autocorrelation (自己相関) ベースのピッチ検出** を実行し、主音 (fundamental frequency) を **音名 (例: A4 / F#4)** と **cents 単位のズレ** に変換して表示します。**ギター / ベース / ボーカル / 笛 / ホイッスル** の楽器チューナー代わりに、録音した A 音 + 12 セント等を即座に確認できます。さらに **時間軸での主音遷移グラフ** を CSV 出力できるので、ボイスメモのピッチ追従 (intonation 練習) や、シンセサイザーで作った 1 トーンのチューニング微調整に。autocorrelation は短いトーン (50ms+) で高精度、複合音 (和音 / コーラス) は誤検出することがあります。`tone-generate` (任意の周波数のトーンを生成) の対称ツールで、本ツールは **既存音声 → 音名検出** に特化。`audio-spectrum` (周波数分布の可視化) とは異なり、主音 1 つに絞った出力。音声はサーバーに送信されません。

音声

音声スペクトラム解析 — 周波数成分を可視化

音声ファイル (MP3 / WAV / M4A / FLAC / OGG / Opus) をドロップすると、ブラウザ内で FFT 解析を行い周波数スペクトルを可視化します。Mode 切替で、全体の平均スペクトル (周波数 vs 振幅) と、時間軸付きのスペクトログラム (時間 × 周波数 × 振幅) を切り替え可能。FFT サイズ (512 / 1024 / 2048 / 4096) と周波数軸 (Linear / Log) を選べます。マスタリング前のローエンド確認、ノイズ帯域の特定、楽器の倍音構成のチェック、講義音声の S/N 確認などに。Canvas を PNG ダウンロード、平均スペクトルは CSV エクスポート対応。音声はすべてブラウザ内で処理され、サーバーには送信されません。

音声抽出