READMEに書いてあるような概要/歴史/機能をまとめています。
Jpsonicって何ですか
Jpsonicはフリーのミュージックストリーミングサーバです。
サーバに標準装備のウェブアプリでHTMLプレイヤーとして使用でき、Subsonic用スマホアプリやUPnPアプリを接続して使用することもできます。
個人用のストリーミングサーバとして、日本でも最初期から知られているSubsonicというサーバがあります。JpsonicはSubsonicの子孫にあたり、基本的な機能も使い方もほぼ同じの日本人向け対応が行われたサーバです。日本語を適正にブラウジングするための機能修正や、日本人がよく使う機能の強化が行われています。
日本語処理の追加により遅くなりそうなイメージがありますが、速度対策も同時に行われているためオリジナルよりも速くなります。またSubsonic/AirsonicはJava8で動作しますが、JpsonicはJava11/Java17をサポートしています。
Jpsonicのルーツ
JpsonicはOpen Subsonicから派生したAirsonicをベースに開発された、日本語機能強化版Subsonicのようなものです。
- Subsonicはもともとオープンソースでしたが現在クローズドソースです。
- Subsonicクローズ時にフルフォークしたサーバがLibresonicです。
- AirsonicはLibresonicの後継で、最も盛んなコミュニティを持ちました。
- JpsonicはAirsonicを日本人用に強化したサーバです。
Jpsonicの特徴
Subsonicの機能を持つサーバには、Subsonicのソースコードから直派生しているサーバと、別のプロダクトにSubsonic APIを後付け移植したサーバが存在します。Jpsonicは前者でありSubsonicに似た仕様をしています。そのためSubsonicからの乗り換えの先の一つとして検討するのに適した機能構成といえるでしょう。SubsonicとJpsonicの違いという記事に詳細があります。
- 「聴く」「探す」機能の修正が優先されます
- どちらかといえばバグフィクスや品質向上を重視しています。そこで手詰まりになるプロダクトが多いためです
- 使用言語はJava、またJetty/Liquibase/Lucene/ANTLR等の超鉄板プロダクトで構成されており長期安定利用が見込めます
- 王道構成ゆえ、セキュリティ更新やバグ更新の頻度は高いです
Subsonicっぽさは維持される
海外のミュージックサーバ関連のフォーラムでも、未だに「Subsonicっぽい良さ気なサーバない?」といったやりとりがされます。この「Subsonicっぽい」というのはおそらく以下のあたりを指します。特に曲を大量管理するユーザに重視されるポイントです。
- ライブラリの3層管理を基本としていること。ミュージックフォルダと分類の方法に記載があります
- フォルダ/タグの両方を扱えること。Web画面の概要に記載があります
- Subsonic APIに対応していること。Subsonicアプリがすぐ使えること
Subsonic APIがサポートされているサーバでは必然的に上記の条件が満たされます。そのため動作仕様はほぼ同じ「Subsonicっぽい」ものになるはずです(そうでない場合、実装は劣化しています)。もちろんJpsonicでもこれらの仕様は今後も変更されません。
軽視されがちな部分を整備する
似た動作仕様になりがちな他のSubsonicサーバと比べた場合、違いが表れやすい部分は以下のような部分です。Jpsonicは多少ダーティーなデータでも自動で日本語索引/ソート/検索が利用可能になっています。
- 真の日本語対応
- ・日本語索引/ソート/検索等のメタ処理が日本語用に再実装されています。処理をバイパスしたり内部でローマ字化も可能です
- ・タグ抜けを内部でマージ/補完。不備のあるデータもまとめて整理可能であり、日本語音声入力にも対応可能です
- ・実際には日本語以外の多くの言語にも配慮されています。Subsonicマルチバイト言語対応版に近いです
- UPnPの再実装
- ・ハイレゾのストリーミングにも対応しています。ExperiaとLDAC機器との連携も簡単になります
- ・UPnPアプリにおいても、日本語の索引/ソート/検索等が利用可能です
- ・UPnPの整備により連携可能なスマホアプリが格段に増えます
- 多数のバグ修正
- ・一度起動したら数年稼働が可能な品質が必要です。多くの改良が行われています
速度が速く精度も高い日本語処理がなければ、いずれスマートリストや未知の高次機能を開発するときに詰まります。またタグが完璧でなければ正常動作できないサーバでは、将来にわたって多大なタグ管理コストがかかります。
巨大なライブラリをブラウジングする場合、それを前提とした通信仕様を持つUPnPを真っ先に整備するのが合理的でしょう。
あんなこといいなできたらいいなは一杯ありますけれども、ストリーミングサーバにとっての再重要機能は実はこのあたりです。個人的にはこれらが実現できていなければ、その他がいかに多機能であろうとストリーミングサーバとして及第点になりません。
今後の方向性
現在スキャンの改善が行われており、しばらくすると高速化される予定です。ぼちぼちDocker対応を行おうと考えています。それらがひと段落したら、スマートリスト等の新機能を追加していく予定です。
画面は全部作り変えたい気持ちはあるのですが、下手するとその時間は丸々ロスになるためペンディングしています。統計的にも「音楽を聴く場面」の上位にくるのは、通勤、通学、ドライブ中、家の中での上位は台所等で、PCでの視聴はむしろ下位です(コロナ禍後のデータは見てない)。年代別傾向としては若い人こそPCを使わないので、年々減少傾向です。極端な話、ガワ(Web画面)は客寄せ機能です。ただし完全に軽視しているわけではなく、シンプルに作り替え、アイコンはIonicにし、設定画面も整理しています。仮にごっそりモダンなフレームワークに作り変えたくなった場合に備え、見積もりがしやすいようにしてあります。
外部サービスとの連携は今後基本ありません(技術的に必要性があるものはPodcast検索くらい)。特に外部サービスとタグ処理を繋げるということは一切しません。日本人、というよりも邦楽にとってメリットが薄いためです。本家CDDBであるGracenote以外のサービスでは曲データのカバー率が落ちます。がんばって作っても実用性は頭打ちであり、速度面でも蛇足になります。
いつか有料版になるんですか?
なりません。Githubで★を押して頂くと追い風になるかもしれません(★でしか判断できない方もいらっしゃいます)。
解説を書いてくれたりスクリプトを作ってくれる方々にはとても感謝しています。この場で謝辞を。
インストールしてみた系記事や関連するTipsのご紹介はいつでも大歓迎です。特定コードを解析してココこうやってんのかヘーという記事も問題ないです(ググればあるだろ・・・ないから書くか・・・みたいなことはしばしばありました)。
私自身が特定機能について、このサイトやGihtub以外で会話に応じることはありません。単純にトラッキングに不向きなためです。場外での情報のやり取りは検証、更新、クローズが行われないため非建設的です。ソリューションに繋げるためには、バグ報告等はGihtubかこのサイトに書き込んで頂ければ幸いです。
一緒に開発したい場合
なにかご提案がある場合、Githubに英語でプルリクしてください。日本語でご相談したい場合、Qiita的などこかに土俵を作って「こんな風にするのがよいと思う」的なやり取りの方法でもOKです。もちろん不要とみなされれば却下されます。
Qiita的なサイトの規約的にそのような使い方が許されるかどうかは知りませんが、まとめ方にもよるのではないかと思います。Jpsonicで行っているのは、10年以上前に作られたJavaプロダクトの再実装です。つまりIT分野のお仕事では割と比重多めの分野であり、むしろ増えていくか減らないテーマのひとつです。般化可能な題材についてそれなりのストーリーや考察が含められた記事であれば、一定の公益にかなう可能性があるのではないかと思います。
範囲はプログラムに限らず、デザインでもテストでもプロジェクトの管理方法でも、なんでもOKです。アイデアだけというのは時間の無駄になるため、将来ご自分が単独で実現するつもりの範囲でお願いします。
forkしたり魔改造していいですか?
ライセンスの範囲内でご自由に。複製プロジェクトでのコードの改編や改変コードの公開に、許可は当然いりません。
- Forkを作成して処理を書き換えて公開してください
- 修正版の再頒布を行いたい場合、プロダクト名が重複しないよう適切なブランドチェンジを行ってください。ApacheやSpring等はプロダクト名の再利用をきつく禁じており理由も記述しています。名称の詐称を許容した場合経緯がわからないユーザは混乱し、プロジェクト潰しが可能になったり共倒れをする原因になります。長期的にみると不幸な結果を招きます。
- もし本気で並行プロジェクトをご希望であれば、チームへの追加も可能です。
コメントはまだありません