エントリー

2010年06月の記事は以下のとおりです。

VAIO U1にSSD

  • 2010/06/15 14:16
  • カテゴリー:散財

 SSDが流行ってますね。昨年末あたりのNANDフラッシュの価格下落の頃に比べれば最近はどちらかというと2TBクラスのHDDの方が話題に上ることも多いのですが,それでもSSDが一定のポジションを確保したことは間違いないでしょう。

 SSDについては,可動部分がないので壊れにくく衝撃などに強い,消費電力が小さい事,発熱が少ないこと,騒音がないこと,高速なことが利点として挙げられますが,このことがSerialATAを装備しない旧式のノートPCを大幅にアップグレードするという,決して大きくない需要を満たすために,それこそある程度の存在感を持つに至っていることでしょうか。

 とりわけ,1.8インチのHDDを搭載する小型ノートPCは,交換用のHDDも品種が少なく,IDEについては全滅と言っていいでしょう。それにHDDに入れ替えたところで,遅い,うるさい,発熱がひどい,電気を食うこと,という不満がそのまま引き継がれてしまいますので,全然うれしくありません。

 これが,SSDに入れ替えるだけで,ほとんどの不満が解消されるというのですから,とても魅力的な話です。Core2Duoを搭載するモバイルノートPCでも,HDDが1.8インチであるばっかりにイライラさせられるわけで,こういうものこそSSDにするとその効果がはっきりします。

 SSDも随分安くなりましたし,当初取り沙汰されたプチフリや寿命の問題についても随分良くなっていると聞きます。

 私の場合,2002年に買ったPCG-U1,私が新品で買った唯一のWIndowsマシンであるVAIO U1に,SSDを使ってみようと思っていました。

 PCG-U1は東芝の1.8インチを使ったマシンですが,今は亡きTransmetaのCrusoeと搭載可能メモリの少なさで,はっきりいって使い物にならないくらい遅いマシンです。WindowsXPを動かすことさえ無理があると思うマシンです。

 ところが実際に使っていると,その速度の遅さというのはどうもHDDへのアクセスが足を引っ張っている部分も多いように思われたのです。発熱もひどいし,東芝の1.8インチは結構うるさいし,SSDに交換して実用レベルになってくれれば,これはとてもありがたいと思いました。

 3月頃に計画を立てていたのですが,ようやく先日SSDを手に入れ,環境の構築をやってみました。

 手に入れたSSDは,ジェイ・ディー・エスという商社がやっている直販サイト,SSD Laboratoryのオリジナルで,BluePolarisという名前のシリーズです。32GBで13380円でした。32GBは64GBよりもライトが遅いのですが,PCG-U1に64GBもいりませんので,これでいいです。

 遅いとはいうものの,リードが100MB/sec, ライトが50MB/secと十分な性能を持っています。これはコントローラに定評あるIndilinx社製,DRAMによるキャッシュは64MBと大容量を搭載した結果でしょう。

 値段の安さと性能の良さで,これに目を付けていた私が引っかかったのは,ZIFコネクタしか用意されていないことでした。変換基板で東芝50ピンに変換しないといけませんが,果たしてPCG-U1にそんなスペースがあるかどうか。

 PCG-U1は8mm厚のHDDが入っていました。このSSDは5mm厚ですから,3mmもスペースがあります。まあどうにかなるでしょう。

 ZIFの基板はやや高くて1200円もしますが,こういうのは一緒に買っておいた方がなにかと都合が良いです。もしトラブルがあったときでも話がしやすいです。

 届いてから早速PCG-U1を分解し,HDDを取り出します。何度となく分解したので,慣れたものです。

 実際にSSDをはめ込んでみると,8mmというのは,5mmの厚さの下側に3mm膨らんでいるような感じですので,HDDの上側を這わせるフレキとの間にスペースがあるわけではありません。変換基板をSSDの上側に置くことは無理です。

 SSDはやや長さ方向が短いので,ここに変換基板を入れようと考えましたが,これも無理。変換基板が入るほどのスペースはありません。

 なら,変換基板をSSDの下に入れるしかないのですが,HDDと繋がっていたコネクタに変換基板のコネクタを差し込みますので,SSDをフレキと変換基板の間に入れなければなりません。それはとても無理です。

 さて困った。こんなことで困るとは,よく調べないといけませんね。

 散々パズルをやった結果,変換基板はSSDの下側に回すのですが,HDDのフレキを少しハサミで切って,うまく変換基板とSSDを繋ぐフレキを取り回し,なんとか押し込む事に成功しました。マグネシウム合金の筐体は導電性もありますので,絶縁のためにテープを貼ることも忘れません。

 仮組みして起動し,BIOSが認識していることを確認出来たら,きちんと組み立てます。リカバリを行い,余計なアプリなどを削除してから,XPのprofessionalへのアップグレードを行うのですが,ここで問題発生。リセットを繰り返してしまい,起動しなくなりました。

 別にHomeEditionでもいいですので,ここは安全にリカバリだけを行い,環境構築を行います。

 さて,使ってみた感想ですが・・・確かにデータの読み出しや書き込み,特に読み出しが高速になったので,起動も速くなりましたし,アプリの起動やスワップも,待ち時間が減りました。その点では改善は大きいです。

 しかし,そもそものCPUパワーが絶望的なことはいかんともしがたく,ここが結構足を引っ張っています。

 ベンチマークを取ろうと思ったのですが,SSDは書き込みをやった分だけ寿命が短くなるので,やめておくことにしました。そもそもPCG-U1のような低速マシンでベンチマークをとっても,意味のある数字が出てくるとも思えません。

 速度の改善は全体の使い勝手の向上にそれほど寄与しませんでしたが,発熱が激減したこと,極めて静かになったこと,そして軽くなったことは,非常に大きいと思います。特に最後の軽い,と言う要素は,想像以上の効果です。PCG-U1は両手で持って使うマシンですが,ぱっと手に取ったときの軽さがここまではっきり違うとは,私も驚きでした。

 ということで,SSDへの置き換えはそこそこの成果を上げました。これ1つで快適になるほど良いマシンではなかったということですが,リカバリをしたということも含めて,PCG-U1はなんとか使えるマシンいなりました。

 高かったこともあるのですが,なにかと気に入ったマシンですので,このまま手元に置いておこうと思うのですが,1つ問題が残っています。

 PCG-U1には,無線LANが内蔵されていません。さらに,USBも1.1です。PCカードでこの2つを実現しないといけないのですが,かつて私は802.11gとUSB2.0のコンボカードを使っていました。

 しかしこのコンボカード,無線LANの感度が非常に悪く,2階にいると接続できなくなります。これではさすがに問題があるので,抜本的に対策を考えます。

 まず,USB2.0をPCカードで増設します。このうち1つのポートに,802.11n対応のUSB接続型無線LANアダプタを差し込んでみます。

 ところが,なにが原因なのか分かりませんが,この無線LANアダプタを繋いでおくと再起動の時にフリーズしてしまうのです。最初はUSB2.0カードの問題かと思いましたが,無線LANアダプタを外せば起動します。さらに本体のUSB1.1ポートにこのアダプタを接続すると起動しますので,もしかしたら電力の供給問題かも知れません。

 別に,USB1.1でもいいような気もしてきました。確かに802.11gや11nの力を発揮できないのですが,そもそもWANは8MbpsのADSLですし,外との接続では関係ありません。他のマシンとのファイル共有で遅くて仕方がないかも知れませんが,そういうファイルはUSBメモリで動かすことにすればいいかなあ。そうするとPCカードも普段は抜いておいてもいいわけだし。

 どっちにしても,もうちょっと試行錯誤をしてみます。

 そうそう,このSSDには寿命診断ソフトのライセンスが付属しているのですが,案内されたダウンロードサイトには繋がらず,ダウンロードが出来ない状態です。サポートにメールをしていますが返事はなく,どうもこのジェー・ディー・エスという会社が,そんなに信頼に足る会社ではないような感じです。クレジットカードの番号などを安易に書き込むことは控えた方がよさそうです。


 

おかえりなさい

 2010年6月13日23時過ぎ,オーストラリアの砂漠に,宇宙から届いたカプセルが届きました。送り主は「はやぶさ」。中身は「イトカワ」のサンプルです。

 先日よりニュースでも報道されている「はやぶさ」の帰還劇は,宇宙大好きな人から科学技術に疎い人まで,多くの人の注目を集めています。相次ぐ故障や予期せぬトラブル,何度も絶望と見られていた地球への帰還が,数年遅れてようやく実現したことは,我々にあきらめないことが何より大事なことを,久々に見せてくれた気がします。

 とはいえ,やっぱり手がなければあきらめざるを得ないわけで,はやぶさにはあきらめずに済むだけの「仕込み」がなされていました。あきらめないことは大事な事ですが,あきらめずに挑戦できるだけの用意がなければならないことも,一緒に教えてくれたように思う訳です。

 考えて見ると,宇宙開発は根性論で出来るようなものではありませんし,冷静でかつ論理的な判断を常に求められる世界のはずです。また,個人でやってることならあきらめないという判断も簡単でしょうが,JAXAは組織で,予算も時間も限られています。本来,ミッションは失敗だったとプロジェクトを放棄されることは当たり前のはずであり,それがこうして何年も延長し,予算も時間も割り当てられるというのは,やはりそれなりの根拠があってのことでしょう。私はここを見逃すべきではないと思っています。

 それはそうと,私は別のblogで,2005年11月29日と同年12月1日に,以下のような書き込みをしていました。

---

(´・ω・)「ふぅ…なんとかサンプル取れたかなあ?あとは帰るだけだお」
(´・ω・)「体のあちこちが痛いお…でもコレ持っていかないと。みんな待ってるお」(`・ω・´)「ガンガル!!」
(´・ω・)「宇宙は寒いよ…寂しいよ…ち、地球だ!見えてきたお!」
(`・ ω・´)「カプセル、投下!受け取って…」
(´・ω・)「ふうっ…終わったお…疲れたなぁ…ああ、地球がどんどん離れていくお…綺麗だなあ…」
(´・ω;)「地球か、なにもかも懐かしいぉ、これで本当のお別れだぉ
       石入ってたかなあ…無かったら、みんなゴメンだぉ…」

機械を擬人化するという習慣は,おそらく機械が我々の手によって生まれてから,ずっと繰り返されてきたものだと思います。
先日のblogは,スラッシュドットからの転載なわけですが,これは言うまでもなく,小惑星イトカワに着陸し,その破片を採取した「ハヤブサ」を擬人化したものです。
動くものは生き物である,故に機械も生き物である,という観念は,かつてどこかで読んだ事があるのですが,「ハヤブサ」はこれほどの手間と予算をかけ,最終的に放棄されるものであるということが,モノづくりを生業とする私にとって,まるで我が子を放棄するような行為に見えていました。
そんな,心のどこかに引っかかった想いが漠然とある中で,その気持ちが一気に具現化したとも言えるのが,この書き込みだったわけです。
残念なことに,「ハヤブサ」は,姿勢制御に問題があり,2系統ある噴射装置のいずれもが動作しない状況に陥っており,地球への帰還が難しいのだそうです。
彼は,与えられた足を2つ完全に失いながら,暗く寒い宇宙空間を漂い,愛すべき人が待ちこがれる,生まれ故郷を再び見ることなく,無限とも言える彼方へ消えてしまうのでしょうか。
可能であるなら,彼を回収し,その労をねぎらい,称え,次の世代に夢を与えるという,そんな舞台を用意できないかと,擬人化している私は,思うのです。

----

 もう4年半も前のものなので驚いているのですが,これ以降もハヤブサは満身創痍にむち打って,何度も何度も絶望視されながら,とうとう昨日地球までやってきて,カプセルを届けるという自分自身の仕事を完遂し,そして大気圏で燃え尽きその一生を終えました。

 ハヤブサはただの機械ですし,人間がいないとそれ単体ではなにも出来ないものです。それはよく分かっていますが,それならなぜこれほど人の心を打つのか。

 2005年にも書いていますが,機械が人間の代わりを一部代替する(あるいは凌駕する)ことを期待されて登場して以来,擬人化されることは続いています。

 今はどうか知りませんがかつて自動車工場で動いていた溶接用アームロボットには,女性の名前(というか当時のアイドルの名前)が付けられていたそうで,これはロボット1つ1つを区別し特定して接していることを意味しているように思います。

 今回のハヤブサ,フィギュアまで登場しているそうですが,まあこれはやり過ぎとしても,単なる機械として見るよりは,褒めて上げたい気持ちゆえに,やっぱり擬人化したくなる気持ちがあるのは自然な事だと思います。

 2005年には,私の無理解もあり,記述にウソがあります。ハヤブサはカプセル放出後に宇宙空間を彷徨うのではなく,大気圏突入後に燃え尽きましたし,サンプルの採取は失敗しており,巻き上げられた砂粒が偶然カプセルに入っていることを期待しているに過ぎません。

 それにしても,最後の1機のイオンエンジンが故障して万事休すのところを,故障した他のエンジンと繋いで動くようにしたという話は,ちょっと考えさせられます。感動的な話ではありますが,密かに仕込んだ2つを繋ぐ回路は,普通なら使われるはずのないものだったわけで,そこに重要やお金を使うことが正しいのかどうか。あるいはその回路を使うことで安価に冗長度を上げることが出来て信頼性向上に役立つとか,もう少し詳しい話が知りたい所ではあります。

 ハヤブサは,最後の最後に生まれ故郷の地球の写真を撮影し,伝送して燃え尽きました。もう二度と見ることはないと何度も何度も思ったであろうその懐かしい姿を,彼はどんな気持ちで写真に収めたのでしょうか。写真も人間が操作したのはわかっています。しかし,撮影したのはハヤブサです。あり得ないことではありますが,ほんのわずか,彼の意志が含まれていたのではないかと,そんな風に思っています。

 カプセルの中身は,基本的には空っぽのはずですが,砂粒1つでも分析は可能とのこと。ハヤブサの想いを無駄にしないためにも,なにか有益な情報が手に入ることを祈っています。

DP1sを買いました

  • 2010/06/10 20:18
  • カテゴリー:散財

 シグマのDP1sというデジカメが,今処分価格になっています。底値は過ぎたかなという印象もありますが,新品同様の中古品が実は新品の可能性がある,という買い方であれば3万円を割り込んだ値段で買うことが出来ます。

 私は32800円で先週買うに至りました。

 買った理由の1つに,現在私は,まともな画を出すデジカメを一眼レフしか持っていないことで,なにかと不便な想いをしている事がありました。

 GRD3にしてもGXRにしても物欲をそそるデジカメではありますが,出来ればセンサのサイズは一眼に近いものがいいという気持ちが私には強くて,前者はどうも買う気になれず,後者はレンズユニット取り外しというギミックが今ひとつ気に入りません。

 マイクロフォーサーズもかなりいいと思いましたが,やっぱセンサのサイズが気になりましたし,かといってソニーのNEXを買う気もなく,困った状況が続いていたところに,3万円程度でAPS-Cサイズに近いセンサを持つ高画質デジカメが手に入ると聞いて,買う決心をしたわけです。

 500万画素もあれば画素数はもう十分で,そこから先はセンサのサイズとレンズ性能が効いてくるというのが以前からの私の考えですが,どっちもコストがかかり,かつコストの下がり方が緩やかだったりしますから,このこだわりを貫こうとすると,自ずと尖った(そしてそれは得てして不便な)デジタルカメラから選ぶしかありません。


 遅い?そんなに連写をする必要性がそもそも普段にありますか?

 AFがおばかさん?28mmはパンフォーカスで撮るのが楽しいですよ。

 大きい?そりゃセンサが大きいんですから。

 JPEGが使い物にならない?RAWから現像できないデジカメよりずっとましです。

 シグマなんてきいたことない?そいつは気の毒に。

 電池がもたない?どんだけ無駄ショットを撮ってるんですか。

 動画がまともに撮れない?ビデオカメラを使ってください。

 ズームじゃない?28mm単焦点で十分。面倒くさがらず自分が動け。 

 F4は暗い?28mmで絞りをあけるんですか?
 
 操作系がダメ?3日で慣れますよ,どんなUIでも愛があれば。

 アフターサービスとかサポートは?偏屈ユーザーの多いレンズ業界をなめてはいけません。

 高い?うーん,それはその通りかも・・・


 こんなくだらないこと(そうでもないか)より,ガラスモールド非球面レンズを贅沢に奢り,無理に明るさを欲張らないゆとりのある設計のレンズを通って曲がる光に想いをはせ,その大きな受光面に投影された画が,色ごとに異なる深さで「染みこんで」いく様を想像すると,もう脳のシワからドーパミンが染み出して止まりません。

 ポテンシャルはとても高く,しかしそのポテンシャルを引き出す条件は狭く厳しい,そういうカメラは実用面はともかく,使って楽しいものであることは確かです。K10Dの便利さや手堅さ,失敗しない安心感もいいですが,D2Hで作り込む面白さもまた捨てがたい。

 そんなこんなで届いたDP1Sは,予想通りのひねくれ者でした。

 デザインは良くも悪くもシグマのデザインで,私はあまり好きにはなれません。実用面でも今ひとつで,持ちにくく,滑りやすく,鞄から取り出しにくいです。

 レンズキャップは被せ式ですが,ロックを外す機構がない上,はめ込むときのキャップの位置が決まっているせいで,非常に使いにくいです。少なくとも,手探りで取り外しや取り付けが出来るようなものではなく,そこが撮影という作業に対する壁になっているように思います。

 そして電源スイッチの位置が微妙に遠くて,一度握ったカメラをもう一度握り直さないと電源スイッチを押せません。申し訳ないけど,おもむろに右手でつかんで「よし撮るぞ」と気合いを入れた後に,左手で支えて電源をぽちっと入れて,また握り直さないといけないような無粋なカメラを,私は初めて見ました。

 しかしシャッターボタンに指をかけると,その感触はなかなかのもので,シャッターを切りたいという欲求は高まります。モード設定ダイアルのクリック感もなかなかよくて,指のかかりもガタのなさも,良くできています。

 電源を入れると,早速訳の分からないユーザーインターフェースに混乱しつつ,それでも精一杯高級コンパクトデジカメにふさわしい「設定の自由度」を割り当てるのに苦労したんだろうなあと思わせます。

 私がDP1シリーズに感じた強烈なアイデンティティの1つに,フォーカスリングがあります。右の親指がかかる一等地に,非常になめらかなダイアルがありますが,これがマニュアルフォーカスの時にしか使わない,フォーカスリングです。

 例えばこれを,コマンドダイアルに割り当ててマニュアルフォーカスの時だけフォーカスリングとして機能するのが普通かなと思うのですが,そういった気の効き方は一切無しです。

 しかも,このフォーカスリングはロックが出来ません。なにかの拍子に簡単に動いてしまいます。電源がOFFの時に動いてしまった場合でも,次の電源ONの時に動いた後の値でフォーカスが調整されるというこだわりようです。(ダイアルが動いたことをまずトリガにして,値をサンプリングするべきです。)

 LCDの画面上に距離目盛りも出るのですが,被写界深度の指標が出てこないばかりか,説明書のどこにも絞り値と被写界深度の一覧表がありません。何のための絞り優先AEとマニュアルフォーカスやら・・・中途半端やなー。

 まあそれは運用でカバーするとして,どうやらF5.6で2mに固定すると,無限遠から1mくらいまでフォーカスが合うように出来るそうです。実際にはちょっと無限遠が出ませんので,F8まで絞るか,3mあたりでフォーカスを固定すると安心でしょう。

 レンズの性能としてはF5.6あたりがピークになるという話ですので,変にプログラムモードで使うより,絞り優先AEで行くのがよいでしょう。

 また,ホワイトバランスはさっぱりあてにならないそうですし,ISO400位から結構ノイズが出てくるということですから,結局のところ以下の設定に収れんしました。

  絞り優先AE(F5.6固定)
  マニュアルフォーカス(2m固定)
  ホワイトバランスは晴れ固定
  ISOは100か200で固定
  RAWで記録

 いやはや,なんとストイックな。でも,撮影直前の余計な操作や動作がなくなりますので,気楽です。

 起動に3秒,書き込みに5秒以上の時間がかかるのですが,まあGR1でもフィルムの巻き上げを考えるとこのくらいの待ち時間はありました。そんなに苦になるものでもありません。

 しかし,前述の通りキャップの付け外しがちょっと気を使うので,撮影機会を何度か逃してしまいました。それでキャップをせずにいたのですが,いつの間にやらレンズがなにかに触れたらしく,油やわずかなコーティングの傷をつけてしまいました。

 買った翌日に,30分ほど散歩して撮影した写真を2つほど掲載します。せっかくですから。

 両方とも上記のモードでスナップしたもので,SigmaPhotoPro4という純正現像ソフトで現像しました。モードはオートで,2枚目だけ露出補正を+0.7してあります。保存サイズはオリジナルの1/2で,JPEGです。トリミング,色の補正などの加工は一切行っていません。

ファイル 377-1.jpg

ファイル 377-2.jpg

 いや,これは一眼レフをある意味凌駕していますね。

 単純比較は難しいですが,画像の出力画素数としては400万画素のセンサのカメラと同等に過ぎません。

 しかし,RGB各色ごとに400万画素を備えるFoveonX3というセンサを使ったDP1sは,他のほとんどのデジカメが採用するベイヤー配列のセンサと違って,そもそもの情報量が全然違います。

 ベイヤー配列だと,同じ400万画素でもRGBそれぞれに400万個の情報が揃っているわけではありませんから,いわば妄想で足りないデータを作っているわけですね。その妄想はかなりの精度で的中することが知られていますが,でも妄想は現実を越えられません。

 だから画素数が少ないことによる解像度の低さは別にして,そこに潜む情報量には息を呑みます。特に色情報の豊かさは他にないものがあって,とりわけ現像時の色や明るさの補正のゆとりの深さは,特筆すべきものがあります。

 実はPhotoshopCS5でRAW現像する方が私の好みなのですが,補正したときになかなか破綻せず粘るんです。これはそこらへんの優等生デジカメとは一線を画すものです。

 そして,原理的に不必要なローパスフィルタが存在せず,レンズ性能にのみ制約を受けた豊かな高域情報を含んだ画像は,中低域との自然な繋がりを持つことで独特の空間表現をしています。

 D2Hに比べればまだまだ条件は広い方という印象で,まあ当たり前のことですが,さすがに2年前のデジタルカメラだなと思います。本来のゆとりはもっとあって,これがコンパクトデジカメという細かい制御が不得意なハードウェアを補完することになっているはずで,その点で言うと同じセンサを使う一眼レフのSD14など,どんな画を吐き出すのか興味がわいてきます。

 何を今さら,と言う気もしますが,これは本当に面白いカメラです。

 さて,せっかくの面白いカメラですから,もっと使いやすくしていこうと思います。グリップ,レンズキャップ・・・いろいろあります。随時ご紹介する予定です。

GL811Eとプレクスター製ドライブとの相性

 今年の2月から取り組んでいることが,手持ちの音楽CDのバックアップです。俗にリッピングと呼ばれる行為ではありますが,私のMacにはすべてのCDがとりあえずAACで取り込まれています。

 これとは別に,非圧縮でまさに「バックアップ」をしないといけないと思っていたのは,以前ここにも書いたように,CDの劣化対策です。ゆえにリードエラーが可能な限り発生しない環境と,オフセットも出来るだけゼロになるような環境として,手持ちのCD-RWドライブであるプレクスターのPX-W5224Aを起用して,作業を進めていました。

 実は先日,すべてのCDのバックアップが完了したのですが,とくに終盤のここ最近の作業において,原因不明のトラブルに悩まされ続けていました。

 それは,リッピング中にドライブの接続が勝手に解除されてしまうという問題です。PX-W5224AはPATAで,これをブリッジでUSBに変換して接続を行っているのですが,作業を始めた2月頃は,接続後10分ほどして一度切断されても,再接続すれば以後は切断されることなどなかったのです。

 それが再接続後も切断されるようになり,次第に短い時間で切断されるようになってきました。リッピング作業終盤の先週など,10分もすると切断されてしまいますから,リッピング途中でも書き込み途中でも情け容赦なく切断されてしまうのです。

 これはさすがに問題があると考えたのですが,こんな話は聞いたことがありません。次第に短くなった時間から進行性の問題だとも思ったのですが,果たしてそんな話があるのかというと,かなり疑問です。(とはいえないわけではありません。私が使っているラックマウントのアナログシンセMatrix-1000が,電源投入後10分ほどで暴走するということがありましたが,暴走までの時間が徐々に短くなっていきました。故障の原因は,プログラムを書き込んだマスクROMの故障で,時間の経過と共にデータが読み出せなくなると言う不良を起こしていました。ROMが読める内にEPROMにコピーして交換すると全く問題なく,現在も元気に動いています。)

 仕方がないので別のブリッジを使ったのですが,これはどうも相性が悪く,エラーが頻発します。一部変換を行っていないコマンドなりステータスなりがあるんでしょうね。必ずしも光学ドライブをサポート仕切れているとは限らないのが,この手のブリッジです。数年前,DVD+R DLを導入した際,ブリッジの問題でクローズ出来ずに困り果てた経験を思い出しました。

 なんとか騙し騙し作業を進めて一応完了したのですが,気持ち悪いしCD-Rへの書き出しが出来ないと困りますから,真面目に調べて見ることにします。

 まず,ブリッジの問題かドライブの故障かを切り分けます。

 PX-W5224Aの代わりにHDDを繋いで試しますが,全く問題なく動作します。残念ながらPX-W5224AをPATAで接続する環境がうちにはないので,別のブリッジを使いますが,エラーは出ても接続が切れるということはありません。ということは,ブリッジは故障しておらず,PX-W5224Aもたぶん壊れていません。

 では,Windowsのせい,PCのせいかも知れません。MacBookProに繋いでみましょう。結果はやはり10分ほどで接続が切れます。ということは,OSやホストに関係ないということになります。

 これは,もうブリッジチップとドライブの相性と考えるのが妥当ということになってしまい,手がありません。ブリッジチップがかなりの高熱を発していることも気になります。

 今回問題となっているブリッジは,GL811Eという有名なチップを使った凡庸なものです。GL811Eはひところ大変評判の悪いチップだったようですが,高速とは言えないまでも,安価ですし,私個人は汎用性の高さで結構気に入っているチップです。

 このGL811Eについてgoogle先生に聞いてみると,どうやらプレクスターのドライブとは相性が良くないらしいのです。このチップを採用したHDDケースのFAQには,はっきりとプレクスターのドライブには未対応と書いてあるくらいです。

 さらに,あるサイトで,プレクスターのドライブに対応できるようなGL811E用のアップデータが用意されていることも知りました。アップデータといってもファームウェアのアップデートではなく,GL811E内蔵のEEPROMに書かれたパラメータを修正するもので,どうやらこれでプレクスター対応になるらしいのです。

 ダメモトでこのアップデータを書き込んでみました。すると,なんとこれまで出ていた問題はすっかり消えて,いつまでたっても接続が切断されません。数を見ていないので断言は出来ませんが,おそらく読み込みも書き込みも大丈夫でしょう。

 ちなみに,随分昔に買った2.5inchのHDDケースに入っていたGL811(Eはつかない)にこのアップデータを試みましたが,デバイスを認識してくれず,書き込むことが出来ませんでした。

 しかし,こんなことであっさりと解決してしまうなんて,ちょっと複雑な気持ちです。確かに面白いなあと思うのですが,これまで4ヶ月かけて行ったCDのリッピングを全部やり直すことになってしまうと,もうこれは立ち直れません。そんな必要はないと思いますが,ちょっと注意をしておかねばならないなあと思います。

文字コード探訪

 一昔前,Shift-JISやJISなどの文字コードが主役だった頃は私もこのあたりの話にしっかりついて行けたのですが,最近のUnicodeの話は,どうも断片的に耳に入ることが多く,まとまった知識がなかなか得られずに気持ち悪い想いをしていました。

 そこで一発奮起,複数の資料を矛盾なく統合して,私なりの理解を得ようと試みました。以下はそのまとめです。実際,本当に正しいのかどうか怪しいところもありますので,もし指摘があればぜひ頂きたいと思います。

 最初に基礎として,ASCIIコードについてです。7ビットのコードで,アルファベットと数字を表現するために生まれました。0x00から0x1F,0x7Fはコントロールコードとなっており,実際の文字は0x20から0x7Eまでに割り当てられています。

 日本では,後に半角カタカナと呼ばれるカタカナを0xA1から0xDFまでに割り当て,8ビットのコードとして使う事が一般的に行われてきました。

 では,Unicodeの話を始めましょう。

 事の始まりは30年近く前,1980年代の初頭に遡ります。ISOは1983年,世界中の文字を1つのコードで扱う事を目指し,統一文字コードの検討を開始しました。

 当時ISOは,日本のJIS漢字コードと呼ばれた16ビットのコードが成功を収め,一般家庭にさえもコンピュータやワープロが普及していく状況を評価しており,これを全世界の文字で出来れば素晴らしいと考えていたようです。

 JISでは,エスケープシーケンスを使ってASCIIと漢字を切り替えます。

 ESC $ @ または ESC $ B のあとに続くコードを16ビット単位で処理して漢字を表すとし,ESC ( B または ESC ( J のあとに続くコードはASCIIとして8ビットで処理します。

 また,ASCIIで使われる範囲のうち,コントロールコードのある0x00から0x1Fのみを避け,16ビットの漢字コードを上位と下位の8ビットいずれにおいても0x21から0x7Eの範囲で表現します。

 7ビットあれば伝送可能という利点もあるのですが,処理が煩雑ですし,文字列の途中からではそれが漢字コードなのかASCIIなのか判別できないので,結構面倒臭いものでした。

 Shift-JISはこうした欠点をカバーするために考えられたもので,半角カタカナを含んだASCIIコードのうち,使用されていない0x81から0x9Fと,0xE0から0xFCを上位8ビットに置き,この部分が漢字コードであることを表します。続く下位の8ビットは0x40から0x7Eと,0x80から0xFCを使いますが,スペースなどの記号や0x7Fというコントロールコードを避けています。

 当然JISとはコードが違いますが,文字集合という観点ではJISと同じと言えるわけで,実は文字集合と文字エンコードがここで分離したと考えることが出来るかも知れません。

 ASCIIと半角カタカナと共存でき,かつ既存のシステムを大きく変更することなく日本語対応させることが可能という利点を持つShift-JISは,MS-DOSを始め,多くのパソコンに使われるようになり,一般化していきました。

 ついでに1980年代後半から90年代にかけてよく使われたEUCについても触れておきます。UNIXを日本語対応させるという目的で考え出されたコードで,半角カタカナを含まないASCIIコードのうち,上位8ビットと下位8ビットのいずれにも0xA1から0xFEを使って,16ビットの漢字を表現します。

 半角カタカナは0x8EA1から0x8EDFまでにマッピングされ,ASCIIでは8ビットで扱う事の出来た文字が,16ビット必要になる領域に飛ばされています。その代わり,上位8ビットを見ればそれが漢字コードであることが分かる(つまりASCIIとの重複がない)こと,エスケープシーケンスを使わずに済むこと,下位8ビットが完全にASCIIと重複しないことがあり,Shift-JISが持つ利点に加えて,Shift-JISよりも「美しい」ため,こだわりの多いUNIXの人たちの間で圧倒的な支持を受けていました。

 1980年代後半までに日本ではこうした動きがあったのですが,ISOとしては全世界統一文字コードとして16ビット固定長のコードを使い,コントロールコードを避ける形で用意した94x94の面を,日本語,韓国語,中国語の現在の文字コードの規格に1面ずつ割り当てて行くことを考えていたようです。

 でも,ちょっと考えると分かるのですが,すでにこの三カ国語の文字だけでもカツカツ,これ以外にそれぞれの拡張文字や台湾,香港の文字,もちろん他の国々の文字などを考えると,もう全然16ビットでは足りないことが分かってきます。

 そこでISOは16ビット固定長のコードをあきらめ,32ビット固定長で検討に入ります。これが後にUCS-4と呼ばれることになります。

 32ビットのうち先頭の1ビットは符号ですので,実質31ビットで扱う事の出来る文字数は実に21億文字以上となり,これだけあればまず困ることはないと思われますが,それまで8ビットですべてを表現出来ていた言語圏の人にとってはデータ量が4倍も増えることになり,ちょっともったいない所があります。

 こうしたこともあってか,ISOとは別にアメリカのコンピュータメーカーが中心となって統一された文字コードを作ろうという動きが出てきます。こうして誕生した団体がUnicodeコンソーシアムです。

 Unicodeコンソーシアムの検討には16ビット固定長という前提条件がありました。しかし,ISOがそうだったように,65000程度の文字数では,とてもすべての文字を割り当てられません。そこで日本語,韓国語,中国語で字源的には同じで,字形の異なる漢字に同じコードを与えるハンユニフィケーション(Han Unification)と呼ばれる方式を採用することになりました。

 この方法によって統合された漢字をCJK統合漢字といいます。かくして,Unicodeは16ビット固定長による,文字コードの統合に一応の決着を付けました。

 さて一方のISOは1991年,かねてから検討していた32ビット固定長の文字コードを使ったドラフトを投票にかけますが,すでに存在したUnicodeとの競合を避ける流れに飲まれ,否決されるに至ります。

 そこでISOは32ビットの文字コードのうち,先頭16ビットがすべてゼロの領域にUnicodeの16ビットコードを取り込むことで,Unicodeとの統一を図ります。

 1993年,この案は採択され,ISO/IEC10646-1として規格化されます。ここで規格化された32ビットコードはUCS-4と呼ばれ,このうち先頭16ビットがゼロの領域に割り当てられたUnicodeとほぼ同じ文字をBMP(基本多言語面)と呼ぶようになります。

 ところで,上位16ビットがすべてゼロであるBMPだけを扱うときは,ゼロが列んだ部分は省略したって構わないわけで,下位の16ビットだけを使うコードをUCS-2といいます。

 よく,UnicodeがISOを食ったとか,ISOを潰したとか,そういう物騒な話を耳にすることがありますが,それはこのあたりの話です。

 1993年のISO/IEC10646-1では,取り込んだUnicodeで使用している下位16ビットしか文字を割り当てることはしなかったのですが,2001年にはようやく上位の16ビットにも文字の割り当てを行うことになり,ISO/IEC10646-2として制定されます。しかし2003年には,両者を統合してISO/IEC10646をして再出発します。

 ここで,お約束です。Unicodeでは,文字の表現をU+という記号を頭に付けた「コードポイント」という数値で表現します。

 先程出てきた16ビットのUCS-2で「ABC」を書くと,はU+0041 U+0042 U+0043と表現されます。都合のいいことに,下位8ビットはASCIIと同じです。

 これが32ビットのUCS-4だと,「ABC」は,U+00000041 U+00000042 U+00000043と表現されます。お気づきと思いますが,上位16ビットは全部ゼロ,下位16ビットはUCS-2と同じです。これは,上位16ビットがゼロの時には下位16ビットはUCS-2と同じにすると言う,ISOがUnicodeを取り込んだという,まさにその結果です。

 さて,国際規格に自分達のコードを格上げできた勝者のUnicodeですが,同じ字源とはいえ,字形の違いがあるのはそれらを母国語とする人々にとっては面白くありません。

 そもそも,割り当て可能なコードが圧倒的に足りないことはUnicodeとしても問題で,結局Unicodeは「16ビット固定長」というポリシーを捨て,U+0000からU+FFFFまでに加えて,U+10000からU+10FFFFまでの約100万文字分を追加することを決定します。つまり,Unicodeは16ビットから21ビットに拡張されてしまった事になります。

 これをUnicodeの敗北という人もいますが,私はそうは思いません。事実,16ビットで決めた範囲で十分な場合も多いですし,そこで不足する分を足りないままで放置するのではなく,ちゃんと拡張するという方法で対応したことは,非常に誠実なことだと感じています。

 とはいえ現実的な問題として,すでにUnicodeは16ビットの範囲を使い切っていますので,増えた100万文字をなんとか表現する方法を考えねばなりません。そこで,これまでに割り当てのなかった上位サロゲートと呼ばれるU+D800からU+DBFFと,下位サロゲートと呼ばれるU+DC00からU+DFFFの2つを組み合わせを用い,拡張された部分を表現するときには32ビットを使うことにしました。(0xDBFF-0xD800)x(0xDFFF-0xDC00)=1024x1024=1048576で,ほら,一気に100万文字も増えたでしょう。

 上位と下位の2つのサロゲートで生まれた領域なので,これをサロゲートペアと呼びます。UTF-16と呼ばれるこのエンコード方式を導入して1996年に誕生したUnicode2.0は,これまでの65000文字に加えて,トータルで約110万文字を扱うことが出来るようになりました。ただし,このUTF-16が正式にRFCで制定されたのは随分遅くて,2000年です。

 UTF-16は,UCS-2を超えた範囲の表現に32ビットを使うという仕組みですので,UCS-2で表現出来るものは16ビットのままです。従って「ABC」はU+0041 U+0042 U+0043とUCS-2と同じになります。

 ここで誤解がないようにしたいのですが,後で出てくるUTF-8と今回のUTF-16は,同じUTFとなっていても,全く違う目的で作られた,全く異なるものだということです。UTF-16はあくまでサロゲートペアを使ってU+10000からU+10FFFFまでのコードをこれまでの16ビットのUnicode(つまりUCS-2)と混在させるために生まれたもので,UTF-8というのはASCIIの文字領域にUCS-2なりUCS-4を埋め込むものです。だから,UTF-16をUTF-8でエンコードすることも可能です。

 そんなこんなで,ISO/IEC10646はUCS-4という元々の4バイトコードで約21億文字,UCS-2というUnicode1.0そのものの2バイトコードで65000文字を規定することになり,一方のUnicodeは1.1までが2バイト固定長の65000文字,2.0でサロゲートペアとUTF-16の導入によって2バイトもしくは4バイトの可変長コードで約110万文字に拡張されることになったわけです。
 
 さらに話は進み,32ビット(実質31ビット)固定長でU+0000000000000000からU+7FFFFFFFFFFFFFFFまでの約21億文字分をカバーする最強のコードだったUCS-4は,2006年の改訂において,UnocodeがサポートするU+0000からU+10FFFFの110万文字のコード以外は永久に使用禁止,と決まるに至って,ISO/IEC10646とUnicodeはその基本的な能力を統一されることになりました。UCS-4は,とうとう牙を抜かれてしまったわけです。

 ところで,UCS-4もUCS-2(Unicode1.1)も,16ビットなり32ビットの空間をすべて使う事を前提としています。当然,これらを8ビットごとに区切った時に,ASCIIでコントロールコードに割り当てられている部分を避けるなどの配慮はされていませんから,UCS-2やUCS-4をそのままモデムなどの伝送路に流し込んでしまうと,偶然コントロールコードになってしまったある8ビットを誤認してしまうことになります。

 そこでコントロールコードを含むASCIIコードの部分は8ビットでそのままASCIIコードを示し,それ以外のコードを16ビットから48ビットの8ビット単位による可変長で表現するという文字エンコード方式が考え出されました。これがUTF-8です。

 こうすると,どの8ビットもコントロールコードを避けるように出来ます(もちろんわざとコントロールコードを流したい場合は別です)。言い換えると,UTF-8というのはUCS-2やUCS-4というバイナリコードを,テキストに変換する,なつかしのuuencodeとかbase64とかISHなどと同じ役割を果たしていることになりますね。

 ところで誤解のないようにしたいのですが,UCS-2にもUCS-4にも,コントロールコードは存在します。UCS-2におけるU+000DはCR(キャリッジリターン)ですし,U+000AはLF(ラインフィード)という,おなじみのコントロールコードです。

 エンコードというと符号化という日本語が割り当てられて,なんだか分かったような分からないような気分になるのですが,どうも英語で言うencodeには,ある数字を別の数字に置き換えることを広く示しているきらいがあり,正確な表現でないことを承知の上であえていえば,UTF-8などは「再マッピング」がもっともイメージの沸きやすい表現ではないかと思います。つまり,UCS-2やUCS-4を,ASCIIのコントロールコードを避けてテキストに割り当てられたコードに再マッピングを行うのが,UTF-8でやっている「エンコード」というわけです。

 余談ですが,Shift-JISという一昔前の漢字コードをこうした視点で見てみると,ASCIIに16ビットのバイナリである漢字コードを再マッピングしたという点ではUTF-8的であり,目的もUTF-8と同じだったりするわけですが,実際に行われた手法というのは空いているコードにASCIIからはみ出たコードを割り当てて8ビットと16ビットの可変長しているわけですから,極めてUTF-16的です。目標はUTF-8,やり方はUTF-16というのが,Shift-JISの正体というと,ちょっと言い過ぎでしょうか。

 UTF-8ではその昔(具体的には制定された1998年から2003年まで),UCS-2だけではなく,UCS-4もエンコード出来る事になっていたわけですが,2003年に新しいRFCによって規定されたUTF-8ではUTF-16で規定された範囲のみを扱う事になり,8ビットから32ビットの8ビット単位による可変長として再定義されました。これにより,UTF-8はUCS-4の範囲のすべてを扱う事が出来なくなってしまったわけですが,前述のようにUCS-4は2006年にUTF-16と同じ文字しか扱わないことになりましたので,これで実害はありません。

 UTF-8の面白いところは,8ビットのASCIIだけで間に合っている人たちにとっては8ビットだけでよく,16ビットで間に合っている日本語においては24ビットまでですべてを扱う事が出来る,という点でしょう。

 確かに16ビットで済んだところを24ビット必要だというのですからデータ量が増えることになりはしますが,16ビット固定長だったものが24ビット可変長になるわけですから,必ずしも1.5倍になるわけではないという点で,少なくとも日本語を扱うシステムにおいては,だたちに損になるという話ではなさそうです。

 それでいて,UTF-8を使えば100万文字を越える文字数を扱う事が出来るわけですから,これが本命として普及しているという話もなるほど納得というところでしょうか。

 最後にお詫びです。まず,UTF-16などの16ビットコードでは,エンディアンの問題がついて回ります。最初にリトルエンディアンもしくはビッグエンディアンと決めておく方法(UTF-16BE,UTF-16LE)もありますし,どちらのエンディアンを使っているかを示すマーク(BOMといいます)を頭につける方法もあります。しかし,これを言い出すとエンディアンとはなにか,から話をしなければならず,ややこしいので,本文では触れないことにしました。

 あと,異文体を扱う事の出来るVariation Selectorについても触れないことにしました。確かに重要なことではあるのですが,文字コードの体系を歴史的に整理するという目的から外れてしまうので,Unicode3.2に初めて登場し,Unicode5.1でようやく漢字の異字体に使われるようになったという比較的新しい仕組みについては,またの機会にしたいと思います。ちなみに,この仕組みを使うと,漢字一文字に64ビット必要になることがあるということだけ,雑学の1つとして覚えておいても良いかもしれません。

 もう1つ,コードの長さを言い表すのに,私は「ビット」を使いました。しかしこれは適当ではなく,本来なら8ビットを1まとめにした「オクテット」という単位を使うのがふさわしいです。

 ん?8ビットならバイトとちゃうの?と思うかも知れませんが,習慣でそうなっているだけの話であり,実は1バイトは必ずしも8ビットと決まっているわけではありません。ですから厳密に表現したい場合には必ず「8ビット」を示すオクテットという単位を用いることになっています。

 過去の話は別にして,現在は1バイトが8ビットとして浸透していますし,別にそれで問題はないのですが,文字コードや通信の世界では(うるさい人が多いこともあってか)オクテットを目にすることが多いのです。ですから,UCS-4は32ビットで間違いはありませんが,どちらかというと4オクテットという言い方の方が正しいわけです。

 間違っても4バイトと言ってはいけません。文字コード厨にこっぴどくやられてしまいます。

 さてさて,こんな感じで全世界の文字に数字を割り振ってコンピュータで使っていきましょうという壮大なお話をまとめてみましたが,1つだけ。

 実は現在すでにUCS-2という言い回しは存在しないことになっています。なぜなら,UCS-2はUCS-4に取り込まれていますし,そのUCS-4を表現するために生まれたUTF-16を使えば,UCS-2の範囲なら全く同一のコードとなりますので,単独でUCS-2が存在する必要性が全くなくなっているからです。

 さらに,前述のようにUCS-4はすでにUnicode2.0以降と統合されていますので,現実的に「Unicode」と言いさえすれば,もうややこしい過去の経緯や,ISO/IEC10646との関係,UCS-4やUTF-16といった細かい話を全く考慮しなくても,100万文字を越える世界中の文字を表現出来る文字コードを唯一示すことが出来るようになっています。

 だから,Unicodeを書き表すための数字のことをUTF-16ということを知っていれば,つまりUnicodeという言葉と,UTF-16という言葉を知っていれば,多言語の文字を扱うことに困りはしません。外と通信するときにUTF-8という「再マッピング」手段をしっていればなお良く,しかもUTF-8とUTF-16は全然別物と覚えておけば,もうそれで十分すぎると言うことができるでしょう。

 今後も,Unicodeという民間団体と,国際機関であるISOとの間で,食い違いが起きないように両者が歩み寄って,この仕組みを維持しようとしています。ひょっとすると同じ事をゴールに置く2つの団体と2つの仕組みが,デファクトを争っていたかも知れない過去を知ると,国際規格の本当の意味を見失わなかったISOという団体と,そしてISOに投票権を持つ国々の良心に,拍手を送りたくなるのです。

 現在Unicodeの(規格全体の)バージョンは5.2.0。昨年10月に制定されましたが,部分的には今年の5月にもアップデートが行われていますし,現在も活発な議論が行われています。人間らしさの源,文化の代表である文字をすべて網羅するという,人類の夢と理想に向かって歩き続けるこの活動こそ,世界平和に貢献するのではないかと,そんな気さえしてきました。

 付録として,軽く各バージョンをまとめておきます。

Unicode1.0 1991年10月 
16ビット固定長,日本語を含む約7600文字

Unicode1.0.1 1992年6月
CLK統合文字を採用。28000文字。

Unicode1.1 1993年6月
ISO/IEC10646に取り込まれる。約34000文字。

Unicode2.0 1996年7月
サロゲートペアを導入し21ビットに拡張。約39000文字。ハングルを大移動させたため1.xとの互換性がなくなる。

Unicode2.1 1998年5月
ユーロ記号を追加。約39000文字。

Unicode3.0 1999年9月
地名人名に使われる漢字が追加。約50000文字。かつてハングルのあった場所に多くの漢字が割り当てられる。

Unicode3.1 2001年3月
さらに漢字が追加され,BMP以外にも割り当てられる。約94000文字。

Unicode3.2 2002年3月
異字体セレクタが登場。約95000文字。

Unicode4.0 2003年4月
16しかなかった異字体セレクタが256に増加。約96000文字。

Unicode4.1 2005年3月
古代ペルシア語など言語を追加。約97000文字。

Unicode5.0 2006年7月
バリ文字,フェニキア文字,くさび形文字が追加。このあたりからどんどんマニアックに。約99000文字。ISO/IEC10646の改訂によりUCS-4がUnicodeと一致。

Unicode5.1 2008年4月
さらに多くの言語が追加された上,なんと麻雀パイまでサポート。異字体セレクタが漢字にも使われるようになる。約100000文字。

Unicode5.2 2009年10月
BMPに各国語が追加され,サロゲート領域にはヒエログリフなども追加。ついでにARIB外字も追加。約107000文字。

Unicode6.0 2010年9月予定
現在ドラフトの段階。砂時計,巻戻しや早送りのマーク,原子力マークやピースマーク,再生紙マーク,果てはドクロマークなどの絵文字が含まれる予定。約109000文字。

ページ移動

  • ページ
  • 1
  • 2

ユーティリティ

2010年06月

- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 - - -

検索

エントリー検索フォーム
キーワード

ユーザー

新着画像

新着エントリー

過去ログ

Feed