サウンドハウスで水が売られている件について
音楽制作者の間ではお馴染み、プロ用音響機器が安く買えると評判のサウンドハウスですが、なんとそのサウンドハウスにてなぜか水が売られています。
最初私はてっきり音響機器の冷却水か何かだと思ったのですが物は試しにページを開いてみると、れっきとした飲料水でした。
http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=1919^AQ500-24
ページの説明によりますと、
“Aquaville（アクアヴィル）”は、カリフォルニア生まれの最高品質のナチュラルウォーターです。
カリフォルニア州オンタリオの井戸から湧き出る美味しい水を、米国市場において45年の歴史を持つボトリング工場でパッケージしました。そのボトルを工場からダイレクトにお届けすることにより、衝撃的な価格を実現しました。1箱 500ml×24本入り
原材料名：水（深井戸水）
内容量：500ml
採水地：カリフォルニア
硬度：1未満（軟水）
賞味期限：製造日から2年間（未開封、冷暗所保管）
原産国：アメリカ合衆国
輸入者：フィットネスハウス株式会社
とのことで、24本入りで860円。
一本当たりおよそ36円。しかも軟水ですから緑茶やカップラーメンにもよく合います。
実は私、水道水は一切飲まず普段の飲料水はミネラルウォーターと緑茶なのですが、24本入りで860円ですからなかなかお買い得ではないでしょうか。ということで早速注文してみようと思います。
Process.Start()で起動したプロセスのメインウィンドウのハンドルが取得できない場合の対処法
現在C#にて、以下のような仕様でプロセス間通信を行うアプリケーションを作っているのですが、プロセスAから起動したプロセスBのメインウィンドウのハンドルが取得できないという問題に遭遇しました。
- ユーザーの操作でプロセスAがプロセスBを起動。
- プロセスAはプロセスBのメインウィンドウにWM_COPYDATAを用いてデータを送信。
- プロセスBはプロセスAから受けた指示に従って各種動作を行う。
一番最初に書いたコードは、次のコードです。
このコードを実行すると、プロセスは起動できるのですがWaitForInputIdle()で起動したプロセスのメッセージループ突入まで待機しているにも関わらず、メインウィンドウのハンドルが取得できずに0が返って来ることがあります。
//プロセスを生成する。
Process p = new Process();
p.StartInfo.FileName = appPath;
p.StartInfo.Arguments = args;
p.StartInfo.UseShellExecute = false;
p.Start();
//念のため待つ。
p.WaitForInputIdle();
// ウィンドウのハンドルを取得するのだが、 // IEや.NETアプリを立ち上げるとゼロになってしまう場合がある。
IntPtr hMainWindow = p.MainWindowHandle;
notepad.exeなどのシンプルなアプリケーションの場合には正しくウィンドウハンドルを取得できるのですが、Internet Explorerや自作の.NETアプリケーションの場合には0が返ってきます。
どうやら挙動を詳しく調べてみると、一部のアプリケーションを起動した場合にはWaitForInputIdle()がきちんとWaitしてくれていないようで、メインウィンドウが生成される前にMainWindowHandleを取得してしまいゼロが取得されるようでした。
おそらく一部のアプリケーションでは、ウィンドウ生成後メッセージループ突入という組み方がされていないためこのような現象が起こるのでは、と推測します。
そこで、以下のようなコードを作成し再びテストを行ったところ、InternetExplorerや.NETアプリケーションを起動してもウィンドウハンドルを取得することができるようになりました。
//プロセスを生成する。
Process p = new Process();
p.StartInfo.FileName = appPath;
p.StartInfo.Arguments = args;
p.StartInfo.UseShellExecute = false;
p.Start();
//念のため待つ。
p.WaitForInputIdle();
//ウィンドウハンドルが取得できるか、 //生成したプロセスが終了するまで待ってみる。
while (p.MainWindowHandle == IntPtr.Zero && p.HasExited == false)
{
System.Threading.Thread.Sleep(1);
p.Refresh();
}
// hMainWindow != IntPtr.Zeroの場合にはウィンドウハンドルを //取得できたと思われる。
IntPtr hMainWindow = p.MainWindowHandle;
このコードでは、WaitForInputIdle();で念のためメッセージループの開始を待った後に、さらに、本当にウィンドウハンドルが取得できたかどうかをチェックし、取得できるまでループを回す、という事を行っています。
その際に、起動したプロセスが異常終了した時の事も考慮し、プロセスが終了してしまった場合にはループを抜けるようにしています。
今のところはこのやり方で、メインウィンドウのハンドルは取得できています。
ただしこのコードにはタイムアウト処理が入っていません。もし起動したプロセスがなんらかの原因でウィンドウの生成に失敗した場合、起動元のプロセスがフリーズしてしまいますので、実際にはタイムアウト処理も入れた方が良いでしょう。
さらに.NET Frameworkのドキュメントによりますと、Windows Formで生成したフォームのウィンドウハンドルはフォームの有効期間中に不変であるという保証はないそうです。（ShowInTaskbarプロパティを操作すると変わったりするようです） 従って、ウィンドウハンドルを取得しそこへウィンドウメッセージを送るという方式でプロセス間通信を実現する場合には、取得したメインウィンドウのハンドルを保持しておくのではなく、メッセージ送信前に取得しなおしておいたほうが確実かもしれません。
マザーボード修理 ～Compaq Presario 3903JP編～
はい。今回もマザーボードの修理の依頼を頂きました。
今回はCompaq Presario 3903JPです。
Compaq Presario 3903JPは2002年製で、製造時期的に不良電解コンデンサ問題の被害を被っていそうな雰囲気です。依頼者様曰く「7年間Webサーバやメールサーバとして常時通電状態で使用していました」とのこと。
交換前の液漏れおよび膨張したコンデンサ。
CPU周りの10本とメモリスロット付近の1本、合計11本のコンデンサがこのように膨らんで液漏れを起こしていました。今にも破裂しそうでパンパンです！！！
早速コンデンサを取り外します。実はハンダ付けする作業よりも取り外す作業のほうが、スルーホールに残ったハンダをきっちりと除去しなければならない分若干手間がかかります。
取り外したコンデンサ。ニチコンHMシリーズ。
ムスカ「怯えることはない。こいつははじめから死んでいる。」
さて、こちらが新品のコンデンサになります。本当はニチコンHMを使用する予定でしたが、あいにく同規格品が品薄でしたので、依頼者様の了解を得て、超低ESRでハイグレードなHZシリーズを使用させて頂きました。ゴールドのスリーブがいかにもハイグレード品という雰囲気を醸し出しています。
そして、ハンダゴテで一本ずつハンダ付け。
めでたく修理が完了したマザーボード。
この後クロネコヤマトに持って行き、依頼者様の元へと返送されます。なお、ドットインパクトプリンターを持っていないので伝票は毎回手書きです。
その後依頼者様から「動作良好です」とのご報告を頂きました。
今までサーバ機として利用していたこのマシンを再びクライアント機として利用することにしたそうです。
TUBE MPの音質はコンデンサの交換を行ったことでどう変化したか
1月27日のエントリで寿命を迎えたコンデンサの交換を行いTUBE MPを格安で復活させた事をお伝えした時に、同時にノイズが減少し音質が改善されたと書いたのですが、コンデンサ交換前の音源ファイルを見つける事ができなかった為に実際の音をお聴かせすることができませんでした。
しかし先日MacのHDDを漁っていたところ運良くTUBE-MPのコンデンサ交換前の録音物を見つけることが出来ましたので、皆様の参考になればと思いこのエントリを書く事に致しました。
※コンデンサ交換前の音源は、もちろんTUBE MPが故障する前に録音された音源です。
TUBE MPの二つのノイズ
さて、TUBE MPが発するノイズには大きくわけて2種類あります。
ひとつは「サー」という常時発される真空管の熱雑音、もう一つは電源系統のノイズです。コンデンサを交換することでほとんど聞こえなくなったノイズは後者のノイズです。
私は主に、エレキベースやエレキギター、マイクなどをTUBE-MPに接続して使用しています。そして、TUBE MP購入当時から安価で手軽に音圧が上がる装置として重宝していたのですが、ひとつだけ気になる点があったのです。
それは、マイクに向かって囁いたとき、ギターやベースを軽くピッキングした時など、いわゆる微弱な信号を入力した時にその信号にまとわりつくように「ササッ、ササッ」というノイズが載るのです。
百聞は一見に、いや百読は一聴にしかずというわけで、運良くコンデンサ交換前の音源を発見できましたので、実際に聴いてみて下さい。なお、パソコンに付属のスピーカーではノイズがよく聞き取れないかもしれません。そのときはモニターヘッドフォンなどを使用してみてください。
おそらくこれはピックか指のどちらかが弦に軽く触れてしまった時の音だと思います。聴き取り易いように編集して音量を上げていますが、実際は非常に弱い信号です。短い音源ですが、ベースの音が鳴った時に「ササッ」もしくは「ザザッ」というノイズも一緒に混入している事がわかると思います。
コンプレッサを併用することでノイズはますます深刻になる
私は元々ロック系の曲を中心に制作していますので、ほとんどの場合は大きな信号ばかり入力させており、そのときには上記のようなノイズはマスキングされて消えてしまうのですが、それでも弱いピッキングや囁くようなボーカルなど弱い信号が必要になる時があります。そんな時にそのノイズが出てくるばかりではなく、TUBE MPのすぐ後ろに接続されているコンプレッサがそのノイズをより一層増幅させてしまっているのです。
そこで私は、安物故の宿命だと思ってできるだけ小さな信号を入力させないように使ってきました。
コンデンサの交換を行うことで音質は飛躍的に改善した。
しかし、コンデンサの交換を行った後に再びTUBE MPの音を聴いてみてびっくりしました。微弱な信号にまとわりつくようなノイズがまったく聞こえないのです。
これも百読は一聴にしかず、ということで、ベースの弦にピックを軽く当てて録音してみました。先ほどの音声サンプルと比較してみてください。この音源も編集によって音量を上げていますが、元々は弦にピックが触れるか触れないかという具合にピッキングしましたので、非常に微弱な信号です。さらに今回は音が減衰するまで、またフレット上で指を動かした時の微弱な音まで録音してみました。
いかがでしょうか。最初から聞こえる熱雑音はしょうがないとしても同じTUBE MPとは思えないほどクリアに録音されていると思いませんか？
ただし、一つだけ録音条件が異なっている点がありまして、TUBE MPのコンデンサを交換した後にベースの弦も張り替えました。その点だけはご了承下さい。
日本のコンデンサの質の良さを改めて思い知らされた
さて、私が交換を行ったコンデンサは電源部に使われているコンデンサ3本で、オーディオ用の高級なものではなく、電源用に使われているごく一般的な物です。かかった経費も送料込みで590円だけでした。
たったこれだけの投資で音質が見違えるように変化したわけですから、元々取り付けられていたコンデンサの品質が如何に悪かったか、また日本のコンデンサの品質が如何に良いかを思い知らされました。
さらなる上を目指して
次の課題は真空管の熱雑音です。ボーカルやアコースティックギターのソロを録音する場合にこの熱雑音は非常に邪魔な存在になります。これは真空管をもっと高級な物に変えることで改善できるのではと考えています。また、電源部のコンデンサもオーディオ用の高級品に変えてみて、さらに音質がどう変化するのかこのブログで改めて書いていければ良いと思っております。
Google BooksのOCRにもやはり誤認識が
興味本位で「親善大便」なんて言葉をググっていたら、ひっかかりました。
追記：
他にもいろいろ検索してみたら、やはり出てくる出てくる（苦笑）
USBギター
最近はUSBギターなるものがあるのか！
といっても値段がアレだから、音にはあまり期待できなさそうだけど、パソコンで手軽に録音できる便利さを考えたらアイデアスケッチなどには良いかも・・・、と思った。
GoogleのJavaScriptオプティマイザ「Closure Compiler」
http://code.google.com/intl/ja/closure/compiler/
What is the Closure Compiler?
The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what’s left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls.
意訳：
Closure Compilerとは何か。
Closure CompilerはJavaScriptの読み込みと実行を高速化するツールである。これは正真正銘のJavaScriptコンパイラであるが、一般的なコンパイラがソースコードを機械語に翻訳する代わりにClosure Compilerは既存のJavaScriptコードをよりパフォーマンスに優れたコードへと変換する。Closure Compilerは最初にJavaScriptの構文解析と分析を行った後、不必要なコードを削除し、残りのコードをより小さなコードへと書き換える。また、文法や変数の参照、型などにいても検査し、JavaScriptにおいて陥りやすい問題について警告する。
コンパイラというよりは、オプティマイザですね。
