オタクソングメタデータ管理前線 in iTunes 2016

このエントリは #kosendj Advent Calendar 2016 の 4 日目です。

3日目のエントリは、id:asonas さんの #kosendj のやりかた - 良いあそなすちゃん でした。


今年の 9 月に開催された KosenDJ-bu #9 に参戦した polamjag です。タイミングを縫ってまた出たいですね。普段はつくばで生活をしています。


まえがき

オタク特有の「複数アーティストの区切りバラバラ問題」に対応する - ハクチョウノミズウミ

わかるんだけど、たとえばアイカツ!曲の "わか・ふうり・すなお from STAR☆ANIS" とかどう分けるんだみたいな話になりませんか / あと iTunes は (UI が) がこれに一切対応してないんだなあ

2016/06/03 12:52

こちらの記事を読みましてのアレという感じで書いていたわけですが、長いこと下書きの肥やしになっており、しかし、そのまま肥やしにしておくのはもったいない感じがしていたので、#kosendj Advent Calendar 2016 に便乗して投稿しようという作戦です。


原始

アーティスト表記の難しさについて、上のコメントで挙げたものより複雑な例を挙げると、たとえばこのような CD が存在する。

Amazon におけるアーティスト表記 *1 には、

あろま&みかん&らぁら&みれぃ&そふぃ(cv.牧野由依渡部優衣茜屋日海夏、芹澤 優、久保田未夢

とある。しかしながら、CD のタイトルにもあるように、劇中においてはこのメンバーが "そらマゲドン・み" というユニットとして活動をしたということになっている。

ところで、この CD のブックレットにおいて、 "そらマゲドン・み" として歌唱した曲のクレジットはこのように表記されている。

f:id:polamjag:20160603162933j:plain (エイベックス・ピクチャーズ EYCA-10539 ブックレット 1 ページ目より)

一方で、販売元の商品ページには次のような記載がある。

アーティスト名:そらマゲドン・み(cv.茜屋日海夏・芹澤 優・久保田未夢牧野由依渡部優衣

また、このアルバムは Spotify でも配信されていて、そちらでは

そらマゲドン・み(cv.牧野由依渡部優衣茜屋日海夏、芹澤 優、久保田未夢)

という名前の単一のアーティストとして登録されているように見える *2

表記ゆれのことは一旦置いておいて、アーティスト欄が複数の値を列挙することに対応したとしても、このような構造を持ったアーティストを表現することは困難だと思っている。

というわけで、デカイことを言っているという感じになってしまったけど、楽曲のメタデータを "正しく"、もしくは "きちんと" 管理するというのは (様々な理由から) 大変な困難を伴うという前提を共有したうえで、どのように少しでもマシな状態に持っていくかという小手先のどうしようもないバッドノウハウについて述べる。

また、複数の理由から iTunes を唯一かつ絶対的・中心的な音楽ライブラリとしているという事情があるので、このエントリではそれを前提とした記述をする。ここで述べるものは、自分がよく聴き、また収集している楽曲のジャンル・文脈 *3 に依存している可能性が高いことにも注意して欲しい。

これは余談だけど、iTunes は最近クラシックとかオペラみたいな楽曲に特化したメタデータ関連の新機能を導入しているが、そのへんのは一切使っていない。

バッドノウハウ

以降、 メタデータのフィールド名について、区別するために英語で表記する (例: Album, Genre)。とくに強調したい場合は Artist のようにマークアップしてある。

スマートプレイリスト

とにかくあらゆる目的でスマートプレイリストを使っているし、オタク楽曲以外でもスマートプレイリストを乱用している。やりすぎていて、あまりスマートとは言えない気もする。

Criteria

ありがちなフィルター (オフボーカル、ソロ歌唱・別メンバー歌唱、…) *4 をそれぞれ一つのスマートプレイリストなどに集約し、それと別のプレイリストとを組み合わせたスマートプレイリストを作成することで、ある程度複雑な条件からなるスマートプレイリストの量産にかかる手間をかなり軽減できる。

iTunes においては、プレイリストフォルダも、そのフォルダが含むプレイリストの全楽曲を含むプレイリストとして扱うことができる *5 。この包含関係みたいなやつを利用することで、集合演算のような感覚でスマートプレイリストを量産できる。

たとえば (and (not "オフボーカル音源を集約したプレイリスト") ("アニメ α の楽曲全部が入ったプレイリスト")) という条件を指定することで、"アニメ α のボーカル曲だけ入ったプレイリスト" を作成できる。

固有名詞

少なからず "構造" を持っている情報について、どのように単なる文字列として表現するのかということについて考えていく。

Artist や Album Artist などについては、基本的に正規化のような行為を諦め、"原典" *6 になるべく忠実になるよう表記することにしている。

例外として、()[]{} などの一部記号は基本的に半角に統一している *7。これに深い理由はなくて、完全一致検索を楽にするのが最大の目的。また、人名の分かち書きについては、日本人の名前を日本語で表記するときに限っては分かち書きしないほう *8 で統一している。これも完全一致検索の手間の軽減が目的。

Genre

たとえば、Genre はたいてい前者に分類されるものだと思う。ロック とか ポップ とか、そういう標準で定められた奴しか使わないのであれば機能しにくいような気がするけど、自分なりに適当な規則を付けてやるとそこそこ効果を発揮する。

ちなみに、いくつかのジャンルについては、以下のような階層構造を取るようにしている:

-+-- Anime (アニメ関連)
 |   +-- Anime / Drama      (アニメ関連コンテンツのドラマトラックなど)
 |   +-- Anime / Soundtrack (アニメのサントラ)
 |   +-- Anime / Remix      (アニソンのリミックス音源)
 |   |   +-- Anime / Remix / Drum & Bass (アニソンをドラムンベースにリミックスしたやつ)
 |   |   +-- Anime / Remix / Dubstep     (アニソンをダブステップにリミックスしたやつ)
 |   :   :
 |
 +-- Pop
 +-- Drum & Bass
 +-- Dubstep
 +-- Electro House
 :

このような構造により、

  • GenreAnime から始まる: アニメ関連楽曲全般
  • GenreAnime と完全一致: (ボーカル入りの) 普通のアニソン
  • GenreAnime / Remix から始まる: アニソンのリミックス音源全般
  • GenreAnime / Remix完全一致: アニソンのリミックス音源 (ジャンル指定無し)
  • GenreDrum & Bass を含む: ドラムンベース楽曲全般 (アニソンをドラムンベースにリミックスしたものも含む)
    • GenreDrum & Bass を含むが、GenreAnime を含まない: アニソンリミックス以外を含まないドラムンベース楽曲

みたいな感じで、まあまあなんとなくマシな感じにできる。スマートプレイリストの条件で "から始まる" と "を含む" と 完全一致 を使い分けるのがミソ。ここではアニソンに限った話として具体例を示しているけど、他の何かにも応用できると思う。

とはいえ、これにも限界があって、あらゆる事柄をこのように階層化出来るわけではないので、様々な問題が生じる。

これは完全に自分の話なんだけど、複数の細かいジャンルを併記したいという場合にも / 区切りを使っていて、あるジャンル名の文字列において / が階層を表すものなのか併記を表すものなのかは文脈による、という状態になってしまっている。とはいえ、別の文字にしたところで何かが解決するというようなものでもないし、とくに変えるつもりもない。

Grouping

iTunes のプロパティ画面には、Grouping (日本語だと グループ) という欄がある。これは、ID3 タグの TIT1 フレームに相当するもので、

The 'Content group description' frame is used if the sound belongs to a larger category of sounds/music. For example, classical music is often sorted in different musical sections (e.g. "Piano Concerto", "Weather - Hurricane").

id3v2.3.0 - ID3.org

とある。が、なし崩し的にこの欄にレーベル名を保存している。ほんとうは TPUB フレーム がそういうのを保存するためのフィールドなんだけど、iTunes のプロパティから編集することができないし、スマートプレイリストの条件にもできないので、仕方なくこのようにしている。然るべきときが来れば、適当にスクリプトを書いてガッと変換するということになろうかと思う。

余談

Pioneer DJ の rekordbox とか、Traktor とか Serato DJ とかみたいな、PCDJ ソフトウェアは、"そういう" 用途に特化した、合理的なメタデータ管理機能が備わっている。特に rekordbox はかなりよく出来ているように感じる。しかし、様々な理由からそれらをメインの音楽プレイヤーや楽曲ライブラリとして使うことは難しく、今日もこうして iTunes を使っている。

サブスクリプション型サービス

(メタデータの壁というか、メタデータスキーマの壁)

Spotify では、複数人による楽曲はそれぞれ個別にアーティストへのリンクが貼られているし、リミックス曲を選択して "アーティストを表示" すると大抵はリミックスした人が表示されるようになっている。

いくつかオタクソングを確認したところ、少なくともエイベックス・ピクチャーズの楽曲については "キャラ名 (cv.声優名)" のような形式でアーティストが登録されていた。複数キャラクターによる楽曲は、それが複数並んでいるという感じで、声優で曲を絞り込むには普通に検索するしかない感じだった。

このへんの話を裏返すと、ユーザーがメタデータを操作することができないので、表記ゆれやミスとかがあっても、それを報告して直してもらうことしかできない、というような気もする。

MPEG-7

あと、ちょっと前に調べていたときに、ご存知 Moving Picture Expert Group こと MPEG が策定した規格として MPEG-7 (ISO/IEC 15938) というものをみつけた。雑に説明すると、XML でコンテンツのメタデータを書けるみたいなやつ。

XML Schema をざっと眺めたところ、このような状態だったので終了している。

iTunes の限界

ここまで述べてきたようなことをやりつつ iTunes に 2 万曲くらい入れると *9 *10 ほんとうに動作が重くて大変という感じになる。とくに、ライブラリに変更が入るような操作をすると、絶対に数秒は操作できないみたいな感じで、曲のプロパティを編集したり CD をインポートするときは集中力が必要、という世界観になる。今は Spotify のデスクトップクライアントの方が操作時のストレスが少ないような気もする。

このような記事などもあるが、現状ではまだまだやっていく必要があるような感じがする。

結論

ここまでやって何が嬉しいんだという感じもするし、正直何もしないのと比べて何が便利になっているのかは自分でもよくわからない。ただ、自分は曲名を覚えるのが苦手で、「こういう感じのメロディで、たしかジャケットが緑っぽかったはず」みたいな思い出し方をよくするので、絞り込み表示をする手段が多いに越したことはないだろう、という考えからこのような行いをやっている。

というわけで、以上は全く僕の持論なので、よりよい方法があれば是非教えて欲しい。

*1:これはいわゆるアルバムアーティストに相当すると考えるのが妥当と思われる

*2:マウスホバー時の underline をみることで、複数のアーティストが登録されている場合はそうわかるようになっている

*3:ダンスミュージック・アニソン・ポップス …

*4:自分の中では Criteria と呼んでいて、そのようなスマートプレイリストをそういう名前のフォルダに全部隔離している

*5:iOS のミュージックアプリだとなんか違ってめんどいよね

*6:ブックレット、ジャケット、Web サイトなどのディスコグラフィ著作権管理団体のデータベース など

*7:わざと全角文字を使用していることが文脈から明らかであればそのままにする

*8:"木村拓也" と書くか、"木村 拓哉" と書くかみたいな話で、ここでは前者

*9:Apple Music とか iTunes Match とかは一切使って無くて、全部ローカルにファイルを置いているだけ

*10:現状 iTunes Library.itl が 13 MiB, iTunes Library.xml が 57 MiB くらいあるっぽい