あるもので作るか、新しく作るか (2)

トップダウンでいくのか、ボトムアップでいくのか。
カスタマイズをしだしたときに、標準からのずれをどこまでフォローできるのか？
メインテナンスは、(セミ)プロがするのか、素人がするのか。
セットアップは誰がするのか？

個人的には、答えはもう出ている。
セットアップはプロが行う。素人にそういう特殊技術を要求するのは過大な要求だし、「ホームページを作ること」そのものに価値を見出す時代ではすでになくなっている。
制限された枠組みの中で、素人でも操作できることが重要。
エンドユーザーレベルでのカスタマイズは、せいぜいデザイン程度。機能的な追加は出来合いのものを使うか、あるいは、他のサイトでも流用できる程度に汎用的に作ったものを、「プロ」が用意する。

あるもので作るか、新しく作るか。

IT関連の技術の急激な進歩を考えると、何をやるにしても、つい、今できる技術の組み合わせでできないか、と考えてしまう。
もちろん、それは決して悪いことではなく、それがベストの選択であることが多いのだ。実際、どこかに既に存在するものをもう一度自分でつくることは、「車輪の再発明」としてしばしば揶揄される。
とはいえ、そういう生活をずっと続けていると、いつのまにか自分でつくることを忘れてしまうのも悲しい事実。
ちょっとした、１ページ程度のスクリプトですむような処理ですら、ネットで検索するようなことをしがちになる。

思えば、XMLのparser程度は、学生の頃は一日くらいでちょいちょいと書いていた。いまだとライブラリの呼び出しで９割方の用は足りる。さて、残りの１割の、帯に短し襷に長しの機能を実現したくなったとき、ライブラリに手を入れるか、そういうものだと諦めて、要求仕様を変更してしまうか。

(あ、もちろん、今考えているのは、parserの問題ではない。)

とりあえず一段落

3月以来、かなりペースが落ちていたけれど、とりあえずJASRACに絡まない曲については全曲収録終了。
さて次の段階は、ということなんだけれど、やっぱり暫く放置かな。有名な曲(というか、好かれる曲)については、ぼちぼちアレンジを加えようかとも思うけれど、他の曲まではどう考えても無理。
正直なところ、典礼聖歌って、熱烈な高田ファンがいる(らしい)割には、あまり芸術性を感じないんだな。ユニゾンが多いし。

とりあえず、最低ラインは作ったから、我こそはと思う演奏者がいれば演奏を提供してくれないかな。自動演奏以下の品質ならちょっとお断りだけれど、ミサの実況から切り出したものとか、あったらいいな。ある程度集まったら、また JARACに許諾をとって正式運用するかもしれない。集まらなければ、今のまま。許諾料を支払ってまで公開するような演奏レベルじゃないのでね。

Darwin Streaming Server(2)

なんだか、ブラウザの互換性の泥沼にはまったのかもしれない。
QuickTime単独では、当然のことながら再生できる。
RealPlayer経由だと、すこし変な挙動がある。
RealPlayerは、本当にQuickTimeをサポートしているのだろうか？ 映像付きのQuickTime movie は、まあ、遜色ない状態で再生してくれている。オーディオのみの QuickTime Movieは？
RealPlayerの QuickTimeサポートは、実は QuickTimeを呼び出しているだけ？
なんだかよくわからないが、とにかく、どこか変。

Bandwidth Limit Exceeded

某サーバーの blog が、Bandwidth Limit Exceeded となっていて、表示されなくなった。
別の某サーバーからも、Temporarily Offline で回復の予定未定とのアナウンスが届く。こちらは、誰かが PHPスクリプトを悪用したのが理由らしい。
別のサーバーには、行儀の悪いロボットがやってきているし、帯域制限のかかるサーバーは、こういうときに大変だなぁ。

rtsp と proxy(3)

以前、「DRM保護されたコンテンツが、proxy経由でアクセスできない」と書いたことがあるが、もしかしたら、UDPをちゃんとproxyしていなかったとか、そんな理由だったのかもしれない。

rtsp と proxy(2)

RTSP proxy kit というのがあって、今回はそれでテストしているのだが、「サンプル実装、そのまま使われることを意図していない」ということのようで、確かに、そのまま使うと open proxy になってしまう。

RTSPプロトコル自体が、HTTPを真似た部分があって、どこをどういじったらいいのかはおおよそ見当がついている。HTTP proxyの適当なソースから、該当部分をコピーしてくれば、なんとかなりそうではある。

もう少しまともな(proxy kit がまともでないという意味ではない)rtsp proxyがあれば、一番よいのだが、探してみるか...

rtsp と proxy

ストリーミングにやけに手間取ってしまったのは、理由がもう一つあって、それが、firewall の問題。

内部のサーバーではうまくいくのに、外部のサーバーにおくと最初の数秒だけうまくいって、あとは時折ブツ、ブツ、と断片が流れる状態が長く続いていて、サーバーの能力が不足しているのだろうと疑っていた時期がかなり長かった。

なにしろ、DarwinStreamServerの要求するSpecをみると、最低128MBのメモリと書いてあって、とりあえず最低の条件は満たしているものの、かなり貧弱なスペックのサーバーでテストしていたのだ。

外部サーバーでテストするのは諦めて、次のステップの rtsp proxy の導入をしてみると、なんと今度は外部サーバーの音が途切れ無しに正常に聞こえる！　そうか、UDPの問題だったのか、というわけ。rtsp の場合、どうやら、クライアント->サーバーの向きの UDP接続のほかに、サーバー -> クライアント向きの UDP接続もあるらしい。
UDPを使わない、TCPオンリーの使い方もあるらしいが、まだよく調べていない。

... というわけで、環境テストが、いましばらく続きそうな気配である。

Darwin Streaming Server

いろいろ試行錯誤してきたけれど、やっとストリーミングのやり方がわかってきた。
出来てみればどうってことはない、マニュアルに書いてあるとおりなんだけど。( 要は、いろんなことができるんで、情報が交錯して混乱してただけってこと )

mp3 を ストリーミングしたいとき。

A. m3u による疑似ストリーミングの方法。
プレーリストファイルを作る。.m3u 形式と .pls 形式がある。
簡単な .m3u の場合だと、mp3ファイルのある URL を 書くだけ。.pls も記述形式が違うだけで、考え方は同じ。
これだけで、mp3ファイルをストリームとして聞くことができる。

このやり方の問題点は、.m3u ファイルをみれば、実際のファイルの場所がわかってしまうこと。URL が http:// で始まっていれば、そちらを直接アクセスしてしまえば、ダウンロードもできてしまうので、ダウンロード防止の目的には使えない。

B. rstp プロトコルを使う方法。
Quicktime Pro を使って、.mp3ファイルを インポートして、それを、ヒントつきムービーとしてイクスポートする。
元の .mp3ファイルと、インクスポートされた .mov ファイルを、DarwinStreamServerのmoviesディレクトリに置く。
rstp://サーバー/xxx.mov でアクセスする。

付記:
1. midi を .wav に変換
VSC3.2 の 変換機能を使うのがたぶん一番安い。
ただし、VSC を他のソフトが使っていると、変換に失敗する。
2. .wav を .mp3 に変換
いろいろソフトがあるようだけれど、とりあえず、AudioEncoderで足りる(かな)。

3. icecastは結局不要のようだ。
　

IPアドレスの追加

いつから始まったのかよくわからないのだけれど、B-fletsで、セッションプラスというオプションサービスがある。
標準の２セッションに加えて、合計で最大五セッションまで pppセッションが使えます というもの。
速度自体は、地域IP網の速度で制限される(たぶん)ので合計で速くなるというわけではないが、複数のプロバイダに同時に接続できるので、IPアドレスもセッションの数だけ使えることになる。
一つのプロバイダで 8IPアドレスを使うのと、二つのプロバイダで、2IPアドレスを使うのと、どちらがいいかと迷うところ。

もちろん、単純なコストパフォーマンスでは同じプロバイダで 8IP 取ったほうがいいのは明白なんだけれど、冗長性とか、1IPと 8IPの価格差を考えると、二つのプロバイダと契約するのも、なかなか捨て難いなというところ。

1セッションプラスの費用が300円、プロバイダ費用が1200円くらいだと、二プロバイダの 2IP で +1500円程度。
同じプロバイダの 8IP プランだと、+2000円程度。
微妙に悩む価格設定だな...