MDR-CD900STで確実に使える変換プラグを紹介します。


ソニーのヘッドフォン「MDR-CD900ST」は本来業務用として開発されたヘッドフォンですが、その音質の高さや解像度の高さからiPod等で音楽をより楽しむ目的でも利用する方が近頃増えています。

ところがiPodなどの機器で使用しようと思った時に、一番のボトルネックになるのはプラグの大きさの違いではないでしょうか。本来なら変換プラグを使えばそのような問題はすぐに解決するのですが、MDR-CD900STの場合はすこし厄介です。

IMG_3333.jpg

ご存じの通り、iPod等のポータブルオーディオプレイヤーを始め、我々の身の回りにはステレオミニプラグを搭載した製品が溢れています。対してMDR-CD900STは業務用故にケーブルの先には標準プラグしか付いておらず、また製品パッケージには変換プラグの類は一切付属しません。

IMG_5169.jpg

そこで、当然のことながらiPod等の機器でMDR-CD900STを使おうとする場合には変換プラグを別途購入する必要があるのですが、実はこれには鬼門があります。それは変換プラグとMDR-CD900STの相性です。

「MDR-CD900STの片方の音が聞こえません!!!」というトラブルの原因の多くは変換プラグの相性です。

不思議なことに、他のヘッドフォンでは何の問題もなく使える変換プラグが、MDR-CD900STでは上手く使えないことが多々あります。そして多くの場合、相性の悪い変換プラグを用いると片方の音が聞こえなくなります。通常、ステレオプラグをモノラルジャックに差すとこのような現象が起きることがありますが、「ステレオ→ステレオ」の変換プラグでもこの現象が起きてしまうのです。私はこれで実際に数本の変換プラグを無駄買いしてしまいました。

そこで、本記事ではMDR-CD900STで確実に使える変換プラグを紹介したいと思います。

ズバリMDR-CD900STで確実に使える変換プラグはVictorから出ているAP-233Aという製品(写真左)です。このほかに、iPod touchをケースに入れて使う場合には、CN-M30-Bという延長ケーブル(写真右)があるとなおベターです。

IMGP1256.jpg

なぜ延長ケーブルがあるとベターなのか

 私はiPod touchをケースに入れて使っていますが、ケースによってはジャック周辺に設けられた穴の口径が小さく、微妙に邪魔になってしまい変換プラグが奥まできっちりと刺さりません。そこで、変換プラグとは別にプラグの根本が細い延長ケーブルが必要になります。

変換プラグのみでは奥まで刺さらない。

IMG_5162.jpg

 というわけで、変換プラグと延長ケーブルを両方組み合わせて使うと下の写真のようにうまく収ります。(ケースは赤いやつから透明な物に変えました。すみません)

IMGP1630.jpg

私は普段はこの方法でiPodを利用しています。さすがに外にiPodを持って行って音楽を聴く場合には付属のイヤホンで我慢しておりますが・・・。

ただし、この方法にもデメリットがあり、変換プラグの本体が微妙に邪魔で持ち運ぶ際に結構鬱陶しいということです。そこでMDR-CD900STをiPodメインで使いたい場合には思い切ってプラグを取り替えるという手もあります。(MDR-CD900STは業務用なのでイヤーパッドからドライバーユニット、プラグに至るまで補修部品を自分で取り替えられるようになっており、中には標準プラグからステレオミニプラグに取り替えてしまう人もいるようです)

まとめ

iPodでMDR-CD900STを使うには若干手間がかかりますが、一度この音に慣れてしまうと他のヘッドフォンには行けなくなります。解像度の高さ故から聞きたくない音まで聞こえてきてしまうという欠点はありますが(その辺のレビューは以前書いた記事をご覧下さい)

ちなみに私は、MDR-CD900STではMP3やAACの音質劣化が目立ってしまって気になるので、お気に入りのCDはすべてApple Losslessでエンコードし直しました。(流石に容量の関係から全部のCDというわけにはいきませんでした)

しかし、MSXは死に絶えてはいなかった!


 ネットをブラブラ見ていたら、MSXパソコンの組み立てキットなるものを発見しました。
しかも、MSXというから古い商品かと思いきや現役の商品だそうです。

https://www.offshore-ww.com/gr8bit-top.html

 MSXとは1983年にマイクロソフトとアスキーにより提唱された8ビットパソコンの規格で、当時ソニーや松下、三菱、日立などからMSX規格のパソコンが発売されていました。

 実は私がコンピュータと出会い、プログラミングにハマるきっかけとなったのがサンヨーのMSX2+で、走査線割り込みからプリンタポートによるMIDI演奏まで、出来ることはやり尽くしました。私がMSXと出会っていなかったら今現在こうしてコンピュータでプログラムを作ったり音楽を作ったりはしていなかったでしょう。

 ただ、心残りなのは、私が当時プログラム雑誌(ベーマガやMSX-FAN)に投稿したプログラムが何一つ採用されなかったことです。無念。

 ちなみに、15年ほど前、私はとある同人ソフトサークルに所属しており、こちらのページでいくつも紹介されているMSXの同人ソフトのとある作品(3つぐらい)の開発(音楽と自分のコーナーのプログラム)に携わりました。実は今もそのディスクを所有しているのですが、今改めて見てみると中二病全快で・・・恥ずかしい・・・。

さて、このキット、GR8BITという商品だそうで、ロシア人による開発だそうです。

 このように箱を開けると、必要な部品がバラバラに入っており、自分で半田付けなどを行って組み立てるキットになっています。

gr8box_open.jpg

 そしてこれがメインボード。CPUは載っていません。しかしこのメインボードはATX規格になっており、ATX電源コネクタまで搭載しています。
gr8bit_main_board.jpg
そして、こちらがCPU基盤。これをメインボードに差して使うようです。Z80が載っています。
gr8bit_cpu_board.jpg
 こちらはVDPが載っているボード。V9938というVDPチップが載っています。今のパソコンでいうビデオカードに相当するボードですが、能力的には天と地以上の差があります。
gr8bit_video_board.jpg
各種基盤を組み立ててATXケースに組み込んだ所。
gr8bit_proto.jpg
ちゃんとMSXのゲーム(メタルギア)が動いています。すごい!
gr8bit_metal_gear.jpg
気になるお値段は、4万2500円! 今の時代で考えると高いですね・・・。
詳細なスペックはhttps://www.offshore-ww.com/gr8bit-2.htmlに掲載されています。

Dynabook UX/23のBIOSをダウングレードする方法


今回のエントリは、Dynabook UX/23のBIOSをアップグレードしたところスタンバイ・休止状態に不具合が発生し、結局元に戻すことになってしまった時の記録です。

dynabookux23.jpg

はじめに

このエントリは以下の条件に当てはまる方を対象としています。
それ以外の方はこのエントリを読むだけにとどめておいて下さい。BIOSの更新はマシンを再起不能にするリスクを伴います。

  • Dynabook UX/23(PAUX23JNLBL)を使っている。
  • OSはプリインストールされているWindows XP Home Editionから変更していない。
  • アップグレードしてしまったBIOSを元に戻したい。

なお、BIOSの更新失敗による損害についての責任は負いかねます。


きっかけ

 先日のことです。

何気なく東芝のサポートサイトを見ていたら、Dynabook UX/23のBIOSが密かにアップデートされていることに気づきました。
入手してから一回もBIOSの更新を行っておらず、かといって特に不具合も無かったにもかかわらず、ただ単純に新しもの好きの性格が災いして、新しいBIOSを入手しアップグレードしました。

元々のBIOSのバージョンは1.20。これを2.00にアップグレードしました。

スタンバイ・休止状態への移行ができなくなった!

ところが、BIOSを2.00にアップグレードしてからスタンバイ・休止状態への移行ともに100%失敗するようになってしまったのです。具体的には「スタンバイの準備をしています」の画面で止まったままになってしまうのです。

「これはイカン! すぐに元に戻さないと!」と思った時にはもう手遅れでした。
東芝のサイトには古いBIOSのダウンロードリンクさえ用意されていませんでした。

古いBIOSの入手方法

こういう時に頼りになるのが海外サイト。毎回思うのですが海外のコンピュータ系のサイトは日本のサイトと比較して情報量が圧倒的に多く、役に立ちます。

Dynabook UXは海外では「NB200」という名称で知られています。
そこで、「NB200 BIOS」あたりをキーワードにサイトを探していましたところ、以下のサイトを発見し、無事古いバージョンのBIOSを探すことが出来ました。

https://www.notebook-driver.com/toshiba/toshiba-mini-notebook-nb200-windows-drivers/

ダウンロードしたBIOSはインストーラ形式になっており、このインストーラを起動するとWindowsの一時ディレクトリ(XPの場合、C:WindowsTEMPが多い)にWinPhlashというユーティリティと共にBIOSが展開され、そこからWinPhlashが起動するようになっています。

BIOSのダウングレードができない

ところが、いざBIOSの書き換えを行おうとすると「既に新しいBIOS(2.00)が入っているから古いBIOSには書き換えられない」との警告が出て終了してしまいます。

WinPhlashの設定を書き換えてみる。

実は、後に色々試行錯誤していてわかったのですが、WinPhlashの設定を書き換えるだけで無事に古いBIOSにダウングレードすることができましたのでその方法を書きたいと思います。

まずはWinPhlashが展開されたフォルダを探します。
WinPhlashのフォルダは大抵のケースではWindowsの一時ディレクトリに展開されます。(C:WindowsTemp)

winphlash_directory.png

WinPhlashが展開されたフォルダにある「WinPhlash.ini」を開きます。
次に、Advanced = 0;と書かれている部分を、Advanced = 1;に書き換え、そのまま上書き保存します。

Editing_Winphlash_Ini.png

WinPhlash.iniを保存後、改めてWinPhlash.exeを起動するとウィンドウに「Advanced」というボタンが現れます。

Advanced_Setting.png

このボタンをクリックすると表示されるオプションの中の「Flash only if BIOS version is newer than system」という項目のチェックボックスをオフにします。

Advanced_Options.png

この状態で改めてBIOSの書き換えを行うと古いバージョンでも書き込むことができます。

BIOSの書き換えが終了するとコンピュータが再起動します。私の所ではシャットダウン中にフリーズしてしまいましたが、電源ボタン長押しで一度電源を切り、改めて電源を入れ直したところ無事起動しました。

Dynabook UXは素晴らしいプロダクトだと思う。

私は普段はメインマシンにデスクトップを使っているのですが、静かな場所で物書きやちょっとしたプログラミングをしたいとき、また、市内のリハーサルスタジオでボーカルやギターの録音を行うときにこのDynabook UXを持って行っています。

CPUがAtomでDAWなんかできるの!? と思うかもしれませんが、あらかじめ自宅のMacでミックスダウンした伴奏の上にギターやボーカルを録音する程度の処理ならわりと普通にこなせます。

また、バッテリーが意外とタフで、入手してから相当使い込んだはずなのにまだ2時間程度は持ちますし(カタログ公称値は4時間。6セルバッテリを使えば10時間)、キーボードの感触も打ちやすくて好きです。

現在はタブレットが徐々に主流になりつつあり、ネットブックの出番はなくなりつつありますが、それでも

  • 10インチ程度の画面を持ち、
  • Windowsのアプリケーションが動き、
  • キーボードがついている
  • 重量もそれほど重くない

等、メリットは大きいです。

ただし、ネットブックなだけあって画面解像度が1024×600ピクセルと狭く、多くのウェブサイトを閲覧する場合にはスクロールを多用しなければなりませんし、実のところDAWソフトを使うのにも画面は狭いです。その辺はポータビリティと性能のトレードオフといったところでしょう。

私的にはネットブックに(キーボードが付いたまま)タッチパネルが付いたら最強なんじゃないかと思います。


 

マザーボード修理 ~DELL Precision Workstation 650~


 今回のご依頼は、DELLのハイエンドワークステーション「Precision Workstation 650」のマザーボードのコンデンサの交換です。この機種は2004年発売の機種で、Xeon CPUをデュアルで搭載するハイスペックマシンです。

 ハイエンドワークステーションだけあって、コンデンサの搭載量も多く、またマザーボードも大きいです。

依頼者様曰く「PC自体はここ一年、徐々に立ち上がりづらくなりました。現在は電源を入れてもBIOS表示されない状況です。MACアドレスの関係でM/B交換はできない状況ですのでコンデンサ交換をして頂けると非常に助かります。」とのことでご依頼を頂きました。

今回交換するコンデンサは以下の38本になります。

赤:6.3V 2200μF φ10 緑:6.3V 1800μF φ10 水色:16V 1800μF φ10 黄色:6.3V 1500μF φ10 紫:6.3V 820μF φ8

IMGP1247.jpg

 漏れているのは主にニチコンのHMです。コンデンサのスリーブの刻印を見てみますと2002年製造だということがわかります。この時期のニチコンHMはとにかく漏れやすく、私の所へ来る依頼のうちDELLのマシンでは例外なく漏れているコンデンサの一つです。

IMGP1248.jpg

日本ケミコンKZGも早期に漏れやすいコンデンサの一つ。こちらももちろん交換対象にします。

IMGP1249.jpg

 CPU周辺に多数あるコンデンサ。電力消費量が多いXeonを2基搭載しているだけあって、コンデンサの数もそれなりに多いですが、こちらは主にルビコンのMBZが使用されており、液漏れは見られませんでした。しかし、負荷がかかる部位であることと使用年数なども考慮してこちらも交換対象にします。

IMGP1251.jpg

まずはじめに、液漏れを起こしていたニチコンHMの軍団をすべてサンヨーWGへ交換。

IMGP1257.jpg

 CPUスロット1周辺の17本を交換。実は奥に見えるヒートシンクの下に3本コンデンサがあるのですが、ヒートシンクの取り外しが基本的に行えないため、こちらの交換は非常に手間が掛かりました。

IMGP1258.jpg

CPUスロット2付近の6箇所。こちらもサンヨーWGへと交換。

IMGP1261.jpg

チップセット付近、5本。依頼者様のご希望により予防処置として膨らんでいないコンデンサも含め交換しました。

IMGP1263.jpg

最後にメモリスロット側の2本を交換して完了です。

IMGP1268.jpg

 本マザーボードは12月11日を以て依頼者様の元へと返送され、動作確認をお願いしたところ、正常に動作している様子の写真を送って頂きました。

IMG_9937.jpg

OS X Lionで無理矢理XV Editorが動かせるか挑戦してみた。


 私は現在音楽製作とXcodeの勉強用にMacを所持しているのですが、2011年11月現在未だにOSはSnow Leopardです。

 というのも、私がローランドのXV-5050というシンセサイザの音色エディットに使っているXV EditorというプログラムがOS X Lionでは今現在サポートされていないため、アップグレードしたくでも出来ないのです。今回はこの動かないXV EditorをなんとかLionで動かせないかと試行錯誤してみた末の失敗記録です。

OS X LionでXV Editorが動作しないたった一つの理由

 ご存じの通り、OS X LionではRosettaが切り捨てられました。
Rosettaとは、Power PCコードで構成された従来のMac OS XアプリケーションをIntel CPU上で動作させるための機構なのですが、ローランドのXV EditorもPower PCコードで構成された古いアプリケーションの一つなのです。

 つまり、RosettaをサポートしないOS X Lionではどう頑張ってもXV Editorは動かせないのです。

古いOSを入れたくても入れられないのがMac

 実はMacには大きな罠があり、あるモデルにプリインストールされているOSよりも古いOSにはダウングレードできません。
例えばOS X Lionがインストールされて出荷されているMacに以前のバージョンのSnow Leopardをインストールしようとしても出来ません。無理矢理インストールしようとしても弾かれます。

 つまり私が将来的にMacを新調した場合、その時期に登場したOSより古い物はインストールできず、つまりはSnow Leopardもインストールできない、ということになります。

 ということは、動作にSnow Leopardが必要なXV Editorはこのままでは新しいMacでは動かせないと言うことになります。

ならば、無理矢理動かしてみよう。

 私の脳内の声:「Rosettaは廃止されたけど、エミュレータの選択肢は他にもあるよね。ほら、Windowsアプリを他プラットフォームで動かすWineとか」

 というわけで、何もMac用のXV EditorにこだわらなくてもWindows用があるじゃないか、と気づいたためさっそく検証開始です。

 ※私はOS X Lionを所持していないため、実際には「Rosettaが無い」という環境を想定してSnow Loopardで実験を行いました。

WineBottlerという選択肢

 WineBottlerとは、Wineをベースに設定や環境構築をより簡単にしたパッケージで、これを使うとWindows用のアプリケーションを一発でMac用のアプリケーションに変換できるという素晴らしいツールです。実際にWindows用のInternet Explorer等がまるでMacのアプリケーションであるかのように動きます。

 今回はこれを利用してWindows用のXV Editorを無理矢理Mac用に変換してみました。

左のアイコンがWineBottler、そして右のアイコンが実際にWindows用のXV EditorをMac用に変換してみたもの。

winebottler.png

動くことは動いたのだが

 早速WineBottlerを使ってMac用に変換したXV Editorを立ち上げてみます。

xveditor_launching.png

 ところが、起動してしばらくすると「XV-5050との接続を確認できない」とのエラーを告げるダイアログが表示されます。
このソフトはコンピュータとXV-5050の間でMIDIを使い双方向通信を行い、データの同期や機器の接続チェックなどを行っています。従ってXV-5050が接続されているにもかかわらずこのようなエラーが出ると言うことはMIDIの入出力がうまく働いていないということになります。

xveditor_error.png

 ちなみに、画面上の鍵盤をマウスでクリックするとXV-5050から音が出ましたので、どうやらMIDIの出力のほうは上手く動いているようです。

なぜBoot Campでは駄目なのか

 Wineを使ってうまく動かないのであれば、Boot CampでWindowsを動かしてその上でWindows用のXV Editorを動かす方法が一番確実かもしれません。

 しかし、シンセサイザの音色というのは、単体で鳴らした場合と実際に楽曲を流しながら鳴らした場合では同じ音色なのにずいぶんと違った聞こえ方をします。従って、私がいつもシンセサイザの音色を作る場合には同時にシーケンサーを立ち上げて実際に曲を再生しながら作っていきます。単体でエディタのみを走らせる、ということはめったにありません。そして、私が使っているシーケンサーはDigital Performer、これはWindows版が存在しません。つまりいくらBoot Campで確実にXV Editorが動くからといって私のケースでは残念ながら諦めるしかないのです。尤も、Mac用のDigital PerformerをWindows上で無理矢理動かす手段があれば別なのですが。

結局はRolandの対応待ち

 現在Rolandの公式サイトではMac OS X への対応状況というページに同社のハードウェアやソフトウェアのOS X Lionの対応状況が公開されています。わりと頻繁に更新されているようですが今のところXVに関する情報は全く掲載されていません。結局現在の所はRolandの対応を待つしか無いのかもしれません。ただ、XV-5050はかなり古い機器ですのでこのまま対応されずに終ってしまう可能性も否めません。

それでもすごいWineBottlerの可能性

 今回はXV Editorの使用には至りませんでしたが、それでもWineBottlerを使ってWindows用のアプリケーションがMac用に変換され、実際に動いてしまう様は見ていて感動しました。ひょっとしたらXV Editor意外にも有用な音楽用アプリケーションがMacで動作するかもしれませんし、今後いろいろ試してみる価値はありそうです。

 WineBottlerの入手先はこちら → https://winebottler.kronenberg.org/

.NET FrameworkのBeginGetResponseメソッドが実行中のスレッドをブロックしてしまう件


数日前の事ですが、当サイトで公開しているDMMアフィリエイトの商品リンク作成ツールの利用者の方から「今までに比べてリンクの作成に非常に時間がかかるようになった」とのご報告を頂きました。

今までは遅くても数秒以内に作成できていた物が、早くても10秒以上かかるというのです。

こちらではしばらくプログラムの変更は行っていませんでしたので、単にDMMのサーバーが重くなっているのではと考えていましたが実は完全に私のミスでした。

何が原因だったのか

当サイトのDMMアフィリエイトのリンク作成ツールでは、開発言語としてC#が用いられています。つまりは、.NET Frameworkの機能を利用して実装されているということです。

プログラム中では、ユーザーの問い合わせに応じてDMMのサーバーから実際に商品情報と商品パッケージ画像を取得するのですが、この時に.NET FrameworkのBeginGetResponseメソッドを用いています。実はこのメソッドにちょっとした問題がありました。

このメソッドはインターネットリソースの非同期要求を開始するメソッドであり、通常このメソッドが呼ばれた瞬間に、要求の完了・未完を問わずに一瞬で呼び出し元に制御が返ってきます。

ところが、条件によってはBeginGetResponseメソッドから制御が帰らずにスレッドが長時間ブロックされたままになってしまうことがあります。私のツールがリンクの作成に非常に時間がかかるようになったのもこれが原因でした。

どんな条件の時にスレッドがブロックされるのか

例によって、海外サイトを検索していたら次のサイトを発見しました。

webrequest.begingetresponse is taking too much time when the url is invalid
https://stackoverflow.com/questions/1232139/webrequest-begingetresponse-is-taking-too-much-time-when-the-url-is-invalid

要約するとインターネットからのリソースの取得は非同期的に行われるけどDNSの解決なんかは内部で同期的に実行されるから、無効なURLなんかを指定してDNSの解決に失敗したりするとスレッドがその間ブロックされてしまうとのこと。

ところが。
私のプログラムでは無効なURLは指定していませんし、そもそもDMMの商品URLに通常のブラウザからアクセスするとあっという間に結果が表示されます。

しかし、同時にとある事を思い出しました。

実は数日前にApacheの実行ユーザをWindowsサービスのデフォルトユーザから、セキュリティをガチガチに固めた「Apache」というユーザ変更しました。そして改めて検証してみると、Apacheをデフォルトユーザで起動した場合にはリンク作成ツールは今まで通りの速度で動作するのですが、ユーザを「Apache」に変更すると10秒以上の遅延が発生するのです。

ひょっとして、ユーザ「Apache」のインターネット接続設定がおかしいのでは?と思い、ユーザ「Apache」でログオンしていみたところ・・・。

容疑者発見!

internetoption.png

「インターネットオプション」を開いてみたところなぜか「設定を自動的に検出する」というチェックボックスがオンになっていました。物は試しにこのチェックボックスをオフにして再度リンク作成ツールをテストしてみると、見事に遅延は解消されました。犯人はおまえだったのか。

参考までに、なんでこのような現象が起きるのかを調べてみたのですが、マイクロソフトの英語版公式リファレンス によると、こんな記述がありました。

The BeginGetResponse method requires some synchronous setup tasks to complete (DNS resolution, proxy detection, and TCP socket connection, for example) before this method becomes asynchronous. As a result, this method should never be called on a user interface (UI) thread because it might take some time, typically several seconds. 

要約:このメソッドは非同期状態になる前に、いくつかの同期タスク(例えば、DNS解決、プロキシ検出、TCPソケット接続等)を完了する必要があり、場合によってはそれらの同期タスクには数秒を要するため、このメソッドはUIスレッドから呼び出されるべきではありません!

 なお、日本語版のリファレンスには載っていませんでした・・・。


まとめ

 というわけで、どうやらスレッドをブロックしている要因はDNS解
決だけではなく、プロキシ検出なども含まれるため、「設定を自動的に検出する」オプションにチェックが入っているにもかかわらず設定の検出に失敗したり時間を要した場合には、その間スレッドはブロックされてしまうっぽいです。


 ところで、デフォルトでは「設定を自動的に検出する」はオフになるはずなのですが、なぜオンになっていたのでしょうね。

Windows上のApache 2.2.9以降でFastCGIを動かす方法


 Windows上のApacheでFastCGIを動かそうとして少し手こずったので、備忘録的にエントリを書こうと思います。


はじめに

 このエントリは次のような方を対象としています。

  • Windows上でApache 2.2.9以降を使用している。
  • ActivePerlを使用している。
  • Movable Type 5.1を使用している。
  • Movable TypeをFastCGI化して少しでも動作を速くしたい。


Movable Typeが重すぎる

 事のきっかけは、ブログ更新の時に常に感じていた「Movable Typeがあまりにも重い」という事でした。
私がMovable Typeを運用しているサーバはPhenom II X4 945(3.0GHz)で動いており、私のサイトのようなアクセス数が少ない個人サイトの運営にはまったく困らないスペックなのです。

 ところがMovable Typeだけは別でした。画面上の何かしらのアイテムをクリックしてから次の画面が表示されるまでの時間が長いことこの上なく、まさしく「もっさり」という形容詞がふさわしいという動きの遅さでした。そしてこれがブログ更新の際のストレスにもなっていたのです。

 そこで私はネットを検索していろいろと調べた結果、「Movable TypeをFastCGIで動かすと高速化できる」という事を知りました。早速私はMovable Typeの高速化に挑戦することにしたのですが一筋縄ではいきませんでした。


Apache 2.2.9以降では公式のmod_fastcgiが上手く動かないらしい

 まずはじめに私はいくつかのサイトを検索してMovable TypeをFastCGIで動かす具体的な方法を調べました。大まかな手順は以下の通りです。

  1. 公式サイトからmod_fastcgi-2.4.6-AP22.dllを入手してApacheのmodulesフォルダに配置する。
  2. httpd.confを書き換えてMovable TypeがFastCGIで動くように設定する。

 私も当然この手順を試してみたのですがどうにもうまく動いてくれないのです。

 Movable Typeを試しに動かそうとするとInternal Server Errorが表示され、Apacheのログには次のようなエラーが記録されていました。

(OS 109)パイプは終了しました。  : FastCGI: comm with server (中略) aborted: GetOverlappedResult() failed

 ところが私が検索して出てきたサイトやブログの方々は何の問題もなくMovable TypeのFastCGI化に成功しているのです。

 さらに詳しく海外サイトなども調べてみると、どうやら私と同様の問題に悩まされている方が何人かいらっしゃるようで、結局はApache 2.2.9以降では通常の方法で手に入るmod_fastcgi-2.4.6-AP22.dllはうまく動かないと言うことが分かりました。


非公式版mod_fastcgiを使ってみる。
 

 しかし、世の中は広く、mod_fastcgiのソースを独自にビルドしてApache 2.2.9以降に対応したバイナリを配布してくださっている方がいました。何ともありがたい。

 早速そのバイナリを入手して、Apacheのmodulesフォルダにインストールしてみたところ、一発でMovable Typeが起動しました!


というわけで、Windows版Apache 2.2.9以降でFastCGIを動かす手順

  1. CPANからFCGIモジュールとCGI::Fastモジュールを入手してインストールします。
  2. こちらからApache 2.2.9以降向けにビルドされたmod_fastcgiのバイナリをゲットします。x86版とx64版がありますので、自分のOSのプラットフォームに合った物を選択してください。
  3. 入手したmod_fastcgi.soをApacheのmodulesフォルダにインストールします。
  4. httpd.confを書き換えてMovable TypeがFastCGIで動くように設定します。
    設定例

    LoadModule fastcgi_module modules/mod_fastcgi.so

    <IfModule mod_fastcgi.c>
        FastCGIConfig -initial-env PERL5LIB=C:/Perl/lib;C:/Perl/site/lib -autoUpdate -idle-timeout 120 -killInterval 3600 -maxClassProcesses 3 -maxProcesses 15
        AddHandler fastcgi-script .fcgi
    </IfModule>

    <Directory “Movable Typeがインストールされているディレクトリのパス”>
        <IfModule mod_fastcgi.c>
            AllowOverride None
            <FilesMatch “^mt(?:-(?:comments|search|ftsearch|tb|cp))?.cgi$”>
                SetHandler fastcgi-script
            </FilesMatch>
        </IfModule>
    </Directory>

  5. Enjoy!


Movable TypeはFastCGIにより高速化されたのか

 結果から申し上げますと、ハッキリとわかるぐらいに高速化されました。
まず、アイテムをクリックしてから次の画面が現れるまでの反応速度がかなり向上し、ストレスを感じなくなりました。これならブログ更新のモチベーションも保てそうです。
 次に再構築の時間ですが、1分程かかっていたものが44秒まで短縮されました。私のブログは記事数が少ないため再構築にもそれほど時間がかからないのですが、記事数が多いブログを運営されている方はこの差はもっと大きくなるのではないかと思います。

 というわけで、Movable Typeの重さに悩まされている方には、FastCGIは良い高速化手段の一つであると言えます。ただしPerlのプロセスがしばらくの間常駐してメモリを喰い続けるというデメリットもあるわけですが、それでもこれぐらいの速度向上ならばトレードオフといったところでしょう。

マザーボード修理 ~MSI MS-6797~


 今回のご依頼は、MSIのMS-6797というマザーボードのコンデンサの交換です。
依頼者様によりますと、「コンピュータのパーツの入れ替えを行っていたら、突然通電しなくなりコンデンサを見てみたところ茶色いコゲのような物が付着していた。自身でコンデンサの交換を行おうとしたものの、スルーホールに足やハンダが詰まってしまい手も足も出なくなった」とのことでご依頼を頂きました。

今回交換するコンデンサは以下の11箇所になります。

赤:16V 1800μF φ10 緑:6.3V 1800μF φ8

IMGP1223.jpg

 さて、マザーボードをよく見てみますと確かにスルーホールに足が詰まっています。さらに、一見何も詰まっていないように見えるスルーホールにも切れた足の欠片が入っており、これらを取り出すのはなかなか手間が掛かりそうです。
ここは根気よくスルーホールにジョボジョボとハンダを流し込みながら先の細いコテ先でゆっくりと掻き出すようにして足を取り外すことに成功しました。

IMGP1212.jpg

無事、スルーホールの詰まりを解消したマザーボードです。

IMGP1213.jpg

 こちらのコンデンサは膨張・液漏れ共に起こしておりませんが、電源部に使用される負荷のかかるコンデンサということと、依頼者様のコンピュータの使用年数から考えて交換しておいたほうが良いと判断したためこちらも新品に交換することにしました。

IMGP1215.jpg

 問題の液漏れを起こしているコンデンサ。依頼者様があらかじめ取り外した物を(交換用のコンデンサのスペックを確認するために)送って頂きました。2003年製造の物で、寿命を迎えてもおかしくないと思われます。

IMGP1228.jpg

交換に使用するコンデンサはすべてーサンヨーのWGシリーズになります。

IMGP1232.jpg

無事、コンデンサの交換を終えたところ。

IMGP1233.jpg

この後、マザーボードは依頼者様の元へ返送され、無事に起動したとのご報告を頂きました。

マザーボード修理 ~AOpen AX4GER-N 2枚目~


 久々のご依頼です。今回はAOpenのAX4GER-Nになります。
依頼者様によりますと「業務で使用している古い端末がOSが立ち上がった瞬間に電源が落ちてしまう」とのことで、コンデンサ交換のご依頼をいただきました。

交換するコンデンサは以下の19本になります。
緑:16V 2200μF φ12.5 赤:6.3V 3300μF φ10 黄色:6.3V 1000μF φ8 紫:16V 1500μF φ10 水色:16V 680μF φ8 橙:16V 470μF

IMGP1181.jpg

 一番損傷が激しいのはCPU周辺のコンデンサ。コンデンサ上部からの液漏れが激しいです。

IMGP1187.jpg

メモリスロット付近にある3箇所のコンデンサ(緑)こちらはまだ液漏れを起こしていませんが、液漏れを起こしていないコンデンサも予防処置として交換してほしいとのご依頼をいただきましたので併せて交換します。

IMGP1184.jpg

同様に拡張スロット周辺のコンデンサも予防処置として交換します。

IMGP1186.jpg

 CPU周辺電源回路のコンデンサをすべて交換しました。入力側のコンデンサは元々16V 1800μF×2本だったものを若干強化し16V 2200μF×3本(サンヨーWX)に強化し、出力側コンデンサはサンヨーWGを用いました。

IMGP1189.jpg

 メモリスロット周辺のコンデンサは、元々が6.3V 1500μFでしたが、こちらは耐圧16V品のサンヨーWGを使用し、CPU周辺同様に若干の強化を行いました。

IMGP1192.jpg

 その他、拡張スロット周辺のコンデンサに関しましては元のスペックと同様の6.3V 1000μFを使用。こちらもサンヨーのWGです。

IMGP1191.jpg

 無事にコンデンサの交換が完了し、マザーボードは依頼者様の元へ返送されましたが、今回は症状が全く改善されなかったとのご報告を頂きました。おそらくはマザーボード上のMOS-FETが寿命を迎えているか、電源ユニットの寿命の可能性もあります。

今回はご期待に添えず申し訳ございませんでした。

依頼者様からの素敵なお礼の品物が届きました。


 更新が滞ってしまって申し訳ございません。
およそ1ヶ月半ぶりのの更新になります。実はここ1ヶ月ほどコンピュータから離れ、他の方面の勉強などをしていました。
気づいたらすっかり熱中してしまい、こちらのブログを書く事を忘れてしまっていました。

 そんな中、以前ASUS KFN32-D SLIのコンデンサ交換のご依頼を頂いた方から、お礼として素敵な品物が届きました。

 実は以前コンデンサの交換を行ったマザーボードはスタジオでのレコーディングに用いられていた物であり、当然ハイエンドで高価な物であるのですが、実はコンデンサの交換をしても直らなかった場合にはPC自体の買い換えを考えていらっしゃったという事なのです。

 ところが、こちらでコンデンサの交換を行うことによりマザーボードが復活、結果的にはPCの買い換えを行わずにすみ、故にかなり安い費用での復帰が出来たそうで、非常に喜んで頂けたそうです。そしてそのお礼として依頼者様の運営されている音楽レーベルからリリースされているCDやノベルティグッズなどを送って下さいました。

IMGP1078.jpg

 送って頂いたCDは主にクラブミュージックのCDで、詰まる所、低音をガンガン効かせて聴きたかったわけですが、実は私は3月11日の大震災でスピーカーが落下し、振動板が見事に破損、廃棄せざるを得なくなってからずっとヘッドフォンのみで音楽を聴いていたのです。
 が、これらのCDを頂いてからどうしてもスピーカーで低音を楽しみたくなり、先月とうとう新しいスピーカーを買ってしまいました。改めてスピーカーで頂いたCDを聴いてみて思ったことは、「やっぱりウーハーで低音を響かせて聞くクラブミュージックは最高!」ということです。
 ちなみに私のお気に入りのトラックは、
「HOUSE ANTHEMS:02/LOVE LOUGE」より
Track No.06:UNAJI
 イントロのエレピとアコピの絡みが綺麗で、これを聴きながら夜の高速道路を走ったらとてもピッタリ合うのではないかと思われる曲です。
「Funk Da Session/NEURON ATTACK」より
Track No.05:Fallin Love
Track No.06:Goes Back Around
 2曲とも女性ボーカル曲なのですが、キックの4分打ちに対してベースラインがグネグネと動き回り、その上にベースラインの隙間を縫うようなフレーズのボーカルが見事にハマっている、聴いていて非常に気持ちよい曲です。スピーカーの買い換えを決意した曲でもあります。
「NAKED PASSION / LATINO HEAT」より
Track No.7:Out Of The Blue
 フェリー・コーステン(System F)の超有名な名曲のカヴァーです。2:00~と4:00~からの展開とそれに至るまでの流れが心地よすぎて癖になります。これもちょっと車で聴きたいかもしれない1曲。ただ、私の場合車にウーハーを積んでいなくてノーマルスピーカーのみなので低音がショボいんですな。時間が出来たらハードオフでウーハーの掘り出し物でも見つけにいきますかね。
 これらのCDは私がコンデンサの交換を行ったPCで製作された物だそうです。
 この場を借りて、改めてお礼を申し上げたいと思います。
ありがとうございました。
・・・いやぁ、自分のレーベルもサボってないで頑張らないとイカンな・・・(汗