引きこもりでもニートでもないのは部屋にこもって仕事をしてるからなんです

2015年11月3日火曜日

インターネットラジオの録音に関する考察（その３：聴取・録音機能の詳細設計）

前回のポストで、ストリーミング配信ラジオの聴取・録音方法についてまとめました。で、それをもとに詳細設計をする、ということなんですが、これも前回書いた通り、バックグラウンドで必要なソフトを立ち上げるだけでいいわけです。

もうちょっと細かく言うと、
・選局する(聴取・録音するラジオ局を選ぶ)
・聴取の場合は聴取のためのソフトを立ち上げる
　＃rtmpdumpだったりffplayだったり
・録音する場合は録音のためのソフトを立ち上げる
　＃rtmpdump/ffmpeg

聴取するだけなら実は本当にこれでよく、局を変える時もその都度立ち上げたり終了させたり、というだけでいいんですが、問題は録音です。今聴いている局を今から録音する、というシチュエーションは現状では考えにくく(昔のFMではよくやってましたね。好きな曲が流れるまでずっと待っていて、かかった途端に録音ボタンを押したり、あらかじめ録音ボタンと一時停止ボタンを押しておき、一時停止ボタンを解除する、というアレ。懐かしいなぁ・・・)、予約録音をするのが一般的なのではないか、と思います。

すると、予約のための機構を作らなければならない、ということになります。
予約録音自体は、rtmpdumpでもffmpegでも、開始時刻を指定することができないため、アプリ内で予定時刻になったら(実際にはアプリ起動から録音開始まで若干のタイムラグがあるので開始時刻の数秒前に)起動し、そこから指定された時間録音する、というやり方で実装できそうですが、問題はその開始時刻の指定とタイムラグの調整になります(調整レベルの話は内部でごにょごにょになりそうなのでメインは開始時刻指定ですね)。

そこで、番組表の話が持ち上がってきます。
最近のテレビ(地デジ化された後のテレビ、と言い換えてもいいですが)にあるEPG、いわゆる番組表機能は非常に便利です。今何をやっているかもわかりますし、録画したい番組を選んであれこれできたり。個人的にはあれを作りたいですね。やり方がイマイチ見えてないですが。

番組表ができれば、録音のための開始時間はそこから取得できるわけですし、予約などのやり方も簡単にできるようになるはずです。ただ、これについてはおそらくすぐにリリースはできないんじゃないかな、と。だって、やり方が見えないもの。

もう一つ、予約録音に必要な事があります。PCのスリープ解除にまつわる機能です。普段から電源を入れっぱなし、画面も消えない、という状況はまぁ考えにくいわけで、スリープ解除(及び必要があれば録音作業終了後のスリープ設定)をする必要はありますよね。

とりあえず、今できる事は最低限聴取と録音の機能ですね。あとは開発言語をどうするか、というこちらの都合がありますが、まぁそれはどうでもいいことなので。

開発言語の話で一つ思い出したことがあります。最初の設計段階でスマホアプリでは再生機能のみ、としたのですが、この理由は至って簡単。容量の問題が起こるからです。

録音した音源をスマホからその都度PC側に移動させる、という作業を誰もが行うというのであれば、スマホで録音するのは結構都合のいいことのように思えます。が、普段の生活で意識的にPCへデータを移動させることは普通のユーザーはやらないでしょうし、そもそもPCを持っていないスマホユーザーもいるわけで、ずっとスマホにデータを入れっぱなしにしているということは、間違いなくストレージ容量の不足を招くわけです。

もちろん、クラウドへの移行や外部デバイス(SDカードだったりそういうの)への移動も視野に入れるとしても、それでも容量は無限にはなりえない。だとしたら、スマホでの録音は行わないほうが良い、と考えます。スマホからPC側に録画予約ができる機能が実装できるならいいですが、それって相当難しくない？

インターネットラジオの録音に関する考察（その２：ストリーミング配信方式のまとめ）

前回のポストでは、とりあえずの設計をやってみました。基本的に一人でやることなので(以前も書いた通り、似非アジャイル開発です)、小さい機能を作って最終的に組み立てる、というやり方になる以上、ざっくりと頭の中に完成図があればいいわけです。

で、機能面でのメインとなるのは、

普段自分が聴取するであろうラジオ局を聴取する/録音する

というものです。まぁ当たり前の機能ですね。では、その方法について軽くまとめましょう(というか、自分も久しぶりにこの機能の実装をすることになるので、以前の調査結果をまとめておかないとわけがわからなくなるんです)。

インターネット上で配信されている(かつ私が普段聴取するであろう)ラジオはおおよそ、以下の形式で配信されています。
・Radiko(民放ラジオ各社)・・・RTMP
・らじるらじる・・・RTMP/WMA(WMAは2015年8月末で配信終了)
・AFN・・・要調査(HLS？)
・JCBA・・・RTMP
・CSRA・・・WMA？

ざっくりいうと、配信形式は３種類に分かれます。で、それぞれの方式に対応した聴取・録音の仕組みを作らなければいけない・・・のですが、これらを一から作ることは私にはとてもできません。で、どうするかというと、それぞれの方式に対応した聴取・録音ソフトをあらかじめ取得しておく必要があるわけです。

ググって調べてみると、RTMPに対応するソフトが「rtmpdump」、それ以外であれば「ffmpeg」が必要になり(聴取・録音ソフトでフリーのものはこれを使っていることを公言しているものもあるし、おそらく有償のものでも同様なんでしょうね)、アプリ的にはこれらをバックグラウンドで実行させることで聴取・録音を可能にしている、と考えられます。

ちなみに、この聴取・録音をするためのコマンドラインはとても簡単で、例えば、今ちょうど私が聴いているAFN Tokyoの聴取ならば、

ffplay "http://4613.live.streamtheworld.com/AFNP_TKOAAC"

また、それを録音するならば(例として10分録音)、

ffmpeg -i "http://4613.live.streamtheworld.com/AFNP_TKOAAC" -t 600  -vn -c:a copy "~/rec.m4a"

と一行コマンドを実行するだけで済むわけです(ffmpegの再生版がffplay)。本当はもうちょっと細かい技が必要になるのですが、それはおいおい紹介するとして(というか私も調べながらの制作を行うので・・・)。

ということで、聴取・録音機能のやり方をまとめることで詳細設計の大枠が出来上がってきました。次回はこの機能について詳細設計をもう少しまとめてみたいと思います。

インターネットラジオの録音に関する考察（その１：開発再開前夜）

今年初めの頃、Mac用のインターネットラジオ録音アプリを作ろうとしていましたが、他にやりたいこともあり、単体の曲だけ選択し録音機能を実装する、というところでいったん開発が停止していました。

ふだんはMac使いではあるものの、開発の都合からWindowsマシンも持っていたりしますし、仮想環境にもWindowsの古いバージョンが入っていたりするので、実際のところ録音にはWindowsマシンで他の人が作っているアプリを使うことで(あえて何とは言いませんが)何とかなっていました。

ただ、今年の9月からだったか、NHKのストリーミング形式が変わったことで、アプリの録音機能が正常に動作しなくなり、NHKの録音(午後4時からやってる気象通報を録ってました)ができなくなってしまいました。まぁアプリのバージョンアップをすれば済む話なのですが、自分で作ることができるのに他人のアプリを使い続けるのもなぁ、なんて思いながら、しかもNHKの録音した音源に関して言えば、今のところあってもなくてもいいものだったので、とりあえず放置プレイをしてあるわけです。

そうは言っても、「録音できないんだったら自分で作ればいいじゃない」というアントワネット型思考(笑)が頭をよぎる以上、作らなければならないのかなぁ、と思っています。

ということで、ちょっと開発に時間を費やしてみたいと思います。

・・・とここまでならいつもの調子なのですが、その前に、作るにあたっての設計や実際のコードのサンプルなどもブログにアップしてみたいと考えていて、今後しばらくは設計やコードをひたすらブログにあげてみようと思います。

で、とりあえずの設計(いわゆる基本設計、全体像、Perspective)をこんな感じにしてみようと思います。
・一応Mac用アプリとして開発を開始。
・スマホ(iPhone/Android)用アプリも作る予定(ただし録音機能は付けない予定)
・余力があればWindows用も作ってみる
・聴取可能な曲は普段AM/FMで聞いているものを網羅(※)
・番組表は新聞ラテ欄的なデザインで
・プレーヤー自体のデザインもそれなりのものにする

まぁ、他にもいろいろと出てくるのでしょうが、最初のバージョンはシンプルな状態で出したいですね。誰かが使ってくれるのならその段階で要望も出てくるのでしょうし。

それから、もう一つこだわりたいのはやはりデザインでしょうか。直感的なデザインは外せません。機能重視はもちろんなのですが、それによってゴチャゴチャしたデザインになるのは個人的には許せないです。シンプルなのがいいです。シンプルで直感的。

ラジオのデザインと言えば、あくまでも個人的には、ですが、昔のラジカセのデザインは嫌いではありません。同世代(40歳代)のオジサンには共感してもらえると思っていますが・・・。が、あれはシンプルとは言い難いですね。どっちかというとゴチャゴチャ。ボタンがいっぱい付いているのがカッコよかったんですけどね、昔は。

ということで、しばらくラジオネタで引っ張ります。次回はコードを幾つか載せてみますのでお楽しみに。

2015年9月30日水曜日

小ネタ：ブログにコードを貼り付ける

ブログを書いていて、とてもやりたいことの一つに、ブログで作成したコードの一部とかを公開することでした。自分でプログラム作成をするときに参考にするサイトでも、コードのところだけ別の枠に囲まれていて、色やら行数やらついていたりして、カッコイイじゃん！俺もやりてーなー！とずっと思ってはいたのですが、なかなかそこまでに至りませんでした。

で、ちょっと手が空いたときに調べてやってみたのですが、最初はよく分からなくてうまくできなかったのですが、きちんと時間をとって調べてみると、意外と簡単だったりしました。ということで、このブログにも仕込んで見ました。

ちなみに、ブログでプログラムコードのところが↓こんな風になるのを、シンタックスハイライトというらしいです。

<!DOCTYPE HTML>
<html>
 <head>
  <title>Online or offline?</title>
  <script>
   function update(online) {
     document.getElementById('status').textContent =
       online ? 'Online' : 'Offline';
   }
  </script>
 </head>
 <body ononline="update(true)"
       onoffline="update(false)"
       onload="update(navigator.onLine)">
  <p>You are: <span id="status">(Unknown)</span></p>
 </body>
</html>

(w3cのサイトからコピペしてきましたごめんなさい)

これはブログに限った話ではなく、コードを色付けしたりして読みやすくする、というのがメインの目的です。まぁ私のブログ文字多めなんで、これにコードを入れたらもっと文字多くなっちゃって大変ですがねぇ。それはともかく。使い方は他のサイトを参考にしていただくとして(現時点で一番参考になったのはこのサイト。日本語で説明されていることもありますが、元のサイトのリンクも入れてくれていたのは助かりました。感謝いたします)、導入の要点をまとめておきます。

下準備としてスクリプトのリンクを追加しておくこと。参考リンクでは<head>セクションの一番最後(もちろん</head>タグの直前ですよ)に追加、とありますが、これは昔ながらのお約束ですが、近頃(少なくとも2015年の時点)では<body>セクションの一番最後(</body>の直前)に仕込むのが流行りらしいです(速度向上とか)。このサイトでは流行りに負けて<body>セクションの最後に記載してみました。
実際に使う場合、コードを<pre>タグで囲むだけでよいみたいです(参考にしたサイトは情報が古めだったので、実際に元サイトに行ってみるとそう書いてある)。
使い方例：
```
<pre class='brush: ○○; html-script: true;'>
コードの内容
</pre>
```
上記例の「class=brush:○○」のところに使っているコードの名前をここを参考にして記入します。もしhtmlの中のスクリプトだということであればその次の「html-script」項目をTrueにすればよいはずです。
ただし、<pre>タグに囲まれたコードの中で、一部エスケープ文字を使用する必要があります。各言語で異なると思いますが、上記の例で言えば、HTML(XML)の場合は(少なくとも)行頭の「<」はエスケープ文字(「<」)に直しておく必要があります。そうしないと表示が崩れます。＃本当は「>(>)」もやらなきゃいけないみたいですが、＃Bloggerでは行頭を直したら行末は勝手に修正が入ってしまいましたとさ。

ちなみに、これは私が使っているBloggerの場合ですが、おそらく他のブログサイトでも同様でしょう。ちなみに、スクリプトリンクの追加は(Bloggerの場合)テンプレートのHTMLファイルをいじる必要があります。まぁコードを載せようなんて人は「その筋」の人たちでしょうから、元のHTMLファイルを壊す、ということもないと思いますが(笑)。

まだ使い方があまりわかっていませんが(つか元サイトがあまりにも説明少なすぎる気が)色々と調べてみて、わかってきたらまとめて解説してみようかな、と思っています。

2015年9月29日火曜日

古いネットブックへのWindows 10導入顛末

仕事、という内容でもないですが、皆さんの参考になるかと思い、古いネットブックにWindows 10を導入した顛末をお知らせしたいと思います。

結論から言えば、成功しました。そして、かなり使えるらしい(私は使っておらず、使用者である妻の弁)とのことですので、押入れに突っ込んであるネットブックや中古で持ち運びに便利なマシンをお探しの諸兄には福音かもしれません。

ただ、そこに至るまでの道のりは実はすごく長かったです。試行錯誤の結果成功したと言っても過言ではないです。なので、その長かった道のりには触れず、最短でインストール成功する方法をお知らせします。

まず、用意するもの。

ネットブック本体(今回はAsusのEEE PC 1000Hをストック状態で用意)
メモリを積めるだけ(メーカー公称1GBでしたが2GB積めるらしい)
SSD(中古とかの安いので十分)
Windowsのメディア(今回はWindows7とWindows10の二つを用意)

基本的に、Windows7はWindows10にするための踏み台みたいな状態です(もとのネットブックはWindowsXPだったので、そもそもはWindows7をインストールするつもりで買ってあった)。

そして、もしネットブックが現役ならば、データのバックアップをしておいてください。基本、クリーンインストールしますので。

手順を簡単に書くと、

Windows7インストールの前段階として、BIOSを最新版にアップデートする
HDDをSSDに交換し、メモリも最大限積めるだけ積む
Windows7をクリーンインストールする
Windows7用のメーカー提供ドライバの最新版をインストールする
Windows Updateを行って最新の状態にしておく(※オプション)
Windows10にアップデート(引き継ぎなしで行う)
必要に応じてWindows10用のドライバをインストール

直接Windows10をクリーンインストールでもよかったのですが、今回は後で述べる事情があり、Windows 7を一度インストールしたうえでの作業になっています。

注意点を順を追って説明していきます。

BIOSのアップデート
基本的に、Windows7に対応しているマシンはWindows10にも対応していると考えてよいです。Windows7より上位のOS対応のBIOSアップデートがあればそれをインストールすればよいですが、私の場合はWindows7版が最新でした。
SSD・メモリ換装
メモリは、あればあるほどよい、とは言いますが、まずWindows7にする時点で、どんなにメモリを積んでも3GBまでしか認識されないという制限があります(ネットブックでIntel Atomを積んでいるマシンは32bit版しかインストールできないらしいので)。したがって、最大でも4GB(OS側が3GBとして認識)を選ぶ必要があると思います。また、Windows10では32bitでも4GBを認識している、という情報もあるのですが、そもそも32bitOSが4GBのメモリを認識するのか(いわゆる「3GBの壁」の解消がされたのかどうか)わかりません。
SSDについては、必須ではないです。SSD自体、読み込み速度は相当早く、例えばアプリ起動など、いわゆるサクサク「動く」という点では非常に有効ですが、書き込み速度(データをダウンロードしたりファイルを保存したりという作業に影響)が遅いということもあり、私は躊躇したのですが、HDDを積んでいるネットブックのHDDスペックは基本的に低速(回転数が遅い＝読み書き速度が遅い)であり、SSDへの換装により、書き込み速度も向上しました(どんだけ遅いHDDだったんだ、ということにもなりますが・・・)。
Windows 7のクリーンインストール
HDDを換装したのであればバックアップはあとでなんとかなりますが、そうでなければインストール作業前にバックアップは必須です。クリーンインストールで注意する点は他にありませんのでこんなところで。
Windows 7用ドライバインストール
これが意外と大事です。少なくともメーカーで提供しているドライバは全部最新のものを入れておいてください。私はグラフィックスドライバを入れていなかったため、このあとのWindows10インストールで失敗しています。
Windows Update適用(オプション)
実は、私の環境ではこれをしなくてもWindows 10のインストールはできました。というか、Windows Updateがどうしても動かなかったんです。エラー回避方法はいくつかあるので試してみたのですが、どれもうまくいかず、「諦めた」というのが正解かもしれません。これができていれば、もしかするとWindows 10にはしなかったかもしれませんので、よかったのか悪かったのか・・・(これがWindows7経由でWindows10にした理由です)。
Windows 10インストール
クリーンインストールではなく、アップデート(OS起動中にインストール作業を行う)で行いました。この時、前のOSの情報を引き継がないオプションでインストールしました。こうしないとインストールができませんでした。また、更新プログラムのダウンロード・インストールもこの時点では行わないように選択しました。やはりこちらもうまくインストールできなかったので。
Windows10用ドライバのインストール
基本的にWindows7の時もそうですが、実はOSで認識したハードウェアのドライバは正常に動いており、わざわざ変える必要もないかもしれません。どちらかというとハードウェアメーカー側で最適化されたドライバと考えています。私はこの作業を一部しか行っていません(タッチパッドと電源管理のドライバだけはいれておきたかったので)。

このためにかけたコスト概算ですが、

ネットブック本体：¥15,000
OSパッケージ：¥12,000(Windows7 Home 32bit)→Windows 10のDSP版はもう少し高かったです
メモリ(2GB/1枚)：¥3,000(中古)
SSD(128GB)：¥8,000(中古)

しめて¥38,000 ナリ。本体をすでに持っているのであれば、最大23,000円で、すでに本体側の改造済ということならOS料金だけで現役マシンになれる、というお話でした。

ちなみに、個人的には古いネットブックではWindows 10の魅力が半減するかなぁ、というのがちょっと使わせてもらった感触です。デスクトップOSとしては今までのWindows(7まで)を踏襲したものなので、可もなく不可もなし、といったところです。また、今回のインストール作業ではクリーンインストールをメインでやっていますので、余計なサービスやアプリが入っておらず、かなり軽快に動作します。

しかし、当たり前の話ですがタブレットモードがなく、さらに画面タッチもできないのは、タブレットモードに慣れている状態の私には退屈というか面倒というか、ちょっと違和感があります。

2015年9月18日金曜日

メインマシン(iMac)の復旧作業顛末：その後

前回のポストは、現在復旧中、というステータスでしたが、今朝、無事にiMacの復旧作業が完了し、「ほぼ」完全に復旧したことを確認しました。

ちなみに、Time Machine経由の復旧作業は2度目。今回取り替えた旧2TBのHDDを入れた時にも使っていて、その時は今ほど使用量も多くなかったし、たまたまTime Capsuleは有線接続していたのでこんなに時間もかからなかった記憶があります。

で、復旧が「ほぼ」完了した、という微妙な物言いをしているのは、復旧がクラッシュ以前の状態に完璧に戻ったわけではない、ということを表しているつもりです。おおよそ、OSレベルでは問題なし、ファイルも(多分)過不足なく復旧、アプリが一部問題あり、という感じではありますが、細かく状況を記しておきます。

○OS・・・復旧OK
　OSのバージョン(9/15時点では10.10.5)、ユーザー情報、アピアランス、ネットワーク接続情報などなど、基本的な情報については元どおりになっています。
○ファイル・・・復旧OK
　正直、確認のしようがないですが、普段つかっているアプリやメディアなど、動いている・使えている、という状態であれば、大丈夫でしょう。
×アプリ・・・要再設定
　これ、当たり前なのかどうか微妙なところですが、とりあえず一部アプリが使えなくなっていたり、再設定を行わなければならなかったものです。
　・Office365(これは別の問題も発生していて現在使えない→解消)
　・Dropbox(おそらく今回のHDDクラッシュの原因か。プロキシ設定を外して再登録)
　・(9/17現在)今の所これだけですが、随時追加していきます。
そもそも、プロキシを繋げている(串を刺している)状態というのも通常の家庭で置かれているPCではないと思いますので、あまり参考にはならないかもしれませんが、本当はバックアップを復元したらアプリの設定情報などもそのまま引き継いで動く必要があるように思います。

それから、前回も触れたとおり、OSに関しては現在使っているもののリカバリディスクは作っておく必要があります。今回はOSをアップデートしてから作業しましたが、やっぱり面倒くさい。来月、新しいOS(El Capitan、ってなんか言葉の意味知らなければかわいい響きだ)が出るようですし、アップデートをするつもりですので、必ず作らなきゃ、と思っています。

2015年9月16日水曜日

メインマシン(iMac)の復旧作業顛末

普段の作業は基本的にMacを使っている私ですが、ちょっと動きが悪くなり始めたので再起動しようと思ったのが今週の月曜日の朝のことでした。

そして再起動をしたのですが、一向に起動しない。グレーの画面でHDDを読み込んでいるプログレスバーが途中で止まったまま。

いったん強制終了し、ディスクユーティリティを起動(Option+Rを起動時に押して立ち上げるんですよ念のため)、ディスクのチェックをすると、ファイル階層に問題あり、というエラーが出ていて、しかも修復ができない、という状況。

とうとうHDDが逝ってしまわれたか、と考えたのですが、あらかじめHDDの状態を確認できるツールを入れていて、HDD自体に問題があったとは考えにくい状態ではありました。

そして、幸運なことに(というか当たり前なんだと思うんですが)バックアップはTime Capsule経由で毎日取っていたので、念のため新しくHDDを買い、最新のバックアップからの復元を行うことになりました。ですが、結構手間取って、しかも現段階ではまだ復元ができていないので、復元が完了するまでは久しぶりにWindowsマシン(Windows 10 on Surface Pro2)を使って作業をしています。

我が家には、OSXのメディアはSnow Leopard(10.6)しかありません。それ以降のOSはすべてMac App Storeから購入しているのですが、これが意外と復元の手間を増やしてくれました。そこで、実際の手順と、もっと簡単にできた(であろう)方法を、反省の念を込めてここに書いていこうと思います。何かの参考になればいいですが。

１．手順
まず手持ちのOSXをHDDに新規インストールし、徐々にアップデートをかけて最新のOSにする、という流れになります。我が家のケースでは、
「10.6インストール」→「10.6.8アップデート(Mac App Storeがインストールされる)」→「最新版(Yosemite:10.10)アップデート」→「バックアップデータのリストア」
という手順になります。

ここで思ったのは、10.6(SL)のメディアしかない状態だと、必ずMac App Storeの入手をしなくてはならない、ということ。ダウンロードにそれなりの時間を要してしまうため、実はHDDの入れ替えが終わってからMac App Storeが使えるようになるまで半日程度を費やしてしまいました。

ということは、最新のOSバージョン(今回のケースでいえば10.10)の復旧ディスクがあれば作業の手間はかなり短縮されるのではないか、ということが言えるわけです。以前別件でググって、Mac App Storeから入手したOSの復旧ディスクの作成方法がある、ということまでは知っていましたが、まさかこんな時に使えるのだ、とは思いもよりませんでした。

先日、Windows 10もOSXと同様のOTAインストールを採用し、OSのアップデート作業の手間は随分と減りましたが、復旧作業等のことを考えると、緊急用にメディアは作っておいたほうがよいのかな、と思いました。

２．復元作業
先ほども書いた通り、OSを最新のものにする、という作業自体はそれほど手間がかからない(時間はかかりますが)ので、まぁ片手間でも作業できるのですが、バックアップデータを復元させるのにちょっとした問題が発生しました。

メインマシン、と言いつつ、我が家のiMacにはかなりの量のメディアファイルが格納されています。音楽だけでも40GBとか、動画も昔のテレビ番組を変換した奴とか大量に入っていて、なんだかんだで使用量は1TBを超えていました。整理したり、外付けディスクやNASの導入も検討していたのですが、そもそもHDDは2TBあり、まだ大丈夫じゃね？とタカをくくっていたわけです。

で、当然復元をするデータも1TBを超える容量になっているのですが、実は我が家のTime Capsule、Wi-Fi経由でつなげていて、その状態で復元作業を開始すると、とてつもなく時間がかかりそうな予測が出ていました。ちなみに、リストアを開始してから数時間後、残り時間は550時間。20日とかですか。そんなに待ってられないです、というかかかりすぎにもほどがある(笑)。

そこから一晩寝かせておいて、再度残り時間を見ると、それでも470時間。多少短縮されたっぽいにしても、まだ1%程度の復旧率。寝かせておいた時間を12時間と想定しても、おそらく数週間単位での復旧になりそうな感じ。

そこで、Time Capsuleを直接iMacにつないで復旧、と考えたのですが、そもそも、Time CapsuleはUSB-HDDとしての機能を持っていないわけです。となると、Time Capsuleに入っているHDDを抜き出して、USB-HDDとして認識させられないか、と考えて、実際にやってみた(若干話を端折っていますが、Time CapsuleのHDDを取り出す、または交換する方法はググってみると結構出てきます)ところ、認識せず。

ということは、Time CapsuleとiMacをイーサネットケーブル経由で接続しない限り無理、という結論になるわけです。そして、このポストを書いている段階では、イーサ接続をして復元作業中、というのが今ここ、といったところです。ちなみに、作業開始から約1時間経過して、復元率は3%弱。残り時間表示は40時間。随分時間短縮できたもんです。この割合ならば、まぁ1時間で3%と考えれば、35～40時間、1～2日で終わる、と考えていいでしょう。

ただ、正直そんなに時間をかけたくない、ということもありますし、結局Time Capsuleは普段設置してある場所から移動せざるを得なくなった、ということもあり、非常にややこしいことになってしまいました。そんなことならバックアップはTime Capsuleへ、ではなく、復元作業の時間を考えると直接USBなどでつなげたHDDにとっておいたほうがよかったのかもしれない、とは思っています。

バックアップの取り方は置かれている状況にも寄るので、一概にこの方法がベスト、とかこの方法はダメ、とか言えないのですが、少なくともデスクトップ型のPCで容量もそれなりに、ということだと、NASなどのネットワークドライブにバックアップをとるのはあまりお勧めな方法とは言えないかもしれません。逆にノートPCでHDD容量も少ないのであれば、ネットワークドライブはかなりバックアップ先としては有効でしょう。

しかしまぁ、Windowsを久しぶりにガシガシ使うことになりましたが、一番ネックなのはキーボードですわね。メインのキー配列は変わらないですが、日本語と英語の切り替えや、Optionキー(WindowsでいえばCtrlキー)の場所が違っていたりするのはやっぱり面倒ですね。これはWindows 10のインプレとは何の関係もない話ではあるのですが(笑)。

登録: 投稿 (Atom)