Audio ノイズゲート — threshold 以下を無音化、しゃべりとしゃべりの間のサーノイズを除去

ノイズゲートをかける音声が持つ生活・業務文脈

ノイズゲートの用途を具体的に挙げると、ポッドキャスト収録の空調ノイズ除去、ゲーム実況配信のマイクハム音カット、会議録音のキーボード打鍵音抑制、ボーカル録音の息継ぎ処理、インタビュー音声のバックグラウンド雑音削除、などが代表的です。いずれも、音声の中にある発話の内容そのものが制作物や記録の核心です。

ノイズゲートは「小さい音を消す」処理ですが、消す前の音声ファイルは発話のすべてを含んでいます。これを外部サービスにアップロードして処理させると、目的は「ノイズを消すこと」でも、実際には「会話や収録内容をサーバーに渡す」という結果になります。

配信音声・業務録音をクラウドで処理するリスク

音声処理サービスのビジネスモデルには、無料で処理を提供しながらアップロードデータを活用するものがあります。会議録音やポッドキャスト原稿、ゲーム配信の事前テスト音声は、商業的な価値や機密性を持つことがあります。パラメータを変えるたびに再処理を依頼する操作感は、そのつど音声を送信しているという実感を薄れさせます。

個人レベルでも、声は生体的な識別情報です。録音の内容が機微でなくても、音声が誰のものであるかはデータとして残ります。近年の声紋認識・音声合成技術の進歩を考えると、不必要な声データの外部送信は、数年前より大きなリスクを持つようになっています。

Web Audio API のサンプルレベル処理がブラウザ内だけで動く

このツールは Web Audio API の decodeAudioData で音声をデコードし、threshold / attack / hold / release の各パラメータで定義されたゲートロジックをサンプル単位で実行します。具体的には、各サンプルの RMS を計算してゲート状態 (open / closed) を決定し、attack / release の傾きで滑らかに遷移させ、reduction の値だけ音量を下げることで「完全無音」ではなく「ソフトゲート」の再現も可能にしています。この処理全体がブラウザのメモリ内で完結します。

DevTools の Network タブを開きながらパラメータを変えて再処理を何度行っても、音声関連のリクエストは発生しません。実装コードは GitHub で公開されており、ゲートロジックの状態遷移を含めて確認できます。

ゲート処理の前後でするべき確認と組み合わせ

ノイズゲートは「threshold より小さい音を消す」処理なので、threshold の設定が重要です。ノイズフロアより 3〜6 dB 高い値に設定すると、声が入っていない区間だけが消えます。audio-loudness-lufs でノイズフロアの dB を事前に計測しておくと、threshold 設定の根拠が数値で出ます。先頭末尾の無音だけ消したい場合は audio-trim-silence のほうがクリーンに処理できます。

ノイズゲートと audio-compressor の組み合わせは、配信・ポッドキャスト音声の定番仕上げです。ゲート → コンプの順にかけると、ノイズが消えた上で声の音量ムラも均一化されます。最終的な音量確認は audio-loudness-lufs と audio-true-peak でブラウザ内チェックを。

エンベロープ追従と Threshold / Attack / Hold / Release の関係

ノイズゲートの中身は、入力信号のレベルを追跡する エンベロープフォロワー と、それを threshold と比較してゲインを 1.0 (open) か reduction (closed) に切り替える状態機械の組み合わせです。本ツールはサンプルごとに |sample| (絶対値) または短い RMS 窓 (~5 ms) でレベルを推定し、attack (open → 目標ゲイン到達までの時間、0〜100 ms) と release (closed → 目標ゲイン到達までの時間、10〜500 ms) のエクスポネンシャル係数 exp(-1 / (sampleRate · attackTime)) でゲインを滑らかに補間します。hold (0〜500 ms) は信号がしきい値を下回ってもすぐにゲートを閉じない待機時間で、これがないと発話の途中の小さな間 (ブレス間や子音の谷) で頻繁にゲートが開閉して「チャタリング」と呼ばれる不自然な切れが発生します。

reduction パラメータの -100 dB は完全無音を意味し、-20 dB は「小さく残す」設定で、ナレーションや会話の自然な間を保ちながらノイズを目立たなくします。シネマ的な音響では完全無音は不自然に感じられることが多く、室内のごく薄い暗騒音 (room tone) を残す目的で -15〜-20 dB の reduction が好まれます。エンベロープ追従の単位は典型的に RMS (連続音の知覚に近い) か Peak (瞬間的なトランジェントに反応する) で、本ツールは絶対値ベースに近い Peak-like 検出を採用しています。これによりキーボード打鍵音 (1〜2 ms の鋭いトランジェント) も適切にゲートで処理できます。

用途別の設定パターンとサイドチェイン的応用

ポッドキャスト・ナレーションでは threshold = -45〜-35 dB / attack = 5〜10 ms / hold = 100〜200 ms / release = 150〜300 ms / reduction = -20 dB が一般的な出発点です。発話のダイナミクスを保ちながら、空調・ファン・キーボード音を -20 dB 程度に抑える設定です。ゲーム配信のマイク処理では threshold = -50 dB / attack = 2 ms / release = 80 ms のような速い設定で、メカニカルキーボードの打鍵音を即座にカットします。ボーカル録音では、子音 (s, t, k) のアタックを潰さないように attack = 1〜3 ms の極短設定を選びます。

audio-compressor との組み合わせ順序は gate → compressor が原則で、コンプレッサーが小さい音 (=ノイズフロア) を持ち上げる前にノイズを消しておく必要があります。逆順だとノイズもコンプで持ち上げられて、SN 比が悪化します。サイドチェイン応用としては、ダッキング (BGM をナレーションに合わせて自動で下げる) のような効果も理論的には可能ですが、本ツールは内部信号 (self-keyed) のみをサポートし、外部キー入力には対応しません。落とし穴として、(a) threshold をノイズフロアより下に設定するとノイズが除去されない、(b) 上に設定しすぎると小声や子音の谷が消える、(c) release が短すぎるとゲート開閉が聴感に出る、(d) ステレオ素材では L/R を独立にゲート処理すると位相がずれて mono 互換性が悪化する (本ツールは L/R 同期処理を採用)、などがあります。配信前は audio-loudness-lufs でラウドネス、audio-true-peak で True Peak を確認してから書き出すのが標準的なワークフローです。