・「こばと。」
地上波NHKで放送していたときにちゃんと追っていたのに、最後の2話を残した段階でストップしてしまい、観ていなかったのを遂に観終えた。実に3年以上も放置していたことになる。最後の方で観るのを止めてしまう場合というのは、大体が名残惜しいという理由によるものであるが、今回は名残を惜しみ過ぎた。とはいえ、この作品の出来は素晴らしく、本当に久しぶりに見たOPで、しっかりその世界に引き込まれた。主人公、花戸小鳩の声を担当しているのは花澤さんであるが、「こばと。」は私がこれまでに観た花澤さん主役級作品の中でも3本の指に入ると思う（残り2つは「海月姫」と「PSYCHO-PASS サイコパス」）。OP主題歌はCDを放送当時に購入済み。
・「ノラガミ」
x1.3で観ているが、面白いぞ。とても真面目にアニメを作っているような印象を受ける。
・「桜Trick」
x1.2で観てる。とてもじゃないが落ち着いた心持ちでは観れない。しかし、出演声優の演技は楽しめる。主題歌は購入済み。
「Fate/Zero」のBDを全て観終った。再生速度も上げず、OP&EDもスキップせず、持ってる中で一番いいヘッドフォンを使い、真剣に観た。感想を長々と書いてもいいのだが、私の文章力がこの作品をレビューするのに十分か甚だ疑わしいので止めておく。「Fate/Zero」はグラフィックや音楽の出来が他の作品を凌駕しているというだけではなく、ストーリーが圧倒的に凄い。私は原作小説も読んでいるが、アニメ版でもその素晴らしさは生きている。なお、BD版では追加されたカットが結構あるとどこかで読んだ覚えがあるのだが、TVシリーズを2年前に観たきりだった私は、あまりその箇所に気づけなかった。
「面白い話をしよう | Mizukama Blog」に続く記事である。
私自身が面白い話を次々繰り出せる人間ではないのだが、面白い話をする人間にはなりたいと思い、その方法論を考えている。（←前の記事からコピペ）
私が思うに、面白い話のネタを持てるようになったら、次のような能力の習得を目指すのが良い。
1. 声の調子や身振り手振りによるリッチな描写
2. 聴衆を観察する
3. 相手を巻き込む話の進め方
1.は要するに、純粋なアウトプット能力の向上である。話のスピード、声の大きさと高さ、それらを変化させて緩急つけたトークにする。場合によってはモノマネを挿むこともあるだろう。必要であれば身振り手振りも導入する。トークが上手いと言われる芸人は、これらの能力に長けている。一本調子の話ではなく、リッチな描写を伴うことで、聴衆を惹きつけて、多少盛ったような話しでも納得させることができる。ただし、人によっては普段の何気ない話し方が面白く、無理に他人を真似するとかえって面白さが減少するということも考えられるので、難しい。
2.は3.を習得するためにも欠かせない。相手を観察しながら話をすれば、もし相手があまり愉快に思わない話を始めてしまったときでも、早々に切り上げたり、相手の機嫌を回復するための補足を入れることができる。相手に合わせたトークを繰り出せるというわけだ。そうでないと、相手がつまらないと思っている話を長々と続けてしまうことになり、「話のつまらない人間」のレッテルを貼られてしまうことになりかねない。
3.ができるようになると、トークが一方通行ではなくなる。簡単な例を出すと、話の冒頭で「これ知ってるか？」と尋ねたり、中盤なら「普通そう思うだろ？」と同意を求めたりするのだ。自分が用意した面白い話をしよう、という意気込みの時は、決して相手と議論しようと思っているわけでは無いので、質問や同意を求めるときは、相手がすんなり答えられるものがいい。2,3択で答えられるような質問なら、相手が話しベタでも返答が期待できる。聴衆が腹数人いる場合では、全員が自分の話に耳を傾けているとは限らないが、開いている人の顔を見て、相手を自分の話に参加させるようにすれば、場にいる人間を惹きつけることができる。わざと話にツッコミどころを作るなどして、相手が合いの手を入れてくれるようにする、というのができれば上級者だと思う。
「MPDは殆どリソースを消費しない」と説明されていることがあるが、設定によっては結構な負荷がかかることもある。その辺の勘所を書きたいと思う。
MPDに大きな負荷がかかる場合と言うのは、主にサンプリングレートの変換を設定した場合であろう。いわゆるアップサンプリングである。
CPU: Phenom x4 945 (3.0GHz 4 core)
OS: Ubuntu 12.04 LTS 64bit
MPD: 0.16.5
の環境で試したところ、
audio_outputの項目で
format "1764000:32:2"
なおかつ
samplerate_converter "Best Sinc Interpolator" (最高設定)
を指定し、CDからリッピングしたApple Losslessのファイルを再生したとき、MPDのCPU使用率はTOP読みで50%程度（1コアの50%ということ。以下同様）を前後する。
format "1764000:32:2"
のまま、samplerate_converterの項目をコメントアウトしてやる（デフォルト設定になる）と、CPU負荷は15%程度になる。
なお、
samplerate_converter "Best Sinc Interpolator" (最高設定)
のままで、
format "882000:24:2"
に設定してもCPU使用率は50%前後になるので、samplerate_converterを最高設定にしてアップサンプリングする限り、Phenom x4 945で1コアを50%程度使う程度の負荷はかかるということである。
だから、MPDでアップサンプリングを使い、最高設定にしたければ、Raspberry Piなどの低スペックボードでは無理である。AtomやAMDのEシリーズ等の低電圧版x86でも厳しい可能性がある。
次に、MPDをRaspberry Piで使うときの勘所を書きたいと思う。環境は以下の通り。
CPU: ARM1176JZF-S (700MHz)
OS: Raspbian 2014-01-07-wheezy
MPD: 0.16.7
DAC: UCA222
アップサンプリングを行わない場合、MPDで再生中の負荷は平均すると大体10%前後である。が、これが80%程度に達することがある。MPDクライアントからライブラリの更新をかけたときのことである。Raspberry Piのような非力なマシンで膨大な音楽ライブラリを有している場合は、MPDがクライントにライブラリの情報を伝えるだけで、CPU使用率が跳ね上がるのだ。sambaなどで他のサーバーに置いてある音楽ファイルにアクセスしている場合には、ライブラリの更新時に当然のごとくsmbfs等の負荷も高まり、場合によっては100%近くに達することもある。また、新しい曲を再生するよう操作したときも、MPDのCPU使用率は上昇する。これは、MPDが再生する前に曲のデコードを行い、メモリに入れる作業をするためと思われる。大まかに言うと、平均10%のところ、再生開始直後は50%ぐらいまで上昇する。
さて、ここで問題となるのはCPU使用率が跳ね上がった時に、機器の組み合わせによってはノイズが発生するということである。全体のCPU負荷が100%に張り付いていなくても、ノイズの発生は明らかにCPUの負荷が増大した時に頻度を増すのである。この原因について私はよく理解していないが、CPUの負荷が上昇すると、USB通信の質が低下するということではないかと思う（つまり、デコード自体が追いついていないという訳では無いだろうという考え）。そう考えると、mpd.confの中で、”audio_buffer_size”と”buffer_before_play”の設定と音質に関する通説にも少し解が見えてくる気がする。
（参考）
Voyage MPDの使いこなし | PCオーディオ実験室
他のサイトでも多くが共通して書いているのは、”buffer_before_play”は100%が良い、”audio_buffer_size”の値は大きすぎても小さすぎてもいけない、の2点である。普通に考えると、リソースに余裕がある限り、なるべくバッファーサイズは大きくするのが良いように思えるのだが、これは前述の点を考慮すると反論が可能である。つまり、バッファーサイズを大きくしすぎると、MPDは再生を開始後（プレイリストで次の曲が分かっているような場合ではなく、新規に再生を指定した場合を想定している）に大量のデコード作業をこなさなければならず、CPU使用率の高い状態が続き、ノイズが発生したり音質の低下が生じる、ということである。また、”buffer_before_play”は、バッファーに入れてある分が指定割合以下になるとデコードを行うという指定であるため、この値が低いと、CPU負荷の推移に山ができることが予想される（つまり、”buffer_before_play”が100%の場合は、常にデコードをするが、”buffer_before_play”が10%の場合はバッファー量が”audio_buffer_size”で指定した値の10%以下になると100%分になるまでデコードをする、ということ）。よって、再生中にCPUの負荷が高まるタイミングが生じ、そのときにノイズの発生や音質の低下が生じると考えられる。理想としては、デコード作業を完了させてメモリに格納してから再生を開始するのが良いようにも思えるが、それだと操作と再生開始にタイムラグが生じることになるだろう。
もし本当に「CPUの負荷が上昇すると、USB通信の質が低下する」という現象が生じているなら、いわゆる”オーディオ用USBホスト機器”というのも意味があるように思えるし、Raspberry Pi関連のプロジェクトで行われている、USBを介さないi2s DACというのも有効そうだと思われる。また、Raspberry Piの場合は割と細かくオーバークロックやダウンクロックの設定が可能なので、それがどう影響するかも興味がある。ただ、Raspberry Piをわざわざ使うよりは、もう少しましなUSBチップを載せているマザーボードを使うとか、PCIやPCIe接続のちょっといいオーディオボードを取り付けて出力させる、とかの方が確実そうな気がする。