WavPlayer-簡単な方法を探しているのではなく、それらを舗装しています

ご存じのとおり、電話には音声伝送が含まれます。 音声伝送に20Hz〜20kHzの全帯域幅を必要とする人はいません;はっきりと識別可能で認識可能な音声には最大3.5kHzで十分です。 より正確には、電話で使用される音声周波数帯域は300〜3400 Hzです。 帯域幅は4 kHzであるため、正確な割り当てのために共通チャネルに圧縮する場合、エッジに沿った保護周波数間隔が必要です。 デジタル化すると、8kHzになります。 現在、通信チャネルの厚さの開発により、同じスカイプなど、「向上した」品質を誇る16kHzまたは32kHzを使用しますが、通常の会話では実際には聞こえません（ただし、劣化した場合は非常にはっきりと見えます）通信チャネルの品質ですが、マーケティング担当者が心配した場合）。



そのため、電話で使用されるほとんどすべてのサウンドファイルは、8kHzのデジタル化で記録されます。 大きなフローの処理を高速化するために、使用される圧縮方法は単純で、目的の音声圧縮に適用した場合に適切な結果を目指しています。 これは、単純なデジタル化（ PCM ）、単純なデルタコーデック（ADPCM、 G711 ）、またはトリッキーなコーデック（ GSM 06.10 ）です。 これらの形式は、テレフォニーシステムの「ネイティブ」です-アスタリスク、フリースイッチ（およびおそらく他のもの）。 これらのフォーマットでは、システムが人々にプレイするためのデータが準備され、システムの同じフォーマットで記録を記録できます。



しかし、現在、ウェブは地球上でますます拡大しており、人々はウェブ上の会話や挨拶などの録音を聞きたいと思っています。mp3は「ネイティブ」フォーマットになりました...



結果として、まれな「アーカイブを聞く」機能の単純な解決策は、録音を電話形式からMP3にトランスコードするようにサーバーを構成することです。



すべてがうまくいきますが、：

• mp3録音では、より大きくまたはより悪くなります。
• mp3へのトランスコーディングには、サーバーCPUの負荷が必要です。
• トランスコードは事実上で発生し、オンザフライでは発生しません（ただし、これに対する治療法もあります）。
• トランスコードされたファイルは、基本的にクライアントにのみ必要です。

この不名誉を見て、エンジニアの魂は病気になり、うまくやるように要求し始めました。 そして、それは「悪いことをするのではなく、それがどうだったか」ではなく、つまり、それは良いことであり、簡単です。 では、なぜ高価なMP3エンコード操作を実行し、このデコーダーが既に存在するという理由だけで、クライアントで高価なMP3デコード操作を実行するのでしょうか。 クライアントでこの最も単純なデコーダーを作成してみましょう。



これらの既製のデコーダーがないことに特に驚きました。 これがWavPlayerの誕生方法です。電話ファイル用のフラッシュプレーヤーです。



彼にできること：

• レコードにジャンプするためのストリップ付きのGUI、それなしのGUI、通常はUIなし
• JS側でインターフェース全体を管理およびレンダリングするためのAPI
• コーデックサポート：PCM、G.711u / a、GSM 06.10、IMA ADPCM
• フォーマットのサポート：AU、WAV、いくつかの標準RAW

そして最近、ユーザーは標準のMP3プレーヤーにプロキシを追加し、WavPlayerのみを使用してネイティブアーカイブとトランスコードアーカイブの両方を再生できるようにしました。 （当初は、Flash-mp3プレーヤー、html5、またはWavPlayerを使用することがJS側の関心事であると仮定して、これを行いませんでした）。



各コーデックとフォーマットの説明を読む人は誰でも、プレーヤーが渋滞のように単純であることを理解するでしょう。 しかし、もしそうなら、それは長い間存在していたでしょう...したがって、私は簡単にその創造の物語を語ります。



当初、フラッシュでサウンドを再生するのは、mp3インサートの再生のみでした。 それだけです これ以上。 10番目のバージョンから、sampleDataイベントがflash.media.Soundのインターフェイスに登場しました。これにより、生成されたサウンドを生成および再生できます。 しかし、フラッシュにふさわしいので、彼は独自の方法でのみそれを行います。44kHzのみ、ステレオのみ、32ビット浮動小数点数のみです。



そして、8kHz / 16kHzの整数があります。 ソースデータを取得し、そのままの状態で提供するだけの場合、読み取りが不十分で頻度が非常に高くなります。 結論は？ 私たちが持っているサンプルを補間する必要があります-言い換えれば、リサンプルします。



リサンプリングするとき、周波数を単純に2倍にしても、2つのサンプルの間に「平均」数を取り込んで挿入することはできないことを理解することが重要です。 正しいリサンプリングは、元の滑らかな音を復元し（2次導関数を最小化）、目的の周波数で再デジタル化することにより得られます。 このようにして、適切なサンプルレートで適切な滑らかなサウンドを取得します。



私はもちろん理論を知っていますが、実際には非常に怠け者であり、タスクは「レコードを再生する」ことを非常に鋭くすることでしたので、迅速に解決する必要がありました。 私は知らないフラッシュ、およびLinuxで動作するマシン。 フラッシュコンパイラのサイズを確認しました。100メートルで壊れてしまったため、フラッシュにすばやく簡単に描画するための代替手段を見つけることにしました。 クイックグーグルは、すばらしいオプション-HaXeを提供しました 。 シンプルなC / javaのような言語で、必要なプラットフォーム（フラッシュ）を含む複数のターゲットプラットフォームに翻訳できます。 彼は連れて行かれました。



一般に、 最初の作業レイアウトは急いでスクランブルされました。



oggファイルが手動でデコードされるfoggプロジェクトがありました。 そこから、プルの代わりにプッシュインターフェイスを実装するAudioSinkが取得されました。書き込み先のバッファーで、フラッシュが次のデータを必要とする場合、AudioSinkはバッファーからデータを送信します。 最も最適で美しい実装ではありませんが、既製です。 リサンプラーとして、OpenJDKのLanczosリサンプラー実装（sinc関数に基づいた最高品質）が採用されました。 コードは最適ではありません（後で純粋なアクションスクリプトに実装されました-ほぼ4倍高速化できました）が、動作します（他に何も必要ありませんでした）。

インターフェースはシンプルです。三角形が描かれている場合は描画します。 クリックすると、play（）が起動し、正方形が描かれます。 クリックすると、2本の垂直スティックが描かれます。

G711のデコードでは、コードはSoxから取得されました。PCMの場合、コードはそれ自体で生成されました。



そしてもちろん、このTyrocodeのバレルへのOOPスプーン：FileおよびDecoderインターフェースは、メインプレイヤーが特定のバリエーションから抽象化できるようにします。 確かに、インターフェースは体系的にではなく、必然的に生まれましたが、いつ違いましたか？ ファイルは次のように機能します-ファイルの入力データが読み取られ、プッシュ（）メソッドを介してデコーダーに押し込まれます。 すべてのヘッダーが読み取られるとすぐに、ファイルは適切な形式のデコーダーを内部に作成し、オーディオデータをそこに詰め込み始めます。 ready（）メソッドはtrueを返し始め、それ以降、他のすべてのストリームメタデータメソッドも有効になります。getSamples（）リクエストを使用してオーディオストリームデータを読み取ることができます。これは、samplesAvailable（）サンプルを返します。



デコーダーの操作も簡単です。サンプルのサイズをバイト単位で伝達し、ファイルを必要なパケットに分割してデコーダーに入力できるようにします。 デコーダーは、バッファーデータを1つのサンプル（符号付き浮動小数点数）に順次変換します。



発生する主な問題は、サンプラーの適切な供給です。 リサンプラーは仮想ダブル変換の原理で動作することを思い出してください-入力サンプリング周波数の入力データに基づいて、滑らかな信号が復元され、出力周波数で再デジタル化されます。 信号を復元するには、常に信号が必要です。 そのため、最初に初期化のために、デコーダに希望する長さの無音を供給する必要があります。 そして、最初の答えからこの沈黙を捨ててください。そうすれば、最初から正しいリサンプリングが得られます。 同様に、データが終了した後、復元されたすべての情報を取得するために、リサンプラーに無音が供給される必要があります。



そして、このようなマッカーを使用して、兵士の会社は正しい形式で44 kHzで必要なデータ量を正確に生成します。



ベースプレーヤーが動作し始めた後、少しくし状になり始めました。まず、より複雑なコーデック、特にgsmのサポート。 すべてがサンプルごとにデコードされるわけではなく、ここでバッチ処理が必要であることがすぐに明らかになりました。そのため、デコーダーインターフェイスは入力配列+オフセット、出力配列+オフセット用にやり直され、出力に配置されたサンプル数を返します。 Rawファイルをサポートするために、コードの大部分は汎用であり、別の一般クラスに移動されたため、最小値-初期化子の必須パラメーターのみがオーバーライドされました。 GSMデコーダー自体は、検出された場所で通常どおりに使用され、目的の構文にすばやく変換されました。 奇妙なことに、それはすべて強打で動作しました。



同時に、プレーヤーコントロールインターフェイスはJSコードから描画され、ロード、再生、一時停止のイベントが発行されたため、ブラウザーでプレーヤーの状態を必要に応じて描画できます。 結果として得られる製品は、生産で製材され始めました。 彼らがテストを始めたとき、いくつかの問題が出ました。特に、非常に愛されているIEでは、断片的にロードされたファイルは8kまたは4kのようです...一般的に、大量のイベントが生成されたので、それらの生成の頻度を削減する必要がありました。



残念ながら、誰もJSにインターフェースを作成したいとは思わないことがすぐに明らかになりました。 その後、すぐに決定が下され、内側からグアがひざまで深く投げました。 プレーヤーは内部イベントを生成し始め、WavPlayerGuiが作成されました。 彼のミニ相続人は以前のままです-すべてのボタン。 さらに、左側に同じボタンがあり、右側にプログレスバーがあり、長さ、ロードされたボリューム、現在の位置が表示されます。 さて、それは、イベントに応じてサイズが変化した、もう少し正方形の断片です。



これが現れるとすぐに、一般的にそれもチェックする必要があることが明らかになりました。 とにかく、15分から3分を聞く必要がある場合にのみ、録音を聞くことは完全に愚かです...シーク（）を行う必要があります。 この場合のseek（）の実装は最も困難なタスクであることが判明しました。ソースファイルを任意の位置からダウンロードできないため（サーバーからRangeサポートを保証できず、フラッシュでこれを行うのはそれほど簡単ではありません）、seekの可能性を制限する必要がありました（ ） 'ただし、ロードされたパーツ内のみ。 ただし、この場合でも、44 kHzにトランスコードされたデータ（メモリ、泣き言、申し訳ありません）の全量は保存されないため、再配置する必要がある場合は、次のようになります。

• seek（）が既製の44kHzデータの制限内に収まるかどうかを確認します。その場合、準備されたデータを使用して単純なデータを作成します。
• 出ている場合は、元のストリームの観点から再生を開始するサンプルを探します
• 再初期化された無音リサンプラ、
• 入力ストリームは目的の位置に再配置され、
• 再生を開始します。

その後、一般にそれを使用し始めた人からいくつかの化粧品の修正がありました、そして再び挑戦がありました-IMA ADPCMサポートを作ることは可能ですか？ このフォーマットは、普遍的であるという観点からはかなり嫌です。データはチャネルごとではなく、同じ場所で混同されるため、デコードされたチャネルをデコーダに送信する必要がありました。 同時に、他のすべてのコーデックに対して少し普遍性を持たなければなりませんでした。出力データの量は、他のすべてのコーデックの入力に応じて固定され、シンプルだからです。 そしてここで...一般に、それは依存します-明確なストーリーが必要であり、任意の場所からデコードを開始することはできません。 したがって、seek（）の場合、関数は次のように機能します。

• seek（）が既製の44kHzデータの制限内に収まるかどうかを確認します-そうであれば、準備されたデータを使用してsicを作成します
• 出ている場合は、元のストリームの観点から再生を開始するサンプルを探します
• デコードを開始できるサンプルを探しています
• 再初期化された無音リサンプラ、
• 入力ストリームはデコード位置に再配置されます
• 再生を開始する位置にデコードしてスローする
• 再生を開始します。

一般に、奇妙なことに、これも機能します。 そして現時点では、すべての人が使用できます。必要なものを正確に、必要な方法で実行します。

完全なスリルのために、私たちのWeb開発者がやろうと思っていたJSのまさにまさにインターフェースを、とにかく作り上げることだけが残っています。 さらに、シンプルでわかりやすい統合例を作成して、サイトにコピーアンドペーストすることができます。ほとんどの場合、この統合の問題はプログラマではなくシステム管理者の肩にかかっているためです。



Githubのプロジェクト | オンラインデモ。