自分用音楽ストリーミングサーバを考える1

Overview

この記事は

mastodonしてたらjellyfinとかembyとかplexとか録画サーバの話題を見かけて気になった。

わたしの場合容量の問題が大きかったためどうするといい感じかなぁ、とか考えた結果。

ちなみにvolumioとかのMPDじゃなくて、google play musicとかamazon musicみたいなのを想定しています。

ライブラリ

  • 基本はレンタルCDからflacでインポート
  • 気に入ったものとかレンタル無いものは物理CD買ってflacでインポート
  • たまにOTOTOYで買ったりも(やっぱりflac)
  • 6000ファイル合計150GB程度

ハイレゾは妙に高いので手を出す気は無いですが、折角なら人間の可聴域分で保存してある(はず)のCDと同等の音源を持って置きたいなーとか考えた結果こんな感じになってます。

考えられる問題

重要

  • 再生するというだけならnextcloudでいいんだけど、ライブラリが巨大過ぎてスキャンがうまくいかないしイマイチ機能不足
  • flacしか無いのでこれをストリーミングは通信量が…
  • ライブラリが巨大なので適当にVPS使うと追加ディスクのお値段が大変たいへん

どうとでもなる?

  • モバイルで聴く時完全ストリーミングだとたとえmp3でも通信量的に厳しい
    • ダウンロードしておけるクライアントアプリがあるといい

実際にサーバ建てるとして

ホスト先選択肢

  • nextcloudと同居
    • Lightsail RAM 1GBプラン
    • nextcloudがsnapで動いててこのまま同居させると多分管理がしんどい
    • nextcloudをdocker構成に変えて、同じくdockerで動かせるサーバを使う?
  • :don:が動いてるVPCへの踏み台兼VPNサーバに載せる
    • EC2 t3.nano
    • EBSくっつければいいとはいえRAM 512MB無理では?(nextcloudの方も空きはそのくらいだけど)

やるとしたらnextcloudと同居。

容量問題

解決策としては2つ?

  • トランスコードしてくれるサーバソフト(madsonicとか)を使う
    • 上のホスト先で性能足りるか?
    • $5くらいならともかく$10とか出費増えると辛い
  • ストリーミングは音源ファイル分けてaacとかにする
    • 妥当?
    • 試しに数ファイルaacにエンコードしたら35MBが5MBとかだった
    • ライブラリ全体が150GB -> 22GBとかになる?
    • 余裕見て200GB : 40GBとかで予想かなぁ

今回の結論

  • flacのライブラリとは別に、aacのライブラリを持つ
  • docker頑張る
  • ライブラリ全体を変換してみなきゃわからないけど、Lightsailの追加ディスク64GB $6.4で済むと楽

エンコードさえなんとかなればそんなに大変ではなさそうです。

ただ、私のライブラリのディレクトリ構成は

  • アーティスト名\アルバム\曲ファイル
  • 大ジャンル(アイマスとか)\少ジャンル(デレとかシャニとか)\CDシリーズ\アルバム\曲

とか、分け方が混在してるんですよねぇ。

このせいで一括でエンコードというのが既存ソフトだと行えない。

要するに、 music\foo\bar\*\example.flac なんてファイルがあったら

tmplibrary\foo\bar\*\example.m4a にそのまんまのパスで移してくれるとても楽という話。

(まぁ例えば、「元ファイルと同じ場所に変換後ファイルを置く」ように全部変換した後に特定拡張子だけいい感じに移すスクリプトを書くっていうのも全然あり)

実際に建てるのかなり遠くなりそうだなぁ…。

2019/03/23追記

なんとかなりました。

comments powered by Disqus