「表記のゆれは手強いぞ」の巻
iTunes は coverArtMatch コマンドを使ってアートワークのダウンロード URL を特定するわけだが、通常はアーティスト名 (an)、アルバム名 (pn)、アルバムアーティスト名 (aan) をキーとしたクエリが送信される。このとき注意したい点としては
(1) タグが書き込まれていないフィールドは無視される
(2) アルバムアーティスト名はアーティスト名に優先される
(3) 表記のゆれなどでアップルのサーバが管理するアーティスト名やアルバム名と異なる場合、アートワークの取得に失敗する
(1) については読んで字のごとく。(2) については次のようなテストで確認できる。例えば Sara Evans と Debbie Gibson はどちらも "Greatest Hits" というアルバムを出しているが、以下のように "an" と "aan" で異なるアーティストを指定した場合、いずれも "aan" で指定したほうがマッチする(もちろんパラメータの指定順には左右されない)。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Debbie Gibson
aan=Sara Evans
pn=Greatest Hits
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Sara Evans
aan=Debbie Gibson
pn=Greatest Hits
ここで問題となるのは (3) である。例えばサーバ上にアートワークが存在するアルバムであっても、タグ情報に誤りがあれば正しく検索することができない。これは「表記のゆれ」においても同様である。その一例をこれから示したいと思う。以下は Yngwie J. Malmsteen's Rising Force の "Odyssey" というアルバムであるが、ストアにはアルバムがあるにもかかわらず 3004 エラーとなる。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Yngwie J. Malmsteen's Rising Force
pn=Odyssey
しかしアーティスト名を Yngwie Malmsteen に変更すると正しくマッチする。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Yngwie Malmsteen
pn=Odyssey
ちなみに Yngwie J. Malmsteen ではダメ。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Yngwie J. Malmsteen
pn=Odyssey
これが「表記のゆれ」である。サーバ側プログラムの検索アルゴリズムに依存する部分であり、こちらとしてはそれに合わせる他ない。こういうアルバムは意外と多く、アートワークが見つからないときは、そもそもストアにアルバムが存在しないのか、あるいはマッチさせられないだけなのかを明確にしておくべきである。拾えるはずのアートワークを放っておくのは何とも勿体無い。
さてアルバムの有無はストア内を検索すれば確認できるが、そこで使われている正しいアーティスト名を送信してもマッチしない場合がある。次のアルバムは Albert Lee & Hogan's Heroes 名義では検索に失敗するが、Albert Lee 名義ではデータを取得できる。しかし XML データ内の artistName は何と前者である。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Albert Lee & Hogan's Heroes
pn=Tear It Up
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Albert Lee
pn=Tear It Up
よくよく調べてみると悪さをしているのは "&" の部分らしい。アーティスト名を "Hogan's Heroes" や "Albert Lee Hogan's Heroes" に置き換えても検索は成功した。
結局のところ、サーバに正しく検索させるにはクエリを検索アルゴリズムに合わせる必要がある。最も手軽なのは「タグそのものを書き換えてしまう」という方法だが、正直これは不本意である。次に考えられるのは Proxomitron などで通信をトラップし、クエリを置換する方法。しかしそれなりに敷居が高いことは確かである。参考までに以下のようなフィルタを作成すれば実現できる。
[HTTP headers]
In = FALSE
Out = TRUE
Key = "URL: iTunes Artwork (substitute)"
URL = "ax.itunes.apple.com/WebObjects/MZStoreServices.woa/wa/coverArtMatch*"
Match = "$LST(iTAW-Substitute)"
iTAW-Substitute リストの中身はこんな感じ。
$URL(\1%20%26%20Hogan's%20Heroes\2) $RDIR(\1\2)
$URL(\1J.%20Malmsteen's%20Rising%20Force\2) $RDIR(\1Malmsteen\2)
$URL(\1J.%20Malmsteen\2) $RDIR(1Malmsteen\2)
ただしこれはあくまで一時的な回避策である。なぜならアーティスト名の書き換えだけでは対処しきれない場合があるからだ。それが以下のアルバム。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com
an=Kansas
pn=Kansas
<Document xmlns="http://www.apple.com/itms/" disableHistory="true" disableNavigation="true">
<Protocol>
<plist version="1.0">
<dict>
<key>pings</key>
<array></array>
<key>status</key>
<integer>0</integer>
<key>cover-art-url</key>
<string>http://a1.phobos.apple.com/us/r1000/018/Music/f2/14/32/mzi.dgzjndad.enc.jpg?downloadKey2=1242147193_f27e9f636a7e9e482b2b31c5c3a75364</string>
<key>request-delay-seconds</key>
<string>.1</string>
<key>artistName</key>
<string>Kansas</string>
<key>playlistName</key>
<string>The Best of Kansas</string>
<key>artistId</key>
<string>460828</string>
<key>playlistId</key>
<string>158580313</string>
<key>matchType</key>
<string>0</string>
</dict>
</plist>
</Protocol>
</Document>
検索は成功するのだが、返される情報が "The Best of Kansas" という別のアルバムになっている。おそらくキーワードが部分一致で検索されるため、本来マッチしてほしい "Kansas" アルバムより先に "The Best of Kansas" がマッチしてしまうのだろう。現時点ではキーワード検索の限界だと思われる。これ以上正確にマッチさせるにはアーティスト名やアルバム名ではなく、アルバムを一意で指定できる ID のようなものが必要となるだろう。実はそれが playlistId であったのだが、その解説はまた次回・・・。
[本章のまとめ]
アーティスト名やアルバム名を使ったキーワード検索は精度に限界がある。