ロスレスサラウンド音声は、再生チェーン内のいずれかのデバイスまたはソフトウェア層が、そのコーデックとチャンネルレイアウトを変更せずに受け取れない場合に変換されます。
メディアサーバーは、映像をダイレクト再生しながら、Dolby TrueHD、DTS-HD Master Audio、マルチチャンネルFLAC、その他のロスレストラックをAC-3、E-AC-3、AAC、またはステレオPCMに変換できます。判断には、クライアントアプリ、テレビ、ストリーミングボックス、HDMI接続、ARCまたはeARC経路、レシーバー、選択したプレーヤー、報告された対応能力が影響します。テレビの製品ページだけでエンドツーエンドのパススルーを判断せず、実際の音声経路を正確に確認してください。
音声ストリームだけが変換されていることを確認する
影響を受けているクライアントで同じタイトルを再生し、映像品質をオリジナルに設定して字幕を無効にします。サーバーダッシュボードに表示される映像モード、音声モード、選択したトラック、出力コーデック、チャンネル数、トランスコード理由を記録してください。
音声変換では、必ずしも映像のエンコードは必要ありません。Jellyfinのある問題では、H.264映像がコピーされる一方、非対応の音声ストリームがHLS経由でAACに変換されており、音声のみのトランスコードは別の経路であることが示されています。
ダッシュボードで映像変換も報告される場合は、サラウンドトラックを診断する前に、字幕、ビットレート、HDR、コンテナの要因を取り除いてください。目的は、音声の選択だけを変更する、制御された1つのセッションを作ることです。
正確なコーデック、プロファイル、チャンネルレイアウトを特定する
メディアサーバーまたはメディア解析ツールで、選択したストリームを確認します。TrueHD、Atmos付きTrueHD、DTS-HD MA、DTS:X、マルチチャンネルFLAC、PCM、E-AC-3、AC-3のどれなのかに加え、チャンネルレイアウトとサンプルレートを記録してください。
一般的なDTSやDolby Digitalに対応しているクライアントが、ロスレス拡張にも自動的に対応するとは限りません。最近のAndroid TVの回帰報告では、同じデバイスと別のプレーヤーでは正常にパススルーできるにもかかわらず、DTS-HD MAのパススルーに失敗する事例が説明されています。
同じファイルに含まれるロスレストラックと、AC-3、E-AC-3、AAC、またはステレオのフォールバックトラックを比較してください。フォールバックがダイレクト再生され、ロスレストラックだけが変換される場合、映像、ストレージ、ネットワークが主な原因ではありません。
クライアントからレシーバーまでの音声経路全体を追跡する
実際の経路を書き出します。メディアアプリからストリーミングボックスまたはテレビへ進み、次にHDMIでテレビまたはレシーバーへ接続し、ディスプレイから音声が戻る場合はARCまたはeARCを経由します。各経路上の機器が、選択したコーデックを変更せずに伝送できなければなりません。
デバイスによっては、フォーマットをローカルでデコードできても、選択した出力経路を通じてビットストリーム送信できない場合があります。Jellyfinのクライアントインターフェースでは、デバイスまたは接続されたレシーバーが対応している場合のみTrueHDを有効にするよう警告しています。これは、誤った対応能力の設定によって、パススルーではなく再生失敗が発生する可能性があるためです。
プレーヤーをレシーバーに直接接続した場合と、テレビを経由した場合をテストしてください。レシーバーへの直接接続では動作し、テレビから音声を戻す経路で変換または失敗する場合は、メディアサーバーを変更するのではなく、eARCモード、デジタル音声出力、パススルー設定、HDMI入力の対応状況、ケーブルのネゴシエーションを確認してください。
クライアントのパススルー設定とプレーヤーバージョンを比較する
アプリが音声パススルーを自動、直接、無効のどれで使用しているか、またネイティブプレーヤー、ExoPlayer、Webプレーヤー、外部プレーヤーのどれを選択しているかを確認します。設定を変更する前に、クライアントのバージョンを記録してください。
クライアントソフトウェアが、実際にはロスレスコーデックに対応しているハードウェアを、非対応として報告することがあります。Android TVのある問題では、レシーバーとクライアントが対応していると報告されているにもかかわらず、TrueHDとDTSの音声が変換されており、対応能力の報告に不一致があることが示されています。
ファイルを変更せず、同じデバイスとレシーバーで別のアプリをテストしてください。一方のプレーヤーではトラックをパススルーでき、もう一方では変換される場合、サーバー設定はそのままにして、問題のあるクライアントプロファイル、アプリバージョン、選択された再生エンジンに注目します。
チャンネル数の上限とダウンミックス動作を確認する
クライアントがAACまたはPCMを受け入れても、ステレオにしか対応していない場合や、6チャンネルを報告しているのにアプリが2チャンネルを要求している場合があります。サーバーの出力チャンネル数を、レシーバーのフロントパネルに表示されるフォーマットや、実際に音が出ているスピーカーと比較してください。
JellyfinのWebOSユーザーからは、DTS-HD MAとマルチチャンネルFLACが変換された後、ステレオに縮小されたという報告があります。これは、コーデック変換とチャンネル削減が同じセッションで発生する可能性を示しています。
変換後にレシーバーがステレオを表示する場合は、クライアントの最大音声チャンネル数とサーバーのトランスコードプロファイルを確認してください。配信コンテナやテレビが、その経路でマルチチャンネルPCMまたはAACを伝送できない場合、むやみにチャンネル数を増やさないでください。
映像を再エンコードせず、互換性のあるフォールバックを選ぶ
影響を受けるクライアントがロスレス音声をパススルーできない場合は、既存のAC-3またはE-AC-3互換トラックを優先してください。対応するホームシアタークライアント向けには、元のTrueHDまたはDTS-HDストリームを残します。
ライブラリにフォールバックがない場合は、ロスレスのソースを置き換えるのではなく、2つ目の音声トラックまたは別バージョンのメディアを作成してください。音声のみの変換は映像トランスコードよりはるかに軽く、元の映像を維持できます。
ZimaSpaceによる音声トランスコードパイプラインの解説では、互換性のあるフォールバックによってダイレクト再生の映像を維持できる理由を理解するための関連する仕組みが説明されています。
パススルー、同期、再開動作を確認する
ロスレスとフォールバックのトラックを、最初から再生した場合、シークした後、再開した後に再テストします。サーバーモード、レシーバーのフォーマット、出力チャンネル、リップシンク、アプリを再起動しても再生が継続するかを確認してください。
音声のみの変換によって、クライアント固有のシーク問題が明らかになることがあります。Jellyfinのテレビに関する問題では、音声だけにトランスコードが必要な場合、シーク後に再生が停止することが報告されています。
対応クライアントでロスレストラックが変更されずにパススルーされ、制限のあるクライアントでは安定した互換トラックが選択され、可能な限り映像がダイレクト再生され、通常の再生中を通じてレシーバーに期待どおりのコーデックとチャンネルレイアウトが表示されれば、診断は完了です。
サポートとヒント
もっと読む

Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか?
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。

Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか?
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。

リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか?
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。

