エントリー

カテゴリー「マニアックなおはなし」の検索結果は以下のとおりです。

Kindleが日本にやってくる

 来るぞ来るぞといわれても,ちっとも来なかったKindleの日本上陸が,とうとう昨日発表されました。

 e-Inkを搭載するKindlePaperWhiteが3Gありとなしで2バージョン,タブレットであるKindleFireが2機種の,計4機種が導入されます。これに先だって,本日からKidleStoreがオープンし,電子書籍を購入することが出来るようになりました。

 端末がまだなのに?と思った方,違うんですよ,Kindleというのはいわばサービスを含む全体の名前です。Kindleストアで購入した電子書籍を読む事は,PCやMac,android版のリーダーアプリがあれば可能です。

 端末が手に入った暁には,先に購入したコンテンツを端末で読む事が出来るようになります。

 おおむね,端末の発売日に対してコンテンツ側の準備というのは遅れる物ですので,Kindleが先にコンテンツの販売を行い,端末は後からと言うのは,ちょっと珍しいなあと個人的には思っています。普通に考えれば,最大の難題と言われたコンテンツ配信に対する出版社の抵抗は,すでにもう過去の話になっているという,その証になるのではないでしょうか。

 不可解なのは端末が早い物でも1ヶ月ほど遅れてリリースされることです。

 Paperwhiteの国内発売は11月19日ということです。しかし,海外ではすでにリリースされていますし,海外版でも日本語のサポートはあるという話ですから,今回の日本導入に際して大変な作業があったとは考えにくく,サービスインにハードウェアが間に合わないというのは,なんとも解せない話です。

 邪推すれば,Paperwhiteは海外でもよく売れていて,品薄になっています。生産能力から考えた場合に,日本向けの台数を確保するのに,これだけの時間がかかったと考えるのが自然かも知れません。

 Paperwhiteの一番安いWiFiモデルは8000円台,3G搭載でも13000円弱です。通信費用や契約が必要ないというKindle最大の利点は日本版でもきちんと継承されましたから,やっぱamazonは黒船だなあと感心します。

 KindleFireも安いですね。先日googleがNEXUS7を19800円で発売して話題になりましたが,これが霞んで見える価格です。アメリカでの販売価格を為替レートで換算してもさらに安い価格ですので,このあたりもamazonの本気を感じます。

 そういえば,ヨドバシ.comがNEXUS7の取り扱いを中止したときに,ちょっとした憶測が流布しましたが,今にして思えばiPadminiとKindleFireに対する防御策だったのかと思います。とはいえ,NEXUS7は純粋なandroidタブレットですから,iPadともKindleFireとも比べようのない製品なわけで,直接関係ないと思うのですが・・・

 さて,私はKindleDXと3rdGenのKindle(以下Kindle3)をamazon.comから買ってほぼ毎日使っています。稼働率から言えば,KindleDXが圧倒的です。これは,画面サイズとピクセル数の関係から,文字の潰れが文芸書くらいまでならほとんど気にならないからです。

 Kindle3は文庫本を読むならなんとか我慢して読めるかどうか,というレベルだと思います。でも,文庫ならわざわざKindleで読む必要はなくて,紙のままカバンに突っ込んでいけば解決です。

 自炊をする私にとって,持ち歩くのが億劫になる分厚い本,あるいはハードカバーの文芸書を,小さく軽く持ち歩くことは最も期待する点であり,こうしたサイズの大きな本を,文字の潰れを気にせず気分よく読むためには,KindleDXでないと駄目だということがわかりました。

 ちょっと計算して見ましょう。

 文庫本をA6サイズ(105x148mm),文芸書をB6サイズ(128x182mm)としましょう。文字の潰れを,実際の紙の決まった範囲を何ピクセルで構成できるかという数字で表現出来ると考えます。

 9.7インチのKindleDXのピクセル数は832x1280ピクセルです。この画面にB6を表示してみると,紙の上で1cmの直線は約70ピクセルで表現され,画面上では約1.13cmに拡大されます。紙の上の1cmを70ピクセルで構成した場合を見慣れたdpiで換算すると,177.8dpiです。

 一方,6インチのKindle3のピクセル数は600x800ピクセルです。この画面にA6を表示してみると,1cmの直線は約54ピクセルで表現され,0.82cmに縮小されます。そして同様に見慣れたdpiで書けば,137dpiと換算されます。

 それでは,このKindle3でB6を表示するとどうなるか,1cmあたり約44ピクセルしか使われず,約0.7cmに縮小されてしまいます。かなり小さくなりますね。そしてdpiで書くと111.8dpiです。

 この結果から,文字の潰れがないようにするには,紙の上の1cmを最低54ピクセルで表現せねばならないことがわかります。Kindle3で文芸書を読むのは,かなり辛いことが数字からもなんとなく分かって頂けると思います。

 しかし,KindlePaperwhiteは,この根本問題を解決してくれそうです。パネルの解像度が,6インチモデルとしては唯一,768x1024ピクセルというXGAなのです。より白い色になったとか,フロントライトが付いたとか,そういうことも大事な進化ですが,解像度にも手が入ったことは,amazonもe-inkも,決して600x800ピクセルで満足していたわけではないことを示すもので,私はほっとした次第です。

 早速同じような計算で比較してみましょう。KindlePaperwhiteは6インチで768x1024ピクセルです。ここにA6を表示してみると,1cmの直線は約69ピクセルで表現され,0.82cmに縮小されます。見慣れたdpiで書くと175dpiとなります。

 続けてKindlePaperwhiteでB6を表示した場合です。1cmの直線は約56ピクセルで表現され,約0.7cmに縮小されますね。dpiで書けば142dpiです。

 なんだかよく分からない計算をやっているようになってしまいましたが,結果を見れば,商事が縮小されてしまうことを割り引けば,かなりKindleDXに近い品質の表示になってくれそうな期待があります。

 私は,日本導入の前にまたamazon.comから買おうかと思っていたのですが,日本導入が近いという噂も聞いていたので,ちょっと辛抱することにしたのです。

 聞けば,amazon.comのアカウントと統合されるので,amazon.comで買ったコンテンツも読めるようになるそうですが,アカウントを統合した後はamazon.co.jpからしか買えなくとのことです。

 これが即座に問題になることはないと思いますが,それもWiFiでの話です。3Gではamazon.comで買った海外版を国内で使うことは一応出来ない事になっていますから,3Gを使いたい人は日本版を買うしかありません。

 私は3Gで使いたいと,早速3G版を予約しました。amazonによると,日本語のフォントにもこだわったということですので,より白く,より高解像度になったKindlePaperwhiteが届くのが,とても楽しみです。

LaCie d2 QuadraをFireWireで使う作戦

 先日のLaCie d2 Quadraですが,eSATAで運用すれば2.5TBのドライブを認識して使う事が出来るという結論は,ちょっとまずいのではないかと思うようになりました。

 確かに認識してはいますし,ブリッジチップの中でやっていることは単にeSATAとHDDをスルーで繋いでいるだけの話ですから,トラブルは起きないんじゃないかと思いますが,USBやFireWireで2.2TB以上のドライブを正しく認識出来ない以上,やっぱりなにがあってもおかしくありません。

 こわいですね。例えばですね,ブリッジチップが自らなにかHDDに書き込むようなことがあると,今繋いでいる2.5TBのHDDは壊れてしまうかも知れないわけですね。

 そもそも,この問題は2.2TBの壁というよく知られた問題で,これまでの1セクタあたり512kByteで,32bitのアドレスという方式だと2.2TBまでしかアクセス出来ないという問題です。

 そこで,アドレスを64bitに広げることでこの壁を乗り越えるわけですが,なんといっても管理方法が根本的に変わってしまうので,不具合が出ても仕方がありません。

 ということで,なんとかしないといけないなあと思ったわけです。

 とはいえ,先日書いたようにLaCieの純正のアップデータはどうやっても動かすことが出来ませんでした。そもそもLaCie d2 Quadraに対応していると一言も書いていないので,駄目でも元々なわけですけども,それにしてもこの製品には3TBのものも存在するわけですから,出し惜しみしないで欲しいよなあと,思います。

 次に考えたのは,禁断の作戦です。

 LaCie d2 Quadraのブリッジチップは,OxfordのOXUF934DSBです。FireWire800に対応した数少ないチップですが,動作も安定し,速度も速いですから,定評があります。FiewWireに対応したHDDやHDDケースには,これが搭載されていることが多いです。

 このチップは,2.2TBの壁などなかった時代の製品ですが,後に内蔵のファームウェアがアップデートされて,2.2TBを越えるHDDを繋ぐことができるようになりました。

 ところがチップメーカーはファームウェアを公開していません。探し回ったところ,あるHDDケースのメーカーがファームを公開していました。

 このメーカーはご丁寧に,ファームウェアをアップデートした場合の弊害についても触れています。現在出荷されているHDDケースは2.2TBを越えられるものだが,これはFireWireからのブートが出来ないので,どうしてもFireWireからブートしたければ,古いファームウェアを書き込んで使えとあります。親切ですね。

 ただし,このファームウェアというのは結構くせもので,LaCieのようなベンダーだと,自分達の独自機能のためにベンダー独自のファームウェアを作っています。ベンダー名のカスタマイズくらいならよいのですが,ブリッジチップのGPIOを制御するような物だったりすると,ハードウェアとの兼ね合いもあるので,他社のファームウェアを無理に書き込めば,機能が失われるばかりか,最悪壊れてしまいます。

 かなり危険です。

 その,危険なファームウェアが,目の前にあります。付属のリリースノートを見れば,このバージョンは2.2TB越えに対応とあります。

 ということで,危険を承知でやってみることにしました。ファームウェアの書き込みに失敗すれば,8000円のHDDケースはただのゴミになります。無事に書き込めてもちゃんと動く保証はありません。LaCieの独自機能である自動電源ON/OFFについては,完全にアウトではないかと思います。

 本来なら,元に戻す方法を用意してから実行すべきですが,元に戻す方法は見つかりません。片道切符でGo!です。

 で,結果ですが,駄目でした。ファームウェアの書き換えすら出来ませんでした。当たり前と言えば,当たり前ですわね。バカバカしい。

 で,結局どうしたかというと,2TBのHDDに入れ替えました。NASには当初Pogoplugで使っていた2TBを入れていましたが,先日3TBに入れ替えたときに,1つ余ったものがあるのです。

 これに入れ替えると問題なくFireWire800で認識し,読み書きも当然問題なく出来ます。2,5TBのHDDからしょーもないデータを消し,2TBにコピーをして,早速運用を開始しました。2.5TBはもったいないので,動画関係を詰め込んでおきます。ただ,私の経験では,2TBまでなら安定して動いても,それ以上のHDDはどうも不安定で,安心して使えないのです。なかなか認識しないとか,フリーズするとか,そういう心配です。

 ですから,大事なデータを保存するには気が気でならないものがありました。2TBにすることで安心出来るなら,まあよかったんじゃないかと思います。

 とはいえ,HDDの価格はすでにタイの洪水前の水準まで下がって来ています。3TBも1万円を割るのが当たり前になっている現状で2TBという足かせがあるのは,ちょっと窮屈で嫌な感じです。

 しかも,D800のデータが強烈です。ちょっと撮影するとすぐに30GBを越えます。容量が大きいことは確かにお金で解決することではありますが,データの軽いD2Hとのハンドリングの違いは歴然で,D2Hに比べて慎重にシャッターを切るようになりますから,自ずとこの2つで撮影スタイルにまで大きな違いを生むことになります。

 まあ,そのうちFireWireも使えなくなるでしょうし,その時にはUSB3.0への移行を考えるようにしましょう。そのころにはD800も,普通のカメラになってくれるように思います。

TS-119PIIのファームウェアアップデート

 QNAPのNAS,TS-119PIIのファームが3.7.3にアップデートしました。

 心待ちにしていたものだっただけに,すぐにアップデートを行いました。最大の問題は新しいMacのOS,Mountain LionでTimeMachineによるバックアップが出来なくなってしまったことでした。

 MacBookAIrはさっさとアップデートしてしまい,TimeMachineが動かなくなってしまってから気が付いたのですが,この問題が解決するまでMacBookProのアップデートは行わない予定でした。

 macBookAirについては,TimeMachineの設定で,NASを直接指定(私の場合なぜかIPアドレスでの指定では駄目だったので,サーバーの名前で指定しました)することで暫定的に回避していましたが,やっぱり気持ち悪いものです。

 結論ですが,3.7.3になったことでこの問題は綺麗に解決しました。10.7のmacBookProでも,10.8のMacBookAirでも,問題なくバックアップ出来ています。

 3.7.3になることで,他の改善もあるようですが,私は3.7.1にTimeMachine以外の問題を見つけていないので,特に変わったという印象はありません。

 しかし,3.7.3にアップデートすることで,若干問題が発生したので書いておきます。

 1つに,TwonkeyMediaServerの設定が一部元に戻ったことです。大まかな設定などは復元されていますが,私の場合GUIから設定出来ない,フォルダ表示でトラック順にソートするような設定を行っています。これが元に戻ったので設定をしなおしました。

 もう1つ,perlが動かなくなっていました。これも,perlがアンインストールされたわけでも,Apacheの設定ファイルが元に戻ったせいでもなく,シンボリックリンクが切れてしまったことによるものでした。

 スクリプトに書かれたperlの場所にシンボリックリンクを張りなおして,これですんなり動くようになりました。

 大きな問題もなく,とりあえずなんとかなって助かったところです。

 ところで,個人でNASを保有し,結構便利に使っている人間としては,WesternDigitalのNAS用HDDであるREDシリーズが,私とっても気になります。(ここは氷菓っぽく読んでみよう)

 いつか3TBへの拡張もしないといけないと思っていましたから,ちょうど良い機会と思って,現在3TBのREDを注文してあります。8月中に手に入るかなあという感じなので気長に待ちますが,ホットスワップに対応しないシングルドライブのTS-119PIIで,うまくHDDの入れ替えを行う方法をどうしよかと,考えているところです。

 一番簡単なのは,外部ドライブとして新しいHDDを取り付け,これにQ-RAIDという仕組みを使ってミラーリングを行い,完了したところでHDDを入れ替える方法です。

 ただし,Q-RAIDで本当に大丈夫かという不安もありますし,コピーの完了には3日ほどかかるという嫌な話もあって,困ったなあという感じです。

 今にして思えば,ちょっとお値段が張っても,TS-219を買っておけば良かったなあと思うのですが,買ってしまったものは仕方がありません。

 もう少し考えてみます。

Mountain Lionをインストールしてみる

 7月下旬というアナウンス通り,日本時間の7月25日の夜,Mac用の新しいOS,OS X 10.8 Mountain Lionがリリースされました。

 価格は1700円という,有償のOSの価格としては安い価格設定です。機能は200を越えるという事ですが,見た目の違いが乏しいため,比較的地味なアップデートという感じがします。

 販売方法はダウンロードのみ。物理メディアでの提供は現時点ではないという話ですが,どうしてもブロードバンド環境がない人はApple Storeへ持ち込めとありますので,将来的にもダウンロードのみではないかと思います。

 容量は約4.3GBですので,私のような低速ADSLの人だと,実に4時間もかかってしまいました。趣味や仕事だけではなく,コンピュータの維持管理に光回線が必要になる時代が来ようとは,思ってもみませんでした。

 Mountain Lionのコンセプトは,クラウドとの親和性です。1つ前のLionでiOSとの距離を縮める戦略は十分に理解されたとみて良いですが,iCloudをOSでサポートすることで,iOSの搭載機器との間で,データのみならず,「今していたこと」さえもシームレスに連携することになりました。

 まあ,これってOSそのもの,あるいはMacそのものの高機能化というより,iOS機器との抱き合わせのような気がしてくるので,iPadやiPhoneを持たない(ついでにいうと反りが合わない)私のようなマイノリティにとっては,あまり魅力的に見えないアップデートのはずでした。

 セキュリティアップデートのつもりで1700円を支払ったわけですが,実際にインストールして使って見ると,その考えは間違っていたとの認識に至りました。

 ということで,私の独断と偏見による,Mountain Lionの注目すべきポイントです。

(1)完全64ビットOS

 今なお名作の誉れ高い10.6,Snow LeopardでMacOSは64ビットOSへの道を邁進してきたわけですが,巧妙な方法でアプリケーションは32/64ビットを区別なく実行出来るOSであることは,今回のMountain Lionでも代わりません。

 とはいえ,カーネルやドライバは両用には出来ませんので,起動時にどちらか一方を選ぶ事になります。もちろん,メモリ空間もパフォーマンスも64ビットの方が有利なことはいう間でもありません。

 Mountain Lionでは,カーネルやドライバが32ビットでは起動せず,64ビット専用となりました。自動的に,Snow LeopardやLionの時に64ビットモードで起動出来ない古いMacは,動作非対象となります。

 私はMacBookAirの2010年モデルを使っていますが,カーネルはもちろん,ドライバも完全に64ビットのものに揃っており,気持ち悪さが払拭されました。まあ,もともと私は所有する2つのMacのいずれも64ビットモードで動かしていましたので,そんなに変化があるという事ではありません。

 ただ,このことはもっと大きく扱われて良いと思います。Macは68000から68020や68030への移行時,68kからPowerPCへの移行時,PowerPCからx86への移行時,さらにMacOS9からMacOSXへの移行時に,互換性の問題を巧みに回避してきました。

 1つはエミュレーションで,1つはAPIの追加で,1つはフォルダを「アプリケーション」に見せるNeXT由来の技術で,我々は非互換という精神的にも大きな打撃のある問題を,直視せずに済んできたのです。

 気が付いたら移行が終わっていた,どれもそんな感じがします。しかし,その移行は大きな事件として常に取り扱われ,過渡期の対応策の巧みさが賞賛されることも常だったわけです。

 今PCの世界で起こっている64ビットOSへの移行は,まさにこれだと私は思っています。Macが今後も「コンテンツを創るマシン」として生き延びるには,64ビット化が避けられません。しかし,一方で保守的なクリエイター達が反発せず,32ビットから64ビットへの移行を「気付かないうち」に行わねばなりません。

 アップルとMacは,またしてもこの移行を,深く静かに行ったわけです。

 同じCPUですし,あまり違いが取り沙汰されることはないようですが,64ビットと32ビットでは,もう別物だと私は考えています。移行期であったSnow LoepardとLionは,大変に見事でした。

 そして満を持して,Mountain Lionで完全64ビットになったのです。脱落者は,そろそろ買い換えを行う方が良い古いハードウェアを所有する人達だけです。アプリケーションについては,相変わらず32ビットでも動作しますから,ここでの脱落者はいません。

 これでMacは,当分安定したコンピュータでいられるでしょう。なにせ64ビットのアドレス空間は途方もなく広大で,使い切るのに当分かかるはずですから。

 今回の移行は,アーキテクチャを根幹から変えてしまう大きな変革です。他のOSのように古いアーキテクチャと新しいアーキテクチャを混在させれば,メーカーは別に非難もされませんし,ユーザーも不満を訴えませんが,あえてそうしなかったアップルの,シンプルで美しものを求める姿勢は,相変わらず健在です。


(2)音声認識

 デフォルトではOFFになっている機能ですが,実は密かに凄いことになっています。音声合成(Text-to-Speech)は以前からそこそこ使えるものになっていましたが,いかんせん実用性が乏しく,実際に使っている人も少ないのではないでしょうか。

 これが音声認識となると,桁違いの技術的な難易度であり,実用性を議論する前に使い物になるかどうかという時代が長く続きました。私も,結局ニーズもないまま,音声認識は特殊機能まま終わってしまうんじゃないかと思っていました。

 ところが,Siriによって音声認識が使い物になることを示したアップルは,Macにも使い物になる音声認識を機能として入れ込んできました。

 コントロールパネルから音声認識をONにしてから,Fnキーを2回押すと,音声認識モードになります。音声を入力してからFnキーを1度押すと,しばらく悩んだ後に,ほぼ正確なテキストを入力してくれます。簡単な単語なら,まず間違いません。

 一種のインプットメソッドですので,テキスト入力が可能な場所ならすべて利用可能です。また,これまでによく見られた音声認識ソフトのように,音声入力の始まりと終わりをキーの押下で明示しないものではないため,長い話し言葉を文章にするとか,スピーチを書き起こすとか,そういう用途には向いていないと思いますが,それくらいに割り切ってあるから,この認識率なんでしょう。

 実際の所,Twitterのような短い入力を,いちいちキーボードから打ち込むのは面倒なときがありますが,音声認識を使えば文字通り,つぶやくことが出来るわけです。

 私も面白がって試して見ましたが,本体内蔵のマイクでも概ね良好な認識率でした。私としては,とりあえずカナで入力してもらって,かな漢字変換はATOKで出来ればより高い認識率を目指せるんじゃないかと思っていたのですが,そういうことは出来ないようです。


(3)NotificationのOSへの統合

 アプリケーションからの通知が,OSによって用意された通知エリアに表示されるようになった機能については,iOSの機能を取り入れたという文脈で語られることが多いのですが,少し違って見方をしてもよいと思います。

 ファイルの読み書きなどの標準的な入出力やメモリ管理,タスク管理という,どんなアプリにも必要な機能を,共通のソフトとして用意しておくという発想から生まれたのが,Operationg Systemというソフトウェアです。

 OSは基本的なサービスを提供するだけではなく,GUI,グラフィック,検索などの機能も取り込み,それぞれのアプリケーションに提供するようになりました。現代のコンピュータ,とりわけパーソナルコンピュータにおいてOSの果たす役割は極めて大きいと言えます。

 それだけ肥大化したOSにおいて,アプリケーションからユーザーに対して知らせる通知が,各々のアプリケーション任せになっていたことは,考えてみれば不思議なことです。特にマルチタスクが当たり前になった現代のOSで,バックグランドのアプリからの通知が,それぞれに任されているというのは,非常に不自然でした。

 おそらく画面の広さという制約からでしょうが,androidではここをちゃんとOSでサポートしていて,アプリはOSに通知したい内容を渡せば,すべてのアプリに共通化された方法で,通知が行われるようになっていました。

 iOSはこの方法をパクったわけですが,さらにこれはOS Xにも導入されることになりました。これまでアプリが個別に行っていた通知を,一度OSが集約し,OSがユーザーに共通の土俵で伝える仕組みに整理されたわけです。これにより,タッチパッドのジェスチャー入力とも紐付けられ,「大きなお世話」と感じずに済む程度の,絶妙な通知を行ってくれるようになりました。

 Macでは,growlという通知を出すためのフリーソフトが事実上の標準となっており,これに対応したソフトは多く存在しました。私はgrowlは好きにはなれず,全く使っていませんが,この機能が全体のバランスを崩さない形でアップルの手によってOSに統合されるのであれば,大歓迎です。

 Macほど,アプリケーションの流儀にうるさいマシンもありません。どんなAPIを使えとか,そういう話のみならず,その背景や思想まで記述されたガイドラインに従ってソフトを書かねばなりません。なのに,通知をOSでサポートしていなかったというのは,今思えばおかしな話だと思います。


(4)Safari6

 Safariは良くなりました。滑らかになりましたし,高速になりました。私はQNAPのNASを使っていますが,WEBからNASの設定を行う際に,そのキビキビした動きはあらゆるブラウザの中でもはっきりわかる速度です。

 Safariで面白いのは,検索フィールドがなくなったことで,アドレスを入力するフィールドと統合されました。それがURLなのか検索文字列なのかを判断するロジックが入っているわけですが,慣れてしまえばこっちの方が絶対に便利だし,自然です。なにせ,我々はそのWEBページを見たいわけで,手段はどうでもいいのですから。


(5)全体的な速度と快適性

 SnowLeopardからLIonになった時,ちょっと引っかかるような不愉快な感じがあって,残念な気持ちになりました。しかし,今回のMountain Lionは全体にサクサク感が増して,スムーズに動くようになりました。スクロールの端に到達したときのスプリングも少し小さな動きになり,全体の小気味良い動きを後押ししています。


 というところで,全体的に好印象なMountain Lionですが,当然メジャーアップデートですから問題点も出ています。

 まず,QNAPのNASでTimeMachineが動作しなくなったことです。同じ症状の人がそれなりにいるようで,NASのファームウェアがアップデートするまで,TimeMachieは使えません。Lionの時にも同じ事があったそうですが,なんで事前に対応して置いてくれないのかなあと,思います。バックアップの話ですから,早めに解決して欲しいです。

 次に,ソフトウェアアップデートがAppStoreに統合されたことです。長年親しんだソフトウェアアップデートは,OSのアップデートなどの重要なものが一目で分かるものだったのですが,これがAppStoreに統合されると,他のアプリと同じ扱いになってしまい,あまり目立ってくれません。また,AppStoreって無駄に画面が広いので,面倒臭いなあという印象が先に来ます。ま,これは慣れればどってことないかも知れません。

 不具合らしいものは,今のところこのくらいですが,作業用のマシンであるMacBookProへのインストールは,少なくともNASでTimeMachineが動くようになってからにしたいと思います。ソフトの互換性やドライバの問題などで,いろいろ面倒が起こりそうな気がします。

 ということで,1700円という価格なら,やっぱりやっとくべき,アップデートだという結論です。マシンの買い換えまで必要かと問われれば,そこまでではないかなと思いますが,対象機種の方ならやって置いた方がよいと思います。

NASのセットアップ完了・ネットワークオーディオ復活

 DLNAサーバをPogoplugからQNAPのNAS「TS-119PII」にリプレースして少し時間がかかってしまいましたが,昨日の夜ようやくすべての移行作業が終了しました。

 いやー,たいへんだった。

 豊富な機能をどこまで使うのか,その計画もなかなか立たないなかで設定を開始しましたが,幸いなことに基本的な設定とWEBサーバの移行は数日のうちに完了し,すっかり気をよくしていたのですが,やっぱり大変だったのはDLNA,特にネットワークオーディオ用のサーバでした。

 そう,WEBサーバはApacheがインストール済みなのでそのまま使うのであれば何の手間もありません。ただ,私の場合今の自前のホームページをそのまま持って行きたかったので,perlによるCGIが動いて欲しくて,そこが問題かなあと思っていました。

 が,これもあっさり解決。QPKGからperlをインストールすれば,ほとんど設定無しでperlが動き出しました。やったことといえば,シンボリックリンクを張ったことくらいでしょうか。

 ウイルスチェックの機能も気休めでもONにしましたし,SMARTによるHDDのチェックも定期的に実施しています。なにか警告が出ればメールが届くようにもしました。timeMachineのドライブに設定して,私のMacBookProとMacBookAirのバックアップも完璧です。

 しかし,DLNAによるネットワークオーディオ用のサーバ整備が大変でした。

 いやいや,技術的にはなんの問題もなかったのです。もともとLINNの推奨品であるQNAPのNASですから,決められた設定をちょこちょことやれば,もう問題なく動き出します。Pogoplugのように試行錯誤も必要なく,タグ入りのFLACを再生することも,ジャケ写をfolder.jpgとしてフォルダに入れておけばちゃんとジャケ写を表示出来ることも,簡単に確認出来ました。

 しかし,Pogoplugのときは,タグを埋め込めないWAVファイルで,かつリニアPCMのみの対応で,ジャケ写も出せませんでしたから,むしろ用意する音楽のファイルはとてもシンプルで,ほとんど手間がかかりませんでした。

 これがQNAPのNASになると,いろいろ出来る分だけ手間をかけて用意したくなるものです。容量を節約するためにFLACにし,ちゃんとタグを打ち込み,ジャケ写も表示したいです。

 しかし,これがとっても大変な作業になります。今あるWAVファイルをFLACに変換するか,それともCDのイメージから新たに作り直すのか,そこから悩みました。なにせ膨大な数のCDを処理しなければなりません。最初の計画にしくじれば,時間がかかるだけではなく,結局失敗なんてことになりかねません。

 いろいろ考えたのですが,CDのイメージから作り直すことにしました。XLosslessDecoderという定評あるソフトを使って,分割されたFLACを作ります。メタデータはFreeDBから取得してくれますし,なかなか処理も高速で好都合です。

 ただ,ちょっと不親切なところもあり,まずちゃんとしたマニュアルがありませんから,相応のリテラシーがなければ使いこなせません。私は出力ファイルのフォーマットをいじれることに気が付かず,前回のpogoplugの時も,初期設定で出てきたファイル名をリネーム用のツールに正規表現を使って後でリネームするという手間をかけていました。

 今回は,こんな手間はかけたくありません。調べてみると,アルバムごとにフォルダを分けて,ファイルネームのフォーマットも自由にいじれることがわかって,一気に作業が加速しました。いいツールなんですけどね・・・

 とりあえずすべてのCDをFLACにして,あとは手作業でタグの確認をしていきます。そして目処がついたらNASにコピーです。最後にfolder.jpgを入れて終わり,のはずでした。

 ところが,どうもコピーの速度が遅いのです。とんでもなく遅い。おかしいと思ってafpではなくsmbで同じフォルダに接続すると,爆速です。どうもこのNASはsmbでの接続で真価を発揮するようです。

 といいますか,もともとafpは効率も悪く,速度も遅いことで知られています。Macだからafpと決めてかかっていた私は,自分がネットワークの世界ではマイノリティであることを忘れていました。

 そこで以後はsmbで作業を行ったのでですが,ファイルネームの化けがちらほら。どうしたものかと思ったのですが,どうもこれはafpでコピーしたものをsmbでアクセスした場合におこってしまうようです。

 最初は原因がわからず,きっとXLDでデコードしたときに化けたのだろうとデコードからやり直していたのですが,これだとすべてのファイルを確認しなければならず,膨大な時間がかかります。

 原因が分かってからは,途中までの作業を放棄してafpでコピーしたファイルを全部NASから消去し,smbでコピーし直しました。これでこの問題は解決。

 次にジャケ写です。これはfolder.jpgをフォルダに置けばよいのですが,2000枚近いジャケ写をまた集めてくるのはあまりに大変です。そこでiTunesのライブラリから引っ張ってこれないものかと調べてみました。

 すると,あるものですね,AppleScriptで書かれたもので,ジャケ写をjpgに変換してアルバムタイトルのファイルネームで保存するものが見つかりました。これで一気にジャケ写の画像ファイルを作成します。

 しかし,これを各アルバムのフォルダに入れるのは手作業です。コツコツとここ数日,嫁さんと子供が寝息を立てる横で,作業を進めた結果昨日の夜にようやく完了したわけです。

 すべてのアルバムを確認したことで,変換ミスや抜け,タイトルの間違いなども見つかりましたし,こんなアルバム持ってたのか!やら,持ってると思っていたアルバムを実は持っていなかったなど,いろいろな発見がありました。

 すべてのアルバムを聴いて試すわけにいかないのですが,いくつかのアルバムを無作為に選んでN-30から聞いてみますと,ちゃんと動作しています。

 QNAPのDLNAサーバであるTwonkyMediaは,フォルダで音楽を探すと,ソートの順番が狂うのですが,これも設定ファイルを直接いじることで解決しました。とにかくうまく動いてほっとしています。

 おかげさまで,ついつい音楽を聴いて楽しんでしまい,練るのがすっかり遅くなってしまいました。久々に楽しい時間を過ごしたのですが,こういうことがあるから手間がかかってもやめられないんでしょうね。

 ということで,NASの問題はひとまず終了。今のところ目立ったトラブルもなく,快調に動いています。次のテーマはNASのバックアップです。

 これだけ苦労して環境を整えたのですから,データを失ったらもう二度とやる気が起きないでしょう。こんなことなら2ベイのモデルでRAID1を組むべきでした。個人用のNASでそこまで大げさなことはいらんだろうと1ベイにしたのですが,どうも精神的な不安が大きくなって,困ったものです。

 TS-119PIIは1ベイモデルでホットスワップは出来ませんが,eSATAやUSBで繋いだHDDにミラーを作り,これと本体のドライブを入れ替えることは出来るそうです。

 ミラーを今作るのがよいか,それともHDDを交換する時までやめておくか,ちょっと悩みどころです。内蔵したWDのHDDは,現時点で元気そのもので,動作時間の積算もまだ寿命に対して10%未満という状態です。

 PC用の安いドライブですので,簡単に壊れることでしょう。SMARTで予兆を見つけて,次はもう少し信頼性のある3TBのドライブを導入したいと思っていますが,その時までミラーを作るのを待ってもいいかなあと思っています。

 せっかく苦労して用意したNASです。もっと有効活用したいと思いますし,家族で文字通りファイルの共有をやりたいと思っています。


 

ページ移動

ユーティリティ

2020年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