今日の出来事 (Jan, 2011)

○○○でパンヤ (PC エミュレーター編)...

　今月半ばに FIN 氏のブログに， 「○○○でパンヤ」と題して Mac mini (MC270J/A) の Boot Camp を使用した Windows 7 Professional 環境での『スカッとゴルフ パンヤ Season 4 Delight!』の Fraps によるフレームレート計測記事が載りました。 ちなみに， 趣旨はタイトルのとおり「Mac でパンヤを実行してみました」というもので， あくまでも目安のための計測です， 念のため。 (^^;)

Mac で Windows ソフトを動作させるための手段としては Boot Camp を使用して Windows 系 OS をインストールするのが一般的です。 「ハードが Mac」というだけで Windows 7 そのものな訳ですから， 専用ハードである事による問題発生の可能性はあっても， 話が比較的単純です。

Windows ソフトの動作手段しては， もう一つ「PC エミュレーター」によるものがあります。 話が相当ややこしくなったり速度低下を招いたりしますが， 「Mac 環境のままで済む」という絶大なメリットもあります。

というわけで， 幸い手元に Parallels Desktop 6 for Mac を仕込んだ MacBook Air が有りますので， 同様の計測を行ってみました。 本当なら Mac mini を使いたいところですが， そのために買うわけにもいきませんので。 (^^;) ＜ Parallels Desktop 6 for Mac のネタを書きたいがためだけに MacBook Air を買った人間が何を言う!! (笑)

　さて， ホストである MacBook Air のスペックですが， 大まかなところでは Core 2 Duo U9400 1.4GHz， 4GB メモリー， NVIDIA GeForce 320M， Mac OS X 10.6.6 Snow Leopard といったところです。 Mac mini の Core 2 Duo 2.4GHz との差が激しく大きいですね。 何しろ こちらはサブノートクラスの CPU ですから…。 なお， この 1.4GHz というのは Parallels Desktop 6 for Mac の要求スペック 1.6GHz を満たしていません。 (笑)

そのホスト上に Parallels Desktop 6 for Mac Build 11992 をインストールして， そのゲスト OS として Windows 7 Professional (x86) が入っています。 Windows エクスペリエンスの値は以下のとおり：

ちなみに， Mac mini では 5.9， 5.5， 5.3， 6.0， 5.7 です。 やはり CPU が大きく足を引っ張っていますね。 エミュレーターの特性上 描画は Direct3D を OpenGL 2.1 へ翻訳した上でホストに描かせることになりますから， ゲーム用グラフィックス辺りにも CPU の能力不足が影響してしまっています。

ちなみに， Windows ホストの場合， ベンチマーク辺りだと描画方面については概ねホストの半分くらいのスコアといった感じです。

　では， Fraps による計測です。 まずは「ピンクウインド＋エリカ」です。

28fps と そんなものなのですが， ゲージはカクつきキー入力も遅れまくってしまいます。 実際にプレーするのは辛いところです。 ちなみに Mac mini では 87fps。 なお， あえて Aero はオンにしていますし， パンヤのフルスクリーン表示も行っていません。 設定は何も弄っていませんので， 800x600 表示で ほかもデフォルト状態です。

　今度は「ピンクウインド＋ルーシア」です。

本来ならルーシアの髪がヒラヒラする分処理は重くなるのですが， PC エミュレーターによる負荷が全てを決定してしまい， エリカと同じ 28fps となっています。 Mac mini では 69fps。

　お次はフルスクリーン表示での「ピンクウインド＋クー」です。

フルスクリーン表示にすると 38fps と 10fps 程度数値が上がりました。 その数値以上に大きく向上したのが操作性で， ゲージが少々滑るものの入力遅れも発生せず普通にプレーが可能となります。 はっきり言って dynabook NXW/76HPW (Core 2 Duo SU9300 1.2GHz， 3GB RAM，Intel GMA 4500MHD) 辺りよりも快適です。 )

　最後に待機画面です。

さすがに実機でも意外とキツい待機画面だけあって， 4 人ともなると入力が利かなかったりとゲームを始めるまでが苦痛となってしまっています。 Mac mini では 55fps。

件のブログでは続けてチャットルーム (露天部屋) での計測が続くのですが， 負荷が恐ろしくて入れませんので計測していません。 (笑)

　というわけで， フルスクリーン表示であれば概ね Mac mini の半分くらい…と言った感じです。 CPU が激しく足を引っ張っている MacBook Air では辛いところですが， より上位の 2.0 GHz を超える CPU が載った Mac であれば， 意外と PC エミュレーター上でも行けるのではないでしょうか？

　…と言った内容を昨日 Twitter で呟いたところ， 「いつも使っている実機はぁ～？ それと VMware Workstation 7.1…」といった声が (何故かメールで) 聞こえてきましたので， 参考までに それらのデーターも上げておきます。 (笑) 　スペック等については VMware 7.1 その他のページを参照。

　Windows エクスペリエンスの値は以下のとおり：

上が VMware 7.1， 下がホストである Satellite WXW/78DW です。 負荷の分 CPU 値が下がり， それが ほかにも影響しています。 描画方面の差が小さいのは， それくらいの負荷で済んでいるという理由もありますが， それ以上に， 特定能力の有無によって得点クラスが分けられるエクスペリエンスの仕様によるものです。

　次に計測値。 まずは「ピンクウインド＋エリカ」です。

左が VMware 7.1， 右がホストで それぞれ 65fps と 72fps となっています。 今となっては時代遅れの GeForce 8700M GT だけあってホストが 72fps に止まっているのに対して， ゲストのほうは 65fps と意外と頑張っています。 VMware 上での経験則の常に従いゲージが少々滑りはしますが， ホストと遜色なくプレーが可能です。 なお， これは VMware 7.1 での話です。 7.0 以下には通用しませんので， 念のため。

　今度は「ピンクウインド＋ルーシア」です。

それぞれ 62fps， 69fps と， 清く正しくルーシアの髪のヒラヒラに掛かる処理の分だけレートが下がっています。

　番外で「ピンクウインド＋クー」です。

本来ならルーシアと同様に髪のヒラヒラでレートは下がるはずなのですが， 何故か 79fps と一番レートが高くなっています。 クーが小さい分軽くなっているのかもしれません。

　さらに待機画面です。

それぞれ 21fps， 33fps と さすがにレートが かなり下がっています。 が， ホストは普通に操作が可能ですし， ゲストのほうも重いとは言え そんなにストレス無く操作が可能で一昔前のサブノート辺りよりは遙かに快適です。

　最後に， MacBook Air では断念したチャットルーム (露店部屋) です。

30/30 状態で それぞれ 13fps， 16fps と さすがに重くなっています。 が，数値のわりにホスト・ゲスト共々， 意外と支障なく操作が可能となっています。

　…と， いつも使っている環境では こんな感じです。 意外とゲストでの落ち込みは激しくありません。 PC (Windows ホスト。) と Mac (Mac OS X ホスト。)， VMware 7.1 Workstation と Parallels Desktop 6 for Mac という違いはありますが， 意外と似たような傾向が有りますので， Mac + Parallels Desktop 6 for Mac という選択肢も十分有り得ると思います。

VMware Fusion 3.1 は…。 経験則的には あまりお勧めできません。 (^^;;

VirtualBox 4.0.2 r69518 公開...

　しばらくチェックを怠っていた間隙を縫って， VirtualBox 4.0.2 r69518 が先週登場していたようです。 気付いたのが一昨日の真夜中でしたので， 昨日ダウンロードとインストールを行いました。 (^^;)

　さて， 巷的に一番気になる部分は「ICH9 化を行っている Windows 7 ゲスト等で VirtualBox Guest Additions を使うと起動時にブルーサンダーが発生する」の不具合でしょう。 あ， 環境によっては VM がクラッシュするなど微妙に症状は異なっているかもしれません。 製品版で仕込んだという辺りが何だかなぁ…というバグです。

それはともかく， 件の不具合は 4.0.2 では解消されているようです。 が， β4 までとチップセットの認識状況が異なっているような…。 有効化できないのに比べれば遙かにマシですので， 気にしないこととしましょう。 (笑)

　一方， コンシューマー的には「こちらのほうが遙かに問題」と言えそうな， Direct3D での画面初期化失敗の不具合ですが…， こちらは何も変わっていませんでした。 といいますか， Direct3D 自体で言えば悪化しています。 今回の版ではサウンドのブツ切れ現象が発生しますので。

どうやら 4.0.x では Direct3D の更新は たとえバグフィックスであっても行われないようですね。 それどころか 4.x でも行われるかどうか…。 とはいうものの VirtualBox 3.0 から対応化を行っているわけですから， 4.x で 3DMark05 辺りが普通に動作する程度へ もっていかないと， 「技術力がない」と巷から見なされてしまいそうです。

個人的には 4.x の段階で 3DMark05 が動作しないなら， 5.0 以降での Aero 対応も無理だと思っています。 対応するにしても 5 年後？ 　PC エミュレーターに お金を掛けたくない向きには辛い状況ですね。 そこが有料と無料の違いとも言えそうですけれど…。(^^;;

　ともあれ， ICH9 化を行っている若しくは行いたいのであれば， アップデートしておいて損はないような気がします。 ただ， VirtualBox なので保険は掛けた上で行いましょう。 ただ， 意味があるのかどうかは微妙ですけれどね。 PIIX3 設定でも SATA や USB 2.0， HD Audio は使えますので…。 体感速度も変わりませんので， 違いは CPU 型番の認識が行われないくらいかしら？

マイクロソフト セキュリティ アドバイザリ (2269637) さらに その後...

　8 月下旬に大々的に宣伝され， 拙作 LHMelt を含め多数のソフトウェアが該当した「安全でないライブラリのロードにより、リモートでコードが実行される」 (マイクロソフト セキュリティ アドバイザリ (2269637)) の脆弱性ですが， 半年以上経った今でも ちょこちょこと脆弱性情報が載っています。

ここまで来ると残っているのは「『自身には関係ない』と高を括っていた」か「チェックはしたけれど し切れない箇所が残っていた」かの どちらかなのでしょうね。 きっと年単位で散発的に該当ソフトが登場するのでしょう。 はっきり言って他人事ではありません。 (^^;)

いや， お願いですから次の Windows では「端からダメ」という仕様にしてください。 訳の分からない下手な小細工設定を付加しないで…。

『LHA の脆弱性』その後 (6)...

　『LZH 書庫のヘッダー処理における脆弱性について (2010 年版)』 (MHVI#20100425) の その後の状況ですが， 何度か書いているとおり何も変わっていません。 対応を開始したベンダーもありますが， ほぼ全ての自社製品が該当している上に， 昨今ではエンジンが共通化されている傾向のあることから， 簡単にエンジンを更新できない状況となっています。 何しろ， デバッグ対象の製品や範囲が広大ですので。

結果， エンジン自体での対応を終えているベンダーであっても， 対応エンジンの一般公開は行われていないのが実情です。 コンシューマー向けはともかく， 業務用ソフトを使用しているのであれば， 窓口へ問い合わせてみるのも手かもしれません。

　それはともかく， 未だに誤った認識や対応の行われているケースが散見されるようです。 もっとも どこからも正式情報が発信されていないわけですから， 仕方のない話ですけれど。 せめて， 一部の製品については対応可能である旨くらい告知すれば良いのですけれどね。 ＞対応着手済ベンダー

　で， まず 1 点目。 LZH 書庫に脆弱性があるのではありません。 あくまでも対応ソフト側が書庫を正しく扱っていないだけです。 件の問題を「LZH 書庫の脆弱性」と言うのであれば， 現状出回っている ほぼ全ての書庫形式に同じ脆弱性が存在します。 (^^;) 　ちなみに一連のタイトルは， プログラムソースの出所という意味で「LZH 書庫の～」ではなくて「LHA の～」になっています…。

　次に 2 点目。 爆弾を投下した本人が言うのも何ですが， 「必ず LZH 書庫から ZIP を始めとした他形式書庫へ移行しないといけない訳ではありません。」 　巷では徐々に移行が進んでいるようですので， その流れに乗って「これを機会に」といったケースであれば もちろん構わないわけですが…。

件の問題は「LZH 書庫への対応を謳っていて検疫も行われていると思っていたら， 実はすり抜けが発生していた」という点にある訳ですが， 巷でも言及されているように「検疫されない」という点では未対応形式の書庫や暗号化された書庫と何も変わりませんし， 対策ソフトが検疫できないウイルス等が仕込まれていれば それまでです。

最後のケースはともかく， オンデマンド系の機能を有するクライアント型の対策ソフトがインストールされていれば， 少なくともファイルが展開された時点で検疫に引っ掛かります。 なので， 多くの環境では気にするほどの問題とはならないはずです。

危険なのは ISP のサービス (ISP のサーバー) やゲートウェイでの機能のみに頼っているケースです。 要は自身のネットワークや PC へ辿り着くまでの途中経路のみで検疫を行うパターンですね。 この場合は一旦すり抜けてしまえば終わりですし， 今回の問題は「既に対応しているウイルスだろうが何だろうが すり抜け可能」という点にあるのですから。

で， ゲートウェイ等だけに頼っているわけでもなく， ましてや外部と書庫を やり取りするわけでもない， しかも今回の脆弱性の存在しない (攻撃書庫を扱わないようになっている) 内部のみで完結しているシステムを利用している状況で， 何故移行が必要なのかしら？ 　あ，上述の「これを機会に」は別ですよ， 念のため。

特に移行を急ぐ必要もなく問題も発生する恐れはない…といった状況であれば， 無理をして数百万単位 (開発し直すとなれば最低でもそれくらいの金額にはなるでしょう。) の資金を投入して移行する必要はないと思うのですけれど…？

iPhone 5 と iPad 2...

　定期イベント…といいますか， iPhone 5 と iPad 2 が 6 月に登場するようです。 さすがに 1 月ということは無かったようですね。 それはともかく， 新型 CPU である A5 採用に伴って どれくらい動作が速くなるのか興味のあるところです。 iPhone 5 についてはデザインも刷新されますが， それが悪い方向への UI 変更へ繋がらないことを祈りたいところです。 いえ， Apple は たまに やらかしますから…「既存ユーザーを無視して我が道を行く」を。 (笑)

しかし…。 また筐体が変わるとなると…「毎回小物を買わせる」ことにしたのかしら？ 　まさか周辺機器等まで何もかも更新が必要…ということは無いでしょうけれど。 どちらにしろ， 私は先月 iPhone 4 を年貢方式で買ったばかりですし， 特に不満も無く使えていますので， iPhone 5 はスルーですけれど。

　一方の iPad 2 ですが， 何やら大きいもの (要は iPad と同じサイズ。) や小さいものが出るらしいのですが， それよりも解像度が 2048x1536 へ引き上げられる点を個人的には歓迎したいですね。 これなら iPad と同じサイズでも許せます。 iPhone 4 と同じような感じでフォントが表示されると有り難いですし， 「iPad の大きさで iPhone 4 と殆ど同じ解像度」というのが iPad へ堕ちなかった最大の理由でしたから。

iPad と同じサイズのもので UXGA+， 小さいほう (iPhone 4 と iPad の中間サイズとした場合。) で SXGA+ 辺りの解像度といったところでしょうか？ 　いくら何でも小さいほうで UXGA+ は…細かすぎます。 いえ， 拡大すれば良いので やってもらっても構いませんけれど。 とはいうものの…， ここまで解像度が上がるとシングルウインドウだと勿体ない気がします。 (^^;)

　う～ん。 評判にも因りますけれど， iPad 2 には堕ちるような気がします。 ただし， 必要なのは解像度であって iPhone 4 以上に限定された使用法になるでしょうから， MacBook Air 同様， 最廉価品の WiFi オンリーモデルを選択することになると思います。 要は「お試しモード + α」ですね。 それにより WILLCOM D4 辺りの出番は完全に無くなることでしょう。 WILLCOM 03 は…iPhone 4 がトラブった場合の予備機として生き残るかしら？

　あ， 「あくまでも SONY VAIO type P VGN-P91S も持っていて鞄の中に常駐」しているユーザーとしてですので， 念のため。 一般的な視点からは逸脱していますので注意。 同様に「au 携帯を使用。 その他を電話機として使用することは皆無」ですので。 (^^;) 　ついでに， VAIO には WILLCOM CORE 3G (FOMA SIM) を仕込んであって， 自宅以外での回線は E-MOBILE Pocket WiFi (D25HW) を使用しています。 はっきり言って普通ではないです。 (笑)

2010 年末のプロケア 10...

　すっかり忘れていましたので今更クリスマスの話なのですが…， 25 日にプロケア 10 を受けるためにディーラーへ行ってきました。 毎度のフロントウインドウ撥水コーティングとガソリン添加剤…だけなら安く済んだのですが， 夏前にスルーしていたナビデーターの定期更新も行いましたので， ¥32k.- 也でした。 たまたまですが夏にスルーしたのが良い方向へ働いたようで， 自宅から 5km 圏内の比較的新しく出来た道路が反映されていた点はラッキーでした。 [一覧]

いえ， 別に更新するつもりはなかったのですが， 25 日当日まで更新費用が安かったものですから。 普通なら それだけでは更新しないのでしょうけれど， 元々夏に更新する予定でしたから…。

　余談ですが， ここ半年ほど YERA のデーター更新を全くやっていませんので， 次回は契約更新する必要が無さそうですね。 やはり， 自身の活動範囲内で変化が見られないとダメのようです。 「どうせ変化は無いから…」と更新が おざなりに。 (^^;)

年末年始の MacBook Air...

　「使うときは使うけれど使わないときは全く使わない」というセカンドマシン以下の宿命といいますか， 11 月に買った MacBook Air をクリスマス前から全く使っていませんでした。 Mac OS X v10.6.6 へのパッチ当てが無ければ…さらに いつまで放置されていたことか…。 (笑) 　外出時に PC を持ち歩かなければいけない状況は有りませんでしたし， 職場では鞄の中に SONY VAIO type P VGN-P91S を入れていますから…。

Parallels Desktop 6 for Mac 方面が必要なければ， iPad のほうが総合的には便利で使用頻度は上がっていたかもしれませんね…， たとえ iPhone 4 を持っていたとしても。

　そういえば Mac App Store が開始されましたが， iPhone 向け App Store と全く同じような感じだと少々嫌かも…。 いえ， たまに App Store (といいますか iTunes。) がデーターを吹っ飛ばしてくれますので。 iPhone の場合は母艦でバックアップしているわけですが (ぶっちゃけ別フォルダーへ丸ごとコピーとか。)， こちらは母艦そのものですから…。

UNLHA32.DLL の登場経緯と LZH の拡張子...

　LHA が登場してから 20 年以上， UNLHA32.DLL でさえ 16 年経過しているわけですが， 今でも時々「統合アーカイバ・プロジェクト」の成り立ちや LZH の拡張子についての質問メールが飛んできます。 この辺りについては拙作 LHMelt のヘルプに余談として載せてあるのですが， 「それを見ろ」というのも何ですし毎回説明するのもアレですので， これを機会に ここへ載せておくことにしました (笑)：

64 ビット版 DLL， 2011 年の展望...

　開発のタイミングを失ったまま放置…基っ， 手が着けられていない UNLHA32.DLL の 64 ビット版ですが， そうこうしている間に年が明けて 2011 年となってしまいました。 今月末にはメインマシンが 64 ビット機へ更新されることですし， 自身の環境的にも 64 ビット版が必要となってくるわけですが， さて どうしたものか…。

放置の最大要因とも言える例の脆弱性については， 状況が全く変わっていません。 対処すべく手を着けているベンダーも複数存在しますが， どこも非公式な対応しか行っていませんので， 巷的には「対応していない」のと同義です。 あ， ここでいう「非公式」とは， 「一般的なアップグレードやパッチとして提供されていない」の意味です。 半年以上経ち新製品も登場した状況で こうなのですから， 今後も同じなのでしょうね， きっと…。

　とはいうものの， UNLHA32.DLL 自体は対応しているわけですので， それを使うユーザー的には ある意味「どうでも良い問題」では有ります。 (^^;) 　Twitter でも呟きましたが， 状況に関係なく今年の上半期中には 64 ビット版を出すことになると思います， 主に自身の環境における必要性的に。 (^^;) 　一部お約束している方面もありますし…。

出すのは良いとして， その場合は「UNLHA64.DLL」ではなくて「UNLHA32.DLL for x64」になると思います。 要は UNLHA32.DLL の 64 ビット整数を扱う API のみで構成された 64 ビット版 DLL ですね。 業務方面については， 「そのまま 64 ビット化」というケースが意外と多いので， 下手に仕様が変わるより そのままのほうが都合が良くて， そういった要望も多いのでした。 ＞「そのまま 64 ビットにしたものもお願い」リクエスト

　現行の仕様のまま UNLHA64.DLL を出す気はありません。 機会があれば MICLHA32.DLL の後継として 64 ビット版を出すことが有るかもしれませんが， 恐らく出すことはないでしょう。 余生を過ごす段階となった LZH 書庫ですし， 複数形式に対応した内部実装型へ流れつつある現状では， 低レベル API なんて必要ないでしょうから。 まぁ， 「低レベル API を使用して UNLHA32.DLL を構成し直す」なんてのは， 個人的お遊びとしては面白いので， そちらは ちまちま弄り続けるとは思いますけれど…。 ＞MICLHA32.DLL

　お遊びとしては， 「Info-Zip その他の API も組み込む」というのも面白いのですが， 海の向こうは頻繁に仕様の変わってしまう点が激しく難点。 「対応アプリ側も含めて特定版の組み合わせでしか使えない」なんてのは， 御免被りたいところです。 もちろん， 旧 API のままに留めておくという手もあるわけですが， 本家のほうがコロコロ変わるわけですから， 追随しないことには その方面の API を用意する意味がありませんし…。 あ， だめだ。 とてもでは有りませんが， 業務用としては使えそうに有りません。 (笑)

　余談ですが， 自身は ここ数年 LZH 書庫と 7z 書庫しか使っていません。 何だかんだで ZIP 書庫は文字コードで引っかかるケースが意外と多いですし， 普段は LZH 書庫を使っています。 で， 「更新等を行わなくなった且つサイズが気になる」といった場合に 7z 書庫を利用しています。 ぶっちゃけ「全部 7z 書庫にお任せ」でも良いのですが， ちょっとしたことなのですが， 処理時間が気になってしまいますので。 ＞100MB 程度でも結構気になる (笑)

その 7z 書庫ですが， 「何も考えず LZMA で圧縮」状態です。 LZH 書庫に比べれば遙かに圧縮率が高いですから， ヘッダーくらいは圧縮しますがソリッド書庫も全く使いません。 それで十分です。

大晦日の悲劇 (CD 編)...

　昨年のゴールデンウイークに行えなかった「マーラー全交響曲耐久連続視聴」を大晦日から正月に掛けて行っていたのですが， 年明けまであと僅かという時に悲劇は起きました。 あ， 大層なネーミングを行っていますが， 要はマーラーの交響曲の範疇に入りそうな曲を， 『嘆きの歌』から『交響曲第 10 番』 (全曲版) まで ぶっ通しで聴くという単純作業のことです。 (笑)

　6 番まで聴き終わり， 「さて 7 番を…」と CD を取り出そうとしたところ， 保護用のクッションが くっついたまま CD がケースから外れていました。 たまにある話ですので， ここまでなら何の問題もなかったのです。 が， そのクッションを外しに掛かったところ…レーベル面保護シールが くっついてきました。 いえ， ここまでなら良かったのです…ここまでならば。

右の画像を見れば一目瞭然ですが， その保護シールにくっついて， 1/4 ほどの領域の印刷層から記録・反射層までもが剥がれてしまったのです。 「レーベル面保護シールが， そのレーベルどころか樹脂層以外根こそぎ破壊してどうする!!」と思わず目が点になりました。 (大爆笑) 　さすが 30 年近く経った CD だけある…といいますか， このようなことも有るのですね。 記録層まで 1/100 mm しかないってのは， CD 最大の仕様的欠陥だと思いますです。 (^^;)

　ちなみに， 今回不幸にも犠牲者となったのは『マーラー 交響曲第 7 番 ホ短調』 (クラウディオ・アバド/シカゴ交響楽団) です。 アバド旧録音のマーラー全集のやつですね。 今となっては このオリジナルの CD としての入手は不可能です。 国内なら中古で ¥15k とかしますし， 海外でも新品で似たような価格です。

幸い， 国内では無理ですが海外では復刻版が出ていますので， そちらを発注していたりします。 昔は無理だったのが今では 1 枚に収まっていますので， 地味に有り難いですね。 ＞グラモフォン

　余談ですが， 今回の耐久視聴は随分時間が掛かってしまいました。 大晦日の 11 時過ぎに始めたのですが， 昼食・夕食 (年越しそば) 等は もちろん， 上述の顛末を Twitter や TwitPic で呟いたりもしていましたので， 終わったのは年が明けて朝は 6 時半でした。 年末年始の番組は根こそぎスルーです。 (笑)

聴いた面々は以下のとおり：

• 嘆きの歌：シノーポリ/フィルハーモニア管弦楽団。 オリジナル 3 楽章のやつです。
• 交響曲第 1 番 ニ長調：アバド/シカゴ交響楽団
• 交響曲第 2 番 ハ短調：アバド/シカゴ交響楽団。 初めて買ったレコードがこれだったり。 (笑)
• 交響曲第 3 番 ニ短調：アバド/ウイーン・フィルハーモニー管弦楽団。 今でも「世界最長の交響曲」としてギネス・ブックに載っているのかしら？ 　『銀英伝』組には第 1 楽章がおなじみ。 (^^;)
• 交響曲第 4 番 ト長調：ショルティ/アムステルダムコンセルトヘボウ管弦楽団
• 交響曲第 5 番 嬰ハ短調：マゼール/ウイーン・フィルハーモニー管弦楽団。 この面々のライヴが当時のクラシックアワーで流れたのが， マーラー真理教入信のきっかけとなった最有力候補。 第 4 楽章の Adagio は映画や番組で良く使われます。
• 交響曲第 6 番 イ短調：ショルティ/シカゴ交響楽団
• 交響曲第 7 番 ホ短調：アバド/シカゴ交響楽団。 上述のとおり お亡くなりになりました。 (笑)
• 交響曲第 7 番 ホ短調：アバド/ベルリン・フィルハーモニー管弦楽団。 旧録がお亡くなりになったので， 新録に御登場願いました。
• 交響曲第 8 番 変ホ長調：ショルティ/シカゴ交響楽団。 『ハルヒ』 1 期の 6 話は これの第 1 部。 (ラトル/バーミンガムシティ響。)
• 大地の歌：ショルティ/シカゴ交響楽団
• 交響曲第 9 番 ニ長調：アバド/ウイーン・フィルハーモニー管弦楽団
• 交響曲第 10 番 嬰ヘ長調 (マゼッティ版)：スラットキン/セントルイス交響楽団。 各版持っていますが， 今回はマゼッティ版に登場願いました。

殆どが 20 年以上前に揃えたものですので， 旧録ばかりですね。 あ， 新録も持っています。 こうしてみると「基本アバド」なのかしら？ 　しかも 2 極化が進んで…バーンスタインやカラヤン， etc も持っているのに…。 (笑)