くしゃみひどっ！

なんか噂されているのかなぁ、くしゃみがひどいｗｗｗ、まったくぅよっぱさいどのか？
あ、Raspberry Pi Advent Calendar主宰のあっきぃさんだった、きっと。すみません、ゆるして💦
で、今日から技術的な話ですが、本当はね、構図を出すつもりでいましたが、まだまだ、実は高レート音楽を流すチューニングをicecastでしてまして、ごめんなさい。あっきぃさん。書き直した後は、こっち。

Icecastの現実と高レートMP3/AAC

実はIcecastもShoutcastももうかなり廃れたソフトです。バージョンアップももうメジャーはなくマイナーリリースが出ているくらいです。で、このオープンソースが程よくメンテされていた当初はこのころは低レートで、ここに音質をもとめることはなかったので、そんなに気にすることはなかったと思います。
ただ、今は320kbps高ビットレートmp3は当たり前だし、ハイレゾ音源でFLACとかALACとかもうわんさかなわけです。わんこ！ぐらいな。
正直、IcecastやShoutcastベースの配信サーバをSLでDJの方々に貸しているサービスのほとんどは128kbpsをリミットとしての利用なっています。この理由は何？ってわかる人はネットワークをわかっている人です。ハイ、帯域を食うからです。高ビットレート配信であればあるほど帯域を食い、結果大抵のご自宅はルータ経由で1IPアドレスで外にでますから、特にSLを高設定にしてしまっている人は音が原因でSLから落ちたりしちゃう恐れもあるわけです。正直IcecastもShoutcastも128kbps配信を想定しているといっても過言ではないと思います。

可聴音域と非可聴音域

よくCD音域とかでサンプリングレートが44100Hzとか48000Hzとか聞くと思いますが、人間の耳に聞こえる音域はせいぜい20000Hz前後まで、あと人間が差し障らない音域のビットレートは128kbps前後といわれます。ある意味Appleが昔iPod Shuffleで128kpbs音源にするという設定がありましたがあれはそういう意味で、音質とファイル容量の妥協点はこの辺りがポイントになります。じゃぁ非可聴音域や、128kbps以上の音域ってなぜいるのか？というと単に、奥行き感が広がるといったところです。ペラい音質になることがある意味オーディオマニア相当なDJから辟易され最近ではmp3の最大域である320kbpsで配信する人もいます。ただ、そんなレートで配信すれば結果、さきほどいったとおりネットワークへの負荷は大きいですから、きちんとネットワーク設計やサーバ設計をしないと音がとまってしまったり、途切れ途切れやら、音データが順不同でクライアント側に配信されたり、音データが配信遅れと認識して再送をしてしまったりなど…よく言われる『音飛び』の原因になったります。ある意味、ビットレートやサンプリングレートのリミットを128kpbs/44100Hzとする理由は配信においては妥協点であるのです。

CBR/ABR/VBRとか

これがちょっとめんどくさい。MP3ファイルには実装があって、ビットレートを可変するか、固定するかです。可変をすれば、配信するデータ総容量は落ちるため、ネットワークにはありがたいですが、固定であるほうが、エンコードに時間はかかりませんが、データ総容量はでかくなるので結果ネットワーク負荷が大きくなるのでそれはそれで不便です。
端的に紹介するとこんな感じです。いろいろ実はどれが音質がいいか議論があって、参照をだしにくいので、ここはググってみてください。
CBR（固定ビットレート）
VBR（可変ビットレート）
ABR（平均ビットレート）
一般的に皆さんが使っているMP3元ファイルはVBR可変レートになります。これポイント。可変レートなので、クライアント側に左右されつつ、配信をしようとしてくれますが、常に高音質をたもらないため、不便な扱いになります。ある意味クライアント側によってはビットレートを調整してくれますが、その分音質がおちたような感じがしてしまいます。激しい音の落差がある音楽だとバレバレになりますね、VBRは。
うちの配信システムはCBRを使っています。ただ、その通り容量が大きく、ネットワーク設計やらRaspberry Piだと配信自体の負荷は大きいですからね、CBRはVBRと違って音ズレしにくいといいますが、負荷の結果やらいろいろファクターはあるのでしょうが、高ビットレート、高サンプルレートで配信した場合、一定の時間後音飛びはしてしまいます。よくググるとバッファ値をあげるといいよとありますが、実際上げてみてもどこかでRaspberry Piのような非力だからかもしれませんが、音飛びはしてしまうようです。ただ、音飛び出現率は減るので、もちろんバッファ値をあげるのはアリです。ただ、上げすぎると今度はこれ自体が断片化する＝音飛びするようなので、微妙な調整がいるようです。まじしんどい…これはバッファ自体書き込むデータ番地がアドレッシングされているわけでないので、書き込みタイミングによってはおかしくなるのかなぁ、と邪推してます。ただ、バッファ値はある値からは、初期値は一定化し、累積で伸びていくだけで、どうもCeph同様メモリを最後は食いつぶしてしまうようです、ワークアラウンドは同じ。
echo 3 > /proc/sys/vm/drop_caches
ですが、実行タイミングを考えないと音飛びしてしまうので、いまのところ15分にしています。ま、もともとRaspberry Pi手持ちのはメモリ小さいですからね、いらないキャッシュは定期的にクリーンしにないとってところなんでしょうかねぇ。

MP3Lameエンコーダ

これがさらに音質のわかる人なら、こまったちゃんなのですが、よくあるMP3配信クライアントソフト側ではこのLameエンコーダが使われ、デフォルトでは可聴音域以降である20000Hz以降は音データをカットしてしまいます。いくらいいビットレートをつかってもMP3Lameで非可聴音域を切るという所作をやるのでまいったもんです。これはエンコードをするデバイスの負荷を減らすための措置で、ま、Lameも廃れてアップデートしていないので、当初のデバイスからは仕方ないのかな、と思っています。

ALACなどの対ネットワークの仕掛け

じゃぁなんでAppleやらALACとかで高ネットワーク配信できるの？という疑問にぶちあたります。これは簡単で、Appleはきちんと言及していますが、対応デバイス側でデコードする際に高音域データに対応するためで、そりは当たり前だぁなと思うのです。素で384kbpsとかやられたらそれでも重くなる。そこでデコードデバイスは対応済みのものとする。ちなみにAppleはHomePod miniではロスレスオーディオは再生できないと設定から見られます。これは、推測ですが、ネットワーク受信型のHomePod miniではデコード対応していないのでは？と思っています。

ジャンボフレーム対応

音が高ビットレート、高サンプルレートになればなるほどジャンボフレーム対応させないと配信時にネットワーク側がCPUに余力があっても受けきれず、配信自体をicecastの場合だと配信を切ってしまうケースもあります。うちは今試験的にレンダラー、Icecastサーバ間をジャンボフレーム対応にしましたが果て大丈夫やら…ま、試験中です。

デバイスの2秒ルール（メモ）

ちょっと最近クライアントデバイスがどれくらいバッファするのか調べていたのですが約2秒だそうで…ただ、個体差はあるのだそうです。何が言いたいかというとSLで個別で聞こえなくなったとか音がおかしくなったとかは、個別問題もあるということはDJさんも念頭におきましょう。

MP3の最大ビットレートは320kbps（メモ）

これ、あたしも最近までよく知らなかった。多分これがmp3というフォーマットの限界なのでしょうけど。今うちはこれで配信テストしてます。

SLの土地音楽のMaxビットレートは192kbps(メモ)

もちろん知ってますよ。ただこれ以上で流すことに意味がないわけではない。オーバービットレート分は音の深さを作ってくれるので、間違いでないです。

結論：ストリーム配信の高音質化はかなり難しい。

これにつきます。ネットワーク負荷が大きいのとその結果、音飛びしやすくなります。正直音を追求しないで、音楽を追求するSL DJさんは、128kbps以上での配信は望まないほうがいいと思います。コンテンツ勝負で！という方は音質を追求しないほうがいいです。

で、Raspberry Piと関係あんの？

ま、こんなで、今も音楽調整中なのです、ほんと高音域再生はキッツなのです、、
まじきっつ。長時間再生での高音質はかなり無茶ですねぇ。