2026年10月のブラインド試聴テストでは、160 kbpsが音楽で厳密な知覚的透明性に達した最も低いOpusのビットレートであり、テスト中の最も耳の厳しい聴取者でさえ、非圧縮の原音と確実には区別できなかった(同等性のp = 0.024) (Deezer Research、MartinとHennequin、arXiv 2026)。これはOBS Studioが6本すべての音声トラックに既定で設定している音声ビットレートとまったく同じ値だが(OBS Project、OBS Studioソースコード 2026)、ライブプラットフォームが求める値はそれより低い。YouTube Liveはステレオに128 kbpsを推奨し(Google、YouTube Help 2026)、MetaはFacebook Liveに128 kbpsを推奨している(Meta for Developers、Live Video API reference 2026)。目標96 kbpsの時点で、Opusは公開マルチフォーマット・ブラインドテストですでに5点満点中4.65点を獲得していた(Hydrogenaudio、公開試聴テスト 2014)。当社のポッドキャストのホスティング帯域とストレージの統計で扱うオンデマンドのファイルと違い、ライブのエンコーダーにはやり直しの機会がない。当社は、Deezer Research、YouTube Help、Meta for Developers、Kick Help Center、OBS Project、IETF、Apple、EBU、ITU-R、Spotify、そしてHydrogenaudioの試聴テストコミュニティのデータを集計した。
主なポイント
- 160 kbpsのOpusは非圧縮音声と統計的に同等だったが(p = 0.024)、最も耳の厳しい聴取者10人は128 kbpsを聴き分けた(p = 0.030)(Deezer Research、arXiv 2026)
- YouTube Liveは44.1 kHzのステレオで128 kbpsを求めており、これはアップロード動画に推奨する48 kHzの384 kbpsの3分の1だ(YouTube Help、ライブとアップロードの設定 2026)
- Facebook Liveは128 kbpsのAAC-LCステレオ音声を推奨し、最大は256 kbpsだ(Meta for Developers、Live Video API reference 2026)
- OBS Studioの内蔵プリセットは、音声をTwitchで320 kbps、YouTube RTMPSで160 kbps、Facebook Liveで128 kbpsに制限している(OBS Project、services.json 2026)
- OBS Studioの既定値は、音声160 kbps、48,000 Hz、ステレオだ(OBS Project、OBS Studioソースコード 2026)
- AppleのHLS仕様はステレオAACを160 kbit/sに制限し、HE-AACは64 kbit/sを超えて使うべきではないとしている(Apple、HLS Authoring Specification 2026)
- 目標96 kbpsで、Opusは4.65、Apple AACは4.40だった(1から5の尺度)(Hydrogenaudio、公開試聴テスト 2014)
- IETFのOpus標準は、フルバンドの音声に28から40 kbit/s、ステレオ音楽に64から128 kbit/sを推奨している(IETF、RFC 6716 2012)
- Spotifyはアプリでポッドキャストを約96 kbit/sでストリーミングしている(Spotify Support、Audio quality 2026)
- EBUの指針は、非可逆エンコーダーの前の最終リミッターを-2 dBTPに置いている(EBU、Tech 3344 v2.1 2016)
1. プラットフォームのインジェスト仕様:各サービスが求めるもの
「インジェスト」とはアップロード区間のことで、プラットフォームが視聴者向けに再エンコードする前に、エンコーダーがプラットフォームへ送るストリームを指す。この区間で公開されている音声の数値は、驚くほど控えめだ。YouTubeはライブ配信には128 kbpsのステレオ音声を求めるが、アップロード動画には384 kbpsのステレオを求めており、3倍の差がある(Google、YouTube Help 2026)。ライブ音声はマスターではなく、混雑した家庭用の上り回線に耐えなければならない伝送用フィードとして扱われている。
サンプリングレートに関する指針も揃っていない。YouTube Liveはステレオに44.1 kHzを挙げる一方、自社のアップロードページとOBSの既定値は48 kHzを使い、Kickは最大48 kHzまで許容する。この不一致自体は聴感上のコストにならないが、マイク、ミキサー、エンコーダーの間でリサンプリングを行うたびに、誤った設定が紛れ込む余地が生まれる。チャンネルが直面する音声のルールは音声設定だけではなく、もう一つは権利管理であり、当社のライブ配信の著作権ミュート統計が示すとおりだ。
| 指標 | 値 | 出典 |
|---|---|---|
| YouTube Liveの音声:ステレオ対5.1サラウンド | 44.1 kHzで128 kbps対48 kHzで384 kbps(RTMPまたはRTMPS経由の5.1はAACのみ) | Google、YouTube Help: Choose live encoder settings(2026) |
| アップロード動画(ライブ以外)向けのYouTube推奨音声:モノラル / ステレオ / 5.1 | 48 kHzで128 / 384 / 512 kbps | Google、YouTube Help: Recommended upload encoding settings(2026) |
| Facebook Liveの音声ビットレート:推奨対最大 | 128 kbps対256 kbps(AAC低複雑度、ステレオ) | Meta for Developers、Live Video API reference(2026) |
| Facebook Liveが受け付ける音声サンプリングレート | 44.1 kHzまたは48 kHz | Meta for Developers、Live Video API reference(2026) |
| Kickの音声の制限 | ステレオ、最大48 kHz。音声ビットレートは非公開 | Kick Help Center、How to stream on Kick(2026) |
| OBS Studio内蔵サービスプリセットの最大音声ビットレート:Twitch / YouTube RTMPS / Trovo / Facebook Live | 320 / 160 / 160 / 128 kbps | OBS Project、services.jsonプリセットファイル(2026) |
背景メモ:Twitch自身のBroadcasting Guidelinesページはスクリプト経由で読み込まれ、今回のまとめでは読み取れなかったため、上のTwitchの数値は配信ソフトのプリセット上限であり、Twitchからの引用ではない。外部のガイドはより低いTwitchの上限を挙げている(方法論と出典のデータウォッチを参照)。
2. ビットレート予算に占める音声の割合
音声は1080pの配信では誤差の範囲だが、モバイル向けの配信では大きな項目になる。YouTubeがH.264の360pに定める最小0.4 Mbpsでは、128 kbpsのステレオトラックは映像ビットレートの32%に相当する(128 / 400)が、1080p60の推奨値17 Mbpsでは約0.75%にとどまる(128 / 17,000)(Google、YouTube Help 2026)。以下の計算は公開された数値から当社が行ったもので、音声を映像ビットレートのみと比較している。
実務上の読み方はこうだ。高解像度の配信では、音声を160 kbpsから128 kbpsに下げてもほとんど何も節約できないため、音声は最後に切り詰める部分だ。一方、アダプティブラダーの低い段、つまり回線の弱いスマートフォンの視聴者が実際に受け取る段では、音声のビットが映像と直接競合する。これが、アダプティブストリーミングの仕様がステレオAACを32 kbit/sまで許容し、低いレートではHE-AACへ誘導している理由だ。
| 指標 | 値 | 出典 |
|---|---|---|
| YouTube Live 1080p60 H.264の推奨映像ビットレートと、それに占める128 kbps音声の割合 | 17 Mbps。128 / 17,000 = 約0.75% | Google、YouTube Help: Choose live encoder settings(2026) |
| YouTube Live 360p30 H.264の最小映像ビットレートと、それに占める128 kbps音声の割合 | 0.4 Mbps。128 / 400 = 32% | Google、YouTube Help: Choose live encoder settings(2026) |
| Facebook Live 1080p60の映像ビットレート範囲と、それに占める推奨128 kbps音声の割合 | 4,500から9,000 kbps。128 / 9,000 = 約1.4%、128 / 4,500 = 約2.8% | Meta for Developers、Live Video API reference(2026) |
| Kickの映像ビットレート範囲(H.264のみ、固定ビットレートのみ) | 1,000から8,000 kbps | Kick Help Center、How to stream on Kick(2026) |
| OBS StudioのTwitchプリセット:最大映像対最大音声ビットレート | 6,000対320 kbps。320 / 6,000 = 約5.3% | OBS Project、services.json(2026) |
| Apple HLSのステレオAACビットレート範囲 | 32から160 kbit/s | Apple、HLS Authoring Specification for Apple Devices(2026) |
| Apple HLS:これを超えるとHE-AACを使うべきではないビットレート | 64 kbit/s | Apple、HLS Authoring Specification(2026) |
| Apple HLSのライブ配信:宣言された帯域に対して許容される1時間平均とピーク | AVERAGE-BANDWIDTHの110%未満。BANDWIDTHの125%未満 | Apple、HLS Authoring Specification(2026) |
背景メモ:Kickは固定ビットレート(CBR)を必須としており、これはエンコーダーが難しいシーンに多くのビットを使うのではなく、一定のレートを送り続けるという意味だ。CBRにより上記の音声の割合は固定されるため、8,000 kbpsのKick配信で160 kbpsのステレオトラックは映像予算の2%になる(160 / 8,000)。
3. 既定値とコーデックの基盤:AACが主流、Opusが到来中
ほとんどの配信者は音声パネルに触れないため、既定値が事実上の業界標準になる。OBS Studioはすべての音声トラックに、160 kbps、48,000 Hz、ステレオを既定で設定している(OBS Project、OBS Studioソースコード 2026)。この単一の既定値は、YouTubeやFacebookの推奨値より高く、OBSのTwitch上限より低い。1台のエンコーダーが複数のプラットフォームに送出する場合には妥当な中間値だ。加工した声を別のアプリからOBSに入力する場合、たとえばOBS向けボイスチェンジャーを使う場合は、この48 kHzを最初から最後まで揃えておくと、余計なリサンプリングを1回避けられる。
コーデックの状況は足元で変わりつつある。セクション1のRTMPインジェスト仕様はすべてAACを挙げているが、WebRTCの世界ではOpusが必須であり、WHIP(WebRTC-HTTP Ingestion Protocol、WebRTCストリームをサーバーへ送り込むHTTPベースの方式)がその世界を配信ソフトにもたらしている。OBSはバージョン30.0でWHIP出力を追加し、IETFは2025年にWHIPをRFC 9725として公開した。その例示のオファーは、48 kHzのステレオでOpusを交渉する内容になっている(「opus/48000/2」)。
| 指標 | 値 | 出典 |
|---|---|---|
| OBS Studioの既定の音声ビットレート、Simple出力とAdvanced出力の6トラックすべて | 160 kbps | OBS Project、OBS Studioソースコード、InitBasicConfigDefaults(2026) |
| OBS Studioの既定のサンプリングレートとチャンネル構成 | 48,000 Hz、ステレオ | OBS Project、OBS Studioソースコード(2026) |
| 20 msフレームでのOpus推奨ビットレート:フルバンド音声対フルバンドステレオ音楽 | 28から40 kbit/s対64から128 kbit/s | IETF、RFC 6716(2012年9月) |
| Opusのフルバンドモード:実効サンプリングレートと符号化される最高周波数 | 48 kHz。20 kHzを超える音は符号化されない | IETF、RFC 6716(2012年9月) |
| すべてのWebRTCエンドポイントが実装しなければならない音声コーデック | OpusとG.711(PCMAおよびPCMU) | IETF、RFC 7874(2016年5月) |
| WHIP/WebRTC出力を追加したOBS Studioのリリース | 30.0、2023年11月 | OBS Project、OBS Studio 30.0リリースノート(2023) |
背景メモ:WHIP標準自体は必須のコーデックを定めておらず、Opusは例示のやり取りにしか登場しない。Opusの要件は、表にある別のWebRTCコーデック規則に由来し、それはWebRTCエンドポイント全般に適用される。
4. ブラインド試聴テストにおけるAAC対Opus
ブラインドテストはコーデック同士の唯一公平な審判だが、公開されている記録は、それが判定する配信技術の環境より古い。2014年7月のHydrogenaudio公開テストの目標96 kbpsでは、Opus 1.1が4.65、Apple AACが4.40で、1から5の劣化尺度において5は「知覚不能」を意味する(Hydrogenaudio、公開マルチフォーマット試聴テスト 2014)。差は絶対値では小さいが統計的には確かで(p = 0.000)、Opusが平均で3 kbpsしか多く使っていない(106.7対103.7 kbps)状況で得られた。
確認できた最新のデータ:2010年から2014年のテスト結果(出典は表を参照)。2025年や2026年に、現行のAACとOpusのエンコーダーをストリーミングのビットレートで比較した同等の公開マルチフォーマットテストは見つからなかった。これ自体が一つの知見であり、各プラットフォームのAAC既定値は、新しい試聴データではなく互換性に基づいている。ニューラルコーデックがOpusと競合している非常に低いビットレートについては、当社のニューラル音声コーデックのビットレートと品質の統計を参照してほしい。
| 指標 | 値 | 出典 |
|---|---|---|
| 目標96 kbpsでの平均スコア、1から5の尺度(5 = 知覚不能):Opus 1.1対Apple AAC対LAME MP3対Vorbis | 4.65対4.40対4.24対4.24 | Hydrogenaudio、公開マルチフォーマット試聴テストの結果(2014年7月) |
| その目標で実際に得られた平均ビットレート:Opus / Apple AAC / Vorbis / MP3 | 106.7 / 103.7 / 106.1 / 135.5 kbps | Hydrogenaudio、公開マルチフォーマット試聴テスト(2014) |
| 低品質アンカー(旧世代のAACエンコーダーFAAC、96 kbps) | 2.65 | Hydrogenaudio、公開マルチフォーマット試聴テスト(2014) |
| 有意性:Opus対Apple AAC、Apple AAC対MP3 | Opusが優位、p = 0.000。AACが優位、調整後p = 0.043(ブートストラップ) | Hydrogenaudio、公開マルチフォーマット試聴テスト(2014) |
| パネルと素材 | 参加者38人、提出363件のうち有効339件。サンプル40点(音楽35点、音声5点) | Hydrogenaudio、公開マルチフォーマット試聴テスト(2014) |
| Googleのステレオ音楽テスト(聴取者9人):128 kbpsのOpus対64 kbpsのAAC-LC、96 kbpsのMP3、64 kbpsのOpus、64 kbpsのG.719 | 128 kbpsのOpusが他の4つより有意に高いスコア | IETF、draft-ietf-codec-results-03(2013年5月) |
| Broadcomのステレオ音楽テスト(聴取者17人、2010年12月):96 kbpsのOpus対AAC-LCおよびMP3 | AAC-LCよりわずかに劣り、MP3より有意に優れる | IETF、draft-ietf-codec-results-03(2013年5月) |
外れ値メモ:MP3はVorbisと同じ4.24に到達するのにOpusより28.8 kbps多く使い(135.5から106.7 kbpsを引いた値)、それでもAACには及ばなかった。Broadcomの結果は最終版より前のOpusビットストリームを使っており、そのため後のテストと結果が異なる。
5. 透明性のしきい値:追加のビットが意味を持たなくなる地点
「透明」には、音声符号化において明確な意味がある。訓練された聴取者が、管理されたブラインドテストで、符号化された版と原音を確実には区別できないことだ。Deezer Researchは、160 kbpsのOpusがストレス条件下でこの基準を満たしたこと(差の検定p = 0.747、厳密な同等性p = 0.024)、一方で最も難しいサンプルと最も鋭い耳を切り出すと128 kbpsは満たさなかったこと(p = 0.030)を明らかにした(Deezer Research、MartinとHennequin、arXiv 2026)。21人全員が参加した第1段階では128 kbpsは区別できないように見え(p = 0.456)、答えが誰が聴くかにいかに左右されるかを示している。
この研究はITU-R BS.1116-3を用いた。これは、聴取者が原音を聴き、続いて2つの隠された版(1つは符号化版、もう1つは再び原音)を聴いて差を評価する方法だ。「差の評点」0は聴感上の差がないことを意味し、同等性の許容幅はプラスマイナス0.25だった。配信者にとって重要な注意点は2つある。このテストはOpusと音楽のみを対象としていること、そして査読中のプレプリントであることだ。表にある放送用サラウンドの数値は同じ論理をより大きな規模で示しており、安全なビットレートは平均的なケースよりはるかに高い。
| 指標 | 値 | 出典 |
|---|---|---|
| 第1段階の非圧縮音声に対する平均差評点(0 = 聴感上の差なし):32対64対128 kbpsのOpus | -1.661対-0.438対-0.082 | Deezer Research、MartinとHennequin、arXiv 2610.20246(2026年10月) |
| 第1段階、128 kbpsのOpus:差の検定対厳密な同等性の検定 | p = 0.456(検出可能な差なし)対p = 0.064(同等性は示されず) | Deezer Research、arXiv 2610.20246(2026) |
| 第2段階のストレステスト(最も耳の厳しい聴取者10人、最も難しいサンプル8点):96対128対160 kbpsでの差の検定 | p = 0.045対p = 0.030対p = 0.747 | Deezer Research、arXiv 2610.20246(2026) |
| 第2段階、160 kbpsのOpus:厳密な同等性の検定(許容幅プラスマイナス0.25評点)と平均差評点 | p = 0.024。-0.035 | Deezer Research、arXiv 2610.20246(2026) |
| 募集した聴取者対スクリーニング後に適格となった聴取者、音楽の抜粋 | 26人対21人。抜粋23点 | Deezer Research、arXiv 2610.20246(2026) |
| コンテンツを問わず優秀な品質のための安全な選択としてEBUが挙げる5.1サラウンドのビットレート | 448 kbit/s | EBU、Tech 3324 multichannel codec evaluations(2007年9月) |
| 160 kbit/s以上のHE-AAC 5.1サラウンド | 平均では優秀、拍手のみ普通 | EBU、Tech 3324(2007年9月) |
| MUSHRAテストの規則:隠された原音を90未満と評価した項目がこの割合を超える聴取者は除外 | 15% | ITU-R、Recommendation BS.1534-3(2015年10月) |
背景メモ:サラウンドについて確認できた最新のデータ:2007年。MUSHRA(BS.1534)は中程度の品質向けの方法で、0から100で採点し、アンカーは3.5 kHzと7 kHzでローパスフィルターをかけたものを使う。一方、BS.1116は、厳密な条件でしか明らかにならないほど小さな劣化のために用いられる。MUSHRAで「優秀」と判定されたコーデックが、BS.1116の意味で自動的に透明になるわけではない。
6. 音声中心の配信と、聴取者の基準点
ライブ配信の大半は音楽を背景にしたトークであり、音声は音楽よりはるかに少ないビットで足りる。2011年のGoogleの試聴テストは、32 kbpsのフルバンドOpusを北京語の音声で100点満点中98.13点と評価し、同じレートのG.719(93.43)を上回った(IETF、draft-ietf-codec-results-03 2013)。確認できた最新のデータ:2013年。
コンシューマー向けサービスが耳の基準点を決める。Spotifyはアプリでポッドキャストを約96 kbit/sでストリーミングしており、表にあるポッドキャストフィードの指針はモノラルで最大128 kbpsだ。128から160 kbpsで送り出すトーク配信は、聴取者が大手ポッドキャストアプリで聴くものをすでに上回っている。128 kbpsの音楽配信はSpotifyの「高」の段階を下回り、「非常に高い」の段階をはるかに下回る。
| 指標 | 値 | 出典 |
|---|---|---|
| Googleの北京語音声テスト(スクリーニング後の聴取者21人、0から100の尺度):32 kbpsのフルバンドOpus対32 kbpsのG.719対20 kbpsのワイドバンドOpus | 98.13対93.43対81.59 | IETF、draft-ietf-codec-results-03(2013年5月) |
| Spotifyのポッドキャストストリーミングのビットレート:モバイルとデスクトップのアプリ対ウェブプレーヤー | 約96 kbit/s対128 kbit/s | Spotify Support、Audio quality(2026) |
| Spotifyの音楽の段階:低 / 標準 / 高 / 非常に高い | 約24 / 96 / 160 / 320 kbit/s | Spotify Support、Audio quality(2026) |
| Spotifyのウェブプレーヤーの音楽:Free対Premium | AAC 128 kbit/s対AAC 256 kbit/s | Spotify Support、Audio quality(2026) |
| Spotify Losslessの段階(Premium):形式と最大解像度 | FLAC、最大24-bit/44.1 kHz | Spotify Support、Audio quality(2026) |
| Apple PodcastsのRSSフィード、44.1または48 kHzのAAC:モノラル対ステレオの推奨ビットレート | 64から128 kbps対128から256 kbps | Apple、Apple Podcasts for Creators: Audio requirements(2026) |
| Apple PodcastsのMP3の最小値:モノラル対ステレオ | 44.1 kHzで32 kbps対64 kbps | Apple、Apple Podcasts for Creators: Audio requirements(2026) |
背景メモ:スマートフォンとタブレットでは、Spotifyで低品質を選ぶとポッドキャストも既定の96 kbit/sの4分の1にあたる約24 kbit/sに下がる。これは多くの聴取者がすでにトークとして受け入れている下限だ。
7. エンコーダー前のヘッドルームとラウドネス
非可逆エンコーダーは波形を変えるため、ピークは入力時より高くなって出力されることがある。そのためEBUの指針は、非可逆エンコーダーの前の最終リミッターを-2 dBTPに置いており、これは制作上の上限-1 dBTPより丸1デシベル低い(EBU、Tech 3344 v2.1 2016)。「dBTP」はデシベル・トゥルーピークの意味で、デジタルサンプルの間に生じるオーバーシュートを含むピーク測定値だ。同じ文書は、ビットレートが低いときにはリミッターをさらに下げる必要があるかもしれないと警告しているが、数値は示していない。
ライブのミックスにとって、これは記事中で最も実行しやすい数値だ。配信バスのリミッターを0 dBFSに設定すると、AACやOpusのエンコーダーには自身のオーバーシュートを収める余地が残らない。ラウドネスの目標は別の問題であり、当社の配信音声のラウドネス正規化の統計で詳しく扱っている。EBUのストリーミング補足文書R 128 s2(バージョン3.0、2023年11月)は、サービスがより大きな目標を使う場合に、再生機器側でトゥルーピーク・リミッティングを適用することを推奨している。
| 指標 | 値 | 出典 |
|---|---|---|
| 制作素材の最大トゥルーピークレベル | -1 dBTP | EBU、Tech 3344 v2.1(2016年7月) |
| 非可逆エンコーダーの前の最終ピークリミッターの設定 | -2 dBTP(低ビットレートではさらに低くする必要がある場合あり) | EBU、Tech 3344 v2.1(2016年7月) |
| RFモードのAC-3またはE-AC-3に推奨されるデコーダー最大出力 | -4 dBTP | EBU、Tech 3344 v2.1(2016年7月) |
| トゥルーピークの読み値とアナログ出力レベルの間のオーバーシュート | 1 dB未満(通常は数十分の1 dB) | EBU、Tech 3344 v2.1(2016年7月) |
| Apple Podcastsのトゥルーピーク上限 | -1 dBFS以下 | Apple、Apple Podcasts for Creators: Audio requirements(2026) |
| Apple HLS:ラウドネスまたはダイナミックレンジ制御のメタデータ | 広告を含むすべてのコンテンツが同じレベルでエンコードされている場合を除き、存在するべき(要件2.18) | Apple、HLS Authoring Specification(2026) |
背景メモ:コーデックのヘッドルームについて確認できた最新のデータ:2016年。セクション1で確認したライブのインジェストページ(YouTube Live、Facebook Live、Kick)はいずれもラウドネス目標を公開していないため、上の放送とポッドキャストの数値が、文書で確認できる最も近い基準だ。
まとめ:ライブ配信の音声ビットレートとエンコード設定を数字で見る
| 指標 | 値 | 出典 |
|---|---|---|
| 音楽で厳密な透明性に合格した最も低いOpusのビットレート(BS.1116-3、同等性のp) | 160 kbps(p = 0.024) | Deezer Research、arXiv 2026 |
| 128 kbpsのOpus対非圧縮、最も耳の厳しい聴取者10人 | 劣化として検出(p = 0.030) | Deezer Research、arXiv 2026 |
| YouTube Liveのステレオ音声 | 44.1 kHzで128 kbps | Google、YouTube Help 2026 |
| Facebook Liveの音声ビットレート:推奨対最大 | 128対256 kbps | Meta for Developers 2026 |
| Facebook Liveの1080p60映像範囲に占める128 kbps音声の割合 | 約1.4%から2.8% | Meta for Developers 2026(当社の算出) |
| Kickの音声の制限 | ステレオ、最大48 kHz | Kick Help Center 2026 |
| Spotifyの音楽の段階:高対非常に高い | 約160対320 kbit/s | Spotify Support 2026 |
| OBS Studioの既定の音声ビットレートとサンプリングレート | 160 kbps、48,000 Hz | OBS Project、ソースコード 2026 |
| Apple HLSのステレオAAC範囲 | 32から160 kbit/s | Apple、HLS Authoring Specification 2026 |
| Opusの推奨値:フルバンド音声対ステレオ音楽 | 28から40対64から128 kbit/s | IETF、RFC 6716 2012 |
| すべてのWebRTCエンドポイントで必須のコーデック | OpusとG.711 | IETF、RFC 7874 2016 |
| 目標96 kbpsでのスコア、Opus対Apple AAC(1から5) | 4.65対4.40 | Hydrogenaudioテスト 2014 |
| その目標での実際のビットレート、MP3対Opus | 135.5対106.7 kbps | Hydrogenaudioテスト 2014 |
| YouTube Liveの360p最小映像ビットレートに占める128 kbps音声の割合 | 32%(128 / 400) | Google、YouTube Help 2026(当社の算出) |
| アプリでのSpotifyのポッドキャストビットレート | 約96 kbit/s | Spotify Support 2026 |
| Apple Podcastsの推奨AACステレオビットレート | 128から256 kbps | Apple Podcasts for Creators 2026 |
| 非可逆エンコーダーの前の最終リミッター | -2 dBTP | EBU Tech 3344、2016 |
方法論と出典
本まとめのすべての数値は、2026年11月に一次資料で確認した。セクション2の割合は公表されたビットレートからの当社自身の算術であり、計算式を各値の横に示している。
- Deezer Research、Benjamin MartinとRomain Hennequin、Evaluating perceptual transparency of lossy music audio compression with Opus codec、arXivプレプリント、2026年10月。
- Google、YouTube Help: Choose live encoder settings, bitrates, and resolutions、2026年。
- Google、YouTube Help: Recommended upload encoding settings、2026年。
- Meta for Developers、Live Video API reference、2026年。
- Kick Help Center、How to stream on Kick、2026年。
- OBS Project、rtmp-services services.json、OBS Studioソースコード(既定の設定)、およびOBS Studio 30.0リリースノート。
- IETF、RFC 6716 Opus(2012年)、RFC 7874 WebRTC audio codec requirements(2016年)、RFC 9725 WHIP(2025年)、およびdraft-ietf-codec-results-03(2013年)。
- Apple、HLS Authoring Specification for Apple DevicesおよびApple Podcasts for Creators: Audio requirements、2026年。
- Hydrogenaudioコミュニティ、公開マルチフォーマット試聴テストの結果、2014年7月。
- EBU、Tech 3324: EBU evaluations of multichannel audio codecs(2007年)、Tech 3344 v2.1(2016年)、およびR 128 s2 バージョン3.0(2023年)。
- ITU-R、Recommendation BS.1534-3(2015年)およびRecommendation BS.1116-3(2015年)。
- Spotify Support、Audio quality、2026年。
- データウォッチ:Twitchのブロードキャストガイドライン(Broadcasting Guidelines)ページは読み取れる形で表示できなかったため、使用したTwitchの数値はOBSのプリセット上限(320 kbps)のみである。少なくとも1つの外部エンコーダーガイド(Switchboard)は、TwitchのAAC最大値としてOBSプリセットの半分にあたる160 kbpsを挙げているが、どちらの数値もTwitch自身では確認できなかったため、実際のページで確認するまでTwitchの音声制限は未検証として扱ってほしい。Kickは音声ビットレートを公開していない。Deezerの研究はICASSP 2027向けに査読中のプレプリントであり、聴取者はDeezerの従業員で、音楽のみでOpusをテストしたため、その160 kbpsというしきい値をAACや音声に当てはめるべきではない。Hydrogenaudioの結果ページは、MP3の追加ビットレートを「30kbps増」と「29%増」の両方で説明しているが、当社は測定された平均値のみを報告する。EBU Tech 3324は結論で約150人の被験者による14,000件以上の評点を引用しているが、これは同文書の研究所別の表(受け入れられた聴取者87人と71人)と一致しないため、この文書からの聴取者総数は使用しない。セクション4と5の試聴テストのデータは大半が3年以上前のもの(2007年から2014年)で、最近の例外はDeezerの研究だけだ。YouTube Liveはステレオに44.1 kHzを推奨しているが、そのアップロード指針、Kick、OBSは48 kHzを使っている。
最終更新日:2026年11月6日。当社はこのまとめを四半期ごとに更新しており、次回の更新は、ICASSP 2027の論文集でDeezer Researchの透明性研究の査読済み版が公開される時期を予定している。