HTML5オーディオ-ステータス。 パート2

（2012年5月8日付のフロントエンドおよびメディアタグの専門家であるMark Boasによる記事。最終パートの翻訳。最初は、キッチン全体をマスターする前に汗をかかなければならないことが明らかになりましたが、これはまだ開発中です...短いレシピを待ってはいけません。）

最初の部分の内容：
■MIMEタイプ
● サーバー部分
● クライアント部分
■音声の種類を事前に知ることは、.canPlayTypeに役立ちます （おそらく）
■ブラウザでの現在のコーデックサポート
■コンテナ形式とファイル拡張子
■ <audio>タグがあり、使用することを恐れていません！
■バッファリング、検索、および再生間隔
● バッファリングされた属性
● TimeRangesオブジェクト
● シークおよびシーク可能な属性

● シークおよびシーク可能な属性

メディアファイルのコンテキストでの検索は、メディアファイルの前方または後方を探しています。 これは通常、完全なファイルバッファリングがまだ完了していない場合に発生します。 シーク属性は、「 シーク 」イベントが発生したことを示すために使用されます。 trueは、ファイルの一部がまだアップロードされていないことを意味します。

おもしろい ： Safari / Windowsを除くすべての最新のブラウザーには、 シーク可能な属性があります。つまり、 シークイベントは発生しないため、ユーザーはプログラムの目的の部分に直接アクセスできます。 シークされたイベントは発生せず、「 シーク== true 」は常にシークされたイベントの前にあるべきだと考える人を困らせます。

バッファリングされたプロパティは、どの部分がロードされたかを示すことを思い出してください。これは、再生準備の指標としてよく使用されます。 ブラウザがサポートしている場合、 seekable属性を使用して、ファイルのどの部分をアップロードするかを決定するのが理にかなっています。

seekableはTimeRangesオブジェクトを返します-すぐに再生する準備ができている間隔です。 「byte-range-requests」と呼ばれるテクノロジーを使用します。これにより、HTTPリクエストの最後に厳密にではなく、リクエストがまだある間に、データの一部をリクエストすることができます。 つまり、メディアの再生を開始するためにすべてのデータを用意する必要はありません。 例：

var isSeeking = audio.seeking; //     ""? //   seekable, ,    "" var isSeekable = audio.seekable && audio.seekable.length > 0; //   ,       var seekableEnd = audio.seekable.end(); 

注 ： 間隔は誤解を招く可能性があります。 audio.seekable.end（）は、実際には、メディアファイル全体のエンドポイントではなく、最後の間隔のエンドポイントを示します。 ただし、実際には、ブラウザは多くのリクエストを送信するかしないかのいずれかなので、これで十分です。 リクエストがなかったことが判明した場合、 audio.seekableはaudio.bufferedと同等になり 、ファイル内の間隔の終了を正確に示します。

シーク可能な状態の再生セクションは、 バッファリングされた状態の再生セクションとは異なることに注意してください。 両方を同時に使用することはできません。

おかしい ： 実際には、 seekableプロパティに作成されるTimeRangesオブジェクトは1つだけです。 間隔要求をサポートするブラウザーでは、 TimeRangesオブジェクトは再生時間のゼロから終わりまで拡張され、サポートされていないものでは、 TimeRangesはロード時にゼロから終わりまで増加します。

バッファリングとデータ検索は有用な情報を提供できますが、数ポイントでなければ簡単すぎるでしょう。

1.適度に古いブラウザー（Opera 10 / Firefox 3.6）では、プリロードはサポートされていません。
2. バッファリングされた属性は常にサポートされているわけではありません（Blackberry PlayBook）。
3.すべてのHTML5ブラウザーがバイト範囲検索をサポートしているわけではありません（Safari / Windowsなど）。 この場合、Flashと同様に、ロードされたコンテンツの検索が残ります。

ユーザーに最適なソリューションを提供したい場合は、固有の機能をテストしてください。

●プリロードに関する注意

前の記事でpreload属性について言及しました。 次の3つの値を取ります。
1. none-何もプリロードしません。 プレイイベントを待ってから、何かをダウンロードします。
2. メタデータ - メタデータのみをプリロードします。 間隔要求を介してファイルの開始と終了を取得し、再生の継続時間を決定します。
3. auto-ファイル全体をプリロードします。 ファイルの先頭と末尾を取得し、ファイルの先頭からダウンロードを再開します。

おかしい ： モバイルSafariはプリロード属性を無視します。これは常に「 なし 」です。

プリロードに関しては、これはプリロードプロセスをどのように見たいかについてのブラウザへのリクエストまたは要望であることを忘れないでください。 ブラウザは実装する必要がないため、さまざまな方法で動作できます。

●成功しました

間隔が完全に再現されたかどうかを報告するプレイプロパティがあることに注意してください。

 var played = audio.played; //   TimeRanges 

注 ： すべてのaudio.played間隔を要約すると、 リッスンされたオーディオの割合が得られます。これは、メトリックを収集するのに役立ちます。

■メディアイベント

オーディオおよびビデオインターフェイスAPIは、イベントの完全なセットに基づいています。 完全なリストは仕様のWhatWGバージョンで利用可能です。

メディアイベントハンドラをインストールすると、コントロールのステータスの変化を簡単に追跡できます。 たとえば、各timeupdateイベントの再生時間の表示を更新するのに役立ちます。

一般的に使用されるイベントの短いリスト：

イベント	説明
durationchange	期間属性が更新されました
終わった	再生が終了すると停止しました
一時停止	再生が停止されました（ 停止イベントがないことに注意してください）
遊ぶ	ファイルの再生が開始されました
timeupdate	現在の再生位置が変更されました（通常は250ミリ秒ごと）
体積変化	値が変更されました

ヒント ： Android（少なくとも2.3）は常に終了イベントを発生させるわけではありません。 まあ、それは時々良識のために1つを作成すると言いましょうが、一般的に、メディアファイルの終わりに達したときに一時停止イベントをキャプチャし、 audio.currentTimeとaudio.durationを比較することにより、独自のイベントを作成する必要があります。 または、 一時停止イベントを乾燥させて、 audio.currentTimeがゼロであることを確認できます。 確実に確認するには、両方を行う必要があります。

その他のイベント：

イベント	説明
遊べる	ファイルは再生できますが、ロードに時間がかかる場合があります。
canplaythrough	既存のダウンロードレートでは、ファイルは最初から最後まで中断なく再生できると想定されています。
進捗	ブラウザに再生ステータスが表示されます（通常は250ミリ秒ごと）

ここでも、 HTML5 Media Event Inspectorは使いやすいです。

areweplayingyet.orgでブラウザのサポートをテストできます。 コードとテストを見て、何が起こっているのかを理解する価値があります。

■ストリーミング

ストリーミングオーディオは、メディアコントロールの一般的な要件です。 最近まで、Adobe Flashテクノロジーがこの分野を支配していました。 独自のサーバー技術はよく知られています。 主要なものの1つは、Adobeのリアルタイムメッセージングプロトコル（ RTMP ）です。 ただし、最新のブラウザはHTTPプロトコルでのストリーミングのみをサポートしており、フラッシュに似たものにはRTMPストリームが必要です。

現在、ブラウザは、サポートしている場合は、HTTPを介してオーディオを再生するSHOUTcastおよびIcecastサーバーのみをサポートします。 SHOUTcastはプロプライエタリであり、MP3およびAACファイルのみを再生します。Icecastはオープンであり、Ogg Vorbis、MP3およびAACをサポートします。

流れ	Aac	MP3	GG vorbis	ネイティブサポート
アイスキャスト	はい	はい	はい	はい
シャウトキャスト	はい	はい	いや	はい
RTMP	はい	はい	いや	いいえ（Flashが必要）

■仕様の進化（または「Tee Divi！It's Crashing！」）

オーディオ仕様が進化するにつれて、ブラウザの実装にはいくつかの矛盾があり、留意する価値があります。 通常、古いブラウザに表示されます。

●ロード方法

最近まで、 loadメソッドはブラウザにメディアファイルの変更を通知し、コントロールを変更しました。 これで、アイテムがリセットされ、新しいリソースの取得と読み込みがゼロから開始されます。

したがって、Firefox 3.6などの古いブラウザーでは、情報のソースを変更するには、メソッドの値を変更するだけでなく、コマンドも実行する必要があります。

 var audio = new Audio(); audio.setAttribute("src","mynew.mp3"); audio.load(); //     

●ブラウザはいつ公式ドキュメントに戻りますか？

クロスブラウザソリューションの場合、どのブラウザがW3Cドキュメントをサポートしているか、どの程度、どのようにそれから逸脱しているかを知ることは有用です。

●自動再生と音量

iOSとBlackberryは自動再生属性とボリュームコントロールメディア要素を無視しますが、Androidは自動再生をサポートしていますが、ボリューム要素はありません。

実際、BlackberryとIOSでは、自動実行は無効になっています。これは、両方のシステムがそれらを「蹴る」ためのユーザー許可を必要とするためです。 これは不幸な副作用です。オーディオの再生には、必要な対話性の遅延が発生します。

これらの不便さを軽減するために、iOSでのオーディオスプライトの修正に関するRemy Sharp博士の優れた記事を読むことができます 。

●複数のオーディオタグの同時再生

特に、すべての開発者（特にゲーム）を悩ませています。ただし、最も単純なアプリケーションを除き、一部のブラウザー（ここでもiOSとBlackBerryを参照）が複数のトラックを同時に再生できないことを除きます。

●OS依存

ヒント ： 開発者によるこのメソッドの使用は制限されていますが、Ogg Vorbisなど、OSに組み込まれていない他のコーデックをインストールできます。オペレーティングシステムのコーデックを使用するブラウザーは、それらのサポートを開始する必要があります。

Safari（5+）はQuicktime設定に依存しています 。 Windowsを使用している場合、これが問題になることはほとんどありません。

Internet Explorer（9+）は、オペレーティングシステムのコーデックを使用します。 幸いなことにWindowsでしか機能しないため、ほとんどの場合これが当てはまります。

■新機能

Webオーディオ用にいくつかの新機能と新しいAPIが明らかにされているので、近い将来を見てみましょう。

●ステップ変更

いくつかの将来の関数、 playbackRateとdefaultPlaybackRateに注意してください。 これらは、再生の速度と方向を変更します-機能を早送りおよび巻き戻しするか、またはユーザーがリスニング速度を調整して1日あたりのポッドキャストをより多く聞くことができるようにします。

● audio.playbackRateは通常の速度で1を返し、速度乗数として機能します。 たとえば、 playbackRate 2を設定すると速度が2倍になり、-1に設定するとゲームは反対方向に再生されます。
● audio.defaultPlaybackRate-この種類の一時停止、再起動、またはイベント後のデフォルトのメディア速度。

●メディアフラグメント

ここでメディアファイルの一部を参照したい場合、ほとんどの場合、実際には不要なファイルの少なくとも一部をダウンロードする必要があります。 メディアフラグメントに対するW3Cのオファーは、この質問やその他の問題を解決するために作成されました。たとえば、ビデオエリアやトラックの単純に関連するテキスト（オーディオタグ、ラベル）を検索します。 オーディオの場合、URIパラメーターを使用して、どの部分をロードするかを判断できます。

■高度なオーディオAPI：ブラウザの将来のサウンド

高度なオーディオに関しては、Mozillaは最初に実験的なFirefox用のAudio Data APIを導入しました。 これは、JavaScriptでオーディオを操作し、低レベル開発用のプラットフォームを作成するのに役立ちます。

追いつくために、GoogleはChrome用のWeb Audio APIをリリースし、W3Cの提案として提案しました。 Web Audio APIは、オーディオオブジェクトをオーディオノードとして使用する高度な実装であり、多くの便利な機能を提供します。

どちらの実装も、開発者がオーディオをもっと活用したいという要望を反映しています-オーディオをその場で作成、管理、分析、ミックスします。 実際、ある日、ネイティブOSアプリケーションでしかできないことをブラウザーでできるようになるかもしれません。

それでは、ブラウザで高度なオーディオを使用したいのでしょうか？ さて、2つの別個の実装が既に存在します。 APIに基づいてアプリケーションを作成する場合は、違いを抽象化するためにサードパーティのクロスライブラリを作成する必要があります。

かなり新しいMozilla MediaStream処理APIが登場しました 。これは、高レベルと低レベルの両方でオーディオストリームとビデオストリームを制御する機能を持つ異なるアプローチを使用しています。

実際、最新のAPIを使用し、最新のJavaScriptエンジンの速度を使用して、サポートされていないコーデックのデコーダーを作成することもできます。 現在、 JSMad MP3デコーダーとAlac.jsロスレスデコーダーがあります。 どうやらFLACとAACがストリームに含まれているようです。 将来、ブラウザ形式のサポートについて心配する必要はないという希望があります。

現代のインターネットオーディオに興味がある人のために、「 HTML5 Audio API：How Low Can Go？ 」という記事で、クロスブラウザソリューションのアプローチとライブラリの違いについて書きました。

良いニュースは、当事者が同意していることです。 オーディオに関するW3Cワーキンググループでのコミュニケーションがあります 。 すべてが、 単一のオーディオAPIのアイデアの実現に向かって動いているようです。これは、Web標準という形での出版に急速に近づいています。

■おわりに

現在のHTML5オーディオ仕様のブラウザ実装は改善されていますが、完全なクロスブラウザソリューションの作成を妨げるいくつかの問題がまだあります。 ブラウザやiOSなどのプラットフォームの制限を知る必要があります。 問題がなくなることを願っています。

「高度なオーディオ」の前から良いニュースがあります。 新しい標準が作成されており、ブラウザ作成者の作業のために単一の仕様を取得するところです。 同時に、既存の実装間のギャップを埋めるのに役立つJavaScriptライブラリがあります。

さまざまなブラウザーのコーデックへの依存関係の終わりを確認できる兆候があります。 Opera MobileはすでにOSがサポートしているMP3形式をサポートしており、 Mozillaでも対応できるようです。 これがモバイルブラウザで可能であれば、ほとんどのデスクトップブラウザがそれに続きます。

多くが変化しており、すでに多くが達成されています。 実装の不規則性が解消され、標準が採用され、非常に興味深い新技術の基礎が見えてきました。

オンラインオーディオの未来は素晴らしいようです！

余分なフィクション

• 「おそらくない」：HTML5オーディオステータス
• HTML5オーディオステータス
• HTML5 <audio>タグをマスターする
• HTML5 Unleashing Strength <オーディオ>
• HTML5ビデオとオーディオについて知りたいことすべて