ageha was here

　Apple TVハードウェアレポート（笠原一輝のユビキタス情報局）、http: //wiki.awkwardtv.org/wiki/Hardware_Profile、http: //wiki.awkwardtv.org/wiki/Parts、などを総合すると、　Apple TVは「光学ドライブ抜きの完全なPCアーキテクチャ」とでも言うべきハードウェア構成のようだ。

　CPU：
　　1.0GHz Intel Pentium M-based "Crofton" CPU, based on SSE2 Dothan model # 7645A966 0159
　　L2 Cacheは:256KB~ 2 MB、DothanコアベースのLPIAプロセッサ。

　笠原さんは部品原価を約25ドル(日本円で5万円前後)と推定した上で、2つの理由を推測しておられる。

1. アップルが入手しているコンポーネントの原 価が、一般的なOEM価格よりもさらに安い可能性。
2. 戦略的な値段設定をしている可能性。
   本製品の最大の特徴は、iTunes Storeで購入できるHDコンテンツと組み合わせて利用することにことにある。別にハードウェアでもうける必要はないと考えているとも推測できる。つま りハードウェアは赤字かぎりぎり黒字でも、コンテンツを販 売することで利益を出す、そうしたビジネスモデルを想定していると考えるのが自然だろう。

　後者は完全にゲーム機のビジネスモデルだ。AppleTVがMPEG-1/2, AVI, wmvなどに対応すれば根底から崩れる。
　したがって今後の展開は以下のようになるはずです：

• ファームウェアアップデート等による対応動画形式の拡張は無い。
• そうした試みに対してAppleは、技術的・法的・心理的攻撃をかける（例：ソフトウェアアップデート、訴訟、違法イメージ を付与するような宣伝）。

　自室、リビング、歩行（通勤通学）、ドライブ、人間とデジタルコンテンツ（映画音楽写真ゲーム）の接触機会すべてを自社デバイスと自社フォーマッ トで独占できるなら、WinもLinuxどころか全てのAV家電メーカーに君臨できる。デジタルコンテンツ（映画音楽写真ゲーム）の販売機会すべてを自社 で独占できるなら、全てのコンテンツホルダーがその門を叩く。

　そういうの、Big Brotherって言わんか。

---

リンク

1. http://wiki.awkwardtv.org/wiki/Parts
2. http://wiki.awkwardtv.org/wiki/Hardware_Profile
3. Apple TVハードウェアレポート（笠原一輝のユビキタス情報局）
4. Appleはデジタルコンテンツの任天堂

Engadget Japanese http://japanese.engadget.com/2007/04/02/emi-jobs-drm/

---

Q：違法コピー歓迎ということか？

Eric（＊EMIのエリック・ニコリCEO）：違う。われわれは「消費者を信用する」立場をとる。一部に は残念な行為もあるだろう。われわれの狙いは最善の音楽体験を提供することで販売を伸ばすこと。

　成功を祈り、他社が追随する事に期待したい。
　「敬意モデル」とでも言うべきものが巧く稼働するかどうかがカギだろう。
　例えばGPL/CCはどこの国でも法制化されていないので違反しても罰則が無い。てゆうか民事契約だから法廷に持ち込まれればなんらかの判断があり得る が、まだ判例が充分に積み上がっていない（慣習「法」としての洗練度が低い）。現状、GPL/CC違反に対する最大の抑止力は「叩かれる畏れ」だ。

　"EMIのエリック・ニコリCEOは発表文の最後で、「あらゆる形での海賊版との戦いと消費者の教育を続ける」と述べて いる。"そうだが、これは商用販売の音楽で「敬意モデル」を成立させるには不可欠の要素だ。DRMフリーと並ぶ車の両輪と言って良い。DRMフ リーと消費者教育（脳内埋め込み型抑止力）はセットで推進すべきもので、その過程ではDRM付きとナシを使い分けるさじ加減が成否を握る。これはその道の プロにしかできない。たのしそうだなもー。

　napsterか ら8年かかってここまで来たわけだ。EMIは歴史的な決断をしたと言って良いだろう。ワーナーブラザースだって、最初にトーキーを作った時は同業者から絶 対潰れると言われたのだ。

Engadget Japanese http://japanese.engadget.com/2007/04/02/emi-jobs-drm/

---

Q：(ジョブズが個人筆頭株主である) ディズニーのビデオなどはDRMフリーで提供されるのか？

ジョブズ：「今日はその質問をされると思っていた」。ビデオは音楽とは違い、流通の90%がDRMフリー (CD)だったことはない。音楽と同等には考えていない。

　映画の「社会適応」は音楽より強い。製作コストが段違いなだけに既存の保護法制も手厚い。この流れが映画まで波及するかどうかはまだなんとも言い難いの だが、
　紀元前からDRMがあったら聖書も三国志も源氏物語も残ってはいない。

---

agehaにオリジナルなんか無いって

1. 英EMIグループ、アップルのiTunes StoreでDRMなし楽曲を販売すると正式発表 - GIGAZINE
2. ジョブズとEMI、ビットレート2倍＆DRMフリーダウンロードサービスを発表 - Engadget Japanese
3. ITmedia News：EMI、全楽曲を「DRMなし」に――iTunes Storeで販売
4. EMIはDRMを放棄するのだろうか？(技術：生活関連) / 科学ニュースあらかると　-　DRMの撤廃,著作権管理
5. 英EMIが“DRM無し”音楽配信を実施
6. EMI Group、iTunes StoreでDRMフリーの楽曲を販売へ - CNET Japan
7. ジョブズとEMI、ビットレート2倍＆DRMフリーダウンロードサービスを発表 - Engadget Japanese
8. TechCrunch Japanese アーカイブ » EMIとApple、DRMなしの音楽を１曲あたり$1.29で販売へ
9. スラッシュドット ジャパン | EMIがDRMフリーかつ高音質に対応、まずはiTunes Store
10. 米アップルとEMI MusicがDRMフリー楽曲をiTunes Storeで発売 / デジタルARENA

　BPPは1ピクセルあたりのbit数です。
　bpp = vbitrate * 1000 / (width * height * fps)

　基本的に静止画の色深度（表中の1.00～32.00）をそのまま持って来たもので、libavcodec mpeg-4やXvidの初期には画質指標として使われていた時期がありますが（表中のASPの経験則）、静止画と異なり、時間軸圧縮などで素材の動き成分が大きく影響する動画エンコードでは必ずしも「いくつなら良い」と言うものではありません。ですから数値的画質指標に使うのは無理があります。
　Xvidでは0.2あればだいたい大丈夫という感じでしたが、より性能の高いH.264/AVCは画質の幅が広く、電波ノイズやフィルムグレインを保持したいかどうかで評価はかなり違って来ると思います。

　しかしながら、BPPを揃えてエンコードしてやると、様々なH.264コデックやフロントエンド、また解像度やfpsの違いを超えて、画質を比較できる可能性があります。
　例えば、640x272@24fps, 1024kbpsと720x480@24fps, 2048kbpsは、SSIMを同列に比較できるという事になるハズです（あくまでもおおざっぱに、です）。
　また、H.264/AVCのプロトタイプであるH.26Lは720x480@1Mbpsで、"素材と見分けがつかない"という評価を出しています。これはBPP=0.10～0.13に相当しますから、そこを目指してみるのも面白いと思います。
　なお、Apple TVがやけにBPPが高いのは、再生できるビットレート上限をそのまま入れている為です。QuickTime系フロントエンドはシークの追従性を重視して、大量のI/IDRを挿入する傾向（最小GOP間隔が1～5秒）がありますから、厳密な画質比較の際はこれも考慮する必要がありそうです。

x264の手許常用値（一律1024kbps）

x264で良く見かける高画質値 (約2000kbps)

Apple TV

H.26Lの"素材と見分けがつか ない"レベル

　※単位：kbps

		640x272 (シネスコ)		640x352 (16:9)		640x480 (4:3)		704x480 (無効領域抜き)		720x480 (D1)		960x540 (16:9)		1280x720 (16:9)		1920x1080 (16:9)
BPP	ASPの 経験則	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps	24fps	30fps
32.00	(TrueColor)	133,560	166,950	172,842	216,053	235,694	294,617	259,263	324,079	265,156	331,445	397,733	497,167	707,082	883,852	1,590,934	1,988,667
24.00	(FullColor)	100,170	125,212	129,632	162,040	176,770	220,963	194,447	243,059	198,867	248,583	298,300	372,875	530,311	662,889	1,193,200	1,491,500
16.00	(HighColor)	66,780	83,475	86,421	108,026	117,847	147,309	129,632	162,040	132,578	165,722	198,867	248,583	353,541	441,926	795,467	994,334
8.00	(256Color)	33,390	41,737	43,211	54,013	58,923	73,654	64,816	81,020	66,289	82,861	99,433	124,292	176,770	220,963	397,733	497,167
1.00	(白黒二値)	4,174	5,217	5,401	6,752	7,365	9,207	8,102	10,127	8,286	10,358	12,429	15,536	22,096	27,620	49,717	62,146
0.50		2,087	2,609	2,701	3,376	3,683	4,603	4,051	5,064	4,143	5,179	6,215	7,768	11,048	13,810	24,858	31,073
0.40		1,669	2,087	2,161	2,701	2,946	3,683	3,241	4,051	3,314	4,143	4,972	6,215	8,839	11,048	19,887	24,858
0.39		1,628	2,035	2,107	2,633	2,873	3,591	3,160	3,950	3,232	4,039	4,847	6,059	8,618	10,772	19,390	24,237
0.38		1,586	1,983	2,053	2,566	2,799	3,499	3,079	3,848	3,149	3,936	4,723	5,904	8,397	10,496	18,892	23,615
0.37		1,544	1,930	1,998	2,498	2,725	3,407	2,998	3,747	3,066	3,832	4,599	5,748	8,176	10,220	18,395	22,994
0.36		1,503	1,878	1,944	2,431	2,652	3,314	2,917	3,646	2,983	3,729	4,475	5,593	7,955	9,943	17,898	22,373
0.35		1,461	1,826	1,890	2,363	2,578	3,222	2,836	3,545	2,900	3,625	4,350	5,438	7,734	9,667	17,401	21,751
0.34		1,419	1,774	1,836	2,296	2,504	3,130	2,755	3,443	2,817	3,522	4,226	5,282	7,513	9,391	16,904	21,130
0.33		1,377	1,722	1,782	2,228	2,431	3,038	2,674	3,342	2,734	3,418	4,102	5,127	7,292	9,115	16,407	20,508
0.32		1,336	1,669	1,728	2,161	2,357	2,946	2,593	3,241	2,652	3,314	3,977	4,972	7,071	8,839	15,909	19,887
0.31		1,294	1,617	1,674	2,093	2,283	2,854	2,512	3,140	2,569	3,211	3,853	4,816	6,850	8,562	15,412	19,265
0.30	無意味	1,252	1,565	1,620	2,025	2,210	2,762	2,431	3,038	2,486	3,107	3,729	4,661	6,629	8,286	14,915	18,644
0.29		1,210	1,513	1,566	1,958	2,136	2,670	2,350	2,937	2,403	3,004	3,604	4,506	6,408	8,010	14,418	18,022
0.28		1,169	1,461	1,512	1,890	2,062	2,578	2,269	2,836	2,320	2,900	3,480	4,350	6,187	7,734	13,921	17,401
0.27		1,127	1,409	1,458	1,823	1,989	2,486	2,188	2,734	2,237	2,797	3,356	4,195	5,966	7,458	13,424	16,779
0.26		1,085	1,356	1,404	1,755	1,915	2,394	2,107	2,633	2,154	2,693	3,232	4,039	5,745	7,181	12,926	16,158
0.25	非常に良い	1,043	1,304	1,350	1,688	1,841	2,302	2,025	2,532	2,072	2,589	3,107	3,884	5,524	6,905	12,429	15,536
0.24		1,002	1,252	1,296	1,620	1,768	2,210	1,944	2,431	1,989	2,486	2,983	3,729	5,303	6,629	11,932	14,915
0.23		960	1,200	1,242	1,553	1,694	2,118	1,863	2,329	1,906	2,382	2,859	3,573	5,082	6,353	11,435	14,294
0.22		918	1,148	1,188	1,485	1,620	2,025	1,782	2,228	1,823	2,279	2,734	3,418	4,861	6,076	10,938	13,672
0.21		876	1,096	1,134	1,418	1,547	1,933	1,701	2,127	1,740	2,175	2,610	3,263	4,640	5,800	10,441	13,051
0.20	充分	835	1,043	1,080	1,350	1,473	1,841	1,620	2,025	1,657	2,072	2,486	3,107	4,419	5,524	9,943	12,429
0.19		793	991	1,026	1,283	1,399	1,749	1,539	1,924	1,574	1,968	2,362	2,952	4,198	5,248	9,446	11,808
0.18		751	939	972	1,215	1,326	1,657	1,458	1,823	1,492	1,864	2,237	2,797	3,977	4,972	8,949	11,186
0.17		710	887	918	1,148	1,252	1,565	1,377	1,722	1,409	1,761	2,113	2,641	3,756	4,695	8,452	10,565
0.16		668	835	864	1,080	1,178	1,473	1,296	1,620	1,326	1,657	1,989	2,486	3,535	4,419	7,955	9,943
0.15	低画質	626	783	810	1,013	1,105	1,381	1,215	1,519	1,243	1,554	1,864	2,330	3,314	4,143	7,458	9,322
0.14		584	730	756	945	1,031	1,289	1,134	1,418	1,160	1,450	1,740	2,175	3,093	3,867	6,960	8,700
0.13		543	678	702	878	958	1,197	1,053	1,317	1,077	1,346	1,616	2,020	2,873	3,591	6,463	8,079
0.12		501	626	648	810	884	1,105	972	1,215	994	1,243	1,492	1,864	2,652	3,314	5,966	7,458
0.11		459	574	594	743	810	1,013	891	1,114	911	1,139	1,367	1,709	2,431	3,038	5,469	6,836
0.10	ヤメとけ	417	522	540	675	737	921	810	1,013	829	1,036	1,243	1,554	2,210	2,762	4,972	6,215
0.09		376	470	486	608	663	829	729	911	746	932	1,119	1,398	1,989	2,486	4,475	5,593
0.08		334	417	432	540	589	737	648	810	663	829	994	1,243	1,768	2,210	3,977	4,972
0.07		292	365	378	473	516	644	567	709	580	725	870	1,088	1,547	1,933	3,480	4,350
0.06		250	313	324	405	442	552	486	608	497	621	746	932	1,326	1,657	2,983	3,729
0.05		209	261	270	338	368	460	405	506	414	518	621	777	1,105	1,381	2,486	3,107
0.04		167	209	216	270	295	368	324	405	331	414	497	621	884	1,105	1,989	2,486
0.03		125	157	162	203	221	276	243	304	249	311	373	466	663	829	1,492	1,864
0.02		83	104	108	135	147	184	162	203	166	207	249	311	442	552	994	1,243
0.01		42	52	54	68	74	92	81	101	83	104	124	155	221	276	497	621
0.00		0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

---

参考リンク

1. 【元ネタ】ENCODING QUALITY - OR WHY AUTOMATISM IS BAD.
2. linux でHDV 1080iをキャプチャする（ほめいりょすけのほめぱげ）
3. bpp またはCQ ( Compression Quality )とは。（How to Use ffmpegXメモ was here (2005/04~2006/08)）

改訂履歴

• 2006/12/07：初出
• 2007/04/04：全面書き換え。HD解像度・Apple TV・H24Lを追加。

　MPEG-2 PS（MP2音声）のTV録画からH.264/AVC High Profile映像+AAC音声の.mp4ファイルを作る方法。

使うもの

1. x264Encoder 0.5.2：QuickTime系フロントエンド （QuickTime Player Proなど）でx264エンコードを可能にするQuickTimeコンポーネント。
2. avc1Decoder 0.6.4：x264で生成したHigh Profile映像をQuickTime系Player（iTunesなど）でデコードするQuickTimeコンポーネント。
3. MPEG Streamclip 1.8：これがあればQuickTime Player Proはまず不要。
• ※MPEG-2 PS素材の場合、QuickTime Player Pro（有償）+ Apple MPEG-2再生コンポーネント（有償）には以下の制限がある。 MPEG Streamclipがあれば、買うのはMPEG-2再生コンポーネントだけで済む。Proキーもあればあったで楽しいですけど。
1. 映像と音声の同時書き出しが 出来ない。
2. 4GBより大きいMPEG-2 ファイルを読み込めない。

1. システム環境設定

　システム環境設定の「x264Encoder」でPre-Prosess levelをゼロにします。ここではインタレ解除をMPEG Streamclipで行う為です。

• 

2. MPEGStreamClipの設定

　MPEG Streamclipに素材ファイルを読み込み、Fileメニューから「Export to MPEG-4」を選ぶと、次のようなウィンドウが開きます。

	◆2 パスの場合 Multipassにチェック B フレームを使うならB-framesにチェック（使う方が縮む） 望みのファイルサイズになるようLimit Data Rateを入力。 音声は好みで。 地上波アナログなら Frame Sizeは640x480（4:3）にします。 Frame Rateは素材から読み取るので空欄で29.97fpsになります。 ※逆テレシネはありません。 Better Downscalingは多少画質が良くなりますが、やや遅くなります。 Deinterlace Videoにチェックを入れます（インタレ解除）。 他は取りあえず弄らなくて良いです。
	◆1pass crfの場合 Multipassをオフ。 B フレームを使うならB-framesにチェック Limit Data Rateは触らない方が画質は良いです。 ※入れると1000や2000では画質が良く無い事が多いようです。 Compression スライダでおおまかな画質が決まります。

3. x264Encoderの設定

　「Options...」 を推すとx264Encoderの細かい設定ができます。

◆2 パスの場合 図は実用的な範囲で最も時間のかかる=画質の良い設定例です。 avc1Decoder 0.6.4抜き、つまり素のQuickTime系で再生するには： FLAG_2_BPYRAMID(3) FLAG_2_8x8DCT の チェックを外します。 これまでApple-H.264を使っていた人は： nclc and gammaの二項目 　を使った方が色の違和感が少ないでしょう。 ア ニメの場合： sc_thresholdを65 程度まで上げた方が良いようです。 Bフレームを使わない場合、以下は効きません： FLAG_2_BPYRAMID(3) FLAG_2_WPRED FLAG_2_BRDO max_b_frames b_frame_strategy bidir_refine 速 度を上げるのに最も効果が高いのは： refs me_subpel_q... me_range 　 を下げる事です。どれも画質への影響も大きいので、 　デフォルト値以下にはしないのが得策です。 弄 らない方が良いもの： FLAG_2_FASTPSKIP や や速くなりますが闇階調ブロックノイズが出ます。 me_method UMH は劇的に遅くなる割に効果が薄いです。 qcompress 上 げても下げても2パスの意味が薄れます。 b_frame_strategy B を使うなら切らない。

◆1pass crfの場合 crfに チェックを入れます。

4. x264Encoderの設 定項目詳細

＼	Memo	MEncoder -x264encoptsの相当オプションと手許常用値
Box3	基 幹オプション1 　～最初にここを決め、残りはそれとの関連で決めましょう～
refs	速度と画質への影 響・大 複数参照 推奨値3程度。実用上限6程度。 増やすほど圧縮効率が良い。但し、そのぶん時間はうなぎのぼりで効果も漸減してゆく。	frameref=4 1stはturboが勝手に下げる
me_subpel_q...	速度と画質への影響・大 動き予測全般の算出方式を選択。範囲1-7。デフォルト5。推奨6以上。 5以上でないと効果を発揮でき ないオプションがある。	subq=7 1stはturboが勝手に下げる
me_range	速度と画質への影響・大 要・ me_method=umhまたはesa。 umhまたはesaで使える動き捜索の範囲指定。 実用範囲16-32。デフォルト16。	me_range 1stは16 2ndは32
max_b_frames	画質への影響・第２位⇒参考 Bフレームの最大連続枚数。推奨3程度。 いくつに指定しようがBに適さないフレームがあったら自動でI/Pにしてくれる。 Bが3連続するようなケースはまずない。	bframes=3
sc_threshold	画 質への影響・第１位⇒参考 Iフレーム挿入性向。デフォルト40 ほとんどの実写は40でOK。アニメは上げるべき。	scenecut 実写：40 白黒：65 アニメ：65 （かつkeyint_minを1以下）
qcompress	下手に弄 らない。 低くするとビットレートの変動幅が低くなる。=画質の変動幅が大きくなる。 高くするとquantizerの変動幅が低くなる。=画質の変動幅が小さくなる。 ※実写では0.7程度まで上げると画質が良いと言う資料もあるが、基本的に全体 平均ビットレートを低く抑えてbit 配分にメリハリをつけるほうが「画質が良い」。 　qcompressは上げても下げてもメリハリが失 せるという2Passでは画質的に難しい存 在。	qcomp デフォルトのまま。 むしろratetolや、qp_stepで ビットレートやquantizerの メリハリを強化。
noise reduction	ノイズリダクション MEncoderでは有用範囲は100-1000としている。	nr 手許ではhqdn3dを常用。
Box1	基幹オプション2
me_method	速度と画 質への影響・大 モーションベクトルのサーチ方式の指定。推奨はhexかumh。 速い順でumh、esa。 遅い方が画質が良いが、esaの画質向上は速度低下と引き合わない。 ※EPZSの内容不詳。x264cliには存在しない。	me=umh
coder_type	サイズと画質への影響・大 符号記述方式の選択。CABAC大推奨。 CAVLC：適応的可変長符号化 CABAC：15%程度の符号量節約。素のQTPlayerでも再生できる。負荷はエンコード・デコードともに増える。適応的二進数算術符号化 ※単独で15%も節約できるオプションは他に無い。	(no)cabac 必ず使用。
directpred	Bのbit節約になる。Bを使うなら推奨。 一口にBといってもAVCでは細かい種類がある。directはBのモーションベクトルをまじめに書き込まず「隣と同じ」とだけ書き込んでおくType。 まじめに数値を書くよりbitを節約でき、計算時間も早い。ここでは「どっちの隣か」を指定する。 disabled：無し、まじめに 計算して書き込む。画質も速度も最悪。 spatial：空間軸、mencoderの経験上、autoでもほとんどコレになる。最速。 temporal：時間軸、アニメでゴーストが出るという人も居る。これも最速。 auto：空間軸と時間軸を必要に応じて使い分ける。画質は最上、速度は中間。	direct_pred=auto 必ず使用。
trellis	適応的量子化の一種。理屈不詳。 Disabled：非使用 Only final：最終エンコードでのみ使用 All：全モード決定で使用。(低速、要・me_subpel_q...=6以上) ※使わないほうが画質が良いケースもあるとする人もいます。	trellis 必ず使用。
Worker Thereads	速度向上・大 Single/Dual/Quad ス レッド数の指定。 ※分散するほど画質は劣化するが、主観的にも数値的にも事実上無視して良い。	threads 1st=2 2nd=16 上記の理 由
Faster FirstPass	Faster FirstPass 速度向上・大 Disabled/Turbo1/Turbo2 2 パスモードの 1st passで重いオプションを切り、高速化する。 me_method, refs, me_subpel_q...の指定値を無視。独自値を使う。 画質的なデメリットは目で見てもまずバレない範囲とされる。	turbo=1 2パスの1stのみ。 必ず使用。
Box2
crf	1パスで済ませたい人用の「なんちゃって固定量子 化」。 2パスでは無意味。	crf 非使用。2パスしかやらない。 （3パスもやらない）
b_frame_strategy	適応的B挿入のオンオフ。 Bに適さない映像があったときに、勝手にPを使ってくれる。 切ると規則的にmax_b_framesで指定した枚数のBが入る。	b_adapt
cmp(chroma_me)	動き予測に色彩情報も参考にする。 白黒映画でも色彩情報は入っているので切らない方が良い。	chroma_me
partp4x4	細かいマクロブロックを使う。 粉雪とか桜吹雪とか落語家の顔の皺とかアナログ電波ノイズとか、をキレイに残したい場合に使う。bitrateも上げた方が良い感じ。	partitions
bidir_refine	Bフレームの動き予測精度向上。	bime
use 3rd pass	1000フレーム以下の短い素材で効果があるとされる。 ※短い素材はApple-H.264のマルチパス（パス数自動）に任せてしまうのも手。	pass=3
CODEC_FLAG2	補 助的なオプショ ン群
FLAG2_BPYRAMID(3)	Apple-H.264非互換 avc1Decoder 0.6.4が無いと再生できなくなる。 要・ max_b_frames=2以上 Bフレームを参照フレームに使う。Bのbit節約になる。	(no)b_pyramid 必ず使用。
FLAG2_WPRED	要・max_b_frames=1以上 適応重み付け予測。Bのbit節約になる。	(no)weight_b 必ず使用。
FLAG2_MIXED_REFS	要・refs=1以上 複合参照。マクロブロックパーティション単位で独自の参照先を選べるようにする。全体のbit節約。	(no)mixed_refs 必ず使用。
FLAG2_8X8DCT	High Profile専用 avc1Decoder 0.6.4が無いと再生できなくなる。 8x8DCT変換。 使うとほとんど8x8サイズブロックだらけになる。x264はHigh profileに重心がある。	(no)8x8dct 必ず使用。
FLAG2_FASTPSKIP	早い段階でPフレームのskip検出をする。 使った方が地味に速いが、x264最大の弱点「闇階調でフレーム単位でぱたぱたと動くブロックノイズ」が出がち。	(no)fast_pskip 必ずnofast_pskip使用。
FLAG2_AUD	mpeg-TSコンテナに入れる際に必要なものらしい。	不詳
FLAG2_BRDO	要・me_subpel_q...=6以上 Bフレームのレート歪み最適化。Bのbit節約。	(no)brdo 必ず使用。
CODEC_FLAG	補 助的なオプショ ン群
FLAG_LOOP_FILTER	デブロックフィルタ。切 らないのが基本。 MPEG系で発生不可避のブロックノイズ対策を映像データに埋め込む。 再生ソフトのデブロックフィルタ類はこの機能と競合する可能性有り。	(no)deblock 必ず使用
FLAG_PSNR	コンソールログにPSNRを表示。高いほど画質が良い。 値自体は無意味で、 同一素材の設定を試行錯誤する際に使う。 詳細は「SSIMとPSNRとは」参照のこと。	(no)psnr 必ず使用。
Console log
log info	コンソールログに様々な情報を表示。
log debug	コンソールログにデバッグ情報を表示。
log stats	コンソールログに2passの統計情報を表示。
nclc and ganma	QuickTime 固有の要素。
No nclc info	地味に色合いが変わる。特に互換性の問題は無い。	対応無し
Add gamma 2.2	※作者氏の記事参照。	対応無し
Native fps	素材に応 じて指定。

　07年03月中旬からx264の動きが激しい。
　動向はSylphide氏のLunatiliaに詳しいが、ここでは620以降の主なものとPPC Macに関係しそうな変更を拾ってみた。

PPC Mac関連

高速化

rev	date	投稿者	概要	メモ
620	01/21	pengvado	tweak block_residual_write_cavlc. up to 1% faster lossless, no difference at normal bitrates. trunk/encoder/cavlc.c (modified) (6 diffs)	最 大1%高速化。一般的なbitrateでは差はない。 ＊cavlcだしな。
621	01/25	gpoirier	Fix build issues on Linux. Only gcc-4.x is supported, as on OSX. Cleans up a few inconsistencies in the code too. trunk/common/ppc/dct.c (modified) (4 diffs) trunk/common/ppc/quant.c (modified) (6 diffs) trunk/common/ppc/quant.h (modified) (2 diffs)	Linux/OS Xのビルド上の問題を改善。 gcc-4.xしかサポートしない。
623	02/22	pengvado	ooops, scenecut detection failed to activate when using threads and not using B-frames trunk/encoder/encoder.c (modified) (3 diffs) trunk/encoder/slicetype.c (modified) (3 diffs)	ありゃ、 threadを使うとシーンカット検出にしくじってた。Bも使えなくなってた。
624	02/28	aizvorski	add ability to generate doxygen documentation; make dox trunk/Doxyfile (added) trunk/Makefile (modified) (2 diffs)	doxygenドキュメントを生成できるようにした。 ＊少しアプリケーションとしての体裁 が整った？
627	03/03	gpoirier	compile fix for GCC-3.3 on OSX, based on a patch by Patrice Bensoussan % patrice P bensoussan A free P fr% Note: regression test still do not pass with GCC-3.3, but they never did as far as I can remember. trunk/common/ppc/dct.c (modified) (3 diffs) trunk/common/ppc/ppccommon.h (modified) (2 diffs)	OSXのGCC -3.3でのビルド上の問題を改善。 ＊regression testってなんだろうな。文法エラーかなんかか。
629	03/14	sam	common/cpu.c: runtime AltiVec autodetection on Linux. configure, Makefile: do not build the whole project with -maltivec because it generates AltiVec code in weird places.	AltiVec最適化関連？？？
630	03/14	sam	Use -maltivec when building dependencies, or <altivec.h> cannot be used. Do not declare vectors in non-AltiVec files.	AltiVec最適化関連？？？
632	03/14	sam	check x264_cpu_detect() before calling AltiVec functions.	AltiVec最適化関連？？？
633	03/14	sam	Made -DNEED_ALTIVEC unnecessary, thanks to Guillaume Poirier.	AltiVec最適化関連？？？
637	04/02	xtophe	Compile fix trunk/common/ppc/mc.c (modified) (1 diff)	PPC の動き補償関連のビルド修正
638	04/03	pengvado	in hpel search, merge two 16x16 mc calls into one 16x17. 15% faster hpel, .3% overall. trunk/common/mc.h (modified) (1 diff) trunk/common/ppc/mc.c (modified) (1 diff) trunk/encoder/me.c (modified) (2 diffs)	1/2ピクセル精度動き補償を15% 高 速化、全体としては3%。 ＊確かハーフペル精度ってsubq=3でしか使ってなかったような。
641	04/04	pengvado	when encoding with a cqm, probe_skip now also uses the cqm, instead of the flat matrix trunk/encoder/macroblock.c (modified) (4 diffs)	cqm 使用時にprobe_skipもcqmを使うようにした。これまではflatだった。 ＊フレーム単位でぱたぱたと動く闇階調ブロックノイズに効果があるかも。
642	04/04	pengvado	2x faster quant. 2% overall. side effects: not bit-identical to the previous algorithm. while the new algorithm covers a wider range of cqms than the previous one did, I couldn't find a good way to fallback to a general version for the extreme cqms. so now it refuses to encode extreme cqms instead of just being slower. lays a framework for custom deadzone matrices, though I didn't add an api. trunk/common/quant.c (modified) (2 diffs) trunk/common/quant.h (modified) (1 diff) trunk/common/set.c (modified) (7 diffs) trunk/common/set.h (modified) (1 diff) trunk/encoder/encoder.c (modified) (3 diffs) trunk/encoder/macroblock.c (modified) (15 diffs) trunk/encoder/rdo.c (modified) (5 diffs) trunk/tools/checkasm.c (modified) (5 diffs)	量子化を2倍に 高速化。全体としては2%。 過去のアルゴリズムにくらべるとbitレベルで等価では無いが、より幅広いcqmをカバー。 ぶっ とんだcqmをどう扱うのが良いか解らなかったので、そういうものは低速化する代わりに拒絶するようにした。 APIはつけてないが、 カスタムデッドゾーンマトリクスのフレームワークを内蔵している。 ＊cqmをお使いの方はご注意を。
645	04/05	pengvado	x264 H.264/AVC encoder Rev.645参照。 x86 上でのビルド絡みと推測。

　これとは別にman mencoderの方にdeadzone_inter/intraの説明が追加されてたりしますね。
　あといいかげんdiffとか覚えた方がいいと思った。

原文：Elgato's Turbo 264 USB Stick Encodes H.264 for Your iPod, iPhone and Apple TV（GIZMODE）

2007/04/02

　Appleが全てのMacにハードウェアのH.264 encoding/decoding チップを乗せる積もりだ、という噂を追うように、Elgatoはそれ と全く同じ事をするH.264 USB stickをリリースした。以前から言われているようにUSB stickは内蔵チップに比べれば次善の策だが、もたらすものは同じだ。

　Turbo 264は、ビデオのencode/decodeであなたのCPUを肩代わりする。CPUは他の事に使えるわけだ。スクリーンキャストをリアルタイムで録画 したり、様々なコンテントをApple TV用にリアルタイム変換したり、iPod/iPhon向けのビデオを高速に作ったり（他の機能にくらべるとやや退屈だが）、できる。

　いまのところ、EUでしか買えない99ユーロ。 – Jason Chen

---

　この製品、テクノラティ検索とかでやたらと出て来るのだけど、ギズモード・ジャパンにも、Elgatoのサイトにも見当たらず。詳細がなんとも。
　もしかして4/1ネタだったりするかもしれません。

---

追記：

2007/05/29

　結論とかは無いです。おもいつくままにだらだら。

　H.264/AVCはほぼ日本の家電メーカー（例えば東芝の適応重み付け予測）、IBM(CABAC)、Microsoftのパテントでできている。
　MP4コンテナはほぼAppleのパテントでできている。
　韓国とEUも数は多くは無いが入っている。特に人口の少なさを考えると韓国企業は極めて優秀と言える。

　「国際標準規格」に自社特許を盛り込めば、それを使用する会社や個人からお金が取れる。
　というのは企業にとっては大きな魅力だから、実はあんまり大した事の無い特許でもオカネや政治力次第ではねじ込めたりもする。
　あくまでも構造/可能性の話。優秀というのはそのへんも含めての話だ。
　もちろん、タマがアレではどうしようもないのでそこは当然クリアしていなければならない。
　つまり、政治的には「国際標準規格」というのは各国のプロパテント政策の戦場だ。
　これは規格の肥大化とパテント料の高騰を産む。MPEG-4 ASPが変則的な形でしか普及しなかったのは主にここに原因がある。

　これまでのところパテントホルダー側からx264やmp4boxが直接攻撃を受けたという話はないようだが、根本的にはパテント・リスクは潜在してい る。
　パテントホルダー側の戦術として、GIFやMP3のように普及した頃合いでどーんと主張してみる、という手法がかつてあったが、これは世間の評判がめろ めろになる。
　いずれにせよ企業活動はお金の為、という点で一貫している。慎重に差し引き勘定をした上でなければ、もはや取りにくい手法だろう。

　面白いのはEUだ。
　2005年の夏にEU全域をカバーするソフトウェア特許保護法案というのが否決された（域内各国にはその法律がある国もあるがEU全体としては無い）。
　2006年暮れにはフランスでDADVSI法というのが話題になった。
　いずれも成立していればffmpeg/MPlayer/VLC/x264の全てが灰燼に帰していただろう。もちろん、今後もあり得る。

　面白い、というのは情報安全保障の観点からEU全域で推進が進むlinuxにとって、ソフトウェア特許のメリットは大きく無い事だ。
　EU経済にいわゆるワールドクラスの大企業～トムソンとかフィリップスとかダッソーとかABBとかノキアとか～が占める割合は必ずしも大きいとは言え ず、
　ソフトウェア特許があってはむしろ儲けが減ってしまう中小規模の企業が占める割合がデカイらしい。
　メリットを受ける存在はEUより、むしろ北米や日本にある。

　オープンソースにストレートな法的攻撃を加えても、それどころかシェアウェアをまんまパクってもまるでイメージが落ちないのはAppleくらいだ。
　この点、自分はAppleをオープンソース・マルチメディア最大の脅威と評価している。
　リスク評価リストのトップに置くに値する軍備を持っていると言う事で、主義主張思想信仰感情の類いは考慮していない。
　昨年のエイプリルフールにVLCが発したネタは、AppleとMacユーザーに対する皮肉だと思う。

　企業の間で自社技術を一切外に漏らさない。という手法が流行っている。
　特許出願すらせずに完全なブ ラックボックスの形で技術を商品化すれば、特許検索にも引っかからないと言うわけだ。
　特許制度というのは錬金術の反省（盗用をおそれて口伝、非公開、発明者の死亡と ともにロスト、そして伝説へ）から生まれたものなので、
　今世紀中に企業社会の中世化なんてものが見られるかもしれない。一子相伝の液晶パネルとか。

　大企業がヒトモノカネを集約的に運用する、というのは構造的にはあまりイノベーションを生まない。
　キャッチアップ型経済（戦後復興や発展途上国の開発独裁）には便利だが、ゴールにたどり着くと腐敗が始まる。パイが縮小すれば取り分争いだ。
　事業構造の再構築であるはずの「リストラクチャリング」がなぜか「リストラ＝解雇」で定着してしまったのは、
　イノベーションを生むより人件費切ったほうが儲かる、という意識の存在を示している。
　「格差社会」というのも、イノベーションを生むより人件費切ったほうが儲かる、という意識の存在を示している。

　ライブドアがああいう形で無力化した事は、中小のベンチャーに冷や水をかけた。

　「嫌韓」というのは実際には韓国企業を利する。
　韓国製品を買わない。技術を盗んだ。あれらはパクリだ。品質が悪いに違いない。というイメージは、日本企業の国際競争力を確実に削ぐ。
　最大のテキはいつだって油断であり、それを生むのは侮りと奢りだ。
　少なくとも自分の見聞した範囲では、サムスンの人もLGの人も抜群に優秀でガッツがある。

deadzone_inter=<0-32> (default: 21)

　非trellis量子化におけるインター（画面間）輝度量子化のデッドゾーン。
　低くすると細かいディテイルやフィルムグレインの保持に効果がある（一般的には高ビットレート/高画質エンコード向け）。
　高くするとこうしたディテイルをフィルタリングしてbitを節約し、他のマクロブロックやフレームに回す（一般的にはbitrateの厳しいエンコード 向け）。
　このオプションより先にdeadzone_intraを調整するのがお奨め。

deadzone_intra=<0-32> (default: 11)

　非trellis量子化におけるイントラ（画面内）輝度量子化のデッドゾーン。
　deadzone_interと同じだが、効果はイントラフレームに出る。
　deadzone_interより先に調整するのがお奨め。

【補足】

理屈

　「量子化」自体を「画質劣化度」とムリヤリ肚に落としているので「量子化」「量子化値」「被量子化値」「量子化パラメータ」がそれぞれ違うらしい となるとあまり深入りするのも問題だが…。

　「デッドゾーン」とは、量子化値が0になる範囲のことで、非常に細かい値は強制的に0に丸めて省略してしまへ！

　という事のようだ。従って実用上は、deadzone_inter、deadzone_intraの入力値より細かい輝度値（＝ほぼディテイルと 思って良いだろう）は潰してしまいますよ、という理解で良いと思う。上記の通り、x264はそれぞれにデフォルト値が入っており、細かいディテイルを潰し ている。

　他方、教科書p137には「H264/AVCでは画面内、画面間符号化ともデッドゾーンの無い量子化を採用し ています」とある。
　つまり、規格上は非常に細かいフィルムグレインやスノーノイズまでがっつり残せる。

　◆教科書によるデッドゾーンの有無：

	画面内符号化	画面間符号化 （動き補償により小さい成分が多い）	備考
MPEG-2	有り	ナシ
H.264/AVC	ナシ	ナシ	intra,interで同じ量子化が使える

　ただし、フィルムグレインやスノーノイズまでがっつり保持って事になると、必要なビットレートがうなぎのぼる。
　x264は実用性の観点 からデッドゾーンを採用してるって事だ。

実用性

　例えば自分の場合、1024kbpsと2048kbpsの画質差はほとんど感じ取れない。bitrateの高 い方が全体的になんとなぁく、じんわりと「良いかな？」とは思うものの、噺家の顔の皺、着物の質感などにはまず違いがなく、素材と比べるとどちらも同程度 の潰れがある。

　逆に古い白黒映画ではフィルムのコマ単位で輝度がばらついたり、一コマだけやたら汚れてたりする事があるのだが、そうした部分がやけに強調されて しまうケースがある。しかも素材に忠実ではないブロックノイズという形で。そのくせ衣装の毛羽立ち具合などは同程度の潰れがある。

　もちろん、hqdn3d やpp=l5を-vfチェインに組み込んでいるのでその影響が一番大きいハズだが、両デッドゾーンのデフォルト値の存在と教 科書の記述の不整合から見て、x264自体が1024kbps近辺に主眼をおいたチューニングになっているのだと思う。

　使い道としてはまずロスレスを考えたい。huffyuvを受け付けないQuickTime系とapple intermediate/Pixletを受け付けないlinux系を繋ぐ中間生成物だ。
　man mencoderにはqp=0でロスレスとあるが、真のH.264 ロスレスは以下と考えられる。

qp=0:deadzone_intra=0:deadzone_inter=0:nodeblock

　これで理屈上は、スノウノイズだろうがフィルムグレインだろうが着物のケバ立ちだろうが噺家の顔の皺だろうがどーんと来い！って事になる。
　他は
　keyint=0:keyint_min=0:scenecut=100:bframes=0:cabac、
　-oac copy、
　-of lavf -lavfopts format=mov:i_certify_that_my_video_stream_does_not_use_b_frames、
　-o XXX.mov
　と言ったところか。

　最終エンコード向けには、bitrateとの絡みでいくつが良いとは言いにくいようだ。Doom9から画質向上方向のtipsを拾ってみると：

Doom9 Explanation for new switches in x264

---

#4 IgorC

--deadzone：高bitrate でディテイルレベル向上。ノイズ、フィルムグレイン、など。

#10 AlexW（x264 contributor）

IgorC が言ったように、--deadzoneは中～高bitrate領 域での精細なディテイルやフィルムグレインを向上させる。
まず--deadzone-intra の調整から始めるのをお奨めする。違いの大半はここで発生するみたいだから。--deadzone-intra の デフォルト値は11だが、いくぶん0に近い方がややディテイルが残るようだ。CQMと一緒に使うとなお良いハズ。

#23 akupenguin（x264 author）

理論上、lambdaを改造すればtrellisに もdeadzoneが使える。でも実装はまだ。

#10 AlexW（x264 contributor）

まだちゃんとテストしてないが、速度低下は最小限のハズだ。

#14 Sharktooth

一般的なbitrateとして数字を上げるのは意味が無い。完全に素材の複雑さ次 第だからだ。
こんなふうに考えてくれ：
超低ビットレート＝見るに耐えない画質。
低ビットレート＝ 悪くは無いが決して良いとは言えない。
中ビットレート＝ 良い。但し完璧では無い。
高ビットレート＝ 完璧に近い。

#27 akupenguin（x264 author）

Deadzoneはquality-per-qpに 影響する。理想的なデブロック強度はqualityに依るが、現実のデブロック強度（規格上の定義によるもの、およびx264オプション で指定するもの）はQPと相関関係にある。qualityでは無い。
だ からもしquality-per-qpを調節すれば、デブロックの設定も変えたいケースがあるだろう。しかしながら、デブロック設定の単位は極めて粗いの で、deadzoneを最低値の0まで下げた場合でも（推奨しない）、対応するデブロック補正はせいぜい-1に止めるべきだろう（default deadzoneの時に使っていたデブロック強度に対して-1）。反対にdeadzoneを最大値の32まで上げるなら、適切なデブロックはせいぜい+ 1。
　
適切なdeadzoneとbitrateとの間に特定の関係は無い。Deadzoneは常にrate-distorion optimal valueと相関関係にあるので、いかなる変化もサイコビジュアルな もので、まだ断定的な推奨値を書けるほどテストされていない。

#29 pinkie_1

詳しい人に--deadzone の正しい使い方を聞きたいのだが：
奇妙な組み合わせで使う人が多いように思える。例えば(4,4) 、 (6,6,)、(0,0)すらある（intra, interの順）。
自分の理解では:
1. intra < inter であるべき。
2. (0,0) は非実用的。
個人的には--deadzoneを使う際は (2,4) か (4,8) にしてる。

　一般的に適切なbitrateというのは存在しないが、一応の目安としてBPP表を作ってみた。

【原文】http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html
【追記予定先】

• deadzone_inter=<0-32>
• deadzone_intra=<0-32>

---

更新履歴

• 2006/10/09：初出
• 2007/04/07：MPlayer dev-SVN-r22915-4.0.1に合わせて修正。

x264 [info]: slice I:576

　ざっと3秒に一枚。
　手許で一番多かったのはゼーガペインの毎週480～520、I比率1.1x%といったところだが、

23.976fps_アニメ（63件）	SSIM	I比率
平均	0.9908766	1.0%
天元突破グレンラガン_01_お前のドリルで天を突け！！	0.9897144	1.3%

　と言う事で見てみたらまーポンポンとカットのあることあること。
　数値・主観とも画質に文句は無いが、MovieVideoChartで見るとIDRの挿入点に疑問を感じる部分があった。
　うわ、そのシーンカット見つけますか賢いねぇというところもあり、なんでそこにIDRを入れないのだ君わという箇所もありで、判断基準が一貫していな い。
　GOP関連設定はkeyint=240:keyint_min=1:scenecut=65。

そのシーンカット見つけますか賢いねぇ	なんでそこにIDRを入れないのだ君わ	メモ
		ズームではなくすぱっと 切り替わるのでカットと 言えばカット。
		どちらも上と同じ"カット" だが、良く解らない。
		さらに解らない。 輝度？複数参照？
		さらにさらに解らない。 入れるならここは 1224だろう。
		光のつぶつぶが画面を 覆うシークエンスの中に はもっとカットがあるが IDRはこの一枚だけ だった。 これは仕方がないだろう。
		これは明らかに不正確 だと思う。
		左に入って右に入らない のはなぜなんですくわッ。

　理由は

1. thread分散でscenecut検出が地味に不正確になる。但し速度的なメリットのほうが大きい。
2. 1stと2ndでframerefの値を変えると、これもscenecut検出に影響が出る。但しturbo=1を使う以上避けられない （turboの内容を解析して同等設定の1stを使うとPSNR/SSIMともに落ちる）。

　などが考えられます。

　いずれにせよ通常視聴では全く気になりませんでしたし、オープニング約1800枚に入ったIDR56枚のうち、おかしいなと思ったのは上記4箇所だけな ので、気にするのはかなり偏執的だと思った。
　でも地味に不可解だと思った。
　あと「ぐれんがらん」じゃないんだと思った。

 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg
===MENCODER_PASS1===
$ mencoder 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile 天元突破グレンラガン_01_お前のドリルで天を突け！！.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /dev/null
 
x264 [info]: using SAR=44/45
x264 [info]: using cpu capabilities 
x264 [info]: slice I:576   Avg QP:18.12  size: 20862  PSNR Mean Y:48.01 U:51.06 V:51.36 Avg:48.76 Global:47.43
x264 [info]: slice P:22732 Avg QP:19.51  size:  6951  PSNR Mean Y:46.27 U:49.68 V:50.31 Avg:47.12 Global:45.78
x264 [info]: slice B:12884 Avg QP:21.58  size:  2070  PSNR Mean Y:45.72 U:49.36 V:49.99 Avg:46.64 Global:45.45
x264 [info]: mb I  I16..4: 24.8% 29.7% 45.5%
x264 [info]: mb P  I16..4: 10.4%  9.5%  5.7%  P16..4: 57.6%  7.0%  2.5%  0.0%  0.0%    skip: 7.5%
x264 [info]: mb B  I16..4:  0.5%  1.2%  0.9%  B16..8: 17.6%  0.0%  0.0%  direct: 9.8%  skip:70.0%
x264 [info]: final ratefactor: 20.26
x264 [info]: 8x8 transform  intra:37.0%  inter:23.4%
x264 [info]: direct mvs  spatial:98.7%  temporal:1.3%
x264 [info]: SSIM Mean Y:0.9883897
x264 [info]: PSNR Mean Y:46.101 U:49.584 V:50.211 Avg:46.977 Global:45.677 kb/s:1042.41
 
Video stream: 1042.511 kbit/s  (130313 B/s)  size: 196715275 bytes  1509.550 secs  45242 frames
SEC ; 1815
TIME; 0:30.15
 
===MENCODER_PASS2===
04/05 03:32.16
$ mencoder 天元突破グレンラガン_01_お前のドリルで天を突け！！.mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=1:scenecut=65:qp_min=10:qp_max=51:qp_step=8:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime -passlogfile 天元突破グレンラガン_01_お前のドリルで天を突け！！.264.log -vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o 天元突破グレンラガン_01_お前のドリルで天を突け！！.264
 
x264 [info]: using SAR=44/45
x264 [info]: using cpu capabilities 
x264 [info]: slice I:576   Avg QP:17.62  size: 19584  PSNR Mean Y:48.64 U:51.21 V:51.51 Avg:49.31 Global:48.46
x264 [info]: slice P:22732 Avg QP:18.50  size:  6659  PSNR Mean Y:46.96 U:49.87 V:50.48 Avg:47.74 Global:47.12
x264 [info]: slice B:12884 Avg QP:19.81  size:  2379  PSNR Mean Y:46.65 U:49.72 V:50.33 Avg:47.48 Global:46.84
x264 [info]: mb I  I16..4:  6.4% 77.3% 16.3%
x264 [info]: mb P  I16..4:  0.6%  8.7%  1.5%  P16..4: 61.6% 10.2%  5.1%  0.3%  0.1%    skip:11.9%
x264 [info]: mb B  I16..4:  0.0%  0.4%  0.1%  B16..8: 27.4%  1.8%  4.1%  direct: 3.4%  skip:62.8%
x264 [info]: 8x8 transform  intra:79.4%  inter:62.1%
x264 [info]: direct mvs  spatial:91.2%  temporal:8.8%
x264 [info]: ref P  79.4% 10.8%  6.4%  3.4%
x264 [info]: ref B  74.0% 14.3%  6.8%  4.9%
x264 [info]: SSIM Mean Y:0.9897144
x264 [info]: PSNR Mean Y:46.875 U:49.842 V:50.445 Avg:47.672 Global:47.038 kb/s:1024.49
 
Video stream: 1024.598 kbit/s  (128074 B/s)  size: 193335118 bytes  1509.550 secs  45242 frames
SEC ; 6291
TIME; 1:44.51

◆ Introduction 試訳

　監督：Kevin Munroe（TMNT）。
　Imagi StudioがCGアニメで参加する新しい映画がロングランアニメ「ガッチャマン」を2008年に映画館に持ち込みます。

　オリジナルのガッチャマンは、国際科学機構に雇われた５人の若いスーパーヒーロー忍者が、地球の資源の支配を企む科学的に進んだ「ギャラクター」として知られるワルモノと戦う話です。忍者たちは稀少資源を狙うギャラクターのさまざまな巨大モンスターと戦います。

　監督：Kevin Munroeのコメント：「子供のころ、ガッチャマンは私をアニメーションとコミックと執筆に向かわせた最初の影響だった。ガッチャマンの素晴らしい冒険を大きなスクリーンに持ち込むチャンスを得て、私はほんとうに興奮しています。5人のティーンエイジャーが地球のヒーローとなる中で巻き起こるスゴいアクションとホンモノの人間ドラマは、本来そこ（映画館の大きなスクリーン）にあるべきものです。子供の頃の夢がかなったんだ！」

　1970年代初期にタツノコプロダクションが作ったガッチャマンは205を超えるTVエピソード、一つのフィーチャーフィルム（映画？）で30年以上のあいだ、世界中の"ガッチャマニアック"なファンを大いに喜ばせました。ガッチャマンではLynne Southerlandがプロデューサーを、Mark Tarboxがラインプロデューサーを務めます。

//

　IMAGIは香港のCGI製作会社。東京にはサテライトオフィス、LAに開発拠点（？）がある。2007年3月公開のTeenage Mutant Ninja Turtles(TMNT)のCGIを担当。

　[2007-04-10]日活、タツノコプロの人気アニメーション『ヤッターマン』と『科学忍者隊ガッチャマン』の実写映画化決定（インデックス）との関連性は解りません。監督名が違うから併行か、よくある企画段階のハナシなのかも。

　2007/06/17追記ハリウッド版ガッチャマン　脚本担当決定（6/16）（アニメのニュースと情報）という記事の中に"香港のイマージ・アニメーション・スタジオ"という文言がある。

//

　 ガッチャマンとかキャシャーンとか、あのへんの古いタツノコプロの特徴を一言で言うと、

　『斜陽の映画産業から流れて来た脚本家』

　ご当人たちは「ホンで飯喰えればなんでもいい」というカンジだったらしいが、だからってガキむけの予定調和なんか書いてられっかくぬやろドラマってもんわなぁ、、、ドラマってもんわなぁッ！！という部分を矯められるわけもなく、ひらたくいえばガキにんなもん見せんなやゴルァ！！という救いの無いエピソードあり～の、ぜってー子供の事なんか考えねぇで好きなもん書いただけだろオマエみてぇなエピソードあり～の、、、。

　それに「ずぎゃ～ん！」とやられちまったガキが、どういうわけか世界中に居る。

//

　30年前の海外のTV番組買い付け担当者が「こりゃスゴい！！」と思って買ったわけがない。
　「アニメ」は視聴率が取れる。実写より手が掛かってるカンジがするからだ。
　実際に手が掛かる。従って通常は実写番組より高い。
　ところが、相場からするとやたらに安くで売ってくれる国があった。
　見てみると、まぁアニメと呼べない事も無いデキだがなにしろ二束三文だ。埋め草番組にしたって効率がいい。

　というのが世界中のTV局に日本アニメが売れたほんとうの理由。
　70年代後半からアナログCATVで多チャンネル化が一挙に進行した北米では、特に「埋め草需要」は激しかった。
　もともと国営放送と1～2社くらいしかTV局の無かったEUでも後を追う形で多チャンネル化が進行し、ここでも「埋め草需要」が沸騰した。

　その間、在京キー局6個という世界に例を見ない多局体制を誇る日本は（ホレ、アメリカだって三大ネットワークっていうでしょ？）、
　世界の「埋め草アニメ」供給源でありつづけた。

　つまり、日本アニメが世界で流行った原因は、ダンピングにほかならない。
　その秘訣はスポンサーが払う１億円の番組製作費のうち、製作会社に回るのが800万円という、簒奪構造にある。
　「本来の価値の創造者」に正当な報酬が渡らず、権利取得もままならないとあってはそう呼んでも構わないと思う。

　子供の頃から浴びるほど日本アニメを見続けていれば、当然慣れる。
　そして、その中から良いモノとそうでもないものを分類する能力を身につける。それが教養というものだ。
　身につけた「アニメの教養」を映像に活かしたいと想うオトナ達はいまや世界中に居る。
　彼らの選択肢は四つ。

1. 「価値の創造者に正当な報酬が渡らず、権利取得もままならない」国。
2. 国籍や背景文化を問わず、才能こそ全ての「世界一の映画産業」を誇る国。
3. 「ソフトパワー向上および国際収益の観点から国家を挙げてアニメ産業発展の条件整備に務める」国。
4. 3.の条件を備え、かつ2040年頃までは「労働単価の安さ」を維持できる国。

　1.の国際競争力が維持できる理由が無い。

　マスの動きには必ず経済要因がある。
　この点で3.および4.の産業政策は極めて興味深い。恐らくは、徹底した業界構造分析の上に戦略を立案している。
　それがインテリジェンスと言うものだ。成果は10年を待たず誰の目にも明らかになるだろう。
　DRムービーのアニメに下請けで参加する国内スタジオが出てから騒いでも遅い。
　「製作会社が、自力で作品をつくれるほどの資本蓄積が出来ない構造(*1)」に目を向けるのが先だ。

　国内にはここから人々の意識を逸らすミームが二つある。

　ひとつは嫌韓嫌中。好き嫌いは個人の自由だが判断を曇らせる。民族性は経済や機械の性能や作品の善し悪しとは全く関係が無い。
　もうひとつは「じゃぱにめーしょんのつよみ」に鳥獣戯画とか日本の伝統文化とか日本人独自の感性とやらをもってくる意見。
　こっちは脳みそ膿んでんぢゃねぇの？と思う。
　もしそれが「世界に優れた」ものなら、鳥獣戯画が勘合貿易の主要輸出品目(*2)に乗ってないのはなぜだ？。
　そもそもラスコー洞窟壁画からこっち「絵画ベースのエンターテインメントを持たない文明」って歴史上いくつあるのさ？

　いずれも、1.の改革から目を逸らし(*3)、構造改革の意識浸透を阻害し、国際競争力劣化を加速し、国益を損ねる。
　他の効果はない。

*１）製作会社が、自力で作品をつくれるほどの資本蓄積が出来ない構造：
　韓、中の順に始まった国産アニメ放送優先義務は、くりえいちびちー的にはどうだか知らないが、
　製作会社への資本蓄積を狙うという点で、極めて真っ当な政策だ。てゆうか直球ど真ん中。
　併行して、製作会社へ妥当な報酬が渡るように、作品の版権を持てるように、細かい調整が走ってるだろう。
　クリエイティブだのセンスだのは場数さえ踏めばいくらでもつく。
　才能だの愛だのがいくらあろうと、まずオカネがなければ望むままに発揮する場は作れない。
　オカネがいくらあろうと、愛も才能も無い異業種揃いの「なんたら製作委員会」に作品のポテンシャルは引き出せない。
　これは断じて「育成」ではない。自力で育つための「条件整備」だ。ぜってー日本アニメの産業構造を分析しつくしてる。

*２）勘合貿易の主要輸出品目は日本刀。
　ここで も、だから日本刀の価値は世界的にうんたらいう意見があんだけど、アレ輸出先ではほとんど残って無い。
　武器として重用された形跡 も、下賜贈答品に使われた形跡も無く、出土すらしない。
　"素鋼"としてお買い上げになったっぽい。

*３）3.4.のアニメ制作会社を資本関係に組み込んで1.の支配下に置く手もあるが、当然に両国の経済政策と激突する覚悟が要る。
　 成功した場合でも、より高い報酬を望める2.への移動を厭わない「価値の創造者」対策に悩む事になるだろう。
　てゆうかハリウッドにがっぽりカモられた産油国や日本の家電メーカーを想起する。
　本来、娯楽産業にとってスポンサーってのはカモの代名詞なハズなんだけどな。
　たしか江戸時代はそうだったハズなんだけどな歌舞伎とか。なんでアニメはああなのかな。

//
　余談

　てな事は数年前にNetでこのポスターを拾ってからときどき考えるようになった。
　思わず製作会社の掲示版に英語でがんがれと書いたら数日後に日本語サイトができていた。
　おれの書き込みを見て急遽つくったのだと勝手に思っている。だって自動翻訳でぜんぜん日本語になってなかったから^^;
　その後どこだかのゴミみてぇな島の騒ぎで日本語サイトは消滅し、この作品の進行状況も情報が途絶えた。
　どーなったんだろうなこれは。
　たしか、高度経済成長期の韓国を描くという事だったと思うが。
　昭和懐古ものをありがたがる団塊世代のハートを直撃できると思ったが。

　世の中にはhuffyuv.aviという動画形式がある。らしい。Linux/Winではわりとポピュラーらしい。
　名前からするとたぶん単純にYUV信号にハフマン符号化を積んだものだと思う。映像情報を弄らずに符号記述方式を短く言い換えるみたいな。
　であれば、CAVLC-yuvとかCABAC-yuvとかもあってもよさげだがまだなさげ。QTコンポーネントもあることはあるが、結構Motion JPEGでもQT系とMEncoderで融通効かなかったりするらしいので深入りしてない。

　x264ではH.264/AVCロスレスが作れる。AVC1Decoder大明神のおかげでQT系・Linux系で融通の効く中間生成物として使えるの ではないかと思った。

　まず、Mac OSXで作れる中間生成物をざっと作って見た。ロスレスを標榜していてもほんとにそうとは限らないので比較の為。
　素材はこないだBS2で放送した『劇場版あしたのジョー２』の冒頭部、でかい夕陽のクリップ。6.85sec, 5.9MBのMPEG-2 PS。
　不慣れなため個々の設定が良く解らないが、QTPproでできるだけ高画質、インタレ保持に、なりそうなように心がけました。

	MB	分類	画質スライダ	備考
.mpeg	5.9	DCT	-	素材
Apple intermediate.mov	16.0	DCT	中	実質的にIのみのMPEG-2らしい。 QTPProではなぜか画質スライダが出ないが、他ソフトでは圧縮率を変えられる らしく「圧縮率（中）」みたような表示が出る。 HDVカメラというもので撮影したHD映像編集ソフト（iMovieHDなど）が使う。 左記の通り非常にコンパクトになるが劣化もこの中ではもっとも激しかった。
x264qp0.mp4	40.5	DCT	後述	H.264ロスレス。 x264, interlaced, Iのみ, 量子化抜き。 BがないのでMEncoderでmp4吐き出し。 冒頭の白紙フレームも無いのでQTPProでアスペクト指定後 「そのまま」mp4書き出し。
MJPEG A.mov	47.1	DCT	最高	AとBがあるが良く解らないのでA。 詳細オプションはどちらも同じでインタレ保持絡みの模様。
Pixlet.mov	33.6	DWT	最高	これとJPEG2000とは離散ウェーブレット変換（DWT）という理屈を使う。 マクロブロックを使わないのでブロックノイズが出ないかわり、 同心円上の圧縮ノイズが出るという。圧縮率（中）で出ました。 書き出し速度も再生も他と遜色がない。 PixerとAppleの共同開発だそうで、なにやらスゴそうなものがオマケでついている わけだが、そのわりに使ってますと言う情報が無い。でもかなり優秀。
J2k.mov	63.1	DWT	最高	QT標準搭載のJPEG2000が.movでも使えた。 静止画専用ぢゃなかったのか。 NHK技研もいろいろ研究中っぽい。 書き出しはこのなかでは抜群に遅く、G5, 2Ghzx2では再生もカクカク。

　どれも若干のデノイズっぽい効果を感じた。素材によってはディテイルの潰れであるかも知れない。
　感覚的な画質は：

　J2k　＞　Pixlet　＞＞　x264qp0　＞　MJPEG A　＞＞＞　Apple intermediateといったところ。

　ただし、Apple intermediateを除けば違いは非常に地味（Apple intermediateと他の違いもなかなか地味だけども）。
　あとサイズと画質劣化度と速度を考えると、Pixletはどえりゃあ優秀だがやと思った。これに時間軸圧縮のっけたら一気にクイックタイマーに転向しま すよあたしゃ。

　画質の傾向としては、J2K/MJPEG Aと、Pixlet/x264qp0にグループわけできると思う。
　Pixlet/x264qp0では夕陽外周のグラデーション部分にあった電波ノイズが消え、なめらかになる効果があるが、J2K/MJPEG Aではそうした部分に乗っている電波ノイズもわりあい忠実。
　反面、夕陽の中心部、高輝度部分では、J2K/MJPEG Aともに素材に無い荒れかたをしており、夕陽の輝度が地味に沈む。Pixlet/x264qp0はつるんとデノイズがかかり、素材よりも「真っ赤な夕陽 感」がタカマル。

　-x264encoptsは以下：

-x264encopts \
qp=0:\
bframes=0:\
keyint=0:keyint_min=0:scenecut=100:\
nodeblock:\
cabac:\
cqm=jvt:8x8dct:\
me=umh:me_range=32:subq=7:frameref=1:\
partitions=all:\
trellis=2:\
nofast_pskip:\
nodct_decimate:\
interlaced:\
noglobal_header:\
psnr:ssim:\
threads=1 \
-ofps 30000/1001 \
-of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames \
///
Video stream: 49618.078 kbit/s  (6202259 B/s)  size: 42424490 bytes  6.840 secs  205 frames
x264 [info]: slice I:203   Avg QP: 0.00  size:208908
x264 [info]: mb I  I16..4:  2.6%  0.0% 97.4%
x264 [info]: kb/s:50087.9

　qp=0で量子化そのものをオミットするそうなので他にも無駄なオプションがあるかも知れない。てゆうかtrellisとかcqm=jvtとか要らない よな。8x8dctも効いてないし。てゆうか時間軸圧縮抜いてるんなら少なくとも動き補償系も要らない、、、ぶつぶつぶつ。
　I枚数と総フレーム数が地味にオカシイが、MovieVideoChartで見る限り全てSyncフラグが付いている。
　サイズは映像の内容しだいだが、概算で5MB/secとして、300MB/min, 9GB/30分, 18GB/hr, 36GB/2時間。
　MEncoderでインタレ解除/逆テレシネを掛ければもう少し縮むだろう。

　x264qp0.mp4自体はffmpegでも作れるようだが（-cqp 0）、どうせならMEncoderでデノイズ、インタレ解除、必要ならcropやスケーリングを済ませてしまえば、その後のワークフローがコンパクトにな る。

　これをffmpegでデコードしてx264cliに繋げばlibmpeg2 decoding delayやDelay Frameの無い.264になるかもしれない。
　QT上でx264Encoderに任せても良い。

　x264 lossles.mp4の設定

qp=0:bframes=0:keyint=0:keyint_min=0:scenecut=100:nodeblock:cabac:cqm=jvt:me=umh:me_range=32:subq=7:frameref=1:8x8dct:partitions=all:trellis=2:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:threads=16

　実験の目標その１：ここから無駄な設定を抜く。
　目標その２：このI枚数はやっぱおかしい。フレームが14枚ロスト？

Video stream: 41240.797 kbit/s  (5155099 B/s)  size: 33197640 bytes  6.440 secs  205 frames
x264 [info]: slice I:191   Avg QP: 0.00  size:173745
x264 [info]: mb I  I16..4: 14.7%  0.0% 85.3%
x264 [info]: kb/s:41657.2

　値がゼロで揃ったものは無くても良い。残すべきものは緑で。薄緑は好みで。赤がフレームロスト緩和。
　秒数以外の値は標準との差。

-	変更値	sec	frames	kb/s	I枚数	I_size	I16	I8	I4	memo
標準	-	24	205	41657.2	191	173745	14.7	0	85.3
qp=0	-	-	-	-	-	-	-	-	-	-
bframes=0	14	24	0	-1005	12	-4191	0.5	0	-0.5	Iが203枚になったがBは無い。冒頭におかしなフレーム無し。 MovieVideoChartで確認してもチェックOK
-	1	25	0	-1005	12	-4191	0.5	0	-0.5	同上
keyint=0	999999999	-	-	-	-	-	-	-	-	Pが入る
-	1	25	0	0	0	0	0	0	0	1か0
keyint_min=0	300	36	0	-5475.9	-189	-12534	0	0	0	Pが入る
-	1	23	0	0	0	0	0	0	0	-
scenecut=100	-1	23	0	0	0	0	0	0	0	-
nodeblock	deblock	23	0	0	0	0	0	0	0	-
cabac	nocabac	16	0	5345.7	0	22296	1.1	0	-1.1	-
cqm=jvt	抜き	23	0	0	0	0	0	0	0	-
me=umh	dia	23	0	0	0	0	0	0	0	-
me_range=32	16(umh)	26	0	0	0	0	0	0	0	-
subq=7	1	16	0	158.7	0	662	5.7	0	-5.7	速度向上
frameref=1	15	24	0	0	0	0	0	0	0	-
8x8dct	抜き	23	0	0	0	0	0	0	0	-
partitions=all	抜き	23	0	0	0	0	0	0	0	-
trellis=2	抜き	24	0	0	0	0	0	0	0	-
nofast_pskip	抜き	26	0	0	0	0	0	0	0	-
nodct_decimate	抜き	23	0	0	0	0	0	0	0	-
nointerlaced	-	-	-	-	-	-	-	-	-	-
noglobal_header	抜き	23	0	0	0	0	0	0	0	-
psnr	抜き	24	0	0	0	0	0	0	0	-
ssim	抜き	24	0	0	0	0	0	0	0	-
threads=16	1	44	0	-1005	12	-4191	0.5	0	-0.5	Iが203枚になった。冒頭におかしなフレーム無し。 MovieVideoChartチェックOK

　フレームが14枚もロストする理由は解らないが、恐らくthreadがピクチャをスライス単位に分割するのが原因だと思う。threads=1でロス数 が2に緩和した。
　また面白い事に、bframes=1以上でも同じ効果があった。これも理由不明だが分散方式になにか影響するのだろう。GOP関連設定で抑止すればBも Pも入らない。
　残る2枚もやっつけたいところだが、むははははは。おれをだれだとおもってるッ！！
　これはlibmpeg2 decoding delayという、mencoderがデフォルトで使うMPEG-2デコードライブラリのバグだ。
　-vfm ffmpegで1枚に抑止できる（偉いのはbondさんとakupenguinさんですすいませんすいません）。

　従って望み得る最速設定はこーだ。

mencoder INFILE.mpeg \
-vfm ffmpeg \
-nosound \
-ovc x264 -x264encopts \
qp=0:\
bframes=1:\
keyint=0:\
keyint_min=0:\
nodeblock:\
nocabac:\
subq=1:\
nointerlaced:\
threads=16 \
-vf yadif,hqdn3d=2:1:2,harddup \
-ofps 30000/1001 \
-of lavf -lavfopts format=mp4:i_certify_that_my_video_stream_does_not_use_b_frames \
-o OUTFILE.mp4

　結果は以下。

Video stream: 45796.340 kbit/s  (5724542 B/s)  size: 39156823 bytes  6.840 secs  205 frames
x264 [info]: slice I:204   Avg QP: 0.00  size:191899
x264 [info]: mb I  I16..4: 21.5%  0.0% 78.5%
x264 [info]: kb/s:46009.6
sec 11

　約7sec, 5.9MBのMPEG-2が11secで37.3MBのインタレ解除済みx264ロスレス.mp4になった。但し、末尾1フレームロスト。
　あ、よく考えるとこれベースラインだから、素のQTPでも開けると思う。

	スケーリングしてないので そのままでは720x480表示。
	QTPproの林檎+Jで変える。
	「そのまま」mp4書き出し OKだがここに非Apple製 コデックは出てこない。 これだとアスペクト指定した MP4を書き出せない。

Free > Freedom ≠ 自由

　MEncoderに深入りしてしまったので、行きがかり上、関係のある英文を読む事がある。
　というかスタンスとしては読まざるを得ませんかしくしくというカンジなので、ちょろっと読んでは脳内妄想が。


　GPLの冒頭部に "ソースコードのfreeとは無償（例えば'無料のビール'のFree）ではなくfreedomのことだ" てなカンジの事が書いてあった。
　、、、ソースコードの自由？

　あれか。
　そのうちソースコードも生存権とか職業選択の自由とか健康で文化的な最低限度の生活を営む権利とか言い出すのか。
　愛護団体がソフトに日照権を与えない日本は文明的に遅れているとか言ってゴムボートが発煙筒でにげて～（略）。
　由々しきことである。

　辞書によるとfreeは、主のいないこと。だから"free beer" は「所有者のいないビール」「無主のビール」「誰のものでも無いからおれが呑んでも支払いの義務が無いビール」「無料のビール」。、、、というカンジのト ランスコードだろうか。「誰のものでも無いから」が「おれが呑んでも」に繋がるところが面白い。異文化のかほりがする。日本語なら、誰のものでも無ければ 「みんなのものだから大切に」という縛りがかからんか脳内で。
　 ~domは「～な状態」。freedomは「所有者のいない状態」「無主状態」「誰が主でも無いからそれ自身が主の状態」「自主」、、、「自分の主人は自 分」かな。

　「自由」というのは福沢諭吉が訳語をあてた。わざわざ "自由といっても自由放埒のことではない" 。と但し書きをつけているそうな。どうもそれ以前の日本人は「自由」というコトバを「わがまま・勝手気まま・他人の迷惑省みず」というカンジの悪口を、難 しく言いたい時に使っていたフシがある。「縁、世間、セケンテイ」を行動規範にしていた江戸時代の人には随分とネガティブな響きのあるコトバだったと思 う。カブキ者？DQN？みたいな？

　だから、諭吉さんが言った
　「新時代の人間は自由を行動規範としなければならない。しかし自由といっても,,,」
　は、同時代のみなさんの脳内では、ちょっとスゲェデコード誤差が発生してたんジャマイカ。
　「新時代の人間は自由放埒を行動規範としなければならない。」
　「新時代の人間はカブキ者を行動規範としなければならない。」
　「これからはDQNの時代だ！」
　　※：誤差範囲は搭載デコーダの性能により異なります。

　それまでの日本人の行動規範は「縁、世間、世間体」だったのだから、そー理解するのが妥当だ。なにしろ「縁切り」というのは大事であったようだし、刑罰 のメインは「所払い（今住んでるとこから追放）」だったそうだから。
　今日でも「自由には責任が伴う」という注釈が存在するから、やはり日本人の脳内には「自由」を「自由放埒・わがま ま・勝手気まま・他人の迷惑省みず・無責任」と解釈するデコーダが存在するのだろう。

　それが歴史の慣性というものだ。


　コトバはコンテナであって内部には様々な意味ストリームが存在する。
　文脈に応じて適切なストリームを選択するのは脳内コンテナパーサの役目だ。

　「自由」には、歴史的な「勝手気まま」と、諭吉さんが組み込んだ「Freedom」の二つのストリームが混在する。諭吉さんも、ほんとはどうかなこれは とおもいつつ、でも「再生互換性」の為にそうしたのかもしれない。

　で、あるにしても「自由」はオカシイ。諭吉さんはrightとかcontractとか甚だしくはloveにいたるまで、それまでの日本に無かった概念を 七転八倒して権利とか契約とか恋愛とかの近代用語を生産しまくった超光速トランスコーダなわけだが、だけでなく、若いもんを集めて自家製用語を脳にスリコ ミまくった大洗脳家なわけだが、なにゆえに"Freedom"を当時の常識ではやたらにネガティブな色彩の濃い「自由」にしたのか。アタマがわるいのか？ 疲れてたのか？ガキの頃に「オマエは自由放埒」と酷く折檻されたのか（ありそうだなコレワ）？それとも、わざと？

　彼の時代には、突如来襲したエイリアン文化の大波の上を、涙を呑んで上っ滑りに滑って行く為の波乗り板がとにかく大急ぎで必要だったわけだが、その最大 のテキは「縁、世間、世間体」という強力な社会規範だ。そこで有名人であるオレ様が、敢えて「これからはDQNだ！」と取られかねないコトバを放流すれ ば、テキのパワーを減殺できる。いろんな分野でいろんな人がいろんな波乗り板をたくさん作る。差し引きはプラスだ。常識を180度ぐるんと回せば副作用も 出るだろうが、せめて弟子達にはきっちり注釈を叩き込んでおこうか。

　、、、てなカンジの日本人洗脳計画なんぢゃないのかこれわ。まぁ趣味的にはそーゆーあざといおっさんのほうがスキだが。
　いずれにせよ、明治初期にこれに近い行動規範の180度転換が発生し、近代中国の「百家争鳴・百花斉放」と virtual（限定局面における事実上の等価物）な結果をもたらしたことは確かだ。


　それわそれとして。
　それなりに波を乗り切って安全な陸地にたどり着いた現在では「自由」はデコード誤差が無視し難いように思う。

　例えば「民主主義」コレ誤訳なんだそーな。
　デモクラシーは 制度。各人が各人の主人である事（Freedom）を前提として、たくさんの「ご主人様」同士の利害調整機構として生まれた、ただのツール。
　これは誰が訳語をあてたのか知らないが、主義（イズム）は精神的な価値観だから「民主主義」 だと「自分の主人は自分。これ最強」 が増殖するだけでスタビライザーが無い。日本にはリバイアさんがいらっしゃるわけで酢菜。ちょっと可愛いかもリバイアさん。
　あれだ。ご主人様がいっぱいいるからメイドさんが商売になるんだ？（ないない）。

　社会契約論？ないない。明治政府の正当性なんてだれも議論してないもん。してても敗戦で断絶してるもん。現行憲法の正当性を法学者がなんて言ってるか 知ってる？あいつら「革命があったと考えるべき」とか言ってんだぜ？　根付くかそんな戯言。
　変えるにせよ変えないにせよ、いっぺん民主的な手続きで全文再制定しねぇと、そもそも現行政府の統治権が民主的にクリアにならねぇ。 まぁ何回も民主的な選挙を繰り返してるから手当はつくんだけど、それやらないと、負けたからおしつけられたんだって感情はぐじぐじと残る。消えない。
　紙になんて書いてあっても肚の芯は帝政のままなんだと思うよみんな。芯の仕付け糸が抜けてるからぼやけてるけど。ガワが民主主義だ からナニゲにそうは見えないけど。「自分の主人は自分。これ最強」で済むのはキモチイイけど。

　基礎概念のデコード誤差は画質の悪いIフレームのようなものだ。影響は連鎖的に波及し、幾何級数的に拡大してゆく。

　ああそうか「個人主義」って民主制の前提、つまり各人のFreedomの事を言っているのか。んー ちっとニュアンス違うよなぁ、、、地味にネガティブだ。だってほら「クールな個人主義」とは言うけど「人情味あふれる個人主義」とか「ハートウォーミング 個人主義感動巨編」とは言わんし、それだと全米が泣きそうに無い。てゆうかそういう色の付いたコトバはいかん。「自分の主人は自分」なら「自由には責任が 伴う」なんて注釈は省略できるし。最終責任者だから主人なのだし。Freedomってなかなか、符号 化効率がよさげ。ん～～～～～～自主主義、自決主義、主体思想、、、、ダメだろそっちわ。ん？序の部分はそう悪く、てゆうかモロにFreedomでねぇのかこれは？ちょっと改変。

　自分の運命の主人は自分自身であり、自分の運命を開拓する力も自分自身にある。
　故に、国家統治権の淵元は国民にあり、司法・立法・行政の最終監督権も国民の側にある。

　イズムとクラシーが二行に入る。
　其の先は、なんか違和感バリバリだが、儒教的宗教観・家父長制の社会規範と共産制をなんとか繋いである、ような印象を受けた。
　チャレンジャーだな黄長さん（家族を捨てて脱北して金王朝が倒すために活動してるってのも、この人のFreedomなのか。ご 長寿を）。
　こーゆーのを憲法前文の筆頭に入れといてくれんかな。第一章が天皇なのは譲れないだろうから（天皇制の権威は少し弱めてもいいと思うんだけどねぇ。雅子 さんとか離婚、まぁご本人がしたければだけど、できるようにしたほうがよくない？）。


　たくさんの波乗り板をつくるのに「自由」は便利なツールだったが、それなりに波を乗り切って安全な陸地にたどり着いた現在ではデコード誤差が無視し難い ように思う。波乗り板では外洋に出れない。サカナを取るには舟があったほうが便利なんだが。それが無いからパラダイス鎖国になる。なんちて。福沢諭吉翁の のーみそを踏み台にしてだな、その先へ。なんちて。

　Freedomにはもうちょい適正なコンテナがあったほうがいいと思うんだ。
　【材料】

• 自分で考えて、自分で決めろ（アニメ・エウレカセブン：チャールズ＝ビームズ）
• ネダルナ・カチトレ・サスレバ与えられん（アニメ・エウレカセブン：アクセル＝サーストン）
• 与えられるのは望んでいたものか？タマシイの血の輝きか？
• 芸人は米一粒、麦一粒よう作らん。末路哀れは覚悟の前やで（桂米朝が弟子入りするときの師匠のコトバ）
• 根無し草ニナルナジョミー（マンガ・地球へ…：ソルジャーブルー）
• 自分の人生の文脈で考えろ？てゆうかアニメでこの台詞はしょってあってかなしー。
• 自分の運命の主人は自分自身であり、自分の運命を開拓する力も自分自身にある。（北朝鮮の主体思想：黄長 ）

　まぁ、微妙なものばかりなので材料はもちっと幅広く集めたほうがいいわけだが。
　ミリバールはヘクトパスカルに変わったわけだし、震度はなんとかガルに変わったわけだし、法哲学でやっちゃいけない理由も無いだろう。学問ならね。


　関係ないけど「ごめんなさい」は「御免なさい」だ。
　「御免！」「天下御免」「切り捨て御免」。「わたしはこれをやるにあたってしかるべきスジから御免状をもらっています」とゆう意味だったらどうしま しょ。
　事実上「オレの所為ぢゃない。怨むなら自分かしかるべきスジにしてね」と言ってるようなもんですか。まぁ内心ではお 詫びのキモチ満載なわけだが。
　あれだ。イスラム教の人は「神様の思し召しだ」と言って日本人の怒りを買うらしいが、実は内心ではお詫びのキモチ満載だったりして。大差ないよな。コト バの意味は。
　でも「わたしもこんなことしたくないんだけど上が」とか「悪く思わないで下さいね」とか言う人いるよなぁ。あれなんでかなぁ。
　じゃ上が死ねって言ったら死ぬのかなぁ？

　慰安婦として働いた人たちは大変だったと思う。いや当人にとっちゃ大変なんてもんぢゃないだろうけども、さらに心ならずも/騙されて/強制的に 慰安婦になった人たちの内心に至っては、自分の想像力を超える。
　一方、やってない事にまで責任を負いたがるヒトというのは不思議な存在だ。経験上、普段から口ばかり で役に立たず、修羅場になると真っ先に逃げを打つ。逃げたという自覚も無いから何度でも同じ事を 繰り返す。大抵は民主主義、とか、愛国心、とか、そういう捉えどころの無い大きなものが大好きだ。

　産経と朝日に同一問題について正反対の記事が出たので比べてみました。
　この記事より先には深入りしていません。両記事の文言が全てです。
　得点評価は日本国政府の利益となるかどうか。◎が一点。 得失区分は主観です（この問題に「客観的な事実」や「正しい判断」は有り得ません）。

1. 産経

産経新聞：「組織的強制徴用なし」　慰安婦問題　米議会調査局が報告書(2007/04/12 07:37)

---

　【ワシントン＝古森義久】米国議会調査局は日本の慰安婦問題に関す る決議案に関連して議員向けの調査 報告書をこのほど作成した。同報告書は 安倍晋三首相 の一連の言明を「矛盾」と批判しながらも、焦点の「軍による女性の強制徴用」については軍や政府が全体としてそうした政策をとってはいな かったことを認め る見解を明らかにした。同報告書はさらに決議案の日本側へのこれ以上の謝罪要求に懐疑を示し、賠償を求めれば、日本側から原爆の被害者への賠償請求が起き かねないという懸念をも表明した。

　議会調査局の専門家により３日付で作成された「日本軍の『慰安婦』システム」と題する同報告書は議員の審議用資料で２３ページから成る。

　いわゆる慰安婦問題の主要争点とされる「日本軍による女性の強制徴用」について同報告書は「日本軍はおそらくほとんどの徴募を直接に実行はしな かっただ ろう。とくに朝鮮半島ではそうだった」と述べ、いま下院に提出されている慰安婦問題での日本糾弾の決議案が「日本軍による２０万人女性の性 の奴隷化」とい う表現で非難する日本軍による組織的、政策的な強制徴用はなかったという趣旨の見解を示した。

　しかし同報告書は安倍首相らの強制徴用否定の言明について（１）慰安婦システムの一部分である「徴募」だけの否定の 強調は軍が大きな役割を果たした慰安 所の設置や運営、慰安婦の輸送、管理などを矮小（わいしょう）化する（２）一部の言明は徴用にはいかなる軍の強制もなかったと受 け取られ、日本政府自身の 調査をも含む元慰安婦らの証言に矛盾する－と批判し、「強制性」の最大の論拠としては２００２年に米英両国で出版された「日本の慰安婦」 （田中ユキ著）と いう英文の書を挙げた。

　同報告書はその一方、日本政府が慰安婦問 題に対して１９９０年代前半から「アジア女性基金」の設立などで謝罪や賠償の努力を重ねてきたことを詳述し、 「同基金は元慰安婦たちに償い、助けるための日本政府の真実の努力だ」して、女性たちによるその基金からの賠償金の受け取りを韓国政府が事実上の脅しによ り阻んだとして非難した。同報告書はとくに 賠償について政府間ではすでに対日講和条約や日韓関係正常化で解決ずみとの見解を示し、もし諸外国が日本にいま 公式の賠償を求めれば、「日本側は戦争中の東京大空襲の死者８万人や原爆投下の被害への賠償を求めてくる潜在性もある」とも指摘した。

　下院決議案は日本の首相や政府に改めて謝罪の表明を求めているが、同報告書は河野談話や歴代首相の「アジア女性基金」賠償受け取り の女性への謝罪の重要 性を強調し、「それでも不十分だとする批判者たちはなぜ不十分なのか理由を明示していない」として、謝罪要求への懐疑を明確にした。同決議 案はさらに米側 の一部が「日本の国会での謝罪決議」を求めることに対しても、「そうした決議が成立する見通しはきわめて低い」として、この種の要求の非現実性を指摘する 形となった。

【失点2】

　・安倍晋三首相の一連の言明は「矛盾」

• 報告書はあくまで倫理ではなく論理、主張の合理的妥当性に基準を置いている。

　◎（１）「徴募」だけを強調して否定するのは軍が大きな役割を果たした慰安所の設置や運営、慰安婦の輸送、管理などを矮小化す る。
　◎（２）一部の言明は徴用にはいかなる軍の強制もなかったと受け取られ、日本政府自身の調査をも含む元慰安婦らの証 言に矛盾する。

【得点3】

　・「軍による女性の強制徴用」については軍や政府が全体としてそうした政策をとってはいなかった。
　◎「日本軍はおそらくほとんどの徴募を直接に実行はしなかっただろう。とくに朝鮮半島ではそうだった」
　◎日本政府は１９９０年代前半から「アジア女性基金」の設立などで謝罪や賠償の努力を重ねてきた。

• ・・「同基金は元慰安婦たちに償い、助けるための日本政府の真実の努力だ」
• ・・女性たちによるその基金からの賠償金の受け取りを韓国政府が事実上の脅しにより阻んだとして非難

　◎とくに賠償について政府間ではすでに対日講和条約や日韓関係正常化で解決ずみ

• ・河野談話や歴代首相の「アジア女性基金」賠償受け取りの女性への謝罪が存在する「それでも不十分だとする批判者たちはなぜ不十分なのか理由 を明示していない」

【観測】

　・もし諸外国が日本にいま公式の賠償を求めれば、「日本側は戦争中の東京大空襲の死者８万人や原爆投下の被害への賠償を求めてくる潜在性もある」

【所感】

• 産経は概ね日本に有利なネタを持って来るが、自分達が少数派という自覚がある。洗脳戦の要諦は一に利益、ニに説得力。
• 米国議会調査局のプロ根性に平伏。
• これはあくまで「アメリカ合衆国国民が自己の責 任において自分の態度を決するに当たり、より妥当な判断を下す為の参考資料」。
• 「米国の国益」という観点で透徹しており、美しい。
• 「末端では事実上の強制が存在した可能性」まで全否定/矮小化するのは不利益。
• 逆に日本のネットではこんな意見が⇒だから日本は反省してない、に援用されるリスクあり。このへんも産経はクレバー。愛国を叫ぶ者ほど一 時の快哉を叫ぶ己を愛している。
• 性に関わる問題は人間の本能に直結する。いかなる文化でもなんらかのタブーがあり、一手指し違えば本能的嫌悪感に直結する。
• 全否定・矮小化・反発・強弁・感情論は、斜め上の国という印象・過剰な反証・反発を生み、抗争を激化させる。無益。
• 過剰を避けるには、まず落ち着いて合理的な態度を示す事だ。感情は調味料。
• 焼きそばを作るのに、まず青ノリを鍋に入れるヤツはいない。それでオレは料理がウマいと言っても説得力が薄い。
• 料理のように「喰えばわかる」問題では無い場合、プロセス（結論に至る過程）の説得力がモノを言う。
• 自分自身の過去のプロセスを無視した行動（矛盾）は、信頼を著しく損なう。安倍さんは脇が甘い。
• 河野談話がどうだろうが外国から見りゃ「日本政府の公式方針」だ。
• 「日本の慰安婦」の資料性を日本語で批判しても無意味。彼らに入手可能な資料は英語で書かれたものだから。
• 日本の戦略目標は「ただしい歴史認識を世界に広める」事ではない。沈静化。
• パックス・アメリカーナを批判された時の米国人のテンプレは「個々に間違いがあったかもしれないが、全体としては概ね良かったと言えるの ではないか」だ。愉快ではないが、受け入れる方が妥当と思えるケースが多い。これは根本的には、彼らが殆どのケースで軍事的勝利を収めて いるから。今生きている人間がソレを前提とした社会に生きているからだ。
• 大日本帝国の敗滅を前提とした世界は、基本的にはその行動を是認できない。肯定すれば、今、自分達が生きている世界を否定しなければなら ない局面が 増えるからだ。日本が国際社会において名誉ある地位を維持したいと願うなら、我々は、自己の感情（ex, 先の大戦の反省, 愛国心などの美しいナニカ）に流される事なく冷徹に行動する事が求められる。
• 理屈だけなら慰安婦シ ステム総体の差し引き勘定や、存在の合理的妥当性をアピールすれば効きそうに思えるが、難易度高。性はどこの文化でもタブーなので合理的な理屈は効きが悪 い。まして、それでは奴隷労働の疑いは晴らせない事を考えると、嫌悪感に油をくれてやる公算が高い。
• 「矮小化」の非難を可能な限り抑止する形で沈静化することが第一目標。性奴隷（文字通りsex slave）として使役された女性が一人でもいれば、マクロな視点を主張する事自体が大きなマイナス。ある程度の不名誉は甘受せざるを得ないと覚悟し、妥 当な範囲を見定めるべき。
• 中国の戦略目標は「ただしい歴史認識を世界に広める」事ではない。日米分断。
• 米中戦争の前哨戦は既に始まっている。当面の中国の目標は、2008年の北京五輪、2010年の上海万博、2012年の月面着陸（嫦娥 （チャンア）計画）で求心力を維持しつつ、おおむね2020の時点で、台湾武力統合において、米国の武力干渉を正面から跳ね返す軍事・外交・国力を備えた 地域大国となる事。
• このためには日米分断が不可欠。
• 従って、本決議案が話題になるだけで利得を得るのは中華人民共和国。つまり、、、孔明の罠だ！
• この点からも、感情に流されず、冷静な差し引き勘定が求められる。というかべったべたに中国と仲良く するそぶりでアメリカから譲歩引き出すくらいしてもバチは当たらないとおもう。VC-1は日本メーカーの特許を不当な契約条項で持ってってるって独禁法で 罰金かけても、原爆の賠償よりゃあ安かろうし。

2. 朝日

朝日：慰安婦強制示す調書、東京裁判に各国検察提出（2007年04月15日）

---

　日本軍慰安婦問題をめぐり、東京裁判に提出された各国検察団の証拠 資料の中から、占領支配したアジア の女性が日本軍に強制的に慰安婦にされたことを示す 尋問調書などを、林博史・関東学院大教授（現代史）が確認した。１７日に日本外国特派員協会で会見して公表する。裁判で証拠として採用されたもので、東大 社会科学研究所図書館に所蔵されている。

　東京裁判には、日本軍によるアジア各地での住民・捕虜殺害など具体的な残虐行為を立証するために膨大な証拠資料が提出された。今回、林教授が確認したの は、オランダやフランス、中国など各国の検察団が提出した調書や陳述書など。

　インドネシアで、ジャワ島やモア島、カリマンタン（ボルネオ島）で女性たちが強制的に慰安婦にされたことを示す証拠資料が提出されたことが判明したほ か、アジア各地で同様のケースがあった。これまで、国立国会図書館所蔵の東京裁判関係資料から尋問調書の一部が確認されていた。

　オランダが提出した、ボルネオ島で海軍の情報機関にいた男性軍属に対する４６年３月１３日付の尋問調書。日本人と親しくしていた地元女性が日本軍に拘束 され、警備隊長に平手打ちをされ、裸で立たされる状況に触れて、取調官が追及する。

　彼女たちを拘束した理由について、男性軍属はこう答えた。「抑留したのは彼らを淫売（いんばい）屋に入れることができるための口実を設けるために警備隊 長の命令でなされたのであります」

　４６年５月１６日付の尋問調書では、ジャワ島の民間抑留者の収容所にいたオランダ人女性が強制的に慰安婦にされたことを証言している。

　４４年１月２８日、インドネシア人警察官が彼女を含め計７人の女性や少女を日本軍捕虜収容所事務所に連れていき、日本人に引き渡した。さらに車で小さな 収容所に運ばれた。同年２月３日に医師による健康診断を受けた際、日本人向けの「娼楼（しょうろう）（ｂｒｏｔｈｅｌ）」で働かされることを知ったとい う。

　「労働日には娼楼は日本将校のために、日曜日午後は日本下士官のために開かれ、日曜日の午前は兵卒等のために保留された。時々一般の日本人が来た。私は 常に拒絶したが無駄だった」

　フランスが提出したベトナム人女性の口述書の抜粋には「日本人はフランス兵と一緒に生活していた私の同国人数人に、光安に設けた慰安所 （ｂｒｏｔｈｅｌ）へ一緒へ行くよう強制しました」とある。

　中国の「軍事委員会行政院」が４６年５月２７日付で作成した資料は日本軍の桂林での残虐行為に言及、「四方より女工を招致し、麗澤門外に連れ行き脅迫し て、妓女（ぎじょ）として獣の如（ごと）き軍隊の淫楽（いんらく）に供した」と記す。東京裁判の判決も桂林の残虐行為に触れた中で、「工場を設立するとい う口実で、かれら（日本軍）は女工を募集した。こうして募集された婦女子に、日本軍隊のために醜業を強制した」と認定している。

　一連の資料について林教授は「これらは各国が作成した公文書であり、判決でも強制したことが事実認定されている。サンフランシスコ平和条約で戦犯裁判を 受諾した日本には、これらの文書の意味は無視できないだろう」と話している。

【失点1】

　◎「抑留したのは彼らを淫売（いんばい）屋に入れることができるための口実を設けるために警備隊長の命令でなされたのであります」

• ・・主要争点は「日本軍による女性の強制徴用」。この証言は日本軍属が 警備隊長の指示下で行ったもの。失点採用の理由は、軍属に命令を下せるのは軍人でいいと考えたから。

【得点1】

　◎東京裁判には、日本軍によるアジア各地での住民・捕虜殺害など具体的な残虐行為を立証するために膨大な証拠資料が提出された。

• ・・東京裁判は復讐裁判との見方があり、提出資料の証拠能力には疑問点もある。戦後ホットな時期の裁判だけに、この印象は拭えない。
• ・・この一点を以て日本国の得点とするのは特に戦勝国世論に対して著しく有効性を欠くが、敢えて得点採用した。理由は、要素 項目の評定不能率の高さから。

【評定不能4】

　◯４６年５月１６日付の尋問調書では、ジャワ島の民間抑留者の収容所にいたオランダ人女性が強制的に慰安婦にされたことを証言
　◯「労働日には娼楼は日本将校のために、日曜日午後は日本下士官のために開かれ、日曜日の午前は兵卒等のために保留された。時々一般の日本人が来た。私 は常に拒絶したが無駄だった」

• ・・言ったのは誰か（Who）？　オランダ人女性であってまさかインドネシア人警察官ではないと思うが、 主述関係が切れている。間に小説的な演出を挟んだため。
• ・・おこなったのは誰か（Who）？
• ・・主要争点は「日本軍による女性の強制徴用」。たしかに民間抑留者の収容所から日本軍捕虜収容所事務所 に移ってそこから慰安所送りだから、軍の管理責任は問えそうには思える。しかし主語が不明。「ジャワ島の民間抑留者の収容所」はどこの管轄か？そこから被 害者を連れ出したのが「インドネシア人警察官」なのはなぜか？引き渡された「日本軍捕虜収容所の日本人」とはいかなる 立場の人物か？　感情としては失点にしたいところだが、決め手にかける。「したい」というのは誰が責任者なんだかわからねぇお役所仕事の 結果にも見えるからだ。それで慰安所送りにされちゃたまらんだろ。でもそれはオレの感情なんで採用不能。

　◯フランスが提出したベトナム人女性の口述書の抜粋には「日本人はフランス兵と一緒に生活していた私の同国人数人に、光安に設けた慰安所 （ｂｒｏｔｈｅｌ）へ一緒へ行くよう強制しました」

• ・・主要争点は「日本軍による女性の強制徴用」。この証言は日本軍では無く、日本人。

　◯「四方より女工を招致し、麗澤門外に連れ行き脅迫して、妓女（ぎじょ）として獣の如（ごと）き軍隊の淫楽（いんらく）に供した」

• ・・おこなったのは誰か（Who）？
• ・・女工を募集して騙した者には甚だ虫酸が走るが、誰がやったのか。主要争点は「日本軍による女性の強制 徴用」。この証言の文言に日本軍の文字が無い。カッコで（日本軍）を補足したのは誰か？なぜ主語まで含めて引用しない のか。中国語であれば主語省略は考えにくい。英文であれば主語省略は絶対に無い。
• ・・人数的に大規模であれば、受け入れ時に日本軍は気付かなかったのかという疑問は残る。

【観測】

• 林教授は「これらは各国が作成した公文書であり、判決でも強制したことが事実認定されている。サンフランシスコ平和条約で戦犯裁判を受諾した 日本には、これらの文書の意味は無視できないだろう」と話している。
• ・・前掲の通り、東京裁判資料の証拠能力の妥当性は議論が別れる。この論争に中立の立場を取る場合、この「観測」は判断材料にカウントし にくい。そもそも通常の裁判においても誤審、事実認定の間違い、再審請求はあり得る。一般論としては「受諾したから無視できない」は、刑 に服した事実を以て再審請求の道を封じる論になりかねない。資料そのものを無視すべきではないとの結論は同意だが、その過程は粗雑に思 える。てゆうか人倫にもとる。

【所感】

• 慰安所が存在した以上、同情を寄せるべき「被害者」が存在した可能性は高い。倫理的・本能的に無視しがたい「証言」は今後とも存在し得る。適 切な手当が必要。
• 軍や政府が全体として女性の強制徴用政策をとってはいなかった事は現状ではほぼ妥当と思われる。しかし、末端には必ず暴走者 が出る。
• 慰安所が軍の機関である以上、人材不足箇所に補充を行う事で己の栄達を図る者が必ず出る。それが人間というものだ。人種・文化は関係な い。軍の底辺およびその周辺に、大日本帝国の威光を笠に着て横暴を働いた者が居た事はマクロ的には否定困難。下手人を 捕縛してその責任を負わせるべき。
• これは「昔のことだから/年寄りだから/相手が外交カードに使っているから」ではクリアにならない。その反論自体が甘え であり、腐敗。
• ネトウヨの脆弱さはこの点の認識不足。証言内容が凄惨であればあるほど、感情的な言い回しで信 憑性を疑ったり、外交カードの可能性を指摘する事じたいが論点ずらし・矮小化・隠蔽疑惑を産む。だけでなく、中韓の文化を持ち出すに至ってはレイシスト （人種差別主義者）そのもので あり、うわッこういう連中ならやるね、絶対！という確信を倍増させるだけである。
• 「末端の腐敗」は河野談話の継承とアジア女性基金の推進でストレートに対処可能（実際に腐敗があろうがなかろうが名誉回 復効果を発揮する）。
• なお「末端の腐敗」に焦点を合わせつつ、其の責任を「本来の攻撃目標」に被せるの は、事実上、日本の世論をカッカさせる挑発効果がある。冷静さを欠いた者ほど対処しやすい。
• ホントに孔明いない？
• 文章が要素抽出しにくい。
• 5w1h不徹底。判断材料に使いにくい。読み手の読解力次第でデコード誤差の生じ得る文章は報道ではなく文学。供述内容の並べかたにドラ マチックな手法アリ。感情に訴えるキライ有り。採用不能項目がモッタイナイ。産経より高いのに産経より高いのに産経より高いのに。

3. 得点集計

　「日本国」にとっての得点です。

	得点	失点	得失
産経	3	-2	1
朝日	1	-1	0
合計	4	-3	1

　失点内訳は

• 安倍首相の失言（２）
• 軍部底辺/周辺の暴走（１）

　 一応、両社のカラーにマッチする項目はイジワル気味に落としたわけですが。正直、個々の証言内容にはずーんとココロが重くなりました。この感情に流されて いれば朝日記事の日本の失点は-3。 合計失点で-5。得失は-1になっていたハズです。このへんの重み付けは個人的な倫理観と理性のバランスの取り方で全然変わって来ると思います。
　それでも安倍さんが口に気をつけてりゃ+1のままだったんですけどね。

4. 方策

　大日本帝国両軍が組織的に「女性狩り」を行った証拠は朝日の記事にも出ていません。
　組織的に行ったのであれば、文書命令があるはずです。慰安所は人員輸送と衛生管理を伴う大規模な機構ですし、隠蔽しようとしても漏れは必ず出ます。
　もし今後それが発見されれば以下は瓦解しますが、それまでのあいだは以下の方向が良いと思います。
　目標は日本国のソフトパワーの保全。その被害を極限する事です。

1. 大日本帝国陸海軍が、組織的に「女性狩り」を行った事が無い点は指摘すべき。⇒実行中
2. 慰安所自体は軍の指導管轄の元に設置されたものであるから、日本国は「女性狩り」被害者に対し一定の責任を負う。⇒実行中（河野談話・アジア 女性基金）
3. 誰よりも重い責任を負うべきは、大日本帝国の威光を笠に着て横暴を働いた各実行犯。⇒未クリア。
1. 案１：捕縛して裁判。
2. 案２：倫理的には河野談話承継、実利的にはアジア女性基金の目的を、しかるべき時期に国際的な女性の地位向上に変更・対象者拡充。時間軸 上の累積得点積み上げでソフトパワーをプラス化。

　NOTE：決してすべきではないこ と

1. 「やったのはXX人だ」：明白な人種差別です。日本国のソフトパワーにとって大打撃です。
2. 「日本人がそんな事をするとは思えない」：内面的な信条にすぎず、根拠がありません。日本国のソフト パワーにとって大打撃です。
3. 「全面的に日本の責任だ」：被害者に対する侮辱です。交通事故で すら責任比率というものがあります。巨大 で複雑な問題ほど、関係者は多岐に渡り、責任比率の判断は複雑化します。つまり、これは本気で事実の解明・再発防止策の構築に取り組む意思の無い証明であ り、一見立派に見えながら、実は最も不誠実な責任逃れです。a.b.ならまだ肚のソコで「次からは気をつけなきゃ、なにがマズかったんだ？」と検証する可 能性が残りますが、この立場を取る場合は残りません。c.は再犯リスクが最も高い立場です。日本国のソフトパワーだけでなく、倫理上も真実の大打撃です。

　※これらはどれも、この問題に接する際に感じる「大きな石を胃に詰め込んだような重苦しさ」を一時的に緩和する効果があります。

5. 所感

　この問題は、コア部分に性と奴隷、すなわち近代社会が排除してきたタブーがダブルで、公的施設にからんでるのがやっ かいです。動物的な嫌悪感すら絡みますから、スカッと打開できることではありません。ぶっちゃけ痴漢冤罪事件で疑いを晴らすのに大きな労力がかかるのと一 緒です。

　個々の証言を無批判に詳細に並べただけの朝日の記事は、被害者の言い分を一方的に採用するようなものです。もちろん被害者の言い分は極めて重要ですが、 それだけでは判断は妥当なものになり得ません。

　他方、慰安所そのものが存在した以上、水面下で「暗黙の了解」に基づく運用がなされていたのではないかとの疑惑が残ります。どっちにしろヤッたのは「日 本兵」なのですから、根本的な部分で諸外国の嫌悪感は解消し難いものがあります。
　たとえば、芸能人の資格で入国する人たちがありますわな。民間の入国ブローカー・兼・職業斡旋会社が彼女達を国の施設に斡旋したら、そこで人権上のトラ ブルがあった際に非難感情が向かう先は、やはりまず国でしょう。また米兵が事件をおこした時に、アメリカ人が「これは末端の問題にすぎ ず、総合的に見れば米国がアジアで果たしている役割は」とかずらずら数字だの証拠だの出してきやがったら、それは火事に向かってガソリ ンを放出するような行為です。この種の問題の心理的影響は「末端の問題」と切り捨てるには重すぎます。

　中韓がこの問題を外交カードに使っている場合、感情的な応対は「正しい歴史観の押しつけ」そのものです。日本の世論 が対手の「反日感情」と同じレベルに落ちれば、貴重な外交カードが一枚、相殺されてしまいます。　だからあわてるな。これは孔明（略）。

　内容に議論はあれど日本はこの問題について謝罪し、補償も行っています。不十分というならば、日本にはその合理的な理由を直接に聞かせ てもらう権利が あります（もちろん義務でもあります）。それをせずに第三国にロビー活動をかけ、非難決議採択を推進する国、事実採択する国があるならば、それは既に実務 交渉（洗脳戦）の領域です。胸を張って大いに対抗策を練るべき事であり、倫理や反省や感情論を持ち出す段階ではありません。

　あるいは日本が第二次世界大戦で勝利していれば、ある程度の強弁が通用したかもしれませんが、この世界が大日本帝国の廃滅の上に築かれたものである以 上、我々には慎重さが必要です。たとえ日本語で日本人向けに書くにせよ、どうせ外国人には読めまいという意識では、自己憐憫以上のものにはなり得ません。

　話は飛びますが。
　第二次世界大戦前夜の日系人社会は、日本を応援する一世と、米国に忠誠をちかうべきと考える二世に分裂していました。
　当時の日系人向け新聞は日本語と英語の記事が混在していたのですが、概ね日本語記事は一世、英語記事は二世が執筆していました。その結果、米国社会の日 系人は「日本を支持する日本語の記事」と「米国を支持する英語の記事」が、「一緒に載っている新聞」を読んでいました。たとえばリットン調査団に対する記 事がそれぞれどのような論調になっていたか、一度読んでみたいものです。日本人には、そういう新聞を読んでいる自分を隣人達がどう思うか考えつかない、と いう鈍さがあります。というより甘えですねこれは。形は違えど、今もそうした部分があるでしょう。
　日本語記事の内容は米国人の間で噂となり、日系人社会は、せいぜい良く言って「とても興味深い人々」と見られていた ようです。尾ひれもあったでしょうが、根本的な責任は、論理的な対決を避ける日本人の血にあります。これだけが原因でもないでしょうが、枢軸国の中で日系 人だけが収容所に送られた原因は、単に人種差別で片付けるべき事ではないと思います。少なくとも我々日本人だけは。

　その一方、日中戦争において中国人は、北米で日本の非を鳴らす宣伝活動を盛んに行い、見事な世論誘 導に成功しています。

　我々が議論も英語も苦手なのは今も昔も変わりませんが、基本的に苦手を克服するよりは、得手を伸ばす方が効率が良いものです。

6. むすび

　とはいえ、被害者にとってはんなこたぁどーでもいーのだぐだぐだ抜かすなこのやろおといった所でしょう。どっちにしろヤッたのは「日本兵」なのですか ら。
　深くご同情申し上げ、再発防止に向けて、自分に為し得る事をする意思を表します。

　冒頭で、この問題に客観的な事実や正しい判断は有り得ないと書きましたが、
　正邪の判断は神の領域であり、人が人を裁く事は出来ません。
　地上に起こる事は全て人が為す事であり、利害調停の域を出ません。
　戦争も平和も裁判も交渉も倫理も悪も正義もこの限界の内にあります。
　その限定条件の内で望み得る最善を尽くすのが、謙虚というものだと思います。

　人間に望み得る最善は「死ぬまで"より妥当な判断"を下し続ける」だと思います。
　新聞やブログに決めてもらう必要は無いです。

　感じるな。考えるんだ。

http://d.hatena.ne.jp/uenoB/

Bを使うとQTPで冒頭に入る白紙フレーム。なんかmp4boxで対処できるだろうとは思うものの、delayオプションが期待する動作をした事がない。
それを一気になんとかする巧い手が書いてあるサイトを見つける、とゆー夢を見たw。

はっはっは（乾燥した嗤い）。そんなウマい話があるわ、、、
、、、、、、、、、
、、、、、、、、、ソレなんてベンゼン環？

しかしなにが書いてあるんだかさっぱり理解できないギギギ。
まずmp4boxのビルドを成功させねばな。話はそれからだw。

印象が強い順。

■天元突破グレンラガン
　第一話のI比率1.3%（576枚）はTVアニメとしては初めて見た。びびった。MPEG-2のまま見ちゃった。第三話は流石にと思ったら、、、ながい ながいながい刀長いってば！
　枚数が多いとか少ないとかぢゃなくて、動きの緩急を実写よりぐいっと広くとれるのがアニメのおいしさなんだと思う。目がおいしいとゆっている。
　「描くもの一木一草に意味を込めろ」という絵画のココロイキと「動くもの一挙一動に意味を込めろ」というアニメ屋のココロイキがうまく連・・・いやここ は合体と言わねばなるまいッ！！してアニメ屋魂完全燃焼だ。

　しかし瞬間的なカットがめっさ多いんデスけどコレ。thread分散した"やや不正確な"シーンカット検出では地味に厄介なカンジ。作り手の意図を汲み 切れないんぢゃまいか。カット切り替えのテンポをギャグや外連味（けれんみ）にしてるし。うーん、、、ってナニがクロスカウンターかコラw。
　MEncoderではthread分散すると内部的にシーンカット検出が"やや不正確な"ものに切り替わる（x264cliの--pre- scenecut）。一般的にはそう大した問題では無いし、実はこの素材でも主観画質は特に問題ない。でもなんか負けた気がする。いやナニにってんでなく てオトコのたま（黙れ）。
　あとは緩急だよな。qp_stepとratetol上げるか。幸い16:9だから手許の設定だとBPPにはやや余裕がある（640:352にクロップア ウト＆縮小）。やはりIだな。I/IDRは1stで決まるというから、1stだけthread=1でやっちゃうぞくぬやろ。オレヲダ（黙れ）。
　あと主題歌に歌詞テロップ付けて下さいおねがいします。

■おおきく振りかぶって
　設定上は問題無い。
　のへっとした雰囲気とずごごと燃える雰囲気の緩急が気に入りました。設定はそう難しくなさそうだがなんだろなこの雰囲気は。なんか数字で掴めネェかな。 『僕らがいた』はあからさまに数字が良すぎるので目立ったが。

■大江戸ロケット
　設定上は問題無い。
　元ネタが芝居なんで、実験的な絵が出るかと思ったがあんまそうでも無い。あるっちゃあるけど。いやあるっちゃあるってこたぁやろうとしてるって事だよ な。気をつけよう。自分で自分の台詞に突っ込むギャグとかアニメにしてもあんま違和感ないのが面白かった。新感線だけに。
　あとエウレカ。

■エマ第二幕
　設定上は問題無い。
　随分ボケ味がかかって見えるのは仕様でしょうか電波状態でしょうか。置物とか絨毯とか細かい質感を言い出すとキリが無さそう。

■一騎当千DragonDestiny
　おっぱいがいっぱ、いやインタレ縞が無い。細かく見るとパンツもいっぱ、いや、地味にインターレース縞と思しきものはあるのだが、インタレ縞というより は「その痕跡がやや見受けられる」と言った程度で、止め絵のパンですら縞が無い。
　でも第二話以降はOPとEDだけ24fpsのようだ。なんだこれわ手許では初めて見るが。製作工程の川上から川下までフレーム周波数30Hzで統一？。 インタレ解除で30000/1001fpsで吐くか（そんなにおっぱい好きか）。

■地球へ...
　遺憾ながら残念感が漂う。原作の解釈がかなりオレと違う。
　ソルジャーブルーの最重要台詞は「いくつもの疑問を持ちたまえいくつものいくつものできるだけ多くの疑問を！」と「根無し草ニナルナジョミー！」であっ てだな。テラズナンバー5に顔ついてるし、表情変わるしうぎゃあとか言ってるし。ミュウの敵は感情を感じさせるべきではないと思う。どう表現すべきかは苦 しいと思いますが。

　それに対するソルジャー・ブルー⇒ジョミーに受け継がれたものは「地球へ還る」でも「感情や人間的感性を大切に」などのリリカル＆ノスタルジック＆ キャッチーなものではなく、ほんとに大切なことは誰からも教われないし誰にも教えられないって事（≒自分で考えて、自分で決めろ＆ネダルナ・カチトレ≒末 路哀れは覚悟の前≒Free/Freedom≠自由放埒）だと思っているので、そこ外されるとかなりツライ。
　キオクヲテバナスナは読み手をネナシグサニナルナに導く方便だと思ってる。前者だけ抽出して強調されるとちょっとリリカル＆ノスタルジック＆キャッチー な方向にブレる。
　安いメロドラマになってしまふ。

　でもセキ・レイ・シロエが見たいので見るのであった。彼をただの運命に翻弄された悲劇の人にしないでね。諦めないからシロエくんなんだぜぃ。ぢゃなきゃ キースは機械のままだ。

　「情報」という言葉は元来軍事用語なのだそうだ。
　中国ではこの言葉を日本から「輸入」したが、あくまで軍事用語として扱い、日常的なものは信息と言うそうな。意味は information、news、message。
　そうか軍事用語か。と本棚から江畑謙介さんの本を出したら「informationは情報資料、intelligenceは情報分析。 日本語ではこの区分が明確でないため、たとえば情報収集衛星さえ飛ばせばすぐにアメリカと同じ事ができると思っている政治家・マスコミが多い」 と嘆息しておられた。へぇーと関心していたところで「情報小論」という文章に行き当たった。

　意訳すると。
　元々軍事用語として訳された「情報」が一般に定着したのは日露戦争で新聞が盛んに使ってから。第二次大戦中に「諜報」のような意味で多用されたので、戦 後しばらくはいちいち「インフォメーション」と言い換えていた。その後は意味がじわじわとボケてゆき「情報とは人間精神の創造物」と定義する者も現れた。 「情」の字がなんかマズかったようだ。もとは単に「事情の報知」だったハズなのだが。（意訳終）

　コトバの意味を拾うとこうなる。

英語	独語	軍事	英辞郎
information	Nachricht：未確認情報 Information ：情報資料（これを分析して Intelligenz となる）	情報資料 ：敵又は仮想敵に関する資料で、未だ評価・格付及び解釈を経ていないもの、これに評価及び解釈 を加えれば情報（intelligence）にもなる	情報、資料、データ、知識、案内、通知
intelligence	Intelligenz （資料を審査した精度の高いもの）	情報 ：外国の実情又は作戦地域に関する入手可能なあらゆる資料の収集、評価、分析、総合及び解釈によって得られるもので、 軍事計画及び作戦のために直接又は潜在的に意義を有すること、又はその義務	情報、知性、知能、知力、諜報、諜報機関

　intelligenceってのは『吟味』だと思った。ホレ時代劇でお奉行さんとかが言うアレ。
　「そのほうの申し状、いちいちもっともなり」とか「そのほうの申し状、不届き千万」とかの「申し状」がinformation。
　「この桜吹雪を見忘れ(ry」はなんだろうねあれわ。証拠になるのかね。外連味（けれんみ）だよ な。元ネタを大衆の望む「勧善懲悪」「わかりやすいワルモノたたき」に落とし込むための、飾り？

　江戸時代は平和だ治安だということで人気が高いが、それを支えていたのは別に文化でも伝統でもなく、日本史上まれに見る高度な管理社会・警察国家だと思 う。相互監視・密告制度が異様に発達していたし、刑罰の種類も量刑の幅もちょっとわけわかんねぇほど広い。
　罪刑法定主義が無いから官僚が恣意的なうんぬんで片付けても良いが、それはちと面白味に欠ける。

　こういうのの実務に当たる官僚は、否応無く一級の社会工学者になる。でなきゃ一揆も防げないどころか同僚も説得出来ない。
　彼らはinformationとintelligenceを厳格に使い分けていたはずだ。
　その考え方がなんらかの形で世間に根付いていなかった理由は無い。
　明治初期の軍隊では「情報」と「状報」の使い分けが見られたそうだ。
　情は敵の事情。外からは見えないもの。指揮官の交代、士気、戦う動機、、、
　状は敵の状況。目で見りゃわかるもの。布陣、配置、兵数、装備、、、
　敵に違和感があるなら、テキでも、対象でも言い換えれば潰しが効く。

　吟味力（intelligence）には個人差があり得る。
　受け取ったものを既に吟味済みと看做して消費するか。
　脳に入ってくる物を全て素材（information）と看做して吟味するか。

　informationとintelligenceは立場によっても変わる。
　たとえば第二次大戦前に経済官僚は日本は勝てないという報告書を出しているし、軍部でもB29の開発情報どころか予測登場時期まで粗々に見当をつけてい る。これらはその担当者レベルでは吟味なわけだが、上にとっては一資料に過ぎない。吟味力は 上から腐っていくものなのか、それとも他の要因で腐っていったのか。

　はてブ・ホットエントリから来るアクセスの特徴は、離脱率の高さだ。
　※2007年2月1日～2007年4月18日

	状況開始	タイトル	離脱率	記事被登録数	起点リーチ数	起点評価	備考	試行処置
A	02 月17日	『続・ あたらしい著作権のはなし 』	88.24%	41	347	影響度：S+、リーチ大。フォーカス大浅。 分　類：情報消費型 属 　性：鯖管理人それぷら系 類　例：ワイド ショー	FC2 ランキング滞留8日。	更新中断
B	04 月17日	『牛乳 有害説』	88.50%	73	28	影響度：B、リーチ中。フォーカス中中。 分　類：志向分野探求型 属 　性：もやしもんIT系 類　例：短波ラジオ	速 報系サイト滞留1日。 起点ブログ・残留被曝中x1 波及ブログ・残留被曝大x1	文脈追加
-	-	全体	49.14%	-	-	-	-	-

　ここがブクマされる事は珍しいし、両方と も公開からかなりの時間をおいてブクマされているので、この「情報を消費材として扱う傾向」は否応でも目立つ。はてブ コメントもトラバもリンクもざっと読んだが、異論反論は少なく、物足りなかった。

---

agehaにオリジナルなし。

• キッカケ：はてブホットエントリ
• POP辞書
• 『日本の軍事システムー自衛隊装備の問題点』江畑謙介：2001年、講談社現代新書
• 『情報小論』小野厚夫： 1994年、国際文化学研究創刊号
• 用語集 http://www.p2s2rb.com/yougo.html
• R&Bにハマった人の用語集っぽい。自分には仔細のハラゴナレが良く無いが、いろいろとドキッとした。たとえばコレ
• 「壱を突き詰めた果てに出てくる物が 真の包み込むものであっ て、平均を取ると1番腐った物が出てくる」というのが、人間に与えられた唯一の答えだと思ってる。
• 青空文庫作家別作品リスト：三遊亭 円朝
• 江戸から明治への転換期にあって、伝統的な話芸に新たな可能性を開いた落語家。ある事件をキッカケに自作噺しかしなくな り、自作の怪談や取材に基づいた人情もので独自の境地を開く。海外文学の翻案もアリ。当時目新しかった速記法で新聞などに連載されて広ま り、文芸における言文一致の台頭を促した。
• 、、、コイツが感染源か？　論理構造の表現には漢文調のほうが向いているわけだが。英訳もやりやすいわけだが。
• いやいや夏目漱石がやたら英訳されてるのは、優れているからというより、英訳しやすいからってのもあるはずだ。
• あと天皇陛下のおことばってのも英訳しなきゃなんねぇから、気を使ってるはずだよな。

　http://sourceforge.net/cvs/?group_id=84101
　に従いソースコード取得。

cvs -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac login
cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac

　パスワードは何も入れずにリターンで通る。
　鬼のように大量に落ちて来る。
　とりあえずgpacフォルダに入って./configureのヘルプを見ようとしたら、

$ cd ~/gpac
$ ./configure --help
-bash: ./configure: Permission denied

　アクセス権が無いと言う。良く解らないので全部アクセス権を与える。

chmod a+x *

　ヘルプが出た。

$ ./configure --help
Usage: configure [options]
Options: [defaults in brackets after descriptions]

GPAC configuration options:
  --help                   print this message
  --prefix=PREFIX          install in PREFIX [/usr/local]
  --mandir=DIR             man documentation in DIR [PREFIX/man]

  --source-path=PATH       path of source code []
  --cross-prefix=PREFIX    use PREFIX for compile tools []
  --cc=CC                  use C compiler CC [gcc]
  --make=MAKE              use specified make [make]
  --extra-cflags=ECFLAGS   add ECFLAGS to CFLAGS []
  --extra-ldflags=ELDFLAGS add ELDFLAGS to LDFLAGS [ -Wl,--warn-common]    /*あとでここで引っかかる事になる*/
  --extra-libs=ELIBS       add ELIBS []
  --cpu=CPU                force cpu to CPU  [Power Macintosh]
  --sdl-cfg=SDL_PATH       specify path to sdl-config for local install []
  --enable-sdl-static      use static SDL linking [default=no]
  --X11-path=X11_PATH      specify path for X11 includes and libraries [/usr/X11R6]
  --dxsdk-path=DX_PATH     specify directX SDK for MinGW []
  --mozdir=MOZ_PATH        specify mozilla main directory path for system install

  --enable-debug           produce debug version
  --enable-gprof           enable profiling
  --track-memory           enables tracking of all memory allocated by gpac
  --disable-fragments      disable movie fragments in ISO media support
  --disable-opt            disable GCC optimizations
  --disable-ipv6           disable IPV6 support
  --disable-wx             disable wxWidgets support
  --disable-oss-audio      disable OSS audio
  --disable-x11-shm        disable X11 shared memory support
  --disable-fragments      disable movie fragments in ISO media support
  --enable-readonly        force ISO media to be read-only
  --disable-svg            disable SVG support
  --enable-fixed-point     enable fixed-point math (THIS MODIFIES GPAC MATH.H HEADER)
  --force-fixed-point      force fixed-point math without changing gpac math.h header
  --disable-opengl         disable OpenGL support
  --disable-ssl            disable OpenSSL support
  --enable-amr-nb-fixed    enable AMR NB fixed-point decoder
  --enable-amr-nb          enable AMR NB library
  --enable-amr-wb          enable AMR WB library
  --enable-amr             enable both AMR NB and WB libraries

Extra libraries configuration. You can turn a libray off or force using the local version in gpac/extra_lib/
  --use-js=OPT             force SpiderMonkey ECMAScript OPT=[no,local]
  --use-ft=OPT             force FreeType OPT=[no,local]
  --use-jpeg=OPT           force JPEG OPT=[no,local]
  --use-png=OPT            force PNG OPT=[no,local]
  --use-faad=OPT           force FAAD OPT=[no,local]
  --use-mad=OPT            force MAD OPT=[no,local]
  --use-xvid=OPT           force XVID OPT=[no,local]
  --use-ffmpeg=OPT         force FFMPEG OPT=[no,local]

NOTE: The object files are build at the place where configure is launched

　とりあえずそのまま./configure。

$ ./configure       

** System Configuration
Install prefix: /usr/local
Source path: /Users/USERNAME/gpac
C compiler: cc
make: make
CPU: powerpc
Big Endian: yes

** GPAC 0.4.3-DEV Core Configuration **
debug version: no
GProf enabled: no
Memory tracking enabled: no
read-only version: no
fixed-point version: no
IPV6 Support: no
IsoMedia MovieFragments support: yes
SVG Support disabled: no

** Detected libraries **
zlib: system
OSS Audio: no
ALSA Audio: no
X11 Shared Memory support: yes (path: /usr/X11R6)
SDL Support: yes   /*これはsrcからビルドした記憶がある*/
libXML2: yes
OpenGL support: yes
OpenSSL support: yes
wxWidgets support: Version 253

** Extra Libraries used **
SpiderMonkey: no
FreeType: system
JPEG: system
OpenJPEG: no
PNG: system
MAD: system     /*これはsrcからビルドした記憶がある*/
FAAD: system    /*これはsrcからビルドした*/
XVID: system    /*これもsrcからビルドした*/
FFMPEG: no      /*これは成功した事がない*/
Xiph OGG: no



Creating config.mak
Done - type 'make help' for make info, 'make' to build

　Mac OSXという表示が無いのが地味に不安をそそるが、make helpを見ろと言うので見る。

$ make help
Input to GPAC make:
depend/dep: builds dependencies (dev only)
all (void): builds main library, programs and plugins
lib: builds GPAC library only (libgpac.so)
apps: builds programs only      /*たぶんこれでmp4boxなどのツールだけできる*/
modules: builds modules only
instmoz: build and local install of osmozilla
sggen: builds scene graph generators

clean: clean src repository
distclean: clean src repository and host config file
tar: create GPAC tarball

install: install applications and modules on system
uninstall: uninstall applications and modules

install-lib: install gpac library (dyn and static) and headers <gpac/*.h>, <gpac/modules/*.h> and <gpac/internal/*.h>
uninstall-lib: uninstall gpac library (dyn and static) and headers

to build libgpac documentation, go to gpac/doc and type 'doxygen'

　欲しいのはmp4boxだけなのだけど、とりあえずmake appsで。

$ make apps
make -C applications all
set -e; for i in mp4box mp4client generators osmo4_wx ; do make -C $i all; done 
cc -O3  -no-cpp-precomp -pipe -fomit-frame-pointer -fno-common -fno-strict-aliasing -Wno-pointer-sign -Wall -I/Users/USERNAME/gpac/include -c -o main.o main.c 
cc -O3  -no-cpp-precomp -pipe -fomit-frame-pointer -fno-common -fno-strict-aliasing -Wno-pointer-sign -Wall -I/Users/USERNAME/gpac/include -c -o filedump.o filedump.c 
cc -O3  -no-cpp-precomp -pipe -fomit-frame-pointer -fno-common -fno-strict-aliasing -Wno-pointer-sign -Wall -I/Users/USERNAME/gpac/include -c -o fileimport.o fileimport.c 
cc -Wl,--warn-common -read_only_relocs warning -o ../../bin/gcc/MP4Box main.o filedump.o fileimport.o -L../../bin/gcc -lgpac -lz
/usr/bin/ld: unknown flag: --warn-common
collect2: ld returned 1 exit status
make[2]: *** [MP4Box] Error 1
make[1]: *** [apps] Error 2
make: *** [apps] Error 2

　コケタ。しかも当のmp4boxで。たぶん黄色いとこがエラーだと思う。
　ldってななんだろな。man ld

NAME
       ld - Mach object file link editor

　まで読んだ。Mach objectってたしか、Mach-Oとか書くんだよな。マークオブジェクト。タスケテ海上さん。

• Mac OS X標準のバイナリフォーマット。
• マルチスレッドなどBSDレイヤの機能までフルに活用できる。
• 複数の区画を設けることが可能というMach-Oの特徴を利用すれば、複数の異なるアーキテクチャの実行コードを収めた単一のバイナリ (MAB : Multi Architecture Binary)を生成できる。
• MABは目新しい技術ではなく、NEXTSTEPがx86アーキテクチャに移植された頃に実用化されたもの。

　なにやら大変そうな印象を受けた、、、そういえば「リンカ」って言葉を見た事あるな。

リンカ　【linker】

---

　コンパイラによって変換されたオブジェクトコードに、必要なライブラリなどを付け加えて実行可能ファイルを生成するプログラム。最近はコン パイラにその機能が統合されていることが多い。

　C 言語などの高級言語では、プログラマの書いたソースコードをコンパイラで機械語の集合であるオブジェクトコードに変換するが、単に変換し ただけではコン ピュータ上で実行できる形にはならない。リンカはオブジェクトファイルを解析して、参照している他のオブジェクトファイルやライブラリなどを探し出し、必 要なものを結合して実行形式のファイルを作成する。その際、一つのファイルにすべてを結合する方式を静的リンク、実行時に必要に応じて 外部のファイルをメ モリ上に呼び出す方式を動的リンクという。

　~/gpac/applications/mp4box/以下はこうなっている。

$ ls
CVS             filedump.c      fileimport.c    main.c
Makefile        filedump.o      fileimport.o    main.o

　拡張子.cがソースコード。ソース落とした段階では拡張子.oのものは無かったから、これがオブジェクトコードというものだろ～。
　つまりここまでは出来ているんだけど、こいつらをひとまとめにする段階で、コケテいる。
　ふたたびman ldで--warn-commonっぽいもんを探す。

-warn_commons (64-bit only)
              Causes  the  static  linker to write a diagnostic line about how
              common symbols were processed.  This  is  useful  for  debugging
              problems with common symbols.

　あるじゃん（なんだその微妙な違いは）。

Manpage of ld http://www.linux.or.jp/JM/html/GNU_binutils/man1/ld.1.html

---

-warn-common
共通シンボルが他の共通シンボルやシンボル定義と結合されている場合に警告を発する。 Unix のリンカはこの点には比較的寛容であるが、他の OS のリンカにはそうでないものもある。このオプションはグローバルシンボルを結合することによって生じる問題点を見つける手がかりになるかもしれない。

　なんとなく似たもん同士という印象を受けた。んじゃどっかにある-warn-commonを探して-warn_commons に書き換えてみるデスだよ。
　さてどこでしょお。
　~/gpac/Makefile をCotEditorで開いても-warn-commonはおろかldも無い。ここぢゃない。
　~/gpac/applications/mp4box/Makefile も同様。むむむ。しかし一行目にinclude ../../config.makと書いてある、、、怪しいぞキサマッ！
　二つ上二つ上、、、居た。

　-warn_commonsに書き換えて、もっかいmake apps。

$ make apps
make -C applications all
set -e; for i in mp4box mp4client generators osmo4_wx ; do make -C $i all; done 
cc -Wl,-warn_commons -read_only_relocs warning -o ../../bin/gcc/MP4Box main.o filedump.o fileimport.o -L../../bin/gcc -lgpac -lz
/usr/bin/ld: unknown flag: -warn_commons
collect2: ld returned 1 exit status
make[2]: *** [MP4Box] Error 1
make[1]: *** [apps] Error 2
make: *** [apps] Error 2

　ぢゃ抜いちゃえ。

$ make apps
make -C applications all
set -e; for i in mp4box mp4client generators osmo4_wx ; do make -C $i all; done 
cc -Wl,-read_only_relocs warning -o ../../bin/gcc/MP4Box main.o filedump.o fileimport.o -L../../bin/gcc -lgpac -lz
powerpc-apple-darwin8-gcc-4.0.1: warning: No such file or directory
make[2]: *** [MP4Box] Error 1
make[1]: *** [apps] Error 2
make: *** [apps] Error 2

　なんか全然違うらしい。cc -wl, なんたらって書いてあるから、ccのオプション書式なのかな。cc…Cコンパイラ？
　ぢゃman cc。

Linker Options
           object-file-name  -llibrary -no-c++filt (APPLE ONLY) -nostartfiles
           -nodefaultlibs  -nostdlib -pie -s  -static  -static-libgcc  -shared
           -shared-libgcc  -symbolic -Wl,option  -Xlinker option -u symbol

　ありやんの。　

Manpage of GCC http://www.linux.or.jp/JM/html/GNU_gcc/man1/gcc.1.html

---

-Wl,option
オプション option をリンカに渡します。option がコンマを含む場合は、それらのコンマで複数のオプションとして分割されます。

　ではman ccにもどってずりずりとスクロールしていくと（なんか飛ぶ方法があると思うが）、

       -Wl,option
           Pass option as an option to the linker.  If option contains commas,
           it is split into multiple options at the commas.

　いやそのオプションが知りたいんすけど？むー。
　あれ？./configure --helpに

  --extra-ldflags=ELDFLAGS add ELDFLAGS to LDFLAGS [ -Wl,--warn-common]

　ってあるな。ぢゃ、-Wl,--warn-commonを消してみっか。

$ make apps
make -C applications all
set -e; for i in mp4box mp4client generators osmo4_wx ; do make -C $i all; done 
cc -read_only_relocs warning -o ../../bin/gcc/MP4Box main.o filedump.o fileimport.o -L../../bin/gcc -lgpac -lz
/usr/bin/ld: can't locate file for: -lgpac
collect2: ld returned 1 exit status
make[2]: *** [MP4Box] Error 1
make[1]: *** [apps] Error 2
make: *** [apps] Error 2

　……………取りあえず、一歩進んだという印象を受けた。

Open Tech Press | フランス大統領候補者、フリーソフトウェア関連の問題について語る

---

　4月22日のフランス大統領選挙第1回投票に参加するフリーソフトウェアの支持者たちには、世界でも他に類を見ない情報が提供される。それ は、フリーソ フトウェア、著作権、特許、デジタル著作権管理に関わる問題に対する主要政党すべての方針声明である。さらに（少なく とも北米の人々にとって）驚くべきこ とは、候補者の大部分がこうした問題をしっかりと把握し、明確な立場を打ち出していることだ。

　ナニカの団体が各候補者にアンケートを送ったらしい。よくわからないが表にしてみた。

質 問	国 民運動連合 コワモテ暴言小僧 Nicolas Sarkozy氏	社 会党 マンガも読もうぜ Ségolène Royal氏	フ ランス民主連合 François Bayrou氏	革 命的共産主義者同盟 Olivier Besancenot氏	無 所属 José Bové氏	フ ランス共産党 Marie-George Buffet氏	国 民戦線 元祖ウヨクだ Jean-Marie Le Pen氏	緑 の党 Dominique Voynet氏	備 考
特許は一般的に好ましいものか。 とりわけヨーロッパ特許庁（OEB）の活動について	特 許法を支持 企業の技術革新を促進し、投資を活性化させ、個人による新しい発明の創出を促進するから	特 許化できるものとそうでないものの区別の明確化が必要 特許事務所による立法的行為の防止が必要 欧州議会においてフランス社会党はソフトウェア特許に反対した	「フ リーソフトウェアの開発」 に寄与する法律を支持する	ソ フトウェア特許に反対	ソ フトウェア特許に反対 （FSF財団の4つの自由を引用）	ソ フトウェア特許に反対	ソ フトウェア特許に反対	緑 の党は「アイデアの特許性に反論する」人々を支援する
ロックダウン技術の迂回を試みる人々に対する相互運用性と保護の権利を支持するか また相互運用性のためにソフトウェア開発者による情報提供の義務があるかどうか		相 互運用性はソフトウェア特許より優先されるべき 言論および結社の自由に関わるものであることを示唆	「相 互運用性の権利は、開発者にとってもユーザにとっても不可欠」 「相互運用性の抑制は、クリエイティブな大衆アーティストの阻 害につながる。また、単純にこの質問が個人用にコピーする権利を行使するユーザに言及しているのなら、そうした技術的手法を迂回手段とみなすことはできな いだろう」	概 ね支持	概 ね支持	概 ね支持	概 ね支持	概 ね支持	端的に言えばiTMSで買った音楽をiTunes以外でも再生できるようにするべきか。って事だと 思う。
DADVSI法 （情報化社会における著作者の権利および関連権利についての法律）の撤廃を支持するか	知 的財産権の考え方を支持。 あなた方が暗に示唆している考えには反対の立場をとっている」 見直しが予定されている2007年末にならないうちにDADVSI法の改正に言及するのは時期尚早	大 幅な改正または撤廃の必要性を認める	大 幅な改正または撤廃の必要性を認める	大 幅な改正または撤廃の必要性を認める	大 幅な改正または撤廃の必要性を認める DADVSI法の支持者は「自由破壊者」	大 幅な改正または撤廃の必要性を認める	大 幅な改正または撤廃の必要性を認める	大 幅な改正または撤廃の必要性を認める	昨年、フランス議会で強引に可決されたこの法律は、反DRM活動家たちから「ヨー ロッパで最悪の著作権法」と呼ばれている。 とあるが、確かffmpeg/Mplayer/vlcをヌッ頃す部分は修正削除されたハズ。
どんなソフトウェアも予めインストールされていないコンピュータを消費者が購入できる権利		支 持	支 持	支 持	支 持	支 持	支 持	支 持	予めインストールされたソフトウェア分の費用支払いが消費者の権利に反する とあるが、大手メーカー製品をOS抜きで買いたいという事だろうか。
学生たちにMicrosoft Officeのような「シリーズ製品」（アンケート中の表記より）ではなくワープロや表計算ソフトのような「各カテゴリのツール」を習得させる必要性		支 持	支 持	支 持	支 持	支 持	支 持	支 持	未成年層がソフトウェアベンダの影響を被りやすいことをほのめかしている。
オープンスタンダードとフリーソフトウェアを促進する政府組織を支持するか	「自 由に対する私の考え方によれば、誰にでも1つの型を押しつけることが国家の役割とは思えない」	双 方を奨励する 支援は担当政府機関の基準によって調整しなければならない	双 方を奨励する 支援は担当政府機関の基準によって調整しなければならない それらの普及促進よりも「公的資金の活用」、「利用の自由」、「待遇の均等化」といった原則のほうが重要	双 方を奨励する	双 方を奨励する	双 方を促進する機関を設置する	双 方を奨励する	双 方を支持する政策を実施する
質 問	国 民運動連合 Nicolas Sarkozy氏	社 会党 Ségolène Royal氏	フ ランス民主連合 François Bayrou氏	革 命的共産主義者同盟 Olivier Besancenot氏	無 所属 José Bové氏	フ ランス共産党 Marie-George Buffet氏	国 民戦線 Jean-Marie Le Pen氏	緑 の党 Dominique Voynet氏	備 考

　サルコジさん以外は苦戦してんだなとか、なんで緑の党とルペンさんが同じ主張なんだとか、見方はいろいろあると思います。
　でもみんな解答してるってことは、無視出来ない票になるっていうか、オープンソース・フリーがいっぱしの圧力団体ってことだよなぁ…
　欧州の情勢は複雑怪奇ッ。

　PlayStationとセガサターンがガチンコ勝負していた頃。

　ある講演会で事務方のしたっぱを手伝う事になり、その講師の一人が久夛良木閣下だった。
　会話というようなものではない。ただのスキマ時間潰しの立ち話のつもりだった。
　覚えてるのは、

1. 時間なのに話がうまく切り上げられなくて焦った事。
2. 向こうもそれは解ってるハズなのに、絶対目線を外さない事。
3. こちらがひとこと言うたびに「ふん！」と鼻息を噴いて、一歩踏み出して来た事。
4. 「もっと詳しく！」オーラが噴出して気圧された事。
   

　視線を外されたり、眼光が消えたりしてはイカン！と思ってちょっと必死でしゃべった。
　ほんの5分くらいだったはずだが、20分くらいに感じた。
　ナニをしゃべったかはあまり覚えていない。

　だが、彼の眼光と鼻息は長くオレに残った。
　うまくコトバにできないが、プラネテスでハチマキがエンジンに触れた場面。なんとなくアレが近い。

　だから、ネット上で非難されている彼の暴言や増上慢とされるものを、オレは気にも止めてない。
　不実だと思っている。ナマ久夛良木はアツいぜ。

• 後藤弘茂のWeekly海外ニュース・SCEI 久夛良木社長インタビュー(2)「PS 3のHDDにフル機能Linuxを搭載」
  
• 本田雅一の「週刊モバイル通信」374：SCE久夛良木CEO退任がもたらすもの
  
• SCE久夛良木さんがSCE役員を退任 - パースペクティブ・アイ [ITmedia オルタナティブ・ブログ]

　GPACは、MPEG-4 Systems standard (ISO/IEC 14496-1)に基づくマルチメディア・フレームワークです(*1)。ANSI Cでスクラッチで書き起こされています。

　開発主旨は、MPEG-4 Systems レファレンス・ソフトウェア（IM1の名前でISO/IEC 14496-5で配布されています）の代わりに使える、クリーンで（できるだけ多くの人が読めるという意味です）、小さく、フレキシブルなソフトの提供で す。MPEG-4レファレンス・ソフトウェアは、実際非常に巨大なソフトで、実用性よりは規格そのものの検証に主眼があります。

　この主旨に基づき開発作業は、最新のマルチメディア規格～SVG/SMIL, VRML, X3D, SWF, 3GPP(2) tools, など～を単一のフレームワークに実装する方向で調査してきました。VRML97と、X3D規 格の相当部分は既にGPACに実装済みです。また、SVG (SVG Tiny 1.2)の一部をサポートし、Macromedia Flashのサポートも試験的実装の段階です。

　GPACはC（ほぼ100%ANSI）で書かれています。これは（組み込み機器やDSPへの）ポータビリティ（＊移植性・可搬性＊）の為で、メモリーへ のフットプリント（＊メモリ使用量というほどの意味らしい＊）ができるだけ小さくなるように心がけています。

　Version 0.4.0以降のGPACは、GNU Lesser General Public Licenseでライセンスされています。それ以前の バージョンはGNU General Public Licenseです。

　現在にリリース版（GPAC 0.4.2）は、既にMPEG-4 standardを非常に広くカヴァーしています。また、以下に関してはまずまずサポートしています。VRML/X3D、W3C SVG Tiny 1.2、3GPP、大半の2D MPEG-4 Player（先進的で勢いがあり、広く一般に入手できるもの）、勃興しつつある3D player。サポート済みツールの詳細は、features のページを見て下さい。

　他にもGPACはMPEG-4 Systemの encoder/multiplexerの機能を持っています(*2)。MP4と3GPP(2)ファイルの、パブリッシングとコンテンツ・ディストビュー ション用ツール、そしてscene description（MPEG4/VRML/X3D コンバータ、SWF/MPEG-4、などなど）。

　GPACは現在、以下のプラットフォームで動きます。

• Windows
• Linux platforms
• WindowsCE (SmartPhone/PocketPC 2002/2003) (OpenGL-ES経由の3Dレンダリング)
• 組み込みlinux (familiar 8 + GPE)

---

---

【所感】

(*1)MPEG-4 Systems standard (ISO/IEC 14496-1)に基づくマルチメディア・フレームワークです。

(*2)他にもGPACはMPEG-4 Systemの encoder/multiplexerの機能を持っています。

【ソースコード内のmanがD&Dで開けた】

$ man /Users/USERNAME/gpac/doc/man/gpac.1 

NAME
       GPAC - MPEG-4 Systems Framework and Software Development Kit

DESCRIPTION
       GPAC  stands (does it ?) for GPAC Project on Advanced Content. It is an
       implementation of the MPEG-4 Systems standard written in ANSI  C.  GPAC
       provides  tools  for  media playback, vector graphics and 3D rendering,
       MPEG-4 authoring and distribution.  This man page is  about  configura-
       tion of the GPAC framework version 0.4.3.

INTRODUCTION
       Some applications in the GPAC framework use a configuration file shared
       among modules and reloadable at run time. This file is located  in  the
       user home directory and called ".gpacrc".

       The  configuration  file is based on the win32 .ini file model, ordered
       by sections and keys.

       A section is declared as [SectionName] , a  key  is  declared  as  key-
       Name=value  ,  the  key  value is not interpreted and always handled as
       ASCII text. Plugins may use the configuration file as  well  (to  avoid
       multiple files).

       Note  on  plugin names: Plugin names as given in the configuration file
       are names exported by each interface  and  not  name  of  the  physical
       library  file  (.dll/.so  ...).   The physical file name can however be
       used to identify a plugin, it will be replaced by the interface name if
       the plugin was successfully loaded.

【~/gpac/applicationsの内容】

そうすっとgpacアプリケーションの一覧がそれなりに埋まる。　

名前	種類	メモ
CVS	folder
GPAX	folder	GPAC ActiveX control, IE only
Makefile	file
generators	folder
mp42avi	folder	NAME MP42AVI - MPEG-4 BIFS to Video converter SYNOPSIS MP42AVI [options] file DESCRIPTION MP42AVI is a tool to convert a pure MPEG-4 BIFS presentation (no audio, no image, no video) to an uncompressed sequence of images or an uncom- pressed RGB avi file. Pages du manuel Linux
mp4box	folder	MPEG-4, 3GP, 3GP2コンテントの作成と配布に必要な機能を一つにまとめたツール。 NAME MP4Box - MPEG-4 Systems Toolbox SYNOPSIS MP4Box [options] file [options] DESCRIPTION MP4Box is a multi-purpose command line tool to create and edit MPEG-4 Systems presentations and manipulate ISO-media files (MP4, 3GP, MOV). MP4Box supports file conversion from various raw formats and IsoMe- dia/AVI/MPEG-PS/OGG containers, file hinting for RTP streaming for QuickTime compatible streaming servers, file interleaving, file frag- mentation and track extraction. MP4Box also provides dump tools used to inspect file layout, RTP hint tracks, SDP information, scene composition. It may also be used to con- vert to and from BT/XMT-A/VRML/X3D. MP4Box also features MPEG-4 Systems encoders and decoders for BIFS and OD tools. MP4Box doesn't expect any particular order in options at prompt.
mp4client	folder	NAME MP4Client - GPAC MPEG-4 command-line Player SYNOPSIS MP4Client [options] [file] DESCRIPTION MP4Client is GPAC command-line player. It supports all GPAC playback features (2D and 3D support, local playback, RTP streaming, HTTP fast- start, many audio and video codecs ...). MP4Client also supports visual extraction to BMP, RAW or AVI (no compression, no audio).
osmo4_sym	folder	GPAC Players
osmo4_w32	folder	GPAC Players
osmo4_wce	folder	GPAC Players
osmo4_wx	folder	GPAC Players
osmophone	folder	GPAC Players
osmozilla	folder	GPAC plugin for mozilla-based browsers
standalone2drender	folder
testapps	folder
v4studio	folder

人気記事

	タイトル	カテゴリ タグ	離脱率	固有の訪問数	memo
01	牛 乳有害説	ゲームのミカタ	84.07%	2,874	はてブ
02	AppleTV 改造 - Xvid	ごみ箱 Mac と*nix	79.18%	831
03	PSP ファームウェア3.30	ごみ箱 PSP	73.71%	680
04	MeGUI ガイド_x264の設定	動画全般 試訳 x264 MeGUI	42.01%	464
05	MP4 faq	MPEG-4全般 規格 MPEG-4 コ ンテナ Doom9 MPEG -4の基礎	65.57%	450
06	Apple TV 改造プロジェクト「AwkwardTV」	INBOX Mac と*nix	64.56%	410
07	MP4Box の主要コマンド	mp4box(gpac) 試訳 MP4box コマンド MPEG-4	54.00%	386
08	やっ ぱ牛乳でしょ♪	ゲームのミカタ	63.85%	359
09	縦 横（アスペクト）比	動画全般 H.264/AVC 規格 MEncoder x264cli ア スペクト	67.28%	337
10	カテゴリ：動画全般		29.14%	327

　新規 63.13%　リピート 36.87%

　Apple TV関係は検索で来る人が多い。PSPも同様だがバックリンクを辿るとffmpeg絡みのtipsが増えそう。

プラットホーム

種 類	比 率
Win	81.26%
Mac	15.09%
Linux	2.97%

　概ね前月同等。

Mac

種 類	比 率
PPC	61.97%
Intel	38.03%

　前月にMacintelは今年中に4割いくかなどとほざいたが一気に来た。

Win

	種類	比率
1.	XP	84.42%
2.	2000	10.15%
3.	Vista	3.42%
4.	98	1.05%
5.	Server 2003	0.75%
6.	ME	0.12%
7.	NT	0.09%

その他

1. Internet Explorer 55.29%
2. Firefox 29.37%
3. Safari 9.17%
4. Opera 3.65%