Jpsonicに適した楽曲管理の方法や、メディア分類の方法について記載します。
Jpsonicのミュージックフォルダやメディアの分類仕様は他のSonic系サーバと同じです。

• ミュージックフォルダを作る
• ミュージックフォルダにリッピングしたデータを放り込んでスキャンする
• 複数のミュージックフォルダが使用可能。統合して使用、あるいは個別に切り替えて使用可能

ミュージックフォルダの管理ルールはシンプルなものがハッピーです。
運用開始後の変更は負担やリスクが大きいので、気合いを入れて俺様ルールを発明すると後々困りかねません。
他のアプリとの連携も考えると、音楽の管理方法はある程度常識的な範囲に収めると長期的にルーチン管理できます。

フォルダ階層の名前や役割付けが重要なため、理由も含め解説します。
読むのが面倒な場合、絵だけでもわかるかもしれません。

ディレクトリ構成の仕様

Sonic系サーバのミュージックフォルダは他の一般的なソフトでも使用可能です。
導入負担が少なく、肌に合わなければ途中で使用を中断でき、残されたライブラリは有効利用できます。
編集用のソフト等と並行運用も可能です。

楽曲管理は「アーティスト」「アルバム」「曲」の3階層が基本

Sonic系サーバは多階層のブラウジングも行えますが、(ミュージックフォルダを除いて数えた場合)3階層管理が適しています。

ミュージックフォルダとは

Webで楽曲管理を検索すると「ジャンル」「アーティスト」「アルバム」「曲」というフォルダ管理方法を稀に見かけます。
おそらくCD屋さんでラックごとに「Jポップス」「洋楽」のような分類がしてあるのを想像されているのだと思います。

Sonic系サーバはミュージックフォルダを複数扱うことができます。

またSonic系サーバのミュージックフォルダは以下の機能を持つため、CD屋さんのパーティションを再現することができます。

• アカウント毎に閲覧可能なミュージックフォルダを指定できます(動線)
• Web画面ではミュージックフォルダごとの索引を選択してブラウジング可能です(分量)
• 設定画面でミュージックフォルダに名称を付けられます。ディレクトリ名とは別の名前をいつでも設定可能です(ラベリング)

逆に言えばこれがSonic系サーバのミュージックフォルダの定義です。
ミュージックフォルダとは「3階層の楽曲セットを管理するためのパーティションの役割を持ったフォルダ」と言えます。

3階層に並べると管理上都合が良いのだけれども、人間さんには扱いづらいときがあるので意図的に小分けするという階層です。
使用者の好みでライブラリ分割もできますが、デバイスが分散するという事情がある状況もこれに含まれます。

ここまでを簡単に図解

ざっくりとSonic系サーバのディレクトリの設計思想を図解するとこのように。
大規模な楽曲管理が目的のソフトは大体似たり寄ったりの仕組みをしています。

Sonic系サーバのフォルダ仕様は21世紀初頭に確定したものですが、おそらく今後も変わることはありません。

文字コードの取り扱いといった観点でも、ジャンルはシステムパス依存より外界に依存しないタグ管理が有利になります。
タグで楽曲の様式を分類する場合、未分類の場合別に未記入でも構いませんし、逆にマルチジャンルで高度な管理もできます。

フォルダ依存のジャンル管理ではアーティスト以下を必ず単一のジャンルに割り振るべしという不自然なルールが発生します。
さらにジャンル変更時にパスが別物になり、データベースを持つアプリは都度情報の再構成が必要になる場合があります。

ジャンルは一意に定めることが不可能な、多数の音楽が存在したときに初めて生まれる相対的な概念です。
アルバム名や曲名のように最初から決定されているわけではなく、後世の解釈や個人の基準によって変更があり得ます。
大量管理の際に、楽曲様式(＝ジャンル)の管理とシステムファイルパスの設計を混同するのは合理的ではありません。

ミュージックフォルダの分割粒度

特に不便を感じないという方は、延々と単一のミュージックフォルダ管理をしても問題ありません。
エクスプローラ管理では手動分類が必要な曲数でも、自動索引が利用可能なシステムでは負担が減る場合があります。
「仕切りで小分けにしましょう!」はコンマリさん的整理術では正義ですが、パス設計では敬遠されることも多い思想です。

家族のCDをまとめて管理するような場合は、ある程度の単位で分けると好評かもしれません。
その際に参考になるのは、楽曲の様式を表すジャンルではなくCD屋さんのパーティションです。

例えばCD屋さんでは大抵「日本のアーティスト」と「海外のアーティスト」は分けられていると思います。
英字表記の日本のアーティストと国外のアーティストが混在するインデクスよりも、分かれていた方が探しやすいです。

好みによりジャンルをそのままパーティションに適用できますが、共用する場合は多少注意が必要です。
たとえば、実際のCD屋さんでもフュージョンのCDはいつもどこにいるか曖昧です。
ユーザは一か所直観的でない分類に遭遇すると、他の分類を見るときもストレスを感じるようになるかもしれません。

多人数で共用する場合の適切な分割粒度は、曲の総量、使用者の共有感覚、動線と1ブロックの分量等に依存します。
パーティションは変更の必要性がない少し抽象的で普遍的な区分が適していて、変更可能性がある項目はタグ向きです。
(ゆえにまともな楽曲管理のプロダクトがシステムファイルパスに採用するのは、対象商品が持つ静的プロパティのみ。)

目的は手動管理を試行錯誤して楽しむことではなく、探して聴くことです。
可能な限りシンプルなルールで初め、支障を感じたときに徐々に分割を検討してみるという程度に考えた方が気が楽です。

3階層ではない場合

Web画面の概要にあるようにWeb画面は3階層管理を前提としています。
そのため余分な階層を挟むとかえって検索やブラウジングは使いづらくなる可能性があります。
エクスプローラ的な表示は一応可能ですが、あまりにエクスプローラ的な管理はSonic系サーバとの相性は良くありません。

JpsonicのDLNA機能にあるように、DLNA(UPnP)のクライアントではWeb画面とは異なる表示を選択可能です。
ただし3階層管理かつタグ管理を行っている場合が最も使いやすいです。

メディア分類

ここから先は独自実装が含まれます。
知っていても知らなくても問題はありません。

Sonic系サーバは、内部的にメディアファイルをオーディオとムービーに分類し動作を変更しています。

オーディオにはMUSIC、PODCAST、AUDIOBOOKという種別があります。
ドキュメントのどこにも書かれていないためほぼ隠し仕様なのですが、スキャン時のパス、もしくはタグのジャンルによって振り分けが行われます。

Podcast は固有名詞でありデフォルトのパス名に含まれている為、知らなくても勝手に振り分けられている可能性が高いです。

メディアファイルの種別がPODCASTやAUDIOBOOKの場合、そのファイルは楽曲のシャッフルの対象に含まれなくなります。

使用例

音楽とオーディオブックを分けてみます。

オーディオブックのフォルダ名は「AudioBook 」という名称にしてみます。

ミュージックフォルダが複数存在する場合、Web画面の左側の索引がダイアログで切り替えられるようになります。
全てのミュージックフォルダを統合した索引と、それぞれのミュージックフォルダごとの索引が使用可能です。

オーディオブックの索引を選択すると「AudioBook 」のフォルダに格納されているデータの索引が閲覧可能です。
これらはシャッフルの対象外です。

このような仕様が存在する理由

ID3の標準タグでこれを扱える仕様がないためです。
(元のデバイス種別・・・DVDだったりブルーレイだったりを表現する項目はあるが、音源の内容を分類定義するものはない)
なぜなら、もともと音声全般ではなく「音楽」を管理するためのタグであるためです。

そのため音楽以外の音声ファイルはソフトによって取り扱い方法がまちまちで、統一的な方法は存在しません。
拡張タグを用いたり、あるいはソフト側で独自の設定項目と内部データを持つパターンもあります。

個人的にはどちらも嫌ですが、SONYやAPPLEが拡張タグで音声ファイルの種別を行いだすのであれば従う予定です。
両社が独自実装のままなら、ニッチな要望であり市場に流通させるデータに含めるメタとしてデッドウェイトということです。
(この二社はあんまりオーディオブック持ってなさそうではあるけれども)

仕様的にはグレーゾーン、というよりは音楽用のタグで扱われるものではありません。
ですので設計の整合性に敏感な大手ベンダーがメタにコンテンツの種別を含めてくることはないかもしれません。
動けばオッケー的なフリーソフトはタグを埋め込んできます(褒めてない)。

一方UPnPガイドラインはメディア全般を扱う仕様であるため、それらの種別に対する定義が存在します。
Sonic系サーバのメディア種別分類自体は独自ではなく、どちらかといえばID3ガイドラインでなくUPnP仕様に準拠したものです。

JpsonicのUPnP検索ではこの分類指定に対応する実装がされています。
ただし検索対象のメディアファイルの種別をいちいち細かく分けているクライアントはあまりありません。
BubbleUPnPでもオーディオとムービーを分けて検索する程度です。

現実的にはメディアの種別はシャッフルの対象から除外する程度の用途しかありません。
Subsonicを今まで使っていて気にならなかったのであれば、特に意識する必要がない仕様かもしれません。