iPod の HDD がとんだ上に、環境移行時のバックアップ用 HDD までとんでしまい、僕の音楽鑑賞のための環境は無茶苦茶になってしまっている。これを、心身の余裕のあるときに少しづつ修復している……という話をすると、修復って何なんですか？ CD 突っ込んだら終いじゃないすか、とか聞かれることがある。
本来、僕は巷で言うところのデジタルリマスタリングを行うのは好きではない。しかし、時々だけどやらなければならないことがないわけでもないのだ。その辺りのことは以前に書いた通りなのだけど、今回はまた、この面倒な作業をしなければならないことになった。
今回の音源は『ルパン三世 愛のテーマ』である。この曲、何をどう聞いても、明らかにエレキギターが松木恒秀氏である。水木一郎の歌入りの方も松木氏（氏のギターを知っている人ならご存知のフレーズが満載である）なのだけど、インストゥルメンタルの方が、良い意味で抑制が利いているし、アンサンブルも明らかにこちらの方が優れている。
そんな訳で、僕としてはこの曲は是非とも手元で聞けるようにしておきたいわけなのだが、残念なことに、僕の手持ちの音源はテレビ用にミックスダウンされているもの（それ以外の音源を御存じの方がおられたら是非御一報下さい）で、おそらく 1/4 inch・19 cm/s のメディアから起こしたものらしい。しかも、当時のテレビで再生されることを考慮してのものだと思うけれど、ほぼリバーブなしでミックスダウンされている。これは毎回聞くのが少々辛い。
ということで、まず WAV 形式でセーブしておいてから Cubase に取り込む。Nomad Factory BBE Sound Sonic Sweet に収録されている D82 Sonic Maximizer を立ち上げると……ふむ。やはりこの手のアナログ音源には劇的に効果がありますな。かかってるかどうか分からない位にかけるのがコツなのだが、操作パネルの ON/OFF で比較すると、効果は一目（一聴）瞭然である。低音も少し足してやって、そこに軽くコンプをかけると、埋もれていた楽器のひとつひとつが浮き出してくる。右のアコギと左のエレキ、そして左のパーカッションが不自然でない程度に明瞭になるようにコンプで調整する。
FX チャンネルに SIR2 を立ち上げて、EMT-140 のインパルス応答ファイルを読み込む。本物のプレートエコーと違って、いじることのできるパラメータはプリディレイ位しかないのだけど、前後に色々細工をして、プレートっぽい音（パーカッシブな音の直後に、リリースの遅いコンプみたいに立ち上がっていく感じ）の残響音を作る。このチャンネルへのセンドを調節して、エコーの量を決めていく。トータルエコーの後付けというのはかなり乱暴な業なのだけど、テレビ用でとにかくエコーがかかっていないので、残響音を吟味さえすればちゃんと乗ってくれる。
残響を乗せたところで、最後にコンプ、リミッター、そして EQ で調節する。この音源は、事前に FFT で解析した結果、11 kHz 辺りを不自然に持ち上げているのが分かっていたので、それを除去するように補正して、トータルのダイナミックレンジを揃えてやれば、音源の完成である。どんな風になるか、比較してみていただこう:
ちなみに、オリジナルの方の音源は録音レベルが低いので、いわゆる正規化をして聴感レベルをリマスタリング後に合わせてあるのだが、まあ、こんな感じである。本当はこんなこと、しないで済むに越したことはないのだけど。
ある web ページで、僕の書いたものを引用されていたのだが、
$ sudo `which <command>`
と僕が書いていたのを、
$ sudo `which <command> <引数>`
と誤解されているようだったので、コメントを入れておいたのだった。
そもそも、何故、
$ sudo `which <command>`
などということをしなければならないのか、というと、これはちょっと前に sudo の仕様が変更されたことに起因している。以前は、sudo を使って管理者権限でコマンドを使うとき、そのコマンドの実行において、sudo を実行したユーザの環境変数が反映されるようになっていた。だから、root に妙な PATH を指定することなしに管理者権限のコマンドを使うのに、sudo は結構重宝な道具だったのである。
しかし、これはセキュリティ的にはよろしくない状況である。しかも、何か操作ミスがあったときのリスクも大きくなる。だから、ちょっと前から sudo は仕様を変更して、sudo 専用の環境変数のセットが用意され、sudo でコマンドを実行するときにはその環境変数が反映されるようになっている。
このような状況になると、あまりメジャーでないディレクトリにあるバイナリを起動しようとするときに、そこに PATH が通っていないことが問題になる。当然フルパスを書けばいいのだが、それは面倒極まりない。こういう場合、UNIX の流儀では、小さなコマンドを組み合わせて解決することになるわけだが、そこで先の、
$ sudo `which <command>`
が登場するわけである。
(b)sh 系のシェルでは、バッククォートで囲まれた中身はコマンドとして展開される。つまり "which <command>" の実行結果が文字列としてここに嵌め込まれるわけだ。ここで重要なのは、"which <command>" は、sudo を実行するユーザの権限で実行されることである。つまり、このユーザの環境変数で PATH が通っていれば、このような書き方をすることで、フルパスを sudo に渡すことができるのである。
ここまで分かれば、何故引数をバッククォートの中に入れてはいけないのか、が分かろうというものだろう。うーん……しかしなあ。僕は何も文献など読まずに、この記法を見ただけでそのココロが分かったのだが、そんなに難しいものなのだろうか？ 説明が足らなかったのかなあ。
こんなことをやっていたのか。しかしなあ。これで知能がどうの、天才がどうの、なんて、下らん話だったよ。
ThinkPad X61 のファンがいよいよダメになってきた。ファンの回転が変化するときに「カラカラカラカラ」と派手な音がする。真夜中に使うのが少し憚られるような状況になった。
本来、X61 のファンはユニットアッセンブリーになっていて、CPU と GPU から熱を伝える銅製のヒートパイプと、シロッコファンが密着した同じく銅製のフィンが込みになっている。しかし、全て交換するのはあまりに勿体ないので、ファンだけを某オークションで入手して交換することにした。
HDD → メモリ蓋 → キーボード → 外周部 の順番に分解していく。ディスプレイと指紋認証センサのメンブレンケーブルを外し、HDD コネクタ周辺のカバーを外し、PCMCIA カードスロットのネジを外すと、メインボードが外れる。これを裏返して、ヒートシンクとファンを取り外す。予想通り、CPU の冷却グリスが劣化していたが、今回はそのまま少量のアルコールで練って、ファンを交換してからそのまま取り付けた。途中、無線 LAN と bluetooth のスイッチ（これが機械的に ON/OFF できるのがらしくっていいけど）のノブが外れたりして往生したけれど、作業自体はスムースに進められた。
で、立ち上げてファンの回転数を監視していると……え、こんなに静かだったのか？ という位に静かになった。ぐずぐずせずにさっさと換えるんだったなあ……しかも、冷却速度がぐんと上がった。いい加減ファンのモーターがヘタっていたんだなあ、と改めて実感したのだった……
