goo blog サービス終了のお知らせ 

「アリエッティ日記」を iPod で一気に "聴く" 方法 - その壱

2010-07-17 08:30:00 | iPhone, iPod & iTunes

いよいよ今日から「借りぐらしのアリエッティ」が全国公開されますが、その予習としてお薦めなのが、「アリエッティ日記」という映像ブログ。スタジオジブリの広報部長である西岡さんという方が製作期間中に毎日更新しているものです。動画はすべて YouTube にアップロードされており、2009年12月19日の第一回から視聴することができます。

http://www.youtube.com/user/ghibliNishioka

一回あたり三分程度と短いですが、これまでに二百回以上も投稿され、その総時間は十一時間を越える超大作です。

さて毎日コツコツと見ていた人には関係ない話になってしまいますが、これから一気に観たいという方にちょっとお薦めな方法を紹介したいと思います。というのも私自身、録りためていた動画をそのまま放置しており、今頃になって膨大な量の動画をどう観るかで頭を悩ませることになってしまいました。まあ子供の時分も夏休みの宿題を間際になって慌てて片付けるタイプでしたからねぇ(苦笑)。

さて映像ブログといっても基本的には語り手の西岡さんの話す姿が映されているだけなので、音声だけでも十分楽しめます。私は動画から音声だけを抜き出して iPod で聴くことにしました。通勤時間をうまく使えば十一時間といえど一週間程度で聴き終えることができますからね(正直パソコンモニタを見ながらの十一時間は耐えられそうにない……)。ただそれには音声の抽出と変換という面倒な作業を二百回以上も繰り返さなければなりません。そこでこれらの作業を一括して実行してくれるツールを探すことから始めました。

まずは動画のダウンロードです。拙作の GetFLV は今回の用途には不向きなので一括ダウンロード機能を搭載したツールが必要です。私が今回用いたのは Tooble という YouTube 専用のダウンローダー。特定のユーザがアップロードした動画やプレイリストに登録されている動画をまとめてダウンロードする機能を備えています。ちょっと動作が不安定で完成度は今一歩といったところですが(私が言うなって?)、今回の作業に関しては必要十分であり、落ちずに持ち堪えてくれさえすれば問題はないでしょう。

では Tooble の使い方について、最低限必要な手順だけを説明します。まずはツールをダウンロードしてインストールを済ませてください。Pro 版は有償なので Standard 版を選びましょう。

http://tooble.tv/

アプリケーションを起動後、メニューの Options > Preferences をクリックし、以下のダイアログを表示してください(画像はマウスを乗せるとズームします)。



「観れればいい」という前提に立てば、ダウンロードする動画のフォーマットは極力ファイルサイズが小さいものにするとよいでしょう。この場合、Video quality には "Low Quality"、Video size には "Small" を指定します。Save videos to はダウンロードする動画の保存先です。空き容量が十分な場所を指定しておきましょう。あとは Youtube Account の "Show Uploads" にチェックを入れておいてください(重要です!)。

次にメイン画面の左にあるツリービュー上で右クリックし、Manage Feeds を実行してください。Video Source Manager というダイアログが表示されます。User Feeds を選択し、Username の欄に ghibliNishioka と入力、[+] ボタンを押してください。手順に間違いがなければ、以下のように登録されるはずです。



[OK] ボタンを押すと、ツリービューの Youtube User Feeds に ghibliNishioka が追加されますから、その中の Uploads を選択します。Uploads of ghibliNishioka というタブが追加され、しばらくすると動画リストが表示されるはずです。



次に動画リスト上で右クリックし、Check All を実行します。サムネール画像の左にあるアイコンが緑色のチェック状態になります(個々にチェックを切り替えたい場合はこのアイコンをクリック)。もう一度動画リスト上で右クリックし、Download Checked Videos を実行します。Download ダイアログが開き、動画のダウンロードが開始されます。あとはファイルが保存されるのを待つだけです。たまにダウンロードに失敗する動画がありますが、アイテムを選択し、[Restart] ボタンを押せば再ダウンロードすることができます。Good Luck!!!




P.S. 書き疲れた……。音声の抽出・変換については次回にします(苦笑)。



過去のジブリ作品はこちらからどうぞ!






スマートにポッドキャストを聴く?!

2010-07-08 22:30:24 | iPhone, iPod & iTunes
基本的にポッドキャストは iPod で聴いている。パソコンだとどうしても "ながら" になってしまい、トークに集中できないからだ。ちなみに私は iTunes で以下のようなスマートプレイリストを作り、リリース日でソートさせている。





単にポッドキャストを同期させただけでは iPod は番組を新着順に並べてしまう。エピソードをリリース順に聴きたいときは使い勝手が悪い。その点、このプレイリストは時系列を乱さずに連続して再生できるのが利点だね。個人的には番組が混ざり合うカオスな感じも結構気に入っている(笑)。



iTunes に読み取り専用のファイルを喰わせる - ネットワークフォルダ編

2010-06-20 09:32:59 | iPhone, iPod & iTunes


さて今回はライブラリをネットワーク上の他のマシン(ここでは XP が稼動するマシン)に置いている場合の話である。ネットワーク越しに共有フォルダへアクセスするには UNC パスを用いる必要があるため、前回のようにローカルフォルダのドライブパスと二刀流といった荒業を使うことができない。

ではどうするか。OS が XP Pro であればコトは簡単だ。共有設定ダイアログの「新しい共有」というボタンを押して同一の共有フォルダに対して複数の共有設定を作成すればよい。一方はフルアクセス、もう一方は読み取り専用のアクセスといった具合だ。

問題となるのは XP Home の場合である。前回も少し触れたが、この OS は「簡易ファイルの共有」といって機能の限定された共有フォルダしか作成することができない(XP Pro であっても諸事情により簡易ファイルの共有を使わざるを得ない場合は同様)。ダイアログに「新しい共有」というボタンがないのである。力技で直接レジストリに複数の設定を書き込んでみたが、共有フォルダとしては複数表示されるものの、アクセス許可は双方とも読み取り専用となってしまい、全く役に立たない。自宅サーバは XP Home マシンであり、長いこと手詰まりの状態が続いていた。

※共有設定はレジストリの HKLM¥SYSTEM¥ControlSet001¥Services¥lanmanserver¥Shares 以下に書き込まれている。また OS が認識している共有フォルダはコントロールパネルから [管理ツール > コンピュータの管理 > システムツール > 共有フォルダ > 共有] で確認することができる。


しかし解決のヒントは思わぬところに転がっていた。全く別の件で掻き集めた情報の中にここで使えるテクニックがあったのである。結論から言うと、NTFS の機能であるリパースポイント(Reparse Point)を用いて「ジャンクション」と呼ばれるフォルダのリンクを作成する。いわゆるフォルダのショートカットとは異なるのは、そこに実体があるかのように振舞うということ。

例えば "D:¥Music" のジャンクションとして "D:¥Music2" を作成する。エクスプローラから見るとジャンクションは通常のフォルダと見分けが付かない。"D:¥Music2" にアクセスすると普通に階層を辿れるが、その実態は "D:¥Music" そのものである。わかりやすくいえば「異なるフォルダとして存在しているが実体は同じ」ということになる。Windows では馴染みが薄いが概念的には Linux/Unix などでいう「シンボリックリンク」に近い。

これを利用して、"D:¥Music" をフルアクセス、"D:¥Music2" を読み取り専用の共有フォルダとして公開する。つまり hoge というサーバであれば "¥¥hoge¥Music"、"¥¥hoge¥Music2" というアクセス権の異なる二つの入り口を作ることができる。もちろん iTunes には後者を食わせればよい。

ジャンクションの利用に関しては「無知」が引き起こす大きな問題を孕んでいるため、ここではその作成法を解説しない。外部リンクを参照するなどして、その導入を検討してほしい。


外部リンク


iTunes に読み取り専用のファイルを喰わせる - ローカルフォルダ編

2010-06-19 14:05:45 | iPhone, iPod & iTunes


始めに断っておくと、本記事は iTunes にライブラリの管理を一任させているユーザにはあまり役に立たないネタである。いつものようにかなりマニアックな話題であることをご承知おき願いたい(笑)。

私は音楽ファイルをタグ付けから分類に至るまで手動で管理している。iTunes は単なる iPod の転送ツールとして利用しているに過ぎない(時にはプレーヤーとして活躍することもあるが)。それゆえユーザの目の届かないところでアートワークや独自の情報をファイルに埋め込まれるのはどうにも好まない。iTunes が行う処理をすべて把握していれば、そのような事態を避けることもできるのだろうが、それには『時間』というコストが掛かり過ぎる。趣味レベルでは幾つかの解析に携わってきたが、あいにくそれを全体に展開するほどのスキルや時間は持ち合わせていない。私のようなユーザーを神経質過ぎると非難する向きもあろうが、やはり音楽ファイルを自分の管理下に置いておきたいという思いは強い。その一方、こういった観念から解放されたいという願いもあるにはあるのだが(そうできたらどれほどか心が楽になるだろう)、『性格』という理由を構えて諦めているフシもある(苦笑)。まあこの程度のこだわりで人生が狂わされることもなかろう。

詰まるところ趣旨は「iTunes に余計な処理を行わせたくない」ということである。ユーザが意図していないファイルの書き換えは回避したい。例えば以下の四つのデータがある。

1) 自動ダウンロードされたアートワーク
2) 手動登録されたアートワーク
3) ギャップレス情報
4) サウンドチェック情報
5) マイレート

このうち音楽ファイルの書き換えが発生するのは (2) と (4) である(他はデータベース等が使われる)。それゆえ私はアートワークの手動登録も行わないし、サウンドチェック機能も使わない。他に代替手段を用意すればよいのである。iTunes は我々のためを思って色々としてくれるのだが、一部のユーザにとってはそれが余計なお世話となる。何をしているのか気になってしまうのだ。ひいてはその機能の裏でどのような処理が行われているかを解析するというマニアックな世界に走らざるを得ない。なんとも悲しい性である。しかしこれが iTunes の行儀の悪さから身を守る唯一の術であった。

iTunes の機能はバージョンアップと共に進化する。いつなんどき新たな機能がファイルに変更を加え始めるかわからない。予断を許さない状況だ(あまり大げさに書くとジョークにしか聞こえない。まあ実際半分くらいはそうなんだが)。どんな機能にも対抗しうる完全無欠な防衛手段はないものだろうか。頭の片隅には常に一つのアイデアがあったのだが、ある環境において問題があり具現化できないでいた。

「ファイルが読み取り専用であれさえすれば iTunes に手出しは出来まい」

あまりの枕の長さに辟易されている方も多いだろうが、これが本題である(笑)。




もう少し広義に捉えると「ファイルを読み取り専用にして特定のアプリケーションにファイルの変更を許可しない」ということになる。まずは手段を吟味する。

・ファイルを読み取り専用にするには属性とアクセス制御がある。
・ファイルを読み取り専用属性にした場合、他のアプリケーションにおいて不都合が生じる。
・フォルダのセキュリティ設定によるアクセス制御はローカルアカウントに対するものであり、アプリケーションごとに設定することはできない。

※読み取り専用属性は操作に対する制御ではなく、アプリケーションに書換禁止を通告するものである。つまりアプリケーションは必要とあらば、読み取り専用属性を無視して書き換えることができる(もちろんこの判断はアプリケーションを使用するユーザに委ねられるべきであるが)。これがアクセス制御との大きな違いである。


そこで引っ張り出してきたアイデアがフォルダの共有機能を用いる方法。共有フォルダのアクセス許可はネットワーク経由で接続するユーザーに対してのセキュリティ設定である。つまりアクセス許可を読み取りのみに設定した共有フォルダを用意すれば、ローカルのフォルダであってもネットワーク越しからのアクセスにおいて読み取り専用フォルダを実現できる。

具体的にいうと、hoge というホスト名のマシンが "D:Music" というフォルダを "Music" という共有名で公開した場合、"D:Music" にアクセスすればフルアクセス、UNC パスを用いて "hogeMusic" にアクセスすれば読み取りのみに制限できるということである。これら二つを使い分けることで、特定のアプリケーション(つまり iTunes)に読み取り専用のファイルを喰わせることが可能となる。

ただしプライバシーやセキュリティには十分注意してもらいたい。読み取りのみとはいえ外部に公開することになるのだから何の対策も講じていなければ共有フォルダは誰もが閲覧可能な状態である。特に XP Home の場合は「簡易ファイルの共有」といって、すべてのユーザーに対して同一のアクセス権を与える共有フォルダに限定される。ファイアウォールで接続してくるマシンを制限するなり、共有フォルダを隠し属性(末尾に "$" を付けた共有名)にするなり、環境に合わせた対応をとってほしい。

またグループポリシーやファイアウォール、アンチウイルスソフトの設定によってはローカルからの共有フォルダへのアクセスが制限されることがあるかもしれない。これに関しては本記事の趣旨から外れるため、関連情報を検索し自己解決してほしい。

以下は読み取り専用のファイルを食わせた iTunes の姿。





トラック情報はグレーアウトしており書換不可であることを示している。アートワークのウィンドウも画像のドロップが無駄であることを通告している。どうやら成功したようだ。ひとまずこちらが一本取った形である。

さて今回はローカルフォルダと共有フォルダのアクセス方法を使い、同一フォルダであっても二つの異なるアクセス権を実現したが、メディアライブラリとなるフォルダがローカルマシンではなくネットワーク上のマシンに存在する場合(例えば音楽ファイルを LAN のサーバに置いて管理しているなど)、ここで紹介したテクニックは使えない。お分かりだろうか、ネットワーク上のフォルダにローカルフォルダのパスでアクセスできるわけがないのである。ではどうするか。そのあたりの小技は記事を改めて紹介したい。


外部リンク


「ワンランク上の iTunes/iPod ライフ」 タグ編集篇 #05

2009-12-23 06:59:27 | iPhone, iPod & iTunes

アクションって何? for Mp3tag


Mp3tag の肝ともいえるアクションについて簡単に説明しておきましょう。ユーザは Mp3tag が用意している単一または複数のアクションをグループ化しておき、これを呼び出して利用することになります。例えば前回の "Case conversion" ですが、これはアクショングループに付けられた名前で、実際は(ちょっとややこしいのですが)同名の "Case conversion" というアクションがひとつだけ登録されています。

アクションの設定を確認あるいは編集したい場合、まずはツールバーの "Actions" ボタンを押して "Action groups" ダイアログを表示させます(メインメニューや右クリックメニューから [Convert]-[Actions] でも可)。



次に任意のアクショングループを選択後、右側の "Edit" ボタンを押してください。"Case conversion" というアクショングループであれば同名のアクションがひとつだけ登録されていることがわかると思います。



さらにこの "Case conversion" を選択して "Edit" ボタンを押すと "Case conversion" アクションの設定画面が表示されます(ああややこしい!)。



アクショングループの利点は複数の処理をひとまとめにしておいて、ワンアクションで呼び出せるという点ですね。豊富なアクションやその設定方法は少しずつ学んでいけばいいと思います。まずはどういう仕組みになっているのかをしっかり理解しましょう。

「ワンランク上の iTunes/iPod ライフ」 タグ編集篇 #04

2009-12-22 05:46:38 | iPhone, iPod & iTunes

キャピタライズしよう!


***** STEP *****

対象となるセルを選択して(範囲指定も可能)、右クリックメニューから「単語の1文字目のみを大文字」を実行します。同様の処理はメインメニューからも可能です。筆者はショートカットキー(Ctrl+Q)を割り当てて、一発で呼び出せるようにしています。

※ショートカットキーの割り当ては [オプション]-[オプション設定]-[一般]-[キー割り当て] から行います。詳細はアプリケーションのヘルプを参照してください。


***** Mp3tag *****

Mp3tag ではキャピタライズがメニューとして用意されていません。基本的にこういった処理はユーザがアクションのひとつとして登録していくことになります。ただしキャピタライズに関しては "Case conversion" というアクション名で事前登録されていますから、これをそのまま使うことができます。実行はツールバーにある "Actions" というボタンのドロップダウンリスト(ボタンの右側にある下矢印の部分)から "Case conversion" を選択します。


Mp3tag のアクションって機能としては最高なんだけど、その呼び出しにショートカットキーを割り当てられないのが惜しい。最後の詰めが甘いという感じです(苦笑)。

「ワンランク上の iTunes/iPod ライフ」 タグ編集篇 #03

2009-12-21 06:46:17 | iPhone, iPod & iTunes

キャピタライズって何?


私のマイルール(二重表現?)の中で最も基本的なルールのひとつがキャピタライズです。キャピタライズとは単語の先頭を大文字にする処理のことで、

when the sun meets the sky

であれば

When The Sun Meets The Sky

と表記されます。他にもフィールドの先頭のみを大文字にしたり、助詞や冠詞はキャピタライズから除外したりする人もよく見掛けますね。

When the sun meets the sky

When the Sun Meets the Sky

大文字小文字の使い分けは好みの問題なので、自分が見やすいスタイルを選べばいいと思います。まあこれらが混在しているからといって別段問題があるわけではありませんが、統一していた方が見栄えは良くなりますよね。ちなみに僕は完全キャピタライズ派です。ただし例外として、邦楽のように大文字や小文字の使い分けに製作者の意図が含まれる場合はオリジナルの表記に従うようにしています。それ以外に設けている特殊なケースは追々紹介していきます(そうやっていつも先延ばし・・・苦笑)。

ちなみにキャメライズなんて言葉もあります。タグ編集で出てくることは稀ですけどね。表記としてはキャピタライズ後にスペースを詰めたような感じです(ラクダのこぶのように見えるところからこの名前が付いたとか)。ちなみにプログラムの世界ではよく使われる表記法です。

WhenTheSunMeetsTheSky

先頭のみを小文字にする場合もあります。

whenTheSunMeetsTheSky


ちなみにざっと自分のライブラリを眺めてみましたが、アーティスト名だと DragonForce くらいかな。特殊な表記では SHeDAISY なんてのもありましたけど(笑)。

「ワンランク上の iTunes/iPod ライフ」 タグ編集篇 #02

2009-12-20 08:56:40 | iPhone, iPod & iTunes

タグ編集ツール(タグエディタ)


現在私が使っているタグエディタは次の二つです。用途によって使い分けており、それぞれに長所と短所があります。いずれもフリーソフトとして公開されています。


***** STEP *****

SuperTagEditor をベースに作られた派生版のひとつ。以前は SuperTagEditor 改造版として公開されていましたが、プラグイン化を機に名称を変更したようです。

オリジナルのリリース時期が古いこともあり、時代遅れの感が否めないデザインですが、表計算ソフトのようなインターフェイスは非常に使いやすく、今でも根強い人気を誇るツールです。国産であることもその要因の一つかもしれませんね。

最近 STEP をさらに改良した STEP_M という派生版も出てきたようです。こちらはソースコードを Visual Studio 2008 用に書き直しているということで、個人的にはちょっと弄りたい衝動に駆られています。まあ時間がないのでやらないですけどね(苦笑)。

STEP/STE改:
http://hp.vector.co.jp/authors/VA012911/STEP/step.html

STEP Wiki:
http://haseta2003.hp.infoseek.co.jp/

SuperTagEditor:
http://www5.wisnet.ne.jp/~mercury/

STEP_M:
http://mimura.dyndns.tv/software/


***** mp3tag *****

洗練されたデザインと高機能が売りの海外産タグエディタ。現時点では最強との呼び声が高いです。作者自身も明かしていますが、foobar2000 からの影響が強く、柔軟な置換が可能です。その反面、ある程度の知識が要求されるため、初心者には敷居が高く感じられるかもしれません。

mp3tag:
http://www.mp3tag.de/en/


***** 両者の比較 *****

総合的には mp3tag が STEP を圧倒しますが、それはひとまず置いておいて、私の使い分けの理由となっている機能を以下にまとめてみました。
                                  STEP   mp3tag
ショートカットキーのカスタマイズ   ○       ×
ユーザー定義のフィールド追加     ×       ○
正規表現による置換          ×       ○
フィルタを用いた検索機能       ×       ○
Unicode の対応            ×       ○

これらの機能や他の相違点については、今後実例を交えながら少しずつ紹介していきたいと思います。

「ワンランク上の iTunes/iPod ライフ」 タグ編集篇 #01

2009-12-19 08:59:35 | iPhone, iPod & iTunes

タグ編集って何?


最近ではオンラインのレンタル CD サービスも充実してきており、ミュージック ライブラリの肥大化に拍車が掛かっている方も多いのではないでしょうか。

大半は MP3 などに変換して保存していると思いますが、ライブラリを管理する上で重要になってくるのがタグ編集。曲名やアーティスト名といった楽曲に関する情報をファイルに書き込む作業のことですね。

一般的に MP3 では ID3 というタグを用いることが多く、プレーヤーや管理ツールはこれを参照して楽曲の情報を取得します。単にファイルを整理するだけであれば、フォルダ名やファイル名で見分けられるようにしておけば十分ですが、これだけではプレーヤーや管理ツールの機能を最大限に活用することはできません。

タグ編集は専用のツールを用いることで作業が飛躍的に効率化されます。もっとも最近では iTunes をはじめとする多くのメディアプレーヤーが CDDB に対応しており、ネットワーク越しにアルバムの情報を取得して、ほとんどのタグを自動的に書き込んでくれます。そうなると専用ツールの出番はないと思われるかも知れませんが、実際は機械的に取得したデータの場合、ミスや抜けがあることも多いです。これはフリーで公開されている CDDB サーバでよく見られます。

私個人の考えですが、タグ情報はマイルールを設けてしっかり編集しておくべきだと思います。もちろん慣れるまでは時間を要する面倒な作業ですが、この蓄積が強力なデータベースとなり、後々のライブラリ管理で威力を発揮するはずです。

まあ面倒といっても、カセットテープの時代は手書きだったり、レタリングシートだったりしたわけですから、それと比べれば随分便利な世の中になりましたよね。

さてこの先しばらくはタグ編集について色々と書いてみたいと思います。私自身が愛用しているツールの紹介やニッチなノウハウが中心となる予定ですが、基本は「気まぐれ」なので、あまり期待しないで下さい(苦笑)。つまみ食い的な気分で読んでいただければ幸いです。



...とか、こういうライター気取りで堅い書き方するから途中で挫折するんだよなぁ>自分(笑)。

USB カーチャージャー

2009-08-09 11:59:50 | iPhone, iPod & iTunes
先日の記事でも触れたとおり、百均の安物 USB カーチャージャーは iPod に対応しておらず、充電にはそれなりの改造が必要であることがわかりました。その後、市販製品の iPod 対応状況を調べていたのですが、サンワサプライから発売されている CAR-CHR53U の出来があまりにも素晴らしく、つい衝動買いしてしまいました。百均のカーチャージャーはサイズが大きくて不恰好、おまけにホワイトの本体と赤色 LED が愛車の黒いパネルとはアンバランスで、決して好んで使いたくなるような作りではなかったですからね。取り合えずこちらは電子工作の楽しみとして残しておくことにします(笑)。

CAR-CHR53U は実売で千円程度ですから決して高い商品ではありません。それでも "百均製の十倍" と値が張るだけあり、洗練されたコンパクトなデザインが目を引きます。特にこのサイズは驚異的ですらありますね。同系統の製品の中では群を抜く完成度ではないでしょうか。もちろん "iPod 対応" を謳っている製品だけに iPod nano の充電もバッチリでした。出力電流が 1200mA と高出力なのもウリで iPod touch や iPhone にも対応しているとのことです。



今流行のブルー LED を取り入れているところもオシャレですね。かなり眩しく感じますが、これはコネクタ部を照らすために必要な明るさと考えれば問題ないでしょう。シルバーの取っ手はデザインと機能の両立がお見事。本体の差し込みがかなりキツく設計されているので(おそらくはケーブルを抜く際の脱落防止のため)、取り外しに取っ手は必須ですね。半円のリングを手前に倒して取っ手にするというアイデアは良く考えられていると思います。

ここまで書くと良いことずくめのようですが、本当に欠点らしい欠点が見当たらないんですよね(笑)。強いて挙げるとすれば、取っ手がメッキ加工という点でしょうか。これだと抜き差しの回数が増えるにつれ、剥げてくることは必至でしょう。シルバーメタリック色の無塗装樹脂パーツで代用しても良かったと思いますが、反面光沢は無くなり、高級感が失われるのがデメリット。とにかくメッキが剥げるのがイヤなら抜き差しは控えめにするのが得策でしょうね(笑)。

単ポートのカーチャージャーとしては文句なしにお薦めです。ただしシガーソケット周辺の形状によってはうまく装着できない場合があるかもしれません(購入される方は良く調べたほうがいいと思います)。また同一デザインの類似品も存在するようですが、出力電流が 500mA であったり、最新の iPod や iPhone には非対応であったりするの注意が必要です。外観は同じでも中身は別物ということですね。




iPod のハードウェア認識を調査

2009-08-08 00:32:20 | iPhone, iPod & iTunes
この記事の内容は筆者所有の iPod nano 4G (1.0.3) と数台のマシンにおいて確認したものであり、すべての iPod の動作を保障するものではありません。

iTunes がインストールされているマシンの場合

iPod はマシンに接続すると以下のように認識される。専用ドライバを用いて USB 大容量記憶装置デバイスを扱っていることがわかる。



iTunes の iPod 設定画面において "Enable disk use" のチェックを外すことで、汎用ボリュームの機能を無効にすることができるが、この処理は常に iTunes.exe を経由して行われるため、iTunes を起動し、iPod との通信を終えるまで汎用ボリュームは無効にならない。"Open iTunes when this iPod is attached" を無効にして iPod の接続と iTunes の起動を自動連携させていないユーザは注意されたし。また "Manually manage music and videos" を有効にすると iTunes 起動直後の同期を無効化できるが、同時に "Enable disk use" も有効となる。この場合も注意が必要である。というわけで以下はディスクを無効化している場合の iPod の認識状態である。iTunes との同期が終わると汎用ボリュームは削除される。



ハードウェアを取り外したときの挙動も少々変わっている。通常の USB 大容量記憶装置デバイスは取り外しと同時に認識されなくなるが、Apple の専用ドライバは iPod を完全に切断せず "取り外し中" の状態にしておくらしい。ハードウェアとしてはまだ認識されているため、給電は継続されている。



つまるところ iPod の給電には専用ドライバが一役買っているようで、これを完全にストップさせるにはドライバそのものを停止させる必要があるようだ。下記の状態になって初めて iPod は OS から切断される。何かと問題になっている iPod の充電であるが、結局はソフトウェア的に制御されていることになる。



iTunes がインストールされていないマシンの場合

"Enable disk use" の設定にかかわらず、汎用ボリュームを持つ USB 大容量記憶装置デバイスとして扱われる(この設定は iPod 側に記録されていると思ったが、そうではないらしい)。また当然のことながら専用ドライバは存在せず、USB 大容量記憶装置デバイス以下のいずれかを停止させるとハードウェアそのものが切断され、給電もストップする。逆にいえば、iTunes がインストールされていなくてもマシンに繋げば充電は可能ということ。



iTunes における iPod nano の設定

現在の設定はこんな感じ。Last.fm にスクローブルしているので自動連携は必須。ディスクは外部ストレージとして使用する予定はないので無効。






iPod が充電できない?!

2009-08-07 08:37:10 | iPhone, iPod & iTunes
セルフパワーの USB ハブを購入し「これで手軽に iPod を充電できるぞ」と思ったのも束の間、マシンが起動していないときは、iPod が充電されていないことに気付きました。ポート当たりの出力電流はバスパワー規格と同じ 500mA のはず。「こはいかなる事ぞ」とばかりにネットを検索してみると iPod の充電機能には一癖も二癖もあることが発覚。原因と解決方法はソフトウェアとハードウェアの両面から追求する必要がありそうです。

まず我が家の環境において、マシンを起動せずに充電できるのはプロテック製の CP00541050J という USB AC アダプターを使った場合のみ(現在は販売終了。仕様やデザインが同じ PAC-1200 が後継機種?)。ケーブルは純正以外にセリアという百均の充電/通信ケーブルも試しましたが問題なし。同じケーブルをセルフパワーの USB ハブに繋いだときは前述の通り。定格出力に違いはあるものの(USB AC アダプターは 800mA)、少なくとも iPod nano においては 500mA あれば十分と思われ、これが直接の原因となることはないでしょう。他の機器では同じく百均で購入したシガーソケット USB アダプタに同ケーブルを用いて接続しましたが、やはり充電はできませんでした(出力電流は不明)。

真っ先に思い当たるのは iPod に対して何らかの制御信号が送られているのではないかということ。iPod 側の端子は多数のピンを持っていますが、USB には四本しかなく、まずはこれらを調べることで手がかりが得られそうです(ネットでは USB の仕様書も入手できますが、そこまで深入りする必要はないでしょう)。USB のコネクタは電源 VSUB と接地 GND 及び二本の信号線 Data(+)、Data(-) で構成されています。バスパワーは VSUB と GND 間に約 5V が供給される仕組みです。単にこれを受けるだけであれば給電側に依存して充電が出来たり出来なかったりすることはないはずですし、やはり信号線が何らかの役割を果たしていると考えるのが妥当でしょう。

ネットでこれについて詳しく調査している方のページが幾つか見つかりました。予想通り信号線にちょっとした細工を加え、通常では充電できない接続でも充電が可能なようにしているようです。これはパルス制御ではなく、二本の信号線に定電位を与えるだけで実現できるとのこと。早速アナログテスタを使って USB AC アダプタの信号線の電位を測ってみたところ、Data(+) が約2.5V、Data(-) が約1.0V でした。iPod がホストに接続されていると認識できるよう、こっそり信号線に電圧を供給していたんですね。これで大方疑問が解けました。おそらくは USB ハブやシガーソケット USB アダプタあるいはケーブルのどちらかで信号線の加工をすれば iPod を充電できるようになると思われます。「近いうち百均のケーブルで試してみようかな」といったところで今回はお開きに・・・(笑)。




iTunes のアートワーク機能を探る 其の六

2009-05-10 10:16:14 | iPhone, iPod & iTunes
「iTunes が MP3 に書き込むタグ情報を調べる」の巻

iTunes のエンコーダを使って取り込んだ MP3 には iTunes 独自の情報が色々と追加されている。手元にあった何枚かの CD を取り込み、それぞれ最初の曲のタグ情報を調べてみた。以下の画像は Mp3tag で表示したものである。

[Candlewyck / Candlewyck]


[Johnny Hiland / Johnny Hiland]


[Mark O'Connor / Meanings Of]


上記より、コメントフィールドを用いて ITUNES_CDDB_IDS, ITUNNORM, ITUNPGAP, ITUNSMPB という独自の情報を書き込んでいることがわかる。ITUNNORM, ITUNPGAP, ITUNSMPB の三つはギャップレス再生に関する情報らしい。以下のページで詳しく調査しているのでここでは割愛。

http://nyaochi.sakura.ne.jp/archives/2006/09/15/


ITUNES_CDDB_IDS はその名称から判断すると CDDB から取得したデータに関するものであろう。"+" でさらに三つのフィールドに区切られている。最初のフィールドがアルバムのトラック数であることは容易に想像が付くが、残りの二つはこの時点ではよくわからない。二番目のフィールドは何らかの情報を 128bit のメッセージダイジェストとして出力しているようだ(16進数[4bit] x 32桁)。三番目のフィールドは桁数もまちまちで何らかの ID と思われる。

実は ITUNES_CDDB_IDS に関しては、iTunes の通信をキャプチャすることで手掛かりが得られた。以下はカバーアートをフェッチする際にアクセスのあった URL である(読みやすいようにクエリごとに分割した)。GET メソッドを使っていくつかのクエリを送信しているが、その中に ITUNES_CDDB_IDS に書き込まれている二つの不明フィールドのデータも含まれていた。
http://ax.itunes.apple.com
  /WebObjects/MZStoreServices.woa/wa/coverArtMatch?
an=Candlewyck
pn=Candlewyck
CDDBMediaID=0ED78F3729C93318294294B0AC542171
CDDBMuiID=4352151

これより ITUNES_CDDB_IDS の第二フィールドは CDDB Media ID、第三フィールドは CDDB MUI ID というものであると推測される。調査を進めると CDDBMuiID はアルバムを一意に指定できるデータであることがわかった。つまり "p=playlistId" のようにアーティスト名 (an) やアルバム名 (pn) を送信しなくても正確にカバーアートを取得できる。ただこれに関してはプレイリスト ID が必要十分条件を満たしているので CDDBMuiID の出番はなさそうである。少なくとも iTunes が管理する ID ではないようだ(ストアに存在しないアルバムにも ID が付くため)。

CDDB からのデータの取得に関しては CD をドライブに挿入した際に自動的に行われるが、これらの情報はローカルにキャッシュされるようで二回目からは CDDB へのアクセスは行われない。これを強制的に行わせるにはメニューから [Advanced]-[Get CD Track Names] を実行する。同時に以下のようなリクエストメッセージが送信されるが、POST データの一部は ZIP 圧縮されたデータであり、この中身を見るのはローカルサーバにリダイレクトさせるなどの策を講じる必要がありそうだ。また iTunes は Gracenote の CDDB 機能を利用しているとのことで、解析にはこのあたりの仕様を把握しておかなければならないだろう。ただ今回は本筋から逸れるため、これ以上は深入りしない。
POST /service/2.0/product/1 HTTP/1.1
Accept: application/octet-stream
User-Agent: iTunes/8.1.1 (Windows; N)
Content-Type: application/octet-stream
Host: c14897152.media-cd-id-q.cddb2.cddbp.net
Content-Length: 605
Connection: keep-alive


[本章のまとめ]
残念ながら iTunes を使って作成した MP3 にはプレイリスト ID は書き込まれていないかった。もしかしたらストアで購入する MP3 にはあらかじめ書き込まれている可能性もあるが未確認である。

CDDBMuiID はタグ情報の一部であり、プレイリスト ID を CDDBMuiID に変換する方法があれば、それも解決策のひとつになりそうである。

iTunes のアートワーク機能を探る 其の五

2009-05-09 02:31:41 | iPhone, iPod & iTunes
後回しにしてきた artistId と playlistId であるが、試してみるにしてもパラメータ名がわからない。さてどうしたものか。coverArtMatch コマンドのまとめページでもあれば一発なのだが、そんな都合の良いページは見当たらない。さすがにネタがマニアック過ぎるのだろう。とはいえ今は根気良く検索を続けるしかないわけで・・・。

かなり粘ったように記憶しているが、運良く手掛かりとなりそうなコマンドに出会うことができた。それが initiateSession である。

http://ax.itunes.apple.com/WebObjects/MZInit.woa/wa/initiateSession

上記 URL にアクセスすると、初期化情報と思われるデータが XML 形式で返される。実際に iTunes がこの URL にアクセスしているかは未確認であるが、その可能性はありそうである。取り合えず受け取った XML データの中から cover-art-url に関する情報をピックアップしてみた。
a
p
id
cddb-tuid
cddb
an
aan
pn

"an", "aan", "pn" についてはそれぞれアーティスト名、アルバムアーティスト名、アルバム名(プレイリスト名)であることはすでにわかっている。残りのパラメータに関してだが CDDB はあまり当てにしていないので cddb-tuid と cddb はスルー。気になるのは a,p,id である。artistId や playlistId が使えそうなパラメータ名ではないか。まずは以下のリクエストを送信して、Boston の artistId と "Third Stage" の playlistId を調べておく。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com

an=Boston
pn=Third Stage

次に "an" の代わりに "a=artistId" で試してみる。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com

a=60960
pn=Third Stage

ダメだった・・・。"p" や "id" に渡してもマッチしない。では気を取り直して "p=playlistId" を試してみる。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com

an=Boston
p=96968

おっ、今度はちゃんとマッチするぞ。こいつはもしや・・・。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com

p=96968

思ったとおりだ。"p=playlistId" はアルバムを一意に指定できるパラメータらしい。やっと探していたものが見つかった。おそらく playlistId は iTunes が独自で管理している ID であろう。アップルのサーバに存在するアルバムであればプレイリスト ID は付けられていると推測できる。つまり "p" さえ指定できればアーティスト名やアルバム名の送信は不要となるわけで、表記のゆれも気にする必要がなくなる。しかし XML データを取得しなければ プレイリスト ID がわからないというのでは本末転倒である。なんといっても XML データを取得するためにプレイリスト ID が必要なのだから・・・。

さて「どのようにしてプレイリスト ID を取得するか」が次の悩みどころとなった。iTunes の通信をトラップしたり、色々と手の込んだ調査をしてみたのだが、中々いい結果は得られない。しかし灯台下暗し、答えは意外にも身近なところに転がっていた。実は iTunes ストアでは右クリックメニューから "Copy iTunes Store URL" でページの URL をコピーすることができるのだが、この操作をアルバムに対して行った場合、URL にはプレイリスト ID が含まれているのである。例えば Boston のアルバムをストアで一覧表示させ、"Third Stage" の画像を右クリックすると次のような URL がコピーされる。
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?id=96968&s=143441

ここで "id" はまさに "Third Stage" のプレイリスト ID である(ちなみに "s" はストアの国コードのようだ)。ただし気をつけて欲しいのは viewAlbum コマンドのときの "id" に限られるということ。アーティストのリンクをコピーした場合、コマンドは viewArtist であり、"id" はアーティスト ID を示している。
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewArtist?id=60960

さて前回どうしてもマッチさせることができなかった Kansas の "Kansas" であるが、プレイリスト ID を指定すれば一発である。
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch HTTP/1.1
User-Agent: iTunes
X-Apple-Store-Front: 143441-1
Host: ax.itunes.apple.com

p=192658145

Proxomitron を使うのであれば iTAW-Substitute リストに以下のようなコマンドを追加すればよい(あくまでテスト用なのでフィルタとしての正確さを期すならばもう一工夫必要)。
$URL((*pn=Kansas)1) $RDIR(1&p=192658145)

ここまで辿りついたのだから、完璧まであともう一歩である。できればローカルプロキシというトリッキーな手は使いたくない。もしプレイリスト ID をタグに埋め込むことが可能で、それを iTunes が自動的に送信してくれるとしたら、我々の手間は単に iTunes ストアでプレイリスト ID を調べて、それを MP3 に書き込むだけでよいことになる。HTTP がどうのとか、Proxomitron がどうのとか言わずに、MP3 を普通に扱う知識だけで iTunes ストアにあるアルバムのアートワークを確実に反映させる手法として確立できるのである。無論「アップルのサーバに存在しないアートワークをトラックに埋め込むことなく登録することは可能か?」に関してはトリッキーにならざるを得ないだろうが、それはまた先の話ということで・・・。

[本章のまとめ]
coverArtMatch ではプレイリスト ID (p) を使ってアルバムを一意に指定できる。この ID は iTunes ストアで該当アルバムの URL をコピーして取得することが可能。現時点では iTunes にプレイリスト ID を自動送信する機能が実装されているかは不明。

iTunes のアートワーク機能を探る 其の四

2009-05-08 02:15:16 | iPhone, iPod & iTunes
「表記のゆれは手強いぞ」の巻

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 であったのだが、その解説はまた次回・・・。

[本章のまとめ]
アーティスト名やアルバム名を使ったキーワード検索は精度に限界がある。