• 浅倉大介のCCCDに関する発言 -

Music Liberation Front（http://www.babbagelab.com/blog/archives/000087.html）より。上記画像はアップローダーへのリンクだから多分そのうち消えてしまうので見たい人はお早めに。ポイントだけ抜き出しておくと

一番問題なのは、そうすることによって音質が落ちてしまうっていうこと

"CCCD"では、ボクの発信したい正確な音楽は出せないかなっていう結論に達しました

（CCCDのみで発売されると）創った元の音がない状態で、音質が悪くなったものを「これが次の作品だ」って出すのは、ミュージシャンとしてやっぱりどうしても許容できることではないからね

ソニーがシングル全部"CCCD"になりますってなったときに、「どういうことですか？「音がどう変わるんだ？」って説明を求めたアーティストはボクと奥田（民夫）さんとあともう1人、3人しかいなかった

って感じ。あとaccessとして出す次のシングルはCCCDだけど、アルバムの方は普通のCDになっていて、音にこだわって創った同じ曲をメディア違いで聞き比べられるものになっているらしい。ミュージシャン以外の人が同じ元曲（データ）のCD版とCCCD版を聞き比べられるというのはかなり貴重かも。

浅倉大介って昔ヤマハのイベントで見たとき、新製品の機材を与えられてイベントそっちのけで機械いじりを始めたのを見て以来、基本的に商売人ではなく音楽オタクなんだなーと思っているので、音楽オタクとしての音楽のこだわりはなんとなく信用している。

俺的には普通にPCとシリコンオーディオプレイヤーで聴ける（ATRAC3は扱いが面倒くさくて遅いからいや）ものならば、実際の話、音質はある程度どうでもいいんだけどね。

朝倉じゃなくて浅倉でしたよ

ってことで「朝倉」と書いていた部分をみんな「浅倉」に修正した（@2004/09/07）。それにしても1年半前のネタか……。

• “未来のWindows”の姿が見えてきた - http://www.zdnet.co.jp/news/0303/05/ne00_longhorn.html

このSQL Serverベースのファイルシステムってのにはものすごく期待しているんだよな。現状のマイクロソフトのファイルシステム（＋エクスプローラ）って、あまりにも遅くて低機能で使いにくいから。

一時期自分でOSの外付けで使いやすいエクスプローラライクな文書管理システムを実装しようといろいろやってみたんだけど、やっぱり外付けだと使い勝手があまり良くならないのでペンディング中。

でも、主に検索機能の強化とか自動バックアップとか高度なカテゴライズとかの仕組みってのは、何もファイルシステム全体に対して行う必要はないんだよな。Windows的にはMy Document以下のフォルダ（＝管理したい文書）に対してそういうことがそれで十分だ。マイクロソフトの新しいファイルシステムのできが良ければいいけど、また無駄に重いものが出てきそうな気もする。念のため自分でも作っておこうかな。

• スパム解決の切り札になるか？ 「ホワイトリスト」フィルター - http://www.hotwired.co.jp/news/news/culture/story/20030305206.html

これは何が新しくて話題になっているの？　Outlookのプラグインだから？　でもOutlookのプラグインに今までホワイトリスト系のフィルターはなかったの？　なんか結構謎だ。

アバントゴー社の開発者なのだから、愚かなはずがない。われわれがまだ気づいていないような点があるのだろう。今は成り行きを見守っていようと思う

という程度がこのソフトに対するまっとうな態度なんじゃないか？　なんでWiredはこのソフトを取り上げたんだろう？

SPAMフィルターといえば、最近のMozillaに載っていたり、shiroさんがGauche:SpamFilter（http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Gauche%3aSpamFilter&l=jp）で試しているベイジアンフィルタが面白そうなんだけど、内容は全然読んでいなかったりする。とメモしておこう。

• QuickTime Traveller：MPEG-4は今、どうなっているか？ - http://www.zdnet.co.jp/macwire/0303/07/cj00_traveller.html

Dejimah（http://www.dejimah.com/blog/archives/001161.html#001161）経由。今ちょうどMPEG4 FOMA系のネタをやっていたんだけど、いまいち仕様がよく見えていなかったんで参考になった。と思いきや読んでみてさらに混迷は更に深まったのであった。

昔eggy（NTTドコモのPHS用MPEG4ハード。i-motionという名前ではなく、M-Stage Visual端末といわれていた気がする）で遊んでいたんで、てっきりそのデータフォーマットがFOMAでもそのまま採用されたんだと思いこんでいて、実際に外見上はFOMAのムービーもMPEG4圧縮されたASFファイルで同じ形式っぽいんだけど、実際に扱ってみると何か違う。やたらとデコーダーにbad headerで弾かれる。

ドコモのi-motionの仕様ページ（http://www.nttdocomo.co.jp/english/p_s/i/imotion/）にはeggyのことが何一つ書かれておらず、FOMA i-mode用だと書かれているあたりから察するに、eggyの頃の（M-Stage Visual用の）ムービーフォーマットはsimple Profile Level 0で、i-motionの方は多分3GPP restrictionって奴がメインなんだろう。だからFOMAでもM-Stage Visualは見られるけれども、FOMAで作ったムービーはeggyの頃のデコーダーがうまく通らないことがある。

MPEG4 CODECレベルの話はそんな感じなのかなーと思いつつも、ドコモのムービーフォーマットの話でよく見かけるMobile Profileってのはなんなんだろうな？　CODECレベルではなくてasfファイルに入れたときの仕様の話なのか？　そのあたりの違いもよく分からないな。ASFの仕様は印刷しただけで安心して読んでいないし。そこまで知らなくてもすませられるネタではあるんだけど、一応調べておいた方が安心かなー。

それにしてもこの記事では、ビデオCODECと音声CODECとコンテナフォーマットとが区別されずに書かれていてなんだかよく分からない。っつーかドコモ自体の資料がまずよく分からないんだよな。と思ったら、

• 「ASF」から「MP4」へ〜FOMAのiモーションメール - http://www.zdnet.co.jp/mobile/0212/10/n_motion.html

という記事を発見してしまった。げげげ。俺は今までSH2101Vを機材として与えられたんで、それを中心に考えていたんだけど、すでにFOMAのムービー規格はASFからQuickTime（MP4）に変わっているのか。えーっとなにかいろいろ考え直さなければならないことが出てきたような……。

• インタラクション2003Behind Touch――携帯電話のための背面入力インタフェース - http://www.zdnet.co.jp/mobile/0303/07/n_int.html

昔PC用のキーボードでも、両手を自然に胸の前に掲げた形（大きなボールをもったような感じ）の指の配置でそのまま入力できるようなデバイスが試作されていたよね。あれも一種の背面入力インターフェースだろう。そういうエルゴノミック方面からアプローチすると携帯の背面入力ってのも良さそう。

• 2月末の携帯電話市場、FOMA前月比で14倍、浮上のきっかけとなるか? - http://pcweb.mycom.co.jp/news/2003/03/07/24.html

新しいFOMAは見かけ上のスペックはずいぶん良くなって、ぱっと見はほかの規格と比べても遜色がなくなっているけれど、古いFOMA端末でとても気になる「（歩くスピードで）移動中にやたらと不安定」ってのは解消されたんだろうか？

• ミュージシャンに「ThankYou」するP2Pソフト - http://www.zdnet.co.jp/news/0303/07/xert_thankyou.html

P2Pファイル交換にグリッドコンピューティングの仕組みももたせて、グリッド使用料で稼いだお金でアーティストに直接（レコード会社を通さず）お金を払おうってモデルか。多分うまくいかないだろうけど、発想は面白いね。

• ジョーダン、チーム売却を検討---第一候補は? - http://auto.ascii24.com/auto24/issue/2003/0307/30nms_sn9999_30.html

もう1、2年早くそういう発言をしていれば、ホンダはジョーダンの方と手を組んだかもしれなかったのに。でもホンダはエディ・ジョーダンみたいな強いキャラクターを（自社チームの）監督に据えたいとは思わないだろうから、どうせ交渉は決裂したかな。

このサイトのほとんどの動的生成システムにgzip圧縮を追加しました。多分このサーバーならばgzip圧縮にかかるCPUコストよりも、帯域の方が圧倒的に足りていないから。たいていの人にとっては前よりも快適なレスポンスになったと思います。ただし、HTMLを完全生成するまでに時間がかかるいくつかのページは、表示され始めるまでの応答速度が遅くなってちょっと不快かも。

自分ところの開発サーバーではApacheにmod_gzipを入れているんで、スクリプトレベルで対処するってことをすっかり忘れていたよ。

ふと思いついた。WikiLike同士をXML Webサービスでつないで動かしてみようかな。どうせ現状のコードは破棄するつもりだから、こうなったら汚いコードを後付けで追加するのにも憂いはない。毒をくらわば皿までってことで、ちょっと無茶気味でもやれたら楽しそうなことは実験してみよう。ただどのレベルで接続するかは悩むところ……。

---

一番現実的なのは、すでにGoogle Web APIsを使ってキーワード検索結果を表示しているように、他のWikiLikeサーバーにもキーワード検索を投げて、その結果をキャッシングしつつ一覧表示する感じか。現在Google Web APIsの検索結果は24時間キャッシングしているけれど、キャッシュ時間は本当は動的に変更できた方がいいんだろうな。Wikiサーバーの活発度とかを情報としてもてばそのあたりもなんとかなりそうだ。どのレベルで統計情報をもたせればいいだろう。