日々の戯言


バックナンバー

1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2017年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2018年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2019年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2020年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2021年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2022年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

12月1日(土) SO905i

SO905i (黒) に機種変更をした。申込手続き自体は発売日の 11/29 に新宿ヨドバシでできていたのだけど、前日までの SH/P/N の申し込みが積み上がっていたため引き渡しは翌日の 11/30 になり、帰宅後は RMP ネタを書くだけで時間がつぶれてしまった。あちこちいじりまわすのは今日がはじめて。

である程度触った段階での感想。基本的に携帯は非常時の連絡用 (こちらから発信することはほとんどない) で、最も重視している機能はポータブルオーディオプレイヤー。直前まで利用していた機種は SH902iS という条件。

以上、オーディオプレイヤー関連しか触ってないのがあからさまに判ってしまう第一印象。初期メニューのもっさりっぷりには「無駄なエフェクト入れんな」と思ったりもしたが、その辺を全部 OFF にしてしまえば許容範囲に収まってくれたのでよしとする。


12月2日(日) 有川 浩「図書館革命」(メディアワークス)

ようやく読む時間が確保できたので読み始め、3 時間後に読了。よい物語をありがとうという満ち足りた気分になった。(A+)

このシリーズの第一巻である「図書館戦争」のような、一定手順で脳内のスイッチを押してくれる (健気さを違和感を感じさせずにアピールしてくれるだけで満足) お話が大好きなので、かなり色眼鏡が入った評価になっているはずだけど、それでもそういった話が好きな人には無条件で勧めることができるありがたい作品。

TV アニメ化という非常に恐ろしい話もすすんでいるようだけど、どうか、どうかまともなシナリオと構成で作品化されますようにと祈らずにはいられない。


12月3日(月) Shure SE110

ケーブル被覆が破れて芯線が露出してきた E2c [URI] の代わりに何を買おうか悩んでいたのだけど、結局 Shure の SE110 に流れてしまった。

カナル型イヤホンも増えてきたとはいえ、ケーブルを耳の後ろから回してハウジングを耳孔にのせる Shure の装着方法のホールドのよさ (とケーブルのタッチノイズの少なさ) に勝てそうなものを見つけることができなかった。M-AUDIO IE および Super.Fi シリーズの「ケーブル交換可能」という売り文句に心惹かれるものを感じたりもしたものの、ハウジング部が飛び出る装着方法に不安を感じて脱落。

Audio Technica の CK9 ならその辺りの不安はなかったのだけど、イヤピースのバリエーションや価格とかが不満で脱落。結局 Shure の SE シリーズでの最廉価モデルを購入。

使い始めてそろそろ2週間が経過し、音にも慣れてきたところ。最初は E2c との変化から違和感を感じたりもしたけど、今ではそんなことはなし。今度はもーちょっとケーブルが長持ちしてくれるといいのだけど……やっぱり恒例の Shure 品質なんだろうなぁ。保証書と Amazon の納品書は保存しとくようにしよう。


12月5日(水) ARIB STD-B25 5.0 版 (2007, 3/14 版)

本日クロネコヤマトで配送され、無事受領。まだ普通に購入できるとはなぁ。明日振込処理をしておかなければ。以下、パラパラと目を通した段階でのメモ。


12月10日(月) FLV (VP6/MP3) 出力プラグイン ver. 0.2.0

公開。ダウンロードは AUF から。多分ニコニコも H.264/MP4 に対応するだろうから、じきに需要もなくなるわけだけど、まー一応作ったことだし折角なので。

今回の機能追加は、予告してた自動フィールドシフト (AFS) 等の可変フレームレート対応インタレース解除プラグインへの対応。一応 AFS だけでなく itvfr にも対応してみた。

いや、こんなこともあろうかと flvmux を PTS 指定でフレーム渡しできるように作っておいたおかげで、プラグイン側からフレームの表示時間を取得するモジュールを作るだけで済んだのが嬉しい。珍しく、将来を考えて用意しといた機能が役に立った。

◆◇◆

itvfr 対応の方はできることが少なかった (手動 VFR にまで対応する気がなかったので基本機能しか対応してない) のでさほど大変ではなかったのだけど、AFS の方は出力プラグイン側でやれることが多かったので、力技で無駄に 25fps とか 18fps とかにも対応してみた。

かえって誤爆してるシーンでガタツクようになってしまったかなーと思ったりもするけど、HD コンポーネント素材な (ドット妨害やクロスカラーが出てない) 良好なソース (電脳コイル OP とか) で試した限りではそれほど気になるシーンはなかったのでキニシナイことにする。

ついうっかりまるも式インタレース解除を再検討してみようかという気になったりもしたのだけど、世間的にはここ2年ほど放置していた MPEG-2 VIDEO Plug-In の TS 対応とか AAC 対応の需要の方が大きいだろうし、そっちの作業を進めたほうがよかろ。以前はビデオデコーダ部分を作り直してる最中にやる気が尽きてしまったけど、今度は最後までもってくれるといいな。


12月11日(火) B-CAS カードに頼らない方法

ふと思いついて、ひょっとしたらできるんじゃないのかなーという気分になったのでメモしておく。

と、ここまで考えた時点で脳内麻薬が出始めたので思考停止。そのうち 1T の HDD 買ってきて、鍵データの蓄積を始めるかも。


12月12日(水) FLV (VP6/MP3) 出力プラグイン ver. 0.2.1

公開。バグ修正がメイン。itvfr での非常に恥ずかしいバグ (switch 〜 case 文での break 忘れ) とか AFS 対応の (力技で対応シフトパターンを増やした為に発生した) 実装漏れあれこれの修正とか。

ま〜そんなことはどーでもいいのだ。現状ニコニコ動画 (smile サーバ) では可変フレームレート (フレーム毎に表示時間間隔が異なる) コンテンツはエラーとして全部拒絶してくれるので、ニコニコ向けコンテンツ作成には意味のない機能なのだから。

自分でウェブスペース確保して、SWF プレイヤーかぶせてコンテンツを置いている人であればニコニコの対応を待つまでもなく H.264/MP4 に移行できてるわけでますます意味がない作業をしてしまったなーと空しくなってるところ。

あー何でこんな無駄に帯域食うだけの規制採用してるんだろ。 ver. 0.1.3 の FLV 出力プラグインでも aviutl でドロップフレーム設定されてるフレームは VP6 フレームデータ生成しないようにしてるのでこの規制に引っ掛かるかもしれないから……その辺対処して ver. 0.1.4 作っとかなきゃなー。

◆◇◆

ver. 0.1.4 (可変フレームレート非対応版) も作成、公開した。上の記述 (無駄に帯域食うだけの規制) に関連して、テロップを流す関係でフレームレートが一定でなければ困るのかと好意的に解釈してやろうかと思ったのだけど…… SWF は msec 単位で描画制御できるはずだし、埋め込んでる動画のフレームに描画を同期させる必要はないはずと考え直した。純粋に手抜きなんだろうなぁ。


12月13日(木) TOEIC 結果

10/28 に受けてきた二回目の TOEIC 結果をさらしてみる。リスニングが 295 点にリーディングが 315 点で、トータル 610 点。

見事なまでに 1 月に受けたときよりもスコアが落ちている。特に化けの皮が剥がれたリスニングの下落 (325 -> 295) が痛いな〜。平均を圧倒的に下回ってる。リーディングも平均は超えてるとはいえ文法理解が平均以下。

英語の規格書とかマニュアル類、後は Google Scholar 経由でみつけた面白げな論文を眺めてるぐらいしかしてない偏った生活が見事なまでに反映されてる成績。文法のスコアが低いのは読むだけならその辺はあんまキニシナイで済むからなんだよな〜。

むーせめて 720 点 (欲を言えば 800 点) は越えたいのだけど、きちんと時間をあてて技術を磨かないかぎり実現は難しそうだなぁ。


12月14日(金) 事前調査 [1]

以下 payload_unit_start_indicator=1 の場合のペイロード先頭 8 バイト (MULTI2 での 1 ブロック) のパターン

ch B ピクチャ I/P ピクチャ
20 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0
21 00 00 01 e0 00 00 85 80 00 00 01 e0 00 00 85 c0
22 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0
23 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0
24 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0
25 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0
26 00 00 01 e0 00 00 85 80 00 00 01 e0 00 00 85 c0
27 00 00 01 e0 00 00 85 80 00 00 01 e0 00 00 85 c0
32 00 00 01 e0 00 00 84 80 00 00 01 e0 00 00 84 c0

NHK 系とフジが original_or_copy=1 (original) で他はすべて original_or_copy=0 (copy) 設定になっているらしい。まー両方対応するのはテーブルサイズ倍にするだけだしそんなに大変でもなかろう。stream_id を変えられると 16 倍になるからかな〜り大変だけど。

テーブルサイズは…… 1 PC で現実的に実現できるのは 512G 程度だから…… 1 エントリーあたり 32 バイト割り当てることにすると 2^34 個なら格納できるか。

その場合の平均計算量は 2^30 個の鍵を評価しなきゃいけないから……試しに key[n+1] = multi2_encrypt(plain, key[n]) を回してみると…… Core2Duo E6400 で約 150 秒か…… Ks の更新周期 (1 秒) から考えるとちょっと遅いよなぁ。30 分番組 1 個処理するのに 75 時間か。

対策としてはテーブルサイズを広げるのが一番頭を使わずに済むのだけど…… 128T のストレージは用意できないしなー。くっそー MULTI2 が 56 bit 暗号なら余裕で間に合ったのに。


12月15日(土) 技術的背景

MULTI2 で暗号化を行う場合の平文・スクランブル鍵・暗号文の関係は次の図の形になる。

また、MULTI2 で復号を行う場合の平文・スクランブル鍵・暗号文の関係は同様に次の図の形になる。

平文・暗号文は鍵が共通であれば 1:1 に対応し、自動的に結果を求めることができる。そもそもこれが成り立たないようでは暗号アルゴリズムとして使い物にならないのだけど。

さて、平文と暗号文を知っているけれど鍵を知らない場合。この場合は次の図の形になる。

一応 MULTI2 は Feistel 構造 (算術和と排他的論理和の違いはあるけど本質的には Feistel 構造と変わらない) を採用した現代暗号なので、平文と暗号文があるだけで自動的に鍵が求まるようなことはない。けれど、00 00 00 00 00 00 00 00 から ff ff ff ff ff ff ff ff まで、すべての鍵を試してみれば、平文から正しい暗号文を導ける鍵が発見できる。

また、すべての鍵を評価する際に結果として出力された暗号文と鍵をテーブルに記録しておけば暗号文から自動的に鍵を求めることができる。これがタイムメモリトレードオフ攻撃の基本原理なのだけれど、すべての鍵の結果を記録するためには同じ暗号文を導く鍵の衝突が一切存在しない理想的な場合でも 128 エクサバイトの記録領域が必要になる。現在のストレージ技術では現実的ではない。

この原始的タイムメモリトレードオフ攻撃を洗練された実用品にしたのが Martin E. Hellman 先生 [URI]。こちらがオリジナルの論文 [A Cryptanalytic Time-Memory Trade-Off]。

次の図のように暗号アルゴリズム自体を乱数列生成アルゴリズムとして使うことで、暗号文 - 鍵テーブルを効率よく圧縮することが可能だという点が論文の肝。

まず事前計算として必ず出現すると判っている平文を、ランダムに選択した鍵で暗号化する。生成された暗号文を鍵に使ってもう一度同じ平文を暗号化する。これを延々と続けていき、たとえば暗号文の先頭 30 ビットがすべて 0 になったところで停止して開始時の鍵を記録する。これを繰り返してすべてのテーブルを十分な長さで埋めるまで続ける。

そして鍵推定時には、受け取った暗号文を同じように処理して、テーブルのどの項目にたどりつくか調べる。たどりついたら、今度はテーブルに記録されている始点から、暗号文と同じものが生成されるまで続ける。暗号文が生成されたら、その時に利用した鍵 (直前の回で生成された暗号文) が推定された鍵ということになる。

この場合、事前計算で作成する必要のあるテーブルのエントリー数は 2^34 個になり、一つの鍵を推定するのに必要な平均計算量は 2^30 個の鍵評価だけになる。すべての暗号文を記録する場合と比較すれば圧倒的に少ないストレージサイズしか必要とせず、また総当たりでの鍵推定と比較すれば圧倒的に少ない計算量しか必要としない。事前計算に総当たりと同程度の計算量が必要になるが、それは分散処理を利用すればたいした問題ではない。非常に洗練された美しい手法だと、以前 C2BF の際に専門家の方から教えていただいて感動した記憶がある。

スクランブル鍵 Ks がどのようなアルゴリズムで生成されているかも、ECM がどのようなアルゴリズムで暗号化されているかも、ワーク鍵 Kw の具体的な値は何かも一切必要なく、平文と暗号分のペアだけで現実的な時間内の鍵推定が可能になってしまう。

以上のように、必ず発生する平文が 1 ブロック分 (しかも CBC の先頭で) 特定されてしまうというのはブロック暗号アルゴリズムでは致命的な弱点になる。ARIB に暗号理論の専門家はいなかったのかと疑われても同情の余地はない。何よりも救えない点は、こんな弱い暗号方式を有料放送で使用しているにも関わらず、攻撃者が増えることが予想される無料放送にもそのまま採用したところだ。(日本語にはこのような事態を表現するのにぴったりの「軒を貸して母屋を取られる」という諺がある)


12月16日(日) 日経エレクトロニクス 12/17 号

定期購読はしていない。最新号 1 部注文で金曜のうちに購入手続きはしたのだけど、到着を待ち切れず、日経エレクトロニクスを購入している図書館を探して読みにいってしまった。(さいたま市立中央図書館で閲覧した)

とりあえず先頭記事だったところにびっくり。で、私に関しては「11 月下旬に『ARIB STD-B25 仕様確認テストプログラム』と称するソースコードを匿名の個人が公開した」(雑誌最新号は図書館では自主規制で複製させてくれないので、記憶をたよりに書いている。細かな文言は異なるかも) との記述。うーん匿名で行動しているつもりはなかったのだが個人名を許諾なしに出すのはまずかろうと配慮してくれたのかなぁ。

放送局側関係者すら B-CAS 強化に後ろ向きな中、一人対処を求める椎名さんには同情を禁じ得ない。が、一般消費者としては利害が対立してしまうのでその意見に同意することはできない。

結局、私たちは各人がポジショントークで自分の利益が最大になるように洗脳合戦繰り広げて、多数派を確保した方が勝利をおさめる近代民主国家に暮らしてるわけだ。消費者としては「国民に不利益をもたらすので『無料放送は暗号化をしてはならない』という条文を放送法に追加すべきだ」と堂々と主張しても許されると思うのだけど……なんで皆黙ってるのだろう。だって消費者の方が多数派なんだからよっぽど下手うたない限り勝てるはずじゃん。官僚の方々が大好きな諸外国との比較 (現在無料放送を暗号化してるのは世界で日本だけ) とかもちだしてもいいんだし。


12月17日(月) 佐世保銃乱射事件

痛ましい事件だと思う。なによりも、まともな精神科で診察してもらって、リスパダールとかを処方してもらい、正しく服用していれば発生しなかっただろう事件だというところに救いがない。読売オンラインの「『何しでかすか…』母親にも以前から不安…馬込容疑者」という記事 [URI] からそう思う。

 夜中に「トイレを貸して下さい」と頼みに来ることもあったほか、馬込容疑者の母親から、「『盗聴器をつけられている』と息子が言っている」などと聞かされたこともあった。

私がそう判断した個所は上の引用部分。特に『盗聴器をつけられている』のあたりとか典型的な統合失調症の症状のように見える。(注: 私は DSM-IV を読んだことがあるだけの素人)

勝手な推測になるけど、たぶん精神科に相談とかもしてないんだろうなぁ。この国じゃ精神疾患に対する偏見が強いから。おまけにこの事件でさらに偏見も強くなるだろうし。

ただドーパミンが過剰に出てるせいで考えすぎるようになってしまい、疑い深くなって人を信用するのが難しくなるだけの病気なのに。胃酸過多で胃壁が痛んでるときに中和剤を飲むように、ドーパミンが過剰だからセロトニン・ドーパミン拮抗薬を飲むだけと考えるわけにはいかないのかな。


12月18日(火) 事前調査 [2]

「NG 恋」をオートモードで流してケラケラと笑いながら、軽く key[n+1] = multi2_encrypt('00 00 01 e0 00 00 84 80', key[n]) を回してどーなるかを眺めてみた。以下がその結果。

まず、予想していたよりも鍵の衝突 (同じ暗号文をもたらす鍵の数) が多い。もっとループが長かったり、ノードへの集中は少ないものと期待していたのだけど、短いループが多いうえ、特定のノードにかなり集中している。

うーむ。56 ビット鍵の C2 の時と違って 64 -> 56 の丸めがない分もっと衝突は少なくなるだろうと予想してたのに、アテが外れてしまった。バースディパラドックスから考えれば当然なのかもしれないけど。

そして MSB 側 30 bit がすべて 0 となるものを含まない孤立ループも存在する。うーむ単一ファイルで LSB 34 bit * 32 のフラットなテーブルが使えれば楽ができたんだけどなー。あーテーブルの構造をもちっと考えなきゃだめか。


12月19日(水) 長考中

案 1。ファイルシステム (ディレクトリツリー) をそのままデータベースとして採用。MSB から 2 バイト刻みで 3 段階のディレクトリを掘り、最終段をファイルにしてノード情報を格納する。

この方法のメリットはプログラムの構造がシンプルになること。欠点は 1 ノード 1 ファイルを採用することによってオーバーヘッドが増加すること。ファイルアロケーションユニットサイズが 512 byte の場合、1 エントリーしか格納されないノードでの無駄が大きくなりすぎる。また、ディレクトリが消費するディスク領域も馬鹿にならない。

案 2。DB を採用してテーブルはそちらに格納する。

問題点。私が DB に詳しくないので、正当な評価を下すことができない。そもそもフリーな DB に 2^34 個のエントリーを放り込んで普通に動くほどのスケーラビリティはあるのだろうか。

◆◇◆

堅実志向な保守的人間なので、案 1 のファイルシステムそのまま採用する方針に傾きつつある。うーん他に方法が思い浮かばなかったからという消極的な理由で設計方針選ぶと後で大抵後悔することになるんだよなぁ。


12月24日(月) 野村 美月「文学少女と月花を孕く水妖」(ファミ通文庫)

何かヤバイものを食べたせいか、先週木曜から体調を崩してしまい、この連休はベットで大量に布団を被って毒抜きをしていた。何やら日経新聞で観測気球が上がってるようだけど、空気を読まずに、布団の中で読んでた本の感想を。

「文学少女」シリーズの最新刊。お気に入りのシリーズなので購入。読了。そのまま余勢をかってシリーズ既刊全部再読とかもしてしまった。感想。「手の甲の歯型」はエロいです。(A+)

傍点まで打ってもらってるのに「喉の痣」に二回目読むまで気がつかなかったあたり読解力が落ちてるな〜最近軽い本しか読んでないせいかもとか感じてしまった。構成に気を配って、ある程度考えれば判るように伏線を散りばめ、それでいてすべてを語らずに読者を正解に導いてくれるところが気に入った。シリーズ最終巻になるだろう次巻の発売が待ち遠しい。


12月25日(火) 事前調査 [3]

継続して回していた key[n+1] = multi2_encrypt('00 00 01 e0 00 00 84 80', key[n]) の結果がある程度たまってきたので傾向を眺めてみた。

ノード 上流ノード数 割合
00 00 00 03 1f 25 44 0e 786 12.9%
00 00 00 02 5a 73 97 30 660 10.8%
00 00 00 03 b7 3f a5 2f 575 9.4%
00 00 00 03 c2 56 37 60 213 3.5%
00 00 00 03 0b b8 28 ce 190 3.1%
00 00 00 01 fc e1 0b 72 162 2.7%
00 00 00 03 4c 7b f6 12 160 2.6%
00 00 00 02 32 81 5e aa 108 1.8%
00 00 00 02 e7 bf a6 1a 96 1.6%
00 00 00 03 b0 07 0c 98 93 1.5%
その他 3056 50.1%
総計 6099 100.0%

実に上位 3 ノードに 30% が集中し、上位 10 ノードに 50% が集中してしまっている。常識的に考えれば試行数を増やしてみてもこの辺の比率は変わらないのだろうと予想できる。

1 ノード 1 ファイルで格納する場合にオーバーヘッドを気にしなくても済みそうというのはありがたいことではあるのだけど、鍵推定時の平均計算量が増える (例えば暗号文から開始して 00 00 00 03 1f 25 44 e0 に到達したら、最悪 2^34 個のノードの内 13% を始点候補として評価しなければいけなくなる) のはまったくもって嬉しくない。

さらに、これだけ特定ノードへの集中があるということは、multi2_encrypt('00 00 01 e0 00 00 84 80', key[n]) では絶対に発生しない暗号文パターンというものもかなり高い比率で存在するということになり、この手法での完全解読成功率が低下するという意味にもなる。

なんつーか特定ノード集中の原因がバグであって欲しいと願いたい気分だったりするのだけど、今のとこ怪しげなポイントは見つかってないんだよなぁ。コレ (衝突の多さ) が MULTI2 のアルゴリズム的な弱点だったりしてくれると嬉しいのだけど、そんな期待はしない方がいいだろうし。あー、一応実際に何処で衝突が発生してるか調べておくか。


12月26日(水) ちょっくら総務省いってくる

こーゆーメールが届いたということは、傍聴希望申請は受理されたってことだよな。(公開ページ [URI] に載ってる情報なんで隠す意味があるのか微妙だけど、一応個人名は伏せ字で置き換え)

  総務省デジタル・コンテンツの流通の促進等に関する検討委員会(第30回)
傍聴希望の方へ

総務省情報通信政策局コンテンツ振興課の○×です。
いつもお世話になっております。

下記のとおり第30回デジタル・コンテンツの流通の促進等に関する検討委員会
を開催いたしますので改めてご案内申し上げます。

※なお、当初HP掲載した際より、会議時間を変更しておりますので、
ご留意ください。

 ■記
 〔開催案内〕
 【第30回会合】
 日:12月27日(木)
 時:15:00〜16:30
 於:総務省 8F 第1特別会議室


以上宜しくお願い申し上げます。

とゆーわけで、有給も余ってることだし明日は午後半休とって総務省まで陰険漫才を聞きに行く。聞けた話はこのページで報告する予定。


12月27日(木) デジタルコンテンツの流通の促進等に関する検討委員会 (第30回)

傍聴してきた。まず日経新聞の記事で気になっていただろう人も多い機器認証に関して。機器認証は話題にすら上りませんでした。技術ワーキンググループで検討されてる制度的エンフォースメント (こーゆー政治的用語って実態が判りづらいからやだよね) の検討状況についての報告が主な議題だったようなのだけど、まだワーキンググループ内部でも詰め切れてないらしくアレも検討中、コレも検討中、ソレも検討中との報告。まさか今更エンフォースメントを行うことの経済的効果云々を話し合ってる段階だとは思いませんでしたよ。

で、技術的エンフォースメントのおさらいとアメリカのブロードキャストフラグに関するおさらいがあったあとで、影の主役と思われる某 USB チューナについての報告が行われましたとさ。非常に表現に気をつかって発言してるのがうかがえるものっすごく遠まわしな表現でどーいったものなのか報告していたのだけど……どんな説明だったか書いとくか。

なんつーか、B-CAS がザルだということを極力言わずに済ませながら問題点を伝えようと苦慮してるのが判ってしまう表現だったりするので聞いてて笑い声をこらえるのが大変だった。

◆◇◆

で報告事項が済んだら議論に入るわけだけど、まー話題は最後に報告されたものに集中するわな。口火を切ったのは河村さん。やりとりが面白かったので、ここは紹介せねばなるまい。

河村委員: 最後の報告に関して、大変衝撃的内容だったわけなのですが、現在のコピーワンスですか、スクランブルになるのですか、詳しくは判りませんが、これは簡単にやぶられてしまうものだったのでしょうか?
回答者失念: 暗号は破られていない。正規の手段でスクランブルを解除している。

いやー回答者を尊敬してしまう。なかなかこう言い切ることのできる逸材は少ない。本当に尊敬してしまう。

まー当然ながら、何千万枚とカードを発行して、こんなザルにいくらつぎ込んだのだ、そのコストはどーなるんだ、これからまたエンフォースメント強化でさらに金をかけるのか、誰がそのコスト負担するんだという話の流れになってしまうわなぁ。

◆◇◆

でこれを受けての各立場の方々の発言。最初は椎名さんから。

次に堀さん。

次に長谷川さん。

最後メーカ側担当者 (発言者名失念)

◆◇◆

なんつーか制度的エンフォースメントって結局「補償金」のことなのかなーと邪推してしまったりもする。権利者としては一銭の得にもならない無料放送スクランブルを犠牲にすることで、崩壊が迫ってる補償金制度を復活させるつもりなのかしらんというのが基本的な感想。

あと、無料放送を暗号化している世界で唯一の国という (梯子を登ったけど、誰もついてきてくれない) 孤高の存在でありつづけるのはそれなりに不安なのかなーとゆー感想ももった。だって「本質的にはそもそもなんでこんなことをやってるんだという疑問があがっている」とかゆー発言がこーゆー席で主査だったか主査代理だったかの口から出てくるくらいなんだもの。

とりあえず次回は 1 月 29 日らしいから、忘れずに傍聴希望申し込むようにしないとな。

◆◇◆

肝心なことを忘れていた。河村さんの「使った人は捕まるのですか?」という質問に対しての回答が「B-CAS カードの所有権は Dpa 側にあるので、不正使用ということでカードを没収できる……そもそも不正使用してるかどうか調べる方法はないですが」とのこと。

タイーホ云々で騒いでる人もいるみたいだけど、現実はこんなものらしい。


12月28日(金) GDH P2P

まず、こういった試み [GDH P2P ネットワーク実証実験] の存在自体を賞賛したい。以前 [URI] 書いたように「物理パッケージよりも安い・再生に制限がない・オンライン店舗の検索性が高い」という条件さえ満たせば購入対象として検討するつもりだった。

今までのオンライン配信では「再生に制限がない」という条件を満たすものが無かった (視聴期限が設定されているものばかりだった) けれど、少なくとも今回のものでは視聴期限という購入意欲を削ぐ最大の要因が解消されている。

ただし、この価格設定 (1Mbps 1,050 円 / 3Mbps 1,575 円) をした人間はバカじゃないかと思う。全 24 話購入した場合に DVDBOX [29,925 円 URI] よりも高くなる値段をつけるなんて何を考えているのだろうと罵りたくなる。DVDBOX よりも高いものを買う訳がないと気が付かないのだろうか。

◇◆◇

あのな、ちょっとそこに座って話を聞け。おまいらの商売相手はな、DVDBOX とか買いたくてしょうがないんだよ。でもな、今さら買っても置く場所が無い [実例] から、どうしても欲しいモノしか買えないんだ。あとな、DVD のディスク入れ替え、アレが面倒でたまらないとも思ってるわけだ。

そーゆー意味ではな、今回の実験はものすごく嬉しいわけだ。視聴期限設定のない、オンライン配信。後ろ暗い思いをせずに、せーせーどーどーとコンテンツを PC 上で自由に視聴できるわけだから。いつでも見ることができるという安心感を購入できるわけだな。

でもな、実体が無いのは不安だろ、だから、そーゆー不安なものに実物よりも高い金は払いたくないんだ。P2P なら流通コストも在庫コストもほとんど無視できるから、実物 [DVDBOX] の半額 (具体的には 3Mbps 1 話 525 円) 程度なら払っても妥当かなと思えるわけよ。

なのに、なんで、P2P 配信を実物 (DVDBOX) よりも高くするわけ? ねえバカ? ひょっとしてバカ? うたがいようもなくバカ?

◇◆◇

以上、あれこれと文句はつけたが、現状の不満点は「価格設定」だけで、そこさえ見直してもらえるなら、もっと多くの旧作アニメで同様の配信が行われて欲しいと考えている。応援の意味も込めてダウンロード購入しようと思った。

が、第01話の購入手続き (課金方式は WMV DRM) を取り、再生が開始された段階で非常に萎えるものを感じてしまった。スクイーズじゃなくて 640x480 のレターボックスだよ……これ。本気でこれを 1,575 円で売るつもりなの? (現在は半額キャンペーン中だから 788 円だけど)

残りはどーしようかなーと悩みつつ、とりあえず第02話の購入手続きだけ済ませておこうかと考えてダウンロード済みだった第02話を WMP で再生、購入手続きを済ませてしばらく眺めていると……「テレビを見るときは部屋を明るくして離れて見てください」とのテロップがガガガガゴギギギ。

ごめん。これはわざとやってるんだね。済まなかった。どーやら誤解していたみたいだ。GONZO 社内の DVD 営業部の人が P2P 配信は儲からないという実証データを捏造するためにわざとこういう設定にしたに違いない。いやーここまで手の込んだマーケティングデータ捏造方法を採用するとは。大人の世界って大変なんだなー。


12月30日(日) 相場師見習い Lv.28

おそらく誰も待っていないだろう今年の投資成績のまとめを報告する。

 前期末株式評価額 (A)4,192,900
 前期末投信評価額 (B)981,922
 前期末現金同等物残高 (C)72,174
 期中入金額 (D)1,200,000
今期資本 (E = A + B + C + D)6,446,996
 今期末株式評価額 (F)3,880,300
 今期末投信評価額 (G)1,975,702
 今期末現金同等物残高 (H)304,402
今期末残高計 (I = F + G + H)6,160,404
 受取配当金 (J)+86,670
 MRF 分配金 (K)+759
 投信分配金 (L)+243,106
 実現損益 (M)+433,557
 前期末評価損益 (N)-228,426
 今期末評価損益 (O)-1,279,110
今期損益 (P = I - E = J + K + L + M - N + O)-286,592

約 30 万のマイナス。あーエロゲ 50 本分の損失か。去年 (マイナス 80 万) と比べればマシだし、配当込み TOPIX との比較では多分トントンぐらいになってるはずなんだけど、株を始めてからの通算成績でもマイナスってのは結構きついなー。

特に現時点で抱えてる評価損 (SBI 30 万, エスペック 34 万, 陽光都市開発 35 万, DIAM ワールドリートインカム 23 万) が悲しい。来年もアメリカの住宅バブル崩壊の余波をうけまくるんだろうなー。


12月31日(月) 実家中

帰省して実家でまたーりとすごしている。土産には FOUCHER (フーシェ) のアマンド・ロアを選択した。これは大手小町の「急な来客時に出せる常備菓子」トピックで評判が良かったので年末に帰るときの土産にするかと記憶していたもの。手ごろな値段で買えて家族にも好評だったのでどうやら正解だったらしい。

家では家族が見てるテレビを聴きながら、MULTI2 の鍵衝突ポイント調査用のコードを書いたりしてる。適当にでっち上げたコードは既にある (25 日時点でいちおう動くものができてた) のだけど、これが異常に遅いものになってしまってるので、きちんとマルチスレッド可して複数コアを有効活用したり、過去の計算結果を利用できるようにしたりとかを考えて作り直してるところ。

どのみちメイン PC が置いてる部屋に戻るまではテストしかできないのでのんびりとやるつもり。時間がなくて 8 話まで読んで放置してた「NG 恋」も一応ノート PC にインストールしてもって来たのでこの機会に終わらせておきたい。


1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2017年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2018年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2019年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2020年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2021年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2022年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

[TOP]