小ネタ：散々な一日

たまにこういう日もあるよね、という、仕事あるあるみたいなもんですが。

朝、妻とテレビを見ていました。ちょっと遅めに起きた私は妻を仕事に送っていく準備をいそいそとしていました。そして、出かける直前、占いのコーナーが始まる直前、妻はニヤニヤとしていました。占いの結果は、妻が一位、私が最下位だったのです。そして、それを妻はすでに知っていた(１時間前に同じ占いをやっており、妻はすでに起きていたのです)ので、ドヤ顔で仕事に向かいました。

さて、妻を送り終え、家に帰って仕事を始めようと準備を始めました。PCは基本付けっぱなしなので、まずメインマシンで軽くメールのチェックをしながら、今日の仕事ではWindowsがどうしても必要になるので仮想環境のWindowsにログインしようとしました。しかし、ログインできません。画面が真っ暗です。

再起動をしたところ、今度は起動しません。真っ青です。PCがではなく私が。

特にデータを格納してあったりするわけではないので、最悪OSの再インストールで対応できるのですが、それでも再インストールには時間がかかります。しかもOSだけでなくアプリも復旧させるのは相当な時間のロスです。

とりあえず仮想環境で起こっている問題を解決しようとあれこれと調べつつやってみたのですが、何一つ解決に結びつく情報と出会うことなく、もちろん何ら状況が進展しないまま半日が過ぎました。

もうどうしようもありません。再インストールに方針を変えることにしたのですが、次に起こったのはメインマシンの不調です。こちらも突然真っ暗になり、動かなくなりました。私ももちろん真っ暗です。

メインマシンはどうやら不安定だったようで、再起動すると元どおり動き始めましたが、今度はネットワークが見つからなくなりました。以前バックアップ用のTime Capsuleが不調になった際に仮復旧させた状態で、本来ならば不安定になるはずの状況でしたが、問題も起こらなかったのでしばらく放置していたのが今更不安定になるとは。

そして、ネットワークの環境を正常な状態に戻し、やっと再インストールに取りかかれる、と作業を開始しようと思ったら、今度は仮想環境サーバのハードウェアに異常(というかガタ)が発生。HDDを接続するコネクタとケーブルが妙に引っ張られていて抜けそうになっていたり、ファンが異常な音を出し始めたり、CDのトレイが出なくなっていたり。力技で「なんとか」して、なんとか再インストールに成功しました。

が、これで結局さらに半日を費やすことになり、今日予定していた仕事は全く手につかなかった(仕事は資料作成だったので、空いた時間で手書きの資料を作りましたが)という何とも惨憺たる状況でした。

仕事のうまくいかない日、というのは結構ありますが、ここまで不運が続くのはなかなかありません。しかもそれなりに急ぎの仕事を抱えている時に限ってこういうのが連チャンで発生するんですよね。しかも占いが最下位だったし。

本当は、バックアップを取ったりとかしておかないと、こういう目にあうんですよね。考えておかなければ、なんてずっと思っていましたが、実際に実行に移さないのが悪いんですよね。落ち着いたらやろうっと。(←こういう態度が良くないんですね)

小ネタ：Office 2016 for Mac 再インストール顛末

唐突ですが、普段Mac使いな人たちが意外に困るんじゃないかと思うこと。

「資料」が開けないことがある

基本的に世の中の「資料」はWindowsで使うことを前提に作られているようです。ちょっとした資料が送られてきても、PDFで来ることは稀、WordだったりExcelだったり。ちなみに、そのPDFもたまに開けない(または開いても印刷ができなかったりする)ことがあります。システムで自動作成されたやつで何度無駄紙を印刷したことか・・・。

まぁ、WordやExcelはMacでは絶対に使えないというわけではなく、インストールしている人も多いはずですし(特に仕事で使うなら必須でしょう)、最悪、iWorkを使うという手もあるので、全くお手上げ、ということにはなりません。

が、すでにOfficeをMacで使っている人は、それが突然使えなくなると困ってしまうわけです。私がそうでした。

ここ数日くらい前から、Officeの全アプリが起動しなくなりました。起動は開始するのですが、オープニングの画面(スプラッシュ)が表示されず、「応答なし」状態になってしまうのです。また、それ以前から、アップデートがちょっとおかしい挙動をするようになりました。アップデータをダウンロードし、かつインストールが終わったにもかかわらず、その後再度最新版の確認をすると、同じアップデートが表示され、延々と繰り返してしまうのです。

こういう時はお得意の「ググってみる」ことから始めますが、意外にも「Officeが起動しない」事象が発生していたらしく、いろいろな解決法が検索に引っかかってきました。

それで、自分の状況と照らし合わせてみると、1箇所だけ、自分の状況だけがおかしい、という点を見つけました。

実は、利便化のために、Officeに限っては「アプリケーション」フォルダから別のフォルダ(実際にはフォルダ直下)にもう一つOffice専用のフォルダを作ってあり、その中にOfficeアプリを全部放り込んでいたのです。これ自体は非常に都合がいいのですが(Dockにフォルダを登録しておけばわざわざアプリケーションフォルダから探さなくていいので)、おそらく、これが原因でアップデートが妙な挙動をしていたのではないかと推測できます。
＃こういう時、本来ならエイリアス、Windows的に言えばショートカットを使うんですよね。

とはいえ、それを元に戻したところで起動しないことには変わりがなく、仕方がないので再インストールをすることにしました。そのやり方は思っていた以上に面倒で(基本的に、MacのアプリをアンインストールするのはWindowsに比べるとかなり面倒です)、詳しくはここを参照していただくとして、ざっくり言うと、

• 「アプリケーション」フォルダからアプリを削除
• 不可視フォルダであるライブラリフォルダから特定のファイルを削除
• 再起動後にインストールプログラム起動

と、Windowsのようにアンインストールプログラム一発で削除できるわけではないわけです。

再起動が本当に必要なのかどうかはマユツバですが(私はおまじないレベルだと信じてます)、とりあえず指示通りにやってみました。しかも、これもおまじないと信じてやまないウィルス対策ソフト(我が家はAvastです)の無効化もしてみました。

インストールは無事完了し、一応Wordは起動することがわかりました。その後、アップデートが走り、最新版のOfficeで起動することができたので、問題は解決しました。

Macでも、Windowsのようなアプリの(いわゆる)安全な削除ができるツールを一緒に提供すべきなんだよなぁ、と開発している立場だと思ってしまう、というお話でした。

追記：
Office2016 for Macでの不具合は結構多いみたいです。今回、私は再インストールだけですみましたが、ググってみるとそれだけでは解決しないケースもかなりあるようです。あまり私のケースは参考にならないかもしれませんね。

インターネットラジオの録音に関する考察（その５：進捗状況）つづき０１

毎週報告しなくても、と思いますが一応。

実は今週はほとんどコーディングしていなかったので(別のことやってた)、進んでないです。
まずは現時点(11/20)でできたところ。

• 番組表作成中。
  元となるデータをダウンロードするところまではできました。NHKのデータは3局別のファイルでダウンロードすることになります。radikoは全放送局(もちろん聴取エリア内のみです)が取れます。
  それから、デザインはまだやってないですが、少なくともリスト(JavaFX的にはListView)でやってみて、それから他のパーツを使うなり、いろいろ考えられそうです。

以上。

実は、その後処理になる、データを画面に表示させるところがどうしても実装できないんです。データがあればなんとかなると思ったのが間違いだったですね。世の中そんなに甘くないっす。

ということで、来週以降の予定ですが、

• 番組表の画面表示。とにかく画面に出そう。
• 積み残しのうち、デザインと広告あたり。

一人でやるんでのんびりですが。

小ネタ：無料アプリと広告

今日の小ネタはいつもと違い、アプリの収益に関するお話です。とはいえ、これは私が直面している話ではなく、一般的なお話でございます。

無料でアプリを提供する場合にどのように収益化するか、というのは以前のポストでも書いたことがありますが、アプリ内課金、もしくは広告収入、というのが考えられるわけです。というのを前提に。

わたくし事ですが、最近は使っていないスマホのアプリがいくつかあります。数年前、しかもリリースされて間もない頃に、「そうそう、こういうのが欲しかったんよ！」とインストールし、結構使っていたのですが、ライフスタイルの変化とともに、最近では起動することも少なくなっていました。

そのアプリのうちの一つが、テレビCMで流れるようになったのはここ数ヶ月前からでしょうか。職業柄、どうしても「お、この会社、ずいぶん儲かってるんだね」とアタマの片隅で思いながら、いずれにせよテレビCMを見たからといってアプリの起動契機になるわけでもなく、他のテレビCM同様、見過ごしていたわけです。

そして、今日、ふと気がついたことが。そのアプリからのオプトインメールを受信するように設定していた(らしい)のですが、以前よりオプトインメールの来る頻度が高くなったような気がしたのです。今朝、昨日のメールチェックでそのアプリからのメールを削除した記憶があり、週末に向けて夕方にメールチェックをしたところ、そのアプリからのメールが来ていたことで気がついたのです。確かに、この１ヶ月で週に2〜3通、今週は月曜着から金曜日まで毎日届いています。

ちょっとした違和感を覚えました。メールバンバン流してどんだけ広告収入を得ようとしてんのさ、と。でも、すぐにその理由に気づきました。テレビCMです。

アプリの運営会社はもともと、アプリ内にある広告がメインの収入源になっていたと仮定されます(アプリ内課金もありましたが)。でも、アプリがインストールされればされるほど収入が上がる、ということになるため、アプリの認知度を高める必要があるわけで、今までのように口コミだけではユーザー数は頭打ちになってしまう恐れがあったのではないでしょうか。

そこで、大きな認知度アップキャンペーンを行うことにしたのでしょう。そう、テレビCMです。最近はテレビ離れが進んでいるとは言え、テレビを視聴する人はまだまだ多いわけです。当然認知度が上がったでしょう。

ただ、そこにはおそらく大きな落とし穴があったはずです。テレビCMの制作および放送に相当額の広告費が費やされたはずです。そして、仮にアプリがインストールされたことによる売上が上がったとしても、それに見合うだけの利益を上げることができなかったのではないでしょうか。

とすれば、今度は既存ユーザに対してオプトインメールを送ることで、そこからの広告収入を得る、という方法で、なんとか売上(利益)を維持もしくは上昇させようと考えるのは無理からぬ話です。今日気がついたのはある一つのアプリですが、実は同様の理由で削除したアプリも今までに数多くあります。

その方法がダメだ、と否定するつもりは全くなく、利益を上げなければいけない企業の立場としては当然だとは思いますが、無料で使っているユーザー側として、その程度の「不利益」は受け入れなければならない、と、もしその企業が思っているのだとしたら、それはちょっと極論すぎる気はします。

ちなみに今回のアプリを開発した会社(もちろんどこかなんて言いませんよ)、財務状況とか全くわかりませんが、おそらく利益を少しでも前期より上げようとしているんではないかと。そして目指しているのは上場。そんなところでしょう。

それはいいことだと思いますし、素晴らしいことです。が、それによって、ユーザー側に不利益が少しずつ増えていくとしたら、果たしてそれはいいことなんでしょうか。利益を得たいと思うならまずは利益を出してくれる人のことを考えるべきだと思います。

・・・まぁ、会社によっては(今回のアプリの会社もそうかもしれません)大きな「資金源(≠利益源)」はユーザーではなく資本家だったりしますので、そちらをより大切にしてしまうこともあるかもしれませんけどね。

インターネットラジオの録音に関する考察（その５：進捗状況）

なんか業務連絡みたいなポストであることをご容赦ください。

昨日(11/11)時点でできていることを列記します。

• AFNとNHKは一部の局だけだが再生が可能であることを確認
  (AFN:Local/Japan、NHK:東京エリア)
• 再生可能な局については録音も可能だと思われるが未テスト
  (出力フォルダを作っていないのでめんどくさい)
• デザイン作成中。昔のポータブルカセットレコーダーとかサンプラーとかをイメージした、でも今風のデザイン作り中。
• 開発言語はJava。JavaFXで作る予定。正直すごく楽。XMLさまさまです。

次に考えること/やること

• NHKの番組表を作成。番組表をXMLで作るのはどうやってやるんだろう？なんとなくわかるんだけど(データを引っ張ってきてXMLを自動生成的な？)。
  ちなみに、AFNは番組表がないのでどうしたもんかと考え中。特にLocal Stationはずっと聞き続けないと番組名わかんなさそうだよなぁ。作りながら聞くにしても絶対聞き流しちゃうだろうし。
• radiko加盟局の再生・録音機能実装
  問題点は２つ。一つはradiko特有の「認証」の実装。やり方はわかってるんだけどめんどくさい。もう一つはエリア外聴取への対応(プレミアム対応といってもいい)。そもそも自分がプレミアム加入してないし。
• デザイン(続き)
  そもそもそのデザインでいいのかよ、とは思ってますが。
• 広告の実装
  そういえばデザイン考えるときに広告の配置を考えてなかったな。ちなみに、広告を貼り付けるだけで儲かるわけではないのだが、他に方法はないので(ないわけではないが自分が嫌なことはしたくないし)。

ざっくりとこんな感じです。

ちなみに、番組表の実装ですが、このポストを書いた後(この行より上は昨日の夕方書いた)、風呂に入っている時になんとなくアイデアが湧いてきました。実装がうまくいった時点でやり方を公開する予定ですが(失敗したら恥ずかしいので・・・)、ヒントとなったネットの記事をリンクしておきます。

テレビ画面はdiv要素でできている！- Hybridcastとテレビの未来 –
(from HTML5 Expert.jp)

記事自体は、デジタルテレビにおけるデータ放送画面がHTMLで構成されている、というものです。データ放送(記事内ではNHKのHybridcastについての言及ですが)を起動すると、内部ではブラウザが起動し、いわゆるWebの画面が表示されているという仕組みだ、とあります。

この記事は番組表実装の方法を考えるときにさらっと読んだのですが、その時はあまりピンとこなくて、ざっと読んですぐに閉じてしまいました。が、昨晩、まさに風呂に入っているときにふと、「とりあえず番組表をHTMLで書いたらどうなるんだろう？」と思いついたわけです。今回開発している環境では画面の構築はXMLを使っています。だとすれば、考え方は同じ方向を向いているわけで、うまくいくかもしれない、と。

確かに、データ放送画面を良く見ると(たまたま朝の情報番組を普段通り見ていたのですが)、上記の記事にあったようにHTMLで実装されていると言われればそのように見えます。ということは、テレビ自体がHTMLブラウザではないか、と仮定できます。テレビの機能画面は全てHTMLで描かれていると。

もちろん、これが「正解」とは思いませんし、私自身それほどコーディングに自信があるわけではないのでもっといい方法があるかもしれません。が、一つの方向性としてはアリなんだろう、とは思います。とりあえず出来るところまでやってみます。

小ネタ：アプリ制作とデザイン

私自身は、自分のことをエンジニアだと思っていて、デザイナーでは決してないと思っています。あくまでもプログラムを作る人で、プログラムのデザインとかあまり関係ない、と昔は思っていました。

そうは言っても作ったプログラムを使ってもらうためには、例えば使いやすさとか、使いたいと思わせるような動きとか、それなりに(実際にはかなり)重要だったりするわけで、どうしてもプログラムの「デザイン」、専門的な言葉を使うならUI/UXとか、そういったことを意識しないと本当はいけないわけです。

では、普通にプログラムをエンジニアが作るとどうなるか？基本的にプログラムの機能を作る人が作るものなので、デザインにはそれほどこだわりがありません。もちろん、ボタンの位置とか(整列していないとかどのボタンが右で左で、的なこと)は意識しますが、ストレートに言えばどんなアプリを作ってもまるで業務用のソフトみたいな(今でいうならふた昔前くらいのデザイン、でしょうか)感じになってしまいます。

私自身、そういったプログラムを作ってきた(そしてそれでよかった時代でありクライアントでした)ので、ある時、上司から「君の作るもののデザイン、ダサすぎるね」と言われた時はショックであり混乱もしました。だって、動くんですよ。必要な機能も盛り込んでいますよ。それなのに、アプリの機能と関係ない部分ですから。

しかし、現在、というより時代の流れでしょうか、アプリはただ動くだけではなく、デザイン面での考慮が必須になりました。ですが、開発をしようとしても、開発環境を普通に揃えた状態では、どうしても昔ながらのダサい画面しか開発できない、という状況に変わりがなかったりします。

もちろん、デザインが素晴らしいアプリの開発ができないわけではなく、それなりの環境を揃えることで実現できるわけです。世の中に優れたデザインのアプリが存在するということがその証拠ですが、ではそれは何か。

私は最近までスマホアプリを開発していたので、Javaを使うことが多いのですが、Javaのみで作ろうとすると、どうしても限界が出てきます。そこでスマホでは(そして調べてみるとPCアプリでも)XMLを使ってデザインをする、という方法があります。これはデザイン面での開発にとっては便利であり、簡単でもあるので、私はやりやすいと思います。

もちろん、開発環境の中で、パーツのデザインを含めて提供するというスタイルもありますが、よく言えばデザインが統一される、悪く言えばダサくなりがちだったりするわけですし、逆に、XMLを使うスタイルでも、ごちゃごちゃしたデザインになりがちなので、それぞれに長短あるのですが、いずれにせよ、機能以外の面でダサいアプリを作ることは、あえてそれを狙うことをしない限り(ネタアプリみたいな感じですかね)、できないししなくていいし、そんな時代になったんだなぁ、と思います。

実は、以前言われた「デザインがダサい」という一言は、今でも心の中に引っかかっています。むしろ、もうそんなことを言われたくない、という気持ちに変化していて、どんなアプリを作るにせよ、多少なりともデザインを気にするようにはしています。どんな簡単なアプリでも、誰かが使うことを考えて作ります。

ざっくりですが、私が考えるデザインの順番は、
・まず見た目。見た目が悪ければ使う気は起こらないはず。
・次に使い勝手。ボタンやらコントロールやらの場所を考える。
というもの。どれだけ使い勝手の良いものでも、見た目が悪いとあまり愛着が湧かないというのは「モノ」を選ぶ際のポイントになってくると思います。確かに世の中には見た目より使い勝手重視と思われるものもたくさんあるにはありますが、その全てが万人に受け入れられているとは思えませんし(しかも受け入れられるためには条件がいくつか必要)、見た目が良ければとりあえず受け入れてくれるわけで、見た目を最初に考えるのが私のスタイルです。

インターネットラジオの録音に関する考察（その４：番組表の詳細設計(仮)）

本当ならラジオの番組表は後で作るつもりでいたので、現段階で書くことはなかったはずなのですが、ちょっとデザインを考えているうちにまとまった考えが浮かんだので、仮の設計をしておこうかな、と。

まずこのブログを普通に読んでいる方はおそらく日本人だと思われます。日本語で書いてるし当たり前ですかね。では、そんなあなたに質問。番組表と聞くとどんなイメージをお持ちですか？

おそらく、新聞のラテ欄と同じレイアウトのイメージなのではないかと。画面上にテレビ局が並び、下に行くに従って未来の番組になっていくものです。当たり前といえば当たり前なレイアウトですよね。新聞に限らず、テレビでもラジオ(というかradiko、らじるらじる)でも同様、局が上に来てます。

ということは、このデザイン以外ありえない、ということになりそうですが、実はそうでもないんです。海外のテレビ、しかも多チャンネルな国(アメリカとか中国とか)だと、テレビの番組表は局が横に、時間は左から右へ進んでいく、というのが多いみたいです。CSのチューナーも昔はそんなスタイルだったような記憶があります。

これはなぜか。私自身、それほど海外の事情に詳しいわけではないのでわかりませんが、おそらくは「慣れ」から来ているのではないか、と推測します。

「番組表」の画像検索をしてみると顕著ですが、日本語で「番組表」と検索をすると、基本的に(日本人には)見慣れたスタイルのアレが出てきます。では、英語で「TV Listings」「TV Schedule」と検索するとどうなるか。まぁ多彩なデザインが出てきます。

先ほど書いた、表が日本と逆(局名が左側にある)のもあれば同じのもあったり、古い新聞だと何時からどこのチャンネルで何をやるかが列記されているだけだったりとか、おそらく共通フォーマット的なものが存在しないんでしょう。

だから、日本の場合はおそらく新聞の表現方法がデファクトスタンダードになり(テレビ・ラジオ雑誌もこの表現を踏襲)、デジタル化された現在でもこの表現方法が一般化しているということは言えるでしょう。もちろん、日本人は文字を上から下へと読む習慣があるので、それに倣って造られた表現方法なのだとも考えられますし、そもそも新聞は縦長の紙面なので、それにマッチする表現方法がこれだった、とも考えられます。

逆に、海外ではそう言った新聞などでの番組表の表現方法が確立されておらず、デジタル化された段階で見やすい番組表を模索した結果、横長の画面であるテレビにマッチしたスタイルである、日本とは逆のスタイルになった、または、文字の読む習慣から考えれば右に目線を動かすタイプの方が読みやすかった、という理由があるのかもしれません。

では、私(純粋な日本人です)が作るとしたらどんなデザインになるのか。おそらくですが、どちらも採用しそうです。ユーザーに任せる部分というか。

これには理由があります。
先にちらっと書きましたが、昔のCSチューナーはいわゆる日本式ではない番組表を採用していました。日本製ですが(東芝だったかな？)。理由はわかりませんが、おそらくは、チャンネル数があまりにも莫大なため(そしてこれは現在の海外の事情ともおそらく合致すると思われますが)、「日本式」の番組表では画面に表示されるコンテンツの数があまりにも少なすぎるため、逆にしたのではないか、と思われます。

さて、ネットラジオに話を戻しますが、今回選びたい局は実はかなりの量になります。私自身は現在東京在住なので、それだけでも結構な数の局になる(radikoだけで13局、NHK3局＋AFN Tokyoだけとしても)のですが、そこにコミュニティFMを幾つか加えればなかなかのコンテンツ量です。それを「日本式」で見るのが果たして見やすいのかどうか(もちろん、番組表を取得できれば、という条件はあるにせよ、radiko参加局とNHKは確実に取得できるはずなのだから)。

だとすれば、選局可能なチャンネルが少なければ「日本式」でも構わないし、多くて見にくい、となればそれ以外の方法も選択肢があっていい、という考え方はあっていいと思います。

今回は開発の中でもデザインに特化した内容でしたが(にも関わらず絵を一切掲載しないという暴挙に出ましたが)、アプリを作るときにはどうしてもこういうことも考えないといけないよね、と思い、書いてみました。今後も割とこういうデザインネタは多く書くことになるとは思います。

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

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

もうちょっと細かく言うと、
・選局する(聴取・録音するラジオ局を選ぶ)
・聴取の場合は聴取のためのソフトを立ち上げる
　＃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歳代)のオジサンには共感してもらえると思っていますが・・・。が、あれはシンプルとは言い難いですね。どっちかというとゴチャゴチャ。ボタンがいっぱい付いているのがカッコよかったんですけどね、昔は。

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