ムシュラ

MUSHRA は、Multiple Stimuli with Hidden Reference and Anchor の略で、非可逆オーディオ圧縮アルゴリズムの出力の知覚品質を評価するコーデックのリスニング テストを実行する方法論です。これは、 ITU-R勧告 BS.1534-3で定義されています。 ^[1] MUSHRA 方法論は、「中程度のオーディオ品質」を評価するために推奨されています。非常に小さい、または敏感なオーディオ障害の場合は、代わりに ITU-R 勧告 BS.1116-3 (ABC/HR) が推奨されます。

MUSHRA は、音楽や映画の視聴、ポッドキャストやラジオなどの音声、オンライン ストリーミング(品質とサイズおよび計算の効率のトレードオフが最も重要)、最新のデジタル電話、VOIPアプリケーション (理解可能なままの準リアルタイムの低ビットレート エンコーディングが必要) など、幅広いユース ケースにわたってオーディオ コーデックをテストするために使用できます。プロフェッショナル、"オーディオ マニア"、および "プロシューマー" の用途には、通常、前述の ABC/HR などの代替テストの方が適しています。これは、高品質で高解像度のオーディオを基本前提とし、参照資料とコーデック出力 の間に検出可能な違いが最小限になるようにします。

同様の目的を持つ平均意見評点(MOS) 法に対する主な利点は、MUSHRA では統計的に有意な結果を得るために必要な参加者が少ないことです。 ^[要出典]これは、すべてのコーデックが同時に同じ参加者に提示されるため、統計分析にt 検定または反復測定分散分析を使用できるからです。さらに、MUSHRA で使用される 0 ～ 100 のスケールにより、特にMOS 実験でよく使用される 0 ～ 5 の修正リッカート尺度と比較して、知覚できる差異を非常に細かく表現できます。

MUSHRA では、リスナーに参照 (そのようにラベル付けされている)、一定数のテスト サンプル、参照の非表示バージョン、および 1 つ以上のアンカー (つまり、実験者と参加者の両方がすぐに認識できる、著しく劣化したエンコード。参照と同様に使用され、参加者に品質スケールの下限の現実を示すベースライン (「アンカー」) を提供します) が提示されます。推奨事項では、低域アンカーと中域アンカーをテスト信号に含める必要があると指定されています。これらは通常、参照の 7 kHz および 3.5 kHz のローパス バージョンです。アンカーの目的は、小さなアーティファクトが不当にペナルティを受けないようにスケールを較正することです。これは、異なるラボの結果を比較またはプールするときに特に重要です。

MUSHRAテストとITU BS.1116テスト^[2]はどちらも、典型的なアーティファクトがどのように聞こえるか、どこで発生する可能性があるかを知っている訓練を受けた熟練したリスナーを必要とします。熟練したリスナーは評価尺度をよりよく理解しているため、訓練を受けていないリスナーよりも再現性の高い結果が得られます。したがって、訓練を受けたリスナーであれば、統計的に有意な結果を得るために必要なリスナーの数は少なくなります。

熟練したリスナーと素人のリスナーの好みは似ていると想定されているため、熟練したリスナーの結果は消費者にとっても予測可能である。この想定と一致して、Schinkel-Bielefeld ら^{[3] は}、音色のみを含み空間的アーティファクトを含まないテスト信号を使用した場合、熟練したリスナーと訓練されていないリスナーの間で順位に違いは見られないことを発見した。しかし、Rumsey ら^[4]は、空間的アーティファクトを含む信号の場合、熟練したリスナーは、主に音色アーティファクトに注目する訓練されていないリスナーよりも空間的アーティファクトをわずかに重視することを示した。

これに加えて、熟練したリスナーは、テスト対象信号のより小さなセクションを繰り返し聞くオプションをより多く活用し、テスト対象信号と参照信号との比較をより多く行うことが示されています。^[3]好みの評価を行う素人リスナーとは対照的に、熟練したリスナーはオーディオ品質の評価を行い、テスト対象信号と非圧縮のオリジナルの違いを評価します。これがMUSHRAテストの実際の目的です。

MUSHRA ガイドラインでは、リスナーの信頼性を評価するための 2 つの主要な可能性について説明しています (以下で説明)。

最も簡単で一般的なのは、すべてのテスト項目の 15% 以上で隠しリファレンスの繰り返しが 90 MUSHRA ポイント未満であると評価したリスナー全員を事後的に失格とすることです。隠しリファレンスは、理想的には、元のリファレンス オーディオとの知覚的同等性を示すために 100 ポイントで評価される必要があります。隠しリファレンスと高品質信号が混同されることはありますが、仕様では、評価された信号が元のリファレンスと異なることをリスナーが確信している場合にのみ 90 未満の評価を与えるべきであると規定されているため、隠しリファレンスが 90 未満の評価である場合は、明白で自明なリスナーのエラーと見なされます。

リスナーのパフォーマンスを評価するもう 1 つの方法は、分散分析(ANOVA)に基づくフレームワークであるeGauge ^{[5]です。このフレームワークでは、}一致度、再現性、および識別可能性が計算されますが、事前または事後スクリーニングには後者の 2 つのみが推奨されます。一致度は、リスナーと他のリスナーの一致度の分散分析です。再現性は、同じテスト信号を再度評価する際の個人の内部信頼性を、他のテスト信号の分散と比較して調べます。識別可能性は、リスナーが異なる条件のテスト信号を区別できるかどうかを確認することで、一種のテスト間信頼性を分析します。eGauge ではすべてのテスト信号を 2 回聞く必要があるため、隠れた参照に基づいてリスナーを事後スクリーニングする従来の方法と比較して、短期的には時間的に非効率的です。eGauge には、長期的な視点で使用する場合の利点があります。事後に過度の失敗率が発見されたためにサンプルの結果が十分な統計的検出力を欠くというまれなケースで、完全にやり直すというわずかな可能性がなくなります。さらに、初期の非効率性は、リクルートメント段階の必要性をなくすことで、一連の実験を通じて償却できます。リスナーが eGauge を使用して信頼できるリスナーであることを証明した場合、テストの性質が大幅に変更されない限り、将来のリスニング テストでも信頼できるリスナーと見なすことができます (たとえば、ステレオ テストの信頼できるリスナーは、5.1または22.2構成、さらにはモノラル形式でもアーティファクトを同じように認識できるとは限りません)。

重要なテスト項目を選択することが重要です。具体的には、エンコードが難しく、アーティファクトが発生しやすい項目です。同時に、テスト項目は生態学的に妥当である必要があります。つまり、放送素材を代表するものでなければならず、リアリティを犠牲にしてエンコードを困難にするように設計された単なる合成信号であってはなりません。重要な素材を選択する方法は、Ekerootらによって提示されており、ランク付けによる排除手順を提案しています。^{[6] [詳細な説明が必要]}これは最も重要なテスト項目を選択するのに効果的ですが、さまざまなアーティファクトが発生しやすいさまざまなテスト項目が含まれることを保証するものではありません。

理想的には、MUSHRAテスト項目は、その全期間にわたって同様の特性を維持する必要があります（例：音楽では一貫した楽器の使用、音声では同じ人の声が同様のリズムとトーンで使用されている）。項目の一部に他の部分と比べて異なるアーティファクトや強いアーティファクトが見られる場合、リスナーが一次元MUSHRA評価を決定するのは困難です。これは、オーディオの特性が大きく変動することで起こりやすくなります。^{[7]多くの場合、項目が短いほど}定常性（知覚の一貫性と恒常性）が高くなるため、変動性が低くなります。 ^[8]ただし、定常項目を選択する場合でも、生態学的に有効な刺激（つまり、ラジオなどの現実世界の状況で出現する可能性が高い、または出現する可能性のあるオーディオ）には、信号の残りの部分よりもわずかに重要なセクションが非常に多くあります（例：スピーチのキーワードや音楽の主要なフレーズなど、刺激の種類によって異なります）。信号のさまざまなセクションに注目するリスナーは、それを異なる方法で評価する傾向があるため、定常性は重要です。分析力の高いリスナーは、分析力の低いリスナーよりも、刺激の最も重要な部分を特定する能力に優れているようです。^[9]

ITU-T P.800テスト^[10]は、平均オピニオンスコア法に基づいており、VOIPなどで使用される電話コーデックの評価によく使用されています。この規格では、テストされる音声項目は常にリスナーの母国語でなければならないと規定されています。これらの目的にMUSHRAを使用すると、言語のマッチングは不要になります。MUSHRA実験は、話された単語の了解度をテストすることではなく、それらの単語を含むオーディオの品質と可聴アーティファクト（歪みなど）の有無のみをテストすることを目的とします。中国語（北京語）とドイツ語のリスナーを対象としたMUSHRAの研究では、外国語のテスト項目と母国語のテスト項目の評価に大きな違いは見られませんでした。最終結果に違いがないにもかかわらず、リスナーが外国語の項目を正確に評価するには、より多くの時間と比較の機会（繰り返し）が必要でした。^[11]この補正は、項目が1回しか聞かれず、参照オーディオとの比較が不可能なITU-T P.800 ACRテストでは不可能です。このようなテストでは、MUSHRAテストとは異なり、聞き手のターゲット言語の習熟度が低い場合、実際のコーデックの品質に関係なく、外国語の項目は低品質であると認識され、評価されます。^[12]

• webMUSHRA: YAML を使用して構成可能な、MUSHRA 準拠の Web オーディオ API ベースの実験ソフトウェア
• RateIt: MUSHRA 実験を実行するための GUI
• MUSHRAM - Wayback Machineの MUSHRA リスニング テスト用の Matlab インターフェイス(2008-10-19 アーカイブ)
• MUSHRA リスニング テスト用の Max/MSP インターフェイス
• MUSHRAを含むさまざまなテストを実行するためのブラウザベースのオーディオ評価ツール - コーディングは不要
• BeaqleJS: リスニングテスト用の HTML5 および JavaScript ベースのフレームワーク
• mushraJS+Server: mushraJSをベースに、Erlang Webサーバーであるmochiwebサーバーを搭載