ねとらじヘッドライン取得ツール開発資料
■RAZIEやDolphin、MacではNow Headline XやLadioManagerをはじめとする「ねとらじヘッドライン取得ツール」を自分で作ってみる上で参考になることが多少なり書いてあるかもしれない資料。
■今日のねとらじヘッドライン取得ツールが参照しているファイル
ねとらじヘッドライン取得ツールの類のソフトウェアを使用していない場合は一般的に
http://live.ladio.livedoor.com/ を参照してインターネットラジオを視聴することになるが
ねとらじヘッドライン取得ツールがここのHTMLを分析して番組表を生成しているわけではない。
livedoorねとらじでは、こういったツール向けにテキスト形式で番組一覧、番組の情報（これをヘッドラインという）を提供おり、
WindowsやMac OS Xプラットフォームで動作する各種ねとらじヘッドライン取得ツールのほとんどがこれを利用している。
livedoor ねとらじナレッジベース:ヘッドライン取得ツールへの情報提供について
http://blog.livedoor.jp/ladio_guide/archives/13607162.html
■ヘッドラインファイルには大きく分けて２つあるようだけど？
最近になってlivedoor社内での「ねとらじ部門の担当スタッフ」が変わり、積極的にいろいろといじる人物が担当になったため
livedoor ねとらじ内の様々な部分が改革されている。
例えば、livedoorねとらじの新ストリーミングサーバ設置であったり
ねとらじ公式のヘッドライン取得ツール"Dolphin"ならびに公式放送ツール"Beluga"の開発などがそれにあたるが
その中の一つに「ヘッドラインファイルの形式変更」がある。
なぜ２つあるかというと、今までのヘッドラインファイル利用しており
開発停止などの様々な理由によりバージョンアップによる新形式への対応ができないと思われる
ねとらじヘッドライン取得ツール(RAZIEなど)への影響が懸念されるため、旧形式のヘッドラインファイルを残したまま
番組に関する情報提供を拡張するため、新形式も新しく配信されることとなった。
livedoorねとらじでは、これから新しくねとらじヘッドライン取得ツールを開発する場合
または既存のねとらじヘッドライン取得ツールの開発者向けに、対応できる場合は新形式(list.dat)の使用して設計することを推奨している。
■新形式のヘッドラインファイルで拡張される内容とは
２００７年１１月より提供が開始された新形式のヘッドラインファイル（ファイル名はlist.v2.dat、またはlist.v2.zdat）では
放送側の配信用クライアント(WinampやLadioCast等)から送信されている曲名情報、番組のサンプルレートや
以前はlivedoorねとらじのウェブサイトでのみ確認可能だったMAXリスナ数の値なども参照可能となっている。
また、旧形式で提供されていたXMLやCSVフォーマットは、これらの形式を利用したヘッドライン取得ツールがあまり存在しないなどの理由で提供されていない。
よって、この新形式ではDAT形式での提供のみ行われているが、このDAT形式にもgzip圧縮されて提供されているものとそうでないものがあり
livedoorねとらじ側にはgzip圧縮されたヘッドラインファイルを利用することにより
ヘッドライン配信サーバが使う帯域を削減したいという思惑があるため
可能な限りgzip圧縮版のファイルを利用するようにと呼びかけている。
■実際にアプリケーションからヘッドラインファイルの取得する方法
ここでは新規にアプリケーションを開発する前提で話を進めるため「新形式のヘッドラインファイル」の取得方法について解説する。
gzipではなく無圧縮版をつかって解説するが、実際のアプリケーション開発ではgzip圧縮版を使うようにしてほしい。
★いくつかの注意点
・適切なヘッドラインファイル取得間隔について
list.datは通常、６０秒おきに生成されているため６０秒以内の間隔で取得しても無意味とされている。
しかしながら更新間隔が６０秒キッカリではないことが多いため、実際の開発では７０秒おき、もしくはもっと短い間隔で取得したほうがいいかもしれない。
・User-Agentヘッダ
ヘッドラインファイルを取得する際にUser-Agentヘッダをつけていると
livedoor ねとらじ側でヘッドライン取得ツールごとのシェアを定期的に出してくれる（２００８年３月現在）
作者のモチベーション向上のためにもつけておいたほうがいいかもしれない。
・If-Modified-Sinceヘッダ
最初の取得時には送信せず、ねとらじサーバから帰ってくるHTTPヘッダのLast-Modifiedの内容をメモっておいて次からの取得でIf-Modified-Sinceとして送信することが推奨される。
ヘッドラインが更新されていない場合は304が返ってくる。
この場合はクライアント側でのヘッドライン更新処理しないようにすればクライアントマシンのCPU負荷が大幅に軽減される。
・圧縮版ヘッドラインファイルの取得
新形式・旧形式共にgzip圧縮されているヘッドラインファイルもあわせて配布されている。
livedoor ねとらじでは、サーバの負荷や帯域の関係上、こちらの圧縮版ヘッドラインファイルの仕様を推奨している。
■ヘッドラインファイルを取得したらどう処理するべきか？
旧形式ではほとんど項目の変更はないと思われるが、新形式のヘッドラインファイルでは今後もたびたび取得できる情報の種類が変更される可能性がある。
たとえば、２００８年２月１２日には新形式のヘッドラインファイルにサンプルレートなどの項目が追加され、各項目の並び順も変更された。
このようなことから、項目の順番や項目の増減などがあっても柔軟に対応できるようにすることが求められる。
基本形
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
メタデータの意味=実際のメタデータ
改行＋改行でひとつの番組区切りとなっていることと、メタデータの意味と実際のメタデータの区切りが" = "であることは変わらないとおもわれるので
最初の１番組のデータだけ起動時に抽出して今のヘッドラインファイルでどの項目がどういう並び順になっているのか判断して、それ以降のヘッドライン更新では
その並び順で通すようにするとクライアントマシンのCPU負荷軽減になるとおもう（分かりにくい説明でスミマセン）
■録音ってどうやるの？
今現在のヘッドラインを見たところ基本的にねとらじの音声データを配信するサーバは１台だけだが、決めうちするのは将来的にあまりよろしくない結果を招くことになりかねない。
全体の流れとしては
１．サーバのアドレス:ポート番号/マウントポイント をHTTPで取得する。例（http://203.131.199.131:8000/aaaaa）
２．流れてくるデータを全部ハードディスク上に作ったファイルに書き込む（ただし最初のHTTPヘッダは取り除いて）
３．ユーザが録音停止ボタンを押すか、接続が切れたらそこで終了。
HTTPヘッダを残したままハードディスクに書き込むと、一部のプレイヤーで正常なmp3ファイルとして開けない可能性があるので除去する。
MP3のID3タグが…等々考えずにそのまま書き出すだけでも何ら問題ない。
ただし、放送が予期せず数秒間切れてその後復活する場合もあるので、数十秒後か次回のヘッドライン取得時にもう一度そのアドレスに接続を試みて
404 File NotFoundが帰ってくるのを確認するのが望ましい（かもしれない）
■あとはどうすんの？
ヘッドラインを取得して、番組表の全データを手にしたあなたのアイデア次第。
取得したヘッドラインから特定のキーワードを探させてお気に入り通知するルーチンとか作ればいいとおもうよ。
■過去にこの提供されているファイルに関して起こった事件等
２００５年９月頃
m3uで提供されているプレイリストファイルに変更が加えられ、ねとらじ放送に入る前、終わった後に広告が入るという仕様になった
ストリーミングサーバ側で施されたものではなく、m3uファイルの１行目と３行目に１０秒くらいのmp3ファイルのアドレスが記載、２行目に実際の番組のアドレスが入るという仕様になったことがある。
m3uファイルの仕様としては、1行目から順番に再生されるのでほとんどのプレイヤーではこの広告方法は正常に機能したが、iTunesは１行目しか読まないという仕様になっていたので苦情殺到。
RAZIEのプレイリストURLではなくmp3URLをクリックすれば容易に広告回避が可能、とかいろいろあっていつの間になくなった。
ただし、２００８年３月現在のねとらじスタッフから「聞いている側がウザいと感じるような方法で広告を行うつもりはない」との回答を得ているため
このスタッフがlivedoorねとらじを担当している限りはこの方法では広告の提供は行われないものと見られる。
■細々とした事件
・番組名が２行になる事例が発生。
このせいで１行ずつズレて正常にヘッドラインの読み込みが出来なくなったことがあった。
・ヘッドラインになかなかのらない＆接続は生きてるのにヘッドラインから消える。
新しく放送された番組がヘッドラインになかなか載らなかったり、iTunesなどで視聴していてDJからのコネクションはおそらく生きているのに
ヘッドラインからだけ突如消えてしまう。
ヘッドラインに載ってる番組＝放送されている番組として番組を管理している各種ヘッドライン取得ツールでは消滅とともに録音も途絶えて涙目になるリスナー続出。
これについてはlivedoor側がヘッドラインサーバの不具合として修正を施した。
■番組を特定する材料とすべきでないもの
・マウントポイント（単体）
SHOUTcastクライアントから放送すると、マウントポイント未指定ということで
サーバ側でicy_数字 のマウントポイントが自動的に割り当てられるが
同じマウントポイントはねとらじ全体で１つしかない、としてこれを主キーで管理しようとすると問題が起こる。
なぜならば、ポートが違えば同じマウントポイントはねとらじ全体で複数存在しうるからである。（８０３０番ポートのicy_22、８０４０番ポートのicy_22など）
２００８年３月に予定されているストリーミングサーバのバージョンアップによってこれらSHOUTcast互換の放送はできなくなる予定なので
icyマウントポイントの心配はないと思われるが、依然として別ポートで同じマウントポイントは存在する事態が発生する可能性は残っている。
・同じ番組名・同じジャンル・同じ関連URLの番組
番組名だと、BLACK ANGEL RADIOは同じ番組名で２つ存在する。（しかし放送内容は違う）
ジャンルだと、本来の意味としてとらえてMusicとか入れる人がいるので同じジャンル名の番組が２つ以上発生することがある。
関連URLだと、2ちゃんねるで同じスレを関連URLとして放送し始めると同じ関連URLの番組が２つ以上存在する状況が発生する可能性がある。
つまり、これらの情報単体では番組を特定する材料とすべきではない。
たとえば、ポートとマウントポイントを組み合わせたものならば１つしか存在し得ないので番組を特定する材料になりうる。