今日の出来事 (Sep, 2008)

VMware Workstation 6.5 Build 118166 発売...

　RC2 が登場するかと思っていた VMware Workstation 6.5 ですが， 専用アカウントを必要としない一般のβ公開を行うことなく現地時間の 23 日に製品版が登場してしまいました。 まぁ， βにしろ製品版にしろ手を出す点に変わりはありませんので， 昨日早速ダウンロードしてインストールを行いました。 とりあえず開発環境でもある Windows XP MCE 2005 ゲストなど主要ゲストの動作確認だけは行いましたが， Direct3D 等を始めとした もう少し詳しい確認は週末に行う予定です。 VMware 6.5 のページについては， その結果を踏まえて さらに更新することとなるでしょう。

　幸い「RC より悪い事態」という最悪のケースだけは免れているようです。 反対に， 改善点が見あたらず今のところは全然変わっていない…という印象でもあるわけですけれど。 ベンチ類や一部のソフトを試してみた限りでは Direct3D 方面も変わっていない…のは当然といいますか， 少なくとも (ゲスト側の) ドライバーは RC から更新されていませんでした。 挙動から不具合まで全て同じ…というところからすると， (この方面については) 本体側 (vmware-vmx.exe) も変更されていないようで， 「せっかく比較的安定している状態なのだから触らぬ神に祟りなし」という方針だったのかもしれません。 (^^;)

　製品版ということで VMware 本体や VMware Tools のインストール&削除を全て VMware に任せてみたのですが， 今回は VMware Workstation 6 等と異なり日本語環境でも問題が発生しませんでした。 アカウントやインストール先が (ANSI API での) マルチバイト文字だった場合は判りませんけれど…。 いつぞや経験したような「RC (やβ) から製品版へ更新したら (ゲストで) 再アクティベーションが発生した」という仕打ちにも遭遇しませんでした。 あ， マイナーバージョンアップとは言ってもゲスト PC のバージョンが上がっていますから， ゲストのアップグレードを行った場合は (常ではないものの) 再アクティベーションが発生します， 念のため。

　状況が変わっていませんので RC 段階で書いた記事を一覧しておきます：

• VMware 6.5 の OpenGL 対応度...：OpenGL ネタ
• VMware 6.5 RC で動作した Direct3D (DirectX) 対応ソフト...：Direct3D ソフトネタ
• VMware 6.5 RC での Direct3D 複数環境同時実行...：WS + Player 同時動作ネタ
• VMware 6.5 RC で動作するようになったベンチ...：ベンチネタ
• VMware 6.5 RC のデバッグログと Direct3D...：デバッグログネタ
• VMware Workstation 6.5 RC Build 110068 公開...：βからの改善・改悪ネタ

Diablo II...

　新作の III ではなくて II の話ですが…。 (笑) 　今月初めに VMware Workstation 6.5 RC での Direct3D 対応度及び安定状況再確認用ソフトの一つとして Diablo II + Lord of Destruction を (ゲストの Windows XP MCE 2005 マシンへ) インストールしたのですが， 懐かしさから その後も ちょこちょことプレーしていたりします。 ただ， あまりにも久々でしたので (6 年くらい？) 多くを忘れてしまっている辺りが少々痛いところです。 意外にも悩みの種となったのが当時使用していた 1.08 と今の 1.12 との違いです。 特に困ったのがアイテム合成…。 基本の一つと言えそうな「Healing Potion × 3 + Mana Potion × 3」の合成が行えなかったので Act II 辺りではちょっとだけ苦労しました。 ほかにも Gem や Rune を適用した場合のダメージ修正値の変更などなど…。

　それでも何とか Act V に入っていますが， 今回のアマゾンでのプレーで一番苦労したのは Act II のデュリエルだったような…。 「Townportal による逃げ道確保」という手段を忘却していたので 5 回ほど死んでしまいました。 それに対して， Act I のアンダリエルが弱いのは仕方がないとして， 毎度ながら Act III のメフィストが弱くて Travincal のユニークモンスターのほうが強く思えてしまいます。 で， 主役である Act IV のディアブロはと言えば， その頃には Level 30 を超えていましたので， ワルキューレを召還することで比較的楽に倒すことが可能でした。 デコイは瞬殺でしたし， Act I のクエスト以来ずっと お世話になっている傭兵アマゾンローグ傭兵 (ちなみに Annor。 ^^;) も Fire Nova 等で何もしないうちに倒れていましたけれど…。

　ボス戦はともかく…。 この「ワルキューレ + 自身 (弓アマゾン) + 傭兵 (遠距離系)」の組み合わせは， 毎度ながら楽ちんで良いですね。 デコイを使えば「前衛 2 + 後衛 2」といったパーティーのノリで進められますし。 ただ， この中で一番 Life の少ないのが自身というのは問題かも…。 260 強しかない自身に対してワルキューレなんて倍以上の 700 超えですから。 (笑)

Norton Internet Security 2009 導入...

　Symantec の Norton Internet Security 2009 (NIS 2009) が発売されて 1 週間ほど経ちましたので昨日試してみました。 一応「軽さ」がウリのようですので， 年末の更新期限ではあるものの少々重さが気になるメイン PC の Satellite WXW/78DW へ適用することに…。 Norton System Works (NSW) や Norton AntiBot (NAB) との併用問題を調べるのにも都合が良かったことですし。

　まず， 予想はしていましたが， 何も考えずに購入・ダウンロード・実行しての NIS 2009 インストールを行った限りでは， 年末まで期間があったはずの NIS 2008 の更新期限はクリアーされました。 NIS 2007→2008 等でのアップデートでは， 更新期限にかかわらず期限が保持されたままアップデートが可能だったのですが， 少なくとも NIS 2008→2009 については， 今のところは転けるケースが存在するようです。 いずれ無償アップデートの告知は行われると思いますが， もし配布ファイルに変更がないのであれば， 非常に危なそうです。 (^^;; 　さすがに， これ以上犠牲者を増やすわけにもいきませんので， あと一月ほどで期限となる 3 台ほど (On Going で自動更新予定。) は体験版経由の安全策を採ることにします。 告知後に犠牲者が増えた場合は WXW を含めて Symantec に対処してもらうこととしましょう。

　あと， こちらも毎度のパターンなのですが， NAB との併用は行えなくなりました。 といいますか， NAB が存在すると NIS のインストールが行えません。 それどころか併用するために存在するはずの Basic 版 NSW すら拒否されてしまいました。 いつもながら何を考えているのか分からない仕様ですね。 確かに NIS 2009 には NAB 的要素も付加されていますが， それはあくまでもサブセットであって， NAB が併用できないのであれば単なる改悪でしかありません。 そして， その NAB にも On Going は適用されているわけで…。 中には NAB のライセンスが無駄となってしまうユーザーも出てくることでしょう。 ライセンスが絡んでくる分 Norton Password Manager (NPM) の時よりも訳が悪いと言えそうです。

　そういえば今気付きましたが， WXW では一度も NSW を使っていません。 (爆) 　唯一使っていた Norton Protect (NP) も NPM も今では存在 (若しくは機能) しませんから， 使わないのも当然かしら？ 　せっかくなので WXW くらいへは (可能なら) 入れてあげますが， 後は必要なさそうですね。 あ， もちろん NIS には ID セーフが存在しますが， NPM の改悪品でしかありませんから。

　製品自体が そうなのですから個々の機能も同様です。 NIS 2009 では 2008 に存在したプロテクトセンターが実装されていませんが， プロテクトセンターでの「今すぐ解決」ボタンの代替となる機能すら存在しません。 2009 では「まとめて一括処理」が行えないのです。 要は NIS に任せて自動処理させろ…ということなのでしょう。 変なところで N360 化されているような気がします。 あと， Live Update Notice も存在しないようで， 昔ながらの Live Update のアイコンが寂しく点滅しているだけなのですが， それも管理者アカウントでないと正常動作しません。 一般アカウントでは画像のとおり「OK」ボタンだけのダイアログが表示されます。 恐らく「管理者アカウントでないと実行できない」とか何とか表示するつもりなのでしょうが， それなら一向に消えないアイコンを点滅させないでほしいです。 このような基本的な部分さえ NIS 2008 から改悪されている状況で， いつもながら発売直後はβ版クオリティーです。

　話変わって， NIS 2009 では軽さをウリにしていますが， それは Norton Insight を実行してランク付けを行った結果 (大抵) そうなるものです。 が， よほど PC を暇にさせておかない限り初日にランク付けが行われることは無いようです。 なので， NIS 2008 と変わらない状態が続いていました。 日を越して重たいのは嫌でしたので， 最後に手動でランク付けを行いましたけれど…。 あ， そうそう。 「安全」とか表示されるガジェットですが， 本当にそれだけで あとは何もありません。 あまりにも無駄全開のガジェットです。 それとデザイン。 なにやら 2007 辺りからコロコロ変更ばかりして迷走していますね。 今回は無駄に透過表示を行っていたりしますが， そんな部分に手を入れている暇があったら， 基本部分の作り込みを しっかり行ってもらいたいです。 まともに動作しないのでは， デザインなぞ無意味です。

　とはいうものの， 経験上， ウイルスバスター (2007～2008) は一度更新した途端再インストールを余儀なくされますし， McAfee 方面 (2004～2008) はサポート経由でパッチを手に入れる必要があったりしますし， 慣れもあって基本的には NIS を使い続けることになるのでしょう。 とりあえずは NAB や NSW を併用すべく足掻いてみることにします。 (笑)

VMware Workstation 6.5 の OpenGL 対応度...

　4 日前の記事を書いていて ふと思ったことがあります。 それは， ゲスト上で GL Excess が動作するのは良いとして， 一体どこまで OpenGL に対応しているのかしら？という点です。 いくら DirectX が主要目的の Windows ゲストとは言え， 伝統的に OpenGL が使われている方面のソフトも存在しますし， ある程度は対応しておく必要があるでしょうから。 というわけで， OpenGL Extensions Viewer 3.04 で調べてみました。 結果の概要は以下のとおり：

…………。 VMware Workstation 6.5 は， こと Windows ゲストについては OpenGL に対応していませんでした。 (^^;; 　Microsoft 謹製のソフトウェア処理に丸投げされています。 これでは GL Excess が死ぬほど重いのも当たり前で， むしろ動作しているのが不思議なくらいです。 素人目には， 内部処理が OpenGL だけに翻訳・変換量が少ない分だけ対応しやすい気がするのですが， 果たして将来的に対応予定があるのでしょうか？ 謎です。 もっとも， OpenGL ソフトを使用することはないでしょうから， 個人的には全く影響しませんけれども…。

WILLCOM D4 退院...

　先月の 23 日に省電力強化対応を申し込んで 26 日に入院した WILLCOM D4 ですが， 水曜日に対応完了と送付予定の連絡があって， その予定どおり昨日退院してきました。 ちらほらと聞こえてくる「粗雑な扱いにより そこかしこに傷が付く」といった事態は回避できたようで， 却ってピカピカになって帰ってきました。 汚れを落とすくらいはするでしょうから， その分綺麗になったということのなのでしょう。

　さて， 問題の対応内容ですが， 以下のようになっていました：

• 省電力対応実施致しました
• 各部検査実施良好です
• Ver Up 致しました

　ドライバーのアップデートは指定していましたので， 指定どおり実施されています。 事実 HDD は初期化されていました。 一方， 省電力対応のほうは基板交換を伴わなかったパターンのようです。 確かに， ジャケットが少々綺麗になったものの LCD は保護シート共々そのままですし， MAC アドレスも変わっていません。 LCD 方面はともかく， 交換しているのであれば MAC アドレスが変わっているはずなので， こちらも実施項目どおりということになります。

　…などと確認していたら重大な懸案事項が。 ラベル上， 製造番号の右隣に入っているはずの強化実施を示す緑の●マークが入っていません。 「はて？ 省電力問題発覚後の新型基板でないと付加されないのかしらん？」とか何とか思いつつも， さすがに この辺りは WILLCOM へ聞いてみないことには判りません。 既に問い合わせ可能時間は過ぎていますので， とりあえず充電だけしておいて 後は翌日の宿題としました。

　というわけで今日ですが， まずは 14 時間放置時点で AC アダプターを使用せず起動してみました。 結果は 78%。 アダプター無しということで 2% くらいは起動時に食われている勘定となりますが， それはともかく， 概ね 1.4～1.6%/h の消費状況となります。 入院直前の数値 (最良で 1.2%。) と全く変わらない誤差の範疇と言えそうな状況で， だからこそ基板交換を伴わなかったとも言えそうです。 まぁ， 一度の確認で判断してもしようがありませんから， 半月ほど使って追々確認することにしましょう。

　消費状況の確認も行ったので， 早速 WILLCOM サービスセンターへ問い合わせてみました。 結果は…， やはり基板交換が伴わないと●マークが付加されないようです。 他の方の状況は判りませんが， 同様の付加状況であるのなら ある意味整合性が取れていることになりそうです。 つまり， パターンカット等が行われていたとしても対策前の基板であるのならマークが付加されないわけで， 一目で判断が可能なようにしてあるわけです。 いや， パターンカット等さえ行われていないのかもしれませんね。 「省電力対応実施」というのが基板への何らかの処置を示すとは限りませんから。 チェック作業だけでも「対応」ですし， サービスセンターの お姉さんからも その辺りを臭わす言い回しが伺えましたし。

　「何も考えず全部交換するのが本筋」とは思いますし本来の対応なのでしょうけれど， 「交換した後のほうが結果は悪い」というケースもあるようですし， 部品も足りていないようですから， 「状況が比較的良好なら「触らぬ神に祟りなし」で最低限の処置だけにしておこう」ということなのでしょう。 まぁ， 現在の値で推移してくれるのであれば問題はありません (何しろ公称数値が 1.25%/h。) から， 期限ぎりぎりまでは様子見で構わないでしょう。 何かあれば再度入院させれば良いわけですから， 「本格的な対処 (基板交換) は行っていない」という確かな証拠も存在するわけですし。 (笑)

VMware Workstation 6.5 RC で動作した Direct3D (DirectX) 対応ソフト......

　先月， VMware Workstation 6.5 RC で動作するようになったり動作が改善したりしたソフトについて いくつか画像を上げましたが， 今回は， 以前試したことのある Diablo II などを再び試してみました。 当時は VMware Workstation 6 等だった上にホストも dynabook Satellite TXW/69AW と， 現在 (VMware 6.5 + Satellite WXW/78DW) とは環境が異なっていましたので。

　というわけで， VMware 6.5 上で既に試したものを含め， 備忘録代わりとして一覧しておきます。 ちなみにホストの概要は， Core 2 Duo T7500， 4 GB (3 GB) メモリー， NVIDIA GeForce 8700M GT (256MB)， Windows Vista Ultimate SP1， …といった感じですので， 能力については推し量ってください。(笑) 　ゲストは基本的に Windows XP MCE 2005 SP3 ですが， 一部 Windows XP Home Edition SP3 や Windows 2000 Professional SP4 といった例外が存在します。

　まず， 動作しなかったのは『3DMark99 MAX』と『エヴァベンチ』です。 前者については そもそも Win9x 系でないと動作しませんので， 何かの間違いで Win9x 系での Direct3D 対応化が図られでもしない限り VMware 上での動作は不可能です。 一方， 後者は Build 110068 でも動作しませんでした。 描画がおかしいですしロード画面から (表示のみが) 切り替わらなかったりと不具合満載です。 そして， ESC 等で動作を止めようとすると漏れなく (ゲスト OS が) ブルーサンダーとなります。 GPU やドライバーの対応状況に関係なく機能を使いまくっているのが原因なのではないかと…。

　さて， 本命の動作組ですが， まずは「動作して当然。 してくれないと悲しい」と言えそうな方々から：

　この 2 つは Direct3D を使っていませんので， 動作しない場合は DirectX レベル (若しくは それ以前の仮想 PC レベル) において相当不安定になっていることを示します。 ただ， 当時 (ターゲットが Win9x 系。) のソフトは古い DirectX でないと動作しない場合も多々ありますけれど。 例えば『ファーランドサーガ』は DirectX 8.0 以降で動作しない場合があります。 紆余曲折を経て今は DirectX 9.0c 上で動作していますが…。 あと， ゲームに限らず MIDI や CD-DA を多用している点がネックとなるかもしれません。 上述のファーランドサーガでは， 当初は Windows 98 上の『S-YXG 100 Plus』を使用した MIDI で動作させていましたが， ES1371 上での S-YXG 100 Plus (要はソフトウェア MIDI。) が使い物にならず， 今では Windows 2000 上の CD-DA での実行を余儀なくされています。

　余談ですが， このファーランドサーガ。 キャラデザが山本和枝氏なのですが， シナリオや SRPG の仕様， BGM， イベント画・立ち絵等の線画， …といった辺りの改変を伴わない， 解像度と塗りとエフェクト方面のみを向上した， 現 OS 対応版の登場を個人的に切望しています。 プログラム資産的にも技術は受け継がれているでしょうから， 何かの間違いで Studio e.go! から出てくれないかしら？ (爆)

　次に DirectX 8.1 系までの方々：

　以前と異なり『Age of Empires II (AOK)』 『Diablo II』共に製品版での動作となっています。 「VMware 上では AOK のプロテクト CD を扱えない」というネタを見かけたので今回製品版を試してみたのですが， 少なくとも (私の使っている環境での) VMware 6.5 では大丈夫のようです。 といいますか， 今までプロテクト CD を使えなかった試しが無かったりします。 (^^;) 　動作も軽く『FORTUNE ARTERIAL』共々 VMware での使用に何ら問題は有りません。 それに対して Diablo II は， フルスクリーンの排他動作でも意外と重くプレーするのが少々辛い状況となっていて， 2 章で早くも破綻しそうな気配です。 VMware 6.0 の頃はウインドウモードでもプレーが可能だったのですが， 新たにエフェクト等の有効となった点が仇となってしまっているのかもしれません。 ちなみに， SVGA 表示となっているのは Lord of Destruction 状態だからです。

　続いて， エフェクト方面などに小出しで Direct3D を使用している DirectX 9.0c 系ソフトの方々：

　『プリミティブリンク』と『Wiz Anniversary』については製品版です。 これらのソフトでは， 画面の拡大・縮小・スクロール， 特定領域でのクリッピングや座標変換を伴っての複数動画再生， エフェクト， そして それらの透過を伴った重ね合わせ， …といった特定用途のため (だけ) に DirectX 9.0c や Direct3D が必要とされています。 また， 密かにピクセルシェーダーが使われていたりもします。 そのため， 見かけに反して VMware 6.0 まででは動作しないものとなっています。 (除く 検証版魔女っ娘ア・ラ・モードII。)

　小出しでしか Direct3D の機能を使わないことと， ピクセルシェーダーなどオーバーヘッドの小さい処理が (たまたま) 多いことから， 総じて VMware 上でも重さが気にならないものとなっています。 一方， この辺りの (VMware 6.5 を必要とする) ソフトから小さな不具合も発生し始め， 例えば Wiz Anniversary 辺りではセーブ・ロード画面でのサムネイルが黒抜きとなってしまっています。 もっとも， この現象は実機でも GPU やドライバーの版によって発生しますけれど。

　続いて， アクション系には ほど遠いものの， 一応清く正しい Direct3D 使用ソフトと言えそうな方々：

　『聖なるかな』だけが製品版で残りは一応全て「ベンチ」と銘打たれています。 これらは， アクション系とは比べようがないものの Direct3D を使いまくっている類のソフトです。 Direct3D への依存度とオーバーヘッドの大きい処理の含み具合で動作状況が大きく異なってくる傾向にあり， 比較的依存度の低い 聖なるかな と『ゆめりあベンチ』以外では「動いているだけ」と言えそうなほど非常に動作が重いものとなっています。 この辺り (後ろ 3 つの重い組。) になると， (基本的に) AGP メモリーが前提となっているなど VMware では能力不足に陥ってしまっていて， その辺りも影響して そこかしこで正常に描画されなかったりもしているのですが， そもそもホストで動作させるべきソフトですから， あまり大きな問題とはなりません。

　VMware の対応具合や重さなどのチェックに都合の良いのが この辺りのソフトです。ちなみに， (恐らく) Build 99530 以降では異方性フィルターが使えます。 オーバーヘッドの関係か重さに違いはありませんので， バイリニアよりは こちらを指定しておいたほうが良いでしょう。

　最後は， 正統派 3D ベンチマークの方々：

　VMware の Direct3D 対応度 (だけ) を見るのであれば， 基本となりそうなのが これらのソフトです。 この中で一番重いのは『GL Excess』です。 OpenGL ソフトである点が影響しているのかどうかは定かではありませんが， 恐らく影響しているのでしょう。 (^^;) 　予想に反して非常に重いのが『FINAL REALITY』です。 Win9x 系のソフトである点がオーバーヘッドに大きく影響しているのか『N-Bench3』よりも重いくらいなのですが， ソフトウェア 3D を指定すると一部描画がおかしくなるものの非常に軽くなります。 これらは もはや「動くだけ」状態に陥っています。

　それに対して どこまで行っても (新作となっても。) 比較的軽めのまま推移しているのが 3DMark 系です。 『3DMark2000』辺りは ともかく， 『3DMark05』辺りでも， FINAL REALITY や GL Excess 辺りと比べて随分軽い印象を受けます。 さすがに 3DMark05 ともなると VMware の能力不足が露呈して正常描画されなくなっていますが…。 3D ベンチマークは「重い・軽い」の両極端という印象がありますので， 「重さ」のチェックには あまり向かない気がします。 余談ですが， 3DMark99 MAX の動作不可だった点が非常に残念です。 (^^;)

　VMware 6.0 で行われた OpenGL 系での内部処理共通化により， ハード要件でのハードルの高さは伴ったものの， VMware 6.5 へ掛けて Direct3D への対応度が大きく向上しました。 が， 実用度という点では， 少なくとも現状は「？」という気がします。 短期的には「DirectX 10.0 と WDDM への対応」という目標が存在する (であろう) わけですが， 現在の大きなオーバーヘッドを伴った構造では対応したところで意味がありません。 (実質使い物にならない。) 　それがゲーム等のアプリではなく OS の基本機能として使われるだけに…。 VMware Workstation 7 では無理でしょうが， VMware 7.5 か 8.0 辺りで VT-d への対応化が始まるでしょうから， 「ホストと同じハードのドライバーが用意されているゲストでしか使えない」といった仕様にしてしまわない限りは， Windows ホストでは DirectX， Linux ホストでは OpenGL と， 内部処理が分かれて行くのかもしれません。

UNLHA32.DLL で遊ぶとすれば (2)...

　先日， UNLHA32.DLL での お遊び (実装実験) 予定について書きましたが， まずは暗号化で遊んでみることにしました。 時間的余裕がありませんので， (UNLHA32.DLL としての) 正式対応が いつになるかは全く判りませんけれど。 そこへ至るまでには紆余曲折が予想されますし， 新版・旧版での非互換 (旧版で掛けた暗号が新版で復号できない等。) も発生することでしょう。 それはともかく， まずは叩き台としての仕様概要覚え書きなぞ：

• 暗号化については前に書いたとおり AES-256 を予定。 モードは CBC を使用。 とりあえず Salt は無しで IV については 7-Zip 同様前半 64 ビットをヘッダーに記録する。 ただし， 初期実装では IV を記録しない。 後半 64 ビットは何らかの形でヘッダーの内容が影響を及ぼすようにする予定。 (ヘッダー改竄防止の足しにならないかなぁ～と。 ^^;) 　7-Zip の暗号化形式を採用するわけではありません， 念のため。 (笑)
• 初期実装では圧縮イメージの暗号化しか行わない。 従って， 各種参考情報はヘッダーから読み放題。 (^^;;
• 暗号化の情報を扱うプロテクト情報ヘッダー (ID 0x47) を追加。 サブ ID で暗号形式を示し， 以降のデーターはサブ ID によって異なっても良い。 初期実装である上記 AES-256 形式のサブ ID は 0x01。 0x00 と 0xFF については特殊 ID として予約しておく。
• サブ ID 0x01 用としては， パスワード検証用データーと IV 情報を記録可能とする。 ただし， 上述のとおり初期実装では IV は記録されない。 また， パスワード検証用データーは仕様が存在するだけで今のところ使用予定が無い。
• 互換性は失われるもののヘッダーの暗号化は行えたほうが良いでしょう…ということで， とりあえず それを示すメソッド ID として "ph1" を予約。 暗号化を行う場合は， 上述のプロテクト情報ヘッダーに実際の圧縮メソッド (例えば "lh5"。) を記録する。
• 拡張ヘッダーを使用できる Level 1 ("h1") 以降のヘッダーのみで暗号化が可能。
• 暗号化ヘッダーでは基本ヘッダーの 8 バイト目 ("-lh7-" のメソッド ID の直後。) から拡張ヘッダーの最後 (終端を示す 0x0000 若しくは 0x00000000。) までを暗号化する。
• Level 1 ヘッダーではヘッダー全体のサイズが記録されないことから， Level 3 ヘッダーと同様の位置に付加情報としてサイズを記録するようにする。
• 上記の処理を行うことで事前 (若しくは必ず読み込まれるサイズ内で) のサイズ取得が可能となることから， ヘッダーの暗号化についても AES-256 を使用する。 上記の処理を行わない上で Level 1 ヘッダーに対応する必要があるのであれば， 何らかのストリーム暗号を使用することになると思われる。