canarino blog

PCオーディオ・ネットオーディオ情報&レビュー
担当SによるPCオーディオに関するあれこれ(非公式)
<< March 2024 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
 
RECENT COMMENT
  • 【御礼とご報告】「アナログレコードを自炊アーカイブしてオリジナルハイレゾ音源を作っちゃうおうぜ」イベント
    yoko (06/28)
  • 6/6(土)みんなで比較試聴!NAS用HDDでネットワークオーディオの音質は変わるのか!?
    担当S壱号 (06/09)
  • 6/6(土)みんなで比較試聴!NAS用HDDでネットワークオーディオの音質は変わるのか!?
    元マニア (06/08)
  • 6/6(土)みんなで比較試聴!NAS用HDDでネットワークオーディオの音質は変わるのか!?
    ボブ (06/06)
  • 6/6(土)みんなで比較試聴!NAS用HDDでネットワークオーディオの音質は変わるのか!?
    行けない人 (06/06)
  • 6/6(土)みんなで比較試聴!NAS用HDDでネットワークオーディオの音質は変わるのか!?
    とおりすがり (06/05)
MOBILE
qrcode
PROFILE
無料ブログ作成サービス JUGEM
 
【とりあえずご報告と御礼】4/5開催 “DSD5.6MHzライブストリーミング配信・パブリックリスニング!”
そして、その日はやってきました。
「東京・春・音楽祭」に合わせて行われた、DSD5.6MHzライブストリーミング配信実証実験。

オリオスペックでもAM11:00に合わせてリスニングを開始しました。
バッファリングからサウンドが流れるまでの10秒ほどの時間、ドキドキです。

この日、オリオスペックの環境に限ると、日本の配信サーバからのストリーミングは朝から驚くほど安定していました。
DSD128(5.6MHz) らしい空気感あるサウンドで素晴らしかったです。
ネットワークごしのリアルタイム配信というのが、ちょっと信じられない気分。

事前検証では、平日16時30分を過ぎたあたりから夜にかけて DSD64(2.8MHz) でも途切れ途切れの状態でした。
が、本番は第四部が終了する18時まで、DSD128(5.6MHz) でほぼ途切れず、泣けちゃうほど素晴らしい様相。
途切れたのに気が付いたのは、第三部終了直前の1回だけ。約10秒ほどの再バッファで復旧です。

オリオスペックの周囲の方では、「自宅試聴で全然上手くいかなかった」という方もいらっしゃいましたし、
会場でも同じようにストリーミングをモニターしていたらしいのですが、噂で聞く限りではそこでも切れていたとのこと。
今回は運が良かったのか? どうあれ、本番に強いオリオスペック(笑)


午前中の第一部開始から午後初っ端の第二部終了まではお客様がほとんどいらっしゃらず、
言うならば身内だけのようなものだったので、のんびりまったりした雰囲気。

折角の機会なので、リソースモニターやパフォーマンスモニターで状態をチェックしたり、
Wiresharkを使ってパケットキャプチャを行いながらストリーミングの挙動を観察したり、
tracertで配信サーバからの経路を確認したり。みんな寄って集ってのやりたい放題w
あと、日本以外の配信サーバからのストリーミングをテストしてみたり、
同一LAN内の別クライアントPCからもう1セッション張ってみた時の再生状態を観察したり、もしてみました。
好き物が集まってる時間でしたので、まあ “興味本位のデータ取りタイム” という感じです。


試聴イベントらしい体裁が整ったのは第三部でした。
一般のお客様に加え、某大学でオーケストラ部に所属されている男女7人の皆さんと一緒にのんびり音楽を楽しむ方向へシフト。
題名のついてる鑑賞会、そんな気分です(笑)

お客様20150405.jpg

ほぼすべてのお客様はご自分で楽器を演奏なさる方でして、オーディオマニアの方ではありません。
おまけに、ハイレゾ・DSDについてもほとんど馴染みのない方ばかり。
この点、普段オリオスペックのイベントにご参加頂くお客様とはまた違う層ですね。
そんな若いアマチュア演奏家の皆さんが感じるDSD5.6MHzライブストリーミング配信、
実際どんな印象をお持ちになったのか伺ってみました。
その感想もいつものものとは一味もふた味も違っています。コメント、本当に驚かされた次第。

少しご紹介しますと・・・

--------------------------------
すごく良かった!音自体が立っているというか、一音一音が立体的な感じというか、空間をもっているような感じがした。
個人的な感想をいうと、Fl(フルート)とかpicc(ピッコロ)がみずみずしくて聞き惚れた。
---------------------------------
聴いてみて、ホールにいるような感覚を味わえた。
特に、ピアノの演奏を聴いたとき、ピアノの音がまっすぐ伝わるような蓋側(音がよく響く方)にいる気分。
あと、譜めくりをする人が居るんだけど、歌とのデュエットの時には舞台の中にいるような気分に。
室内楽になったときも、タッチや弦のかすれ、全部の楽器が上手くハモっているところ、ホールよりも細かく聞こえてよかった。
演奏楽器や規模によって、ホールにいるとこのあたりかな・・・というように聞こえ方が変わったように感じた。
ただ、演奏を録音(?)して聴いているので、ホールで自分で好きな場所をとって聴いている時とは違い、
どんな時もハモった一定の綺麗な聞こえ方をしてるのがちょっと残念かも、と思った。
スピーカーの向きや音量を調節すると、低音寄りで聞こえたり2階席にいるような気分が味わえたり・・・と
もっと楽しめるんじゃないかなっと。個人的にはとても好きな感じだったので、家で試してみたくなった。
----------------------------------
DSD特有と言うか、録音環境の空気感をまとめて録っている様な気がするので、
その全体の空気感が丸ごとスピーカーから出てくる感覚を持った。
が、そのまとまった空気感が再生環境下の空気感に溶け込むまでに時間がかかるというのか、
そこに厚い層が1枚あるな、とも同時に感じている。
録音環境下で既に完成された空気感をそのまま再生環境下に持ってくる事により生じる違和感??の様なものも感じた。
----------------------------------

他にもこんな声がありました。

「ピアノのペダルを踏んだとき、気が付きます」
「声楽の時の息づかい、聴こえる」
「ピアノ、ちょっとミスタッチしてた。となりのキーに少しだけ触れた瞬間、わかった」
「演奏者、一瞬気が抜けた瞬間があったのに気が付いた」
そうそう、「DSDで自分たちの演奏を録音されるのは正直コワイ」 とのご意見も(笑)

楽器の向きや演奏時の操作の際の音など、「気配や空間」という部分すらちゃんと読み取っていらっしゃるのですねー。
「現地ホールの空気感と再生環境」に対する視点は個人的に興味深いです。もうちょっと詳しく伺ってみたい気分。
演奏家視点をベースにされた皆さんのコメント、ハイレゾ・DSDに関わる私たちは非常に勉強になりました。
率直な感想をお伺い出来てうれしいです。ご参加の皆さまに心より感謝致しております!

構成される楽器の多さから来る音域の広さや音色の多彩さ、ピアニシモからフォルテシモに至る小音量から大音量の差など、
クラシックは音楽としての構成要素がより多く詰まっていますから、今回の実験としては好ましい選択だったのかもしれませんね。

配信状態がよかったので、なかなか楽しかったです。
再現力、従来のストリーミングとは別次元だったんじゃないかと。
もっとお客様が関心を持ってくれればいいのにね、と皆で話していたくらい。
今週11日土曜日深夜のベルリンフィル中継が待ち遠しい気分です。


以上、取り急ぎのご報告です。

-----------------------
※4/11深夜開催 「ベルリンフィル」の
 DSD5.6MHzリアルタイムストリーミング配信パブリックリスニングのご報告と御礼は こちら
-----------------------


【余談】
▽お遊びの話

折角興味本位のデータ取りをしてみましたので、ちょっとだけ内容をご紹介。
録音技術側の解説は他のオーディオ系メディアの取材記事として既に公開されておりますので、そちらをどうぞ。
ここではPC側の専用アプリケーションと配信サーバ側の振る舞いについて、ちょっぴりお話させて頂こうかと。
分析はまだですが、なかなか興味深い事も見えてきました。

興味おありの方は “続き” をどうぞ。

 
さて、続きです。こんなネタに関心のある人っていらっしゃるのかしら?(笑)


○ Wireshark(以下、鮫)のパケットキャプチャを眺めてみますと、以下のような事が見えてきました。

鮫01_サムネ.jpg
<クリックで拡大 / IPアドレスは消してます。緑:クライアントPC / 赤:配信サーバ >

今回利用されたストリーミング規格、Dynamic Adaptive Streaming over HTTPかな? MPEG-DASHとも言うそうです。
詳しくは知らないんですが、これ、HTTPを利用した動画配信プロトコルの国際標準規格。
同じような技術は他にもあるそうですが、MPEG-DASHはオープンな規格との事。
元々は映像のVoDやライブストリーミング用で利用されるそう。
専用のストリーミングサーバでなく普通のwebサーバを使えばいいので、CDNサービスのサーバに実装しやすいんですって。
既存の実績ある技術がベースなのか。

MPEG-DASH、XMLで記述されたMPD(Media Presentation Description)と称されるファイルが鍵だそう。
ストリーミングに関する各種情報が書かれるMPDの内容を専用プレーヤーが解析した上で、
セグメント分割されたメディアファイルを指定どおりにクライアントが順々取得し、バッファリングしながら再生してく形みたい。
で、最後のセグメントになるまで “メディアファイルを取得→バッファリング→再生” を延々と繰り返すのだそう。
ライブ配信では、このMPDがストリーミング中にコロコロ変わる事もあるらしくて。
ライブ配信中はMPDのファイルが多数生成される場合があるってことかしら。
確かに都度で “GET /hogehoge/hogehoge.mpd HTTP/1.0” のコマンドを発行してます。
その挙動は鮫が食ってました。不思議に思ってたんですよね。


○ リソースモニターのTCPコネクションのグラフを見るとこんな感じ

TCPコネクション_サムネ.jpg
< クリックで拡大 >

ストリーミングしてるのでTCPコネクションは張りっぱなし。
鮫が食ったのを見ると、ちゃんとスリーウェイハンドシェイクしてるのもわかります。
ストリーミングでよく使われるコネクションレスなUDPではありません。


○ストリーミング中のPCのLANポート(タスクマネージャーのネットワークタブ)

ポート_サムネ.jpg
< クリックで拡大 >

正常にストリーミングしている状態だとこんな軌跡になるみたい。
リソースモニターのネットワークと合わせて見ると、12Mbps〜30Mbpsを行ったり来たりしてる感じ。
CPU (Corei5 3470T/35W) には全然負荷が掛かっておらず、ほぼアイドル状態です。


○ 配信サーバへのtracertの結果です。
予想どおりですが、レスポンス時間はJPNが全然早いです。ホップ数も少ないので有利ですね。

<JPN 第一部 11:00〜 ストリーミングの状態:切れなかった>
C:¥Users¥xpc>tracert xxx.xxx.xxx.xxx

JPN配信サーバ [xxx.xxx.xxx.xxx] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     1 ms     1 ms    <1 ms  ホスト01 (社内ルータ)
  2     7 ms     3 ms     4 ms  ホスト02
  3    59 ms     4 ms     3 ms  ホスト03
  4    85 ms     7 ms     6 ms  ホスト04
  5    81 ms    11 ms     3 ms  ホスト05
  6    17 ms     6 ms     6 ms  ホスト06
  7    44 ms     4 ms     4 ms  ホスト07
  8    58 ms     5 ms     5 ms  ホスト08
  9    63 ms     6 ms     7 ms  ホスト09
 10    23 ms     5 ms     8 ms  ホスト10
 11    18 ms     6 ms     6 ms  ホスト11
 12     9 ms     5 ms     7 ms  JPN配信サーバ [xxx.xxx.xxx.xxx]

トレースを完了しました。


<ASIA 第一部 11:00〜 ストリーミングの状態:切れた>
C:¥Users¥xpc>tracert yyy.yyy.yyy.yyy

ASIA配信サーバ [yyy.yyy.yyy.yyy] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     1 ms     1 ms     1 ms  ホスト01(社内ルータ)
  2    89 ms     3 ms     5 ms  ホスト02
  3    42 ms     4 ms     4 ms  ホスト03
  4    27 ms     6 ms     6 ms  ホスト04
  5     5 ms     7 ms     4 ms  ホスト05
  6    90 ms     4 ms     3 ms  ホスト06
  7    19 ms    10 ms    20 ms  ホスト07
  8    78 ms     6 ms     4 ms  ホスト08
  9    82 ms     5 ms     7 ms  ホスト09
 10   175 ms   102 ms   105 ms  ホスト10
 11   194 ms   104 ms   104 ms  ホスト11
 12   190 ms   189 ms   193 ms  ホスト12
 13   399 ms   304 ms   500 ms  ホスト13
 14   281 ms   304 ms   251 ms  ASIA配信サーバ [yyy.yyy.yyy.yyy]

トレースを完了しました。


<EU 第一部 11:00〜 ストリーミングの状態:切れた>
C:¥Users¥xpc>tracert zzz.zzz.zzz.zzz

EU配信サーバ [zzz.zzz.zzz.zzz] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1     3 ms     1 ms    <1 ms  ホスト01(社内ルータ)
  2     6 ms     3 ms     3 ms  ホスト02
  3   155 ms    10 ms    11 ms  ホスト03
  4    22 ms     6 ms     6 ms  ホスト04
  5    75 ms     5 ms    10 ms  ホスト05
  6    67 ms     8 ms    12 ms  ホスト06
  7     9 ms     5 ms     5 ms  ホスト07
  8    24 ms     7 ms     6 ms  ホスト08
  9     8 ms     6 ms    11 ms  ホスト09
 10   170 ms   100 ms   100 ms  ホスト10
 11   149 ms   124 ms   120 ms  ホスト11
 12   220 ms   220 ms   189 ms  ホスト12
 13     *      314 ms     *     ホスト13
 14   233 ms   233 ms   417 ms  EU配信サーバ [zzz.zzz.zzz.zzz]

トレースを完了しました。


<USA 第一部 11:00〜>
※データ取得せず


○ 同一のLAN環境にもう一台クライアントPCとDACを用意し、もうワンセッション追加でストリーミングも行ってみました。

同一LANで2台同時にストリーミングを受けた時の挙動も見てみたかったのです。
なんとこの日は全く影響なし。ツーセッション張っても音が途切れることはありませんでした。
第二部途中から開始して第四部終了の18時に至る長い時間において、2台ともほぼ正常稼働。
うーん、神風でも吹いたのかなあ。ちょっと信じられない気分。


○ 同じ会場のライブ映像&音声をスマホでも観れるレベルに圧縮し、同時配信していたので・・・

実は、同じ会場のライブ映像&音声を圧縮して同時配信していました。(これ、どこでやってたのか忘れました。公式かな?)
ワイヤレス回線のスマホでちゃんと見聞きできますので、その程度に圧縮してあるものです。
これとDSD5.6Mリアルタイム配信をちょっぴり比較してみたのです。
DSD5.6Mリアルタイム配信は、スマホのライブ映像&音声配信から約1分程度のディレイで流れていました。


データ取りも結構おもしろかったですよ(笑)
以上です。
 
コメント
コメントする









 
トラックバック
この記事のトラックバックURL
トラックバック機能は終了しました。
 

(C) 2024 ブログ JUGEM Some Rights Reserved.