Fiio E5+AKG K321

FiiO E5はポータブルヘッドフォンアンプ、AKG K321はカナル型インイヤーヘッドフォンだ。

MP870は出力がかなり小さいこと、MP870の付属ヘッドフォンがあまりにも貧弱なことからchoiceした。

E5はバッテリ内臓でインターフェイスは3.5″in/out、パワースイッチ、ボリュームスイッチ、ミニUSBとシンプル。パワー/チャージランプはある。また、ベースブーストスイッチを持つ。かなりコンパクトで、小ささに驚いた。

スイッチはクリック感に乏しい。しかし操作は確実に行える。低音がしっかりと分離された状態で増幅される印象だ。

それほどとても大きくできるわけではないが、MP870の出力不足を補うには十分。味付けがすごく悪いといったこともなく、まぁ低音がはっきりしたねという程度でちゃんと分離された音になる。

一方、K321は2000円程度でうられているAKGのイヤフォン。まず注意して欲しいのが、セミオープンタイプで外に音がかなり聴こえるということだ。電車の中では控えたい。

最初は高音がちゃきちゃきととても痛い、「エイジングが必要な典型的な音」をしている。エイジングを完了すると、値段からイメージするよりもはるかに明瞭かついい音がする。分離はかなり良好。低音がないという人もいるが、ちゃんと耳にいれれば十分すぎるほど音が出る。「ちゃんと耳にいれる」ことが大切だ。

E5+K321はかなり明瞭に強い低音が出るため、ベースブーストの必要性は全く感じない。

E5のほうにもっとマイレージがあれば、とは思うが、私はかなり満足している。これだけで聞くと言うよりも、外に持ち出す環境としては良いバランスかもしれない。インナーイヤーは壊れやすいからだ。

簡易的なOP25B対応

様々な仕事が滞っている中なので、先行してメールを送れるようにだけはしておいた。

OP25Bとは、SMTPサーバーポートである25をISPが中継しない、というものだ。スパム対策だというのだが、実際は自由にメールを使わせない、メールをISPで一元化するものとなっている。

メールアカウントが提供するサーバーをそのまま使っていれば特に不自由は感じないという人もいるだろうが、近年のSMTPサーバーサービスはかなり複雑に認証され、フィルタされることもあって使い勝手は著しくよくない。以前ならそれに対する対応としてローカルなメールサーバーを使えばよかったのだが、今度はそれがISPによって蓋をされた格好になる。

各家庭でMTAから出す、ということそのものが特殊な要求と見るのかもしれないが、今はそもそもSMTPサーバーを提供しないメールアカウントも珍しくないので、やはりの必要だし、自宅でのメールサーバー公開もできない。

とりあえずシンプルな方法として、セキュアで確実にリレーしてくれるMTAが欲しい、ということで工夫してみた。

まず、VPSにPostfixを導入する。そして、次のように設定する。

inet_interfaces = localhost
mynetworks_style = host

これ以外についても適切に設定するが、これで外部からメールを受けとらないためセキュアな設定となる。もちろん、外部からメールを受けとるように設定する場合には、より広く適切な設定が求められる。

この状態ではSMTPを用いてメールを送信することができるのはVPS自身だけだ。しかし、VPSのループバックインターフェイス経由ならば送信できるため、SSHのポートフォワーディングを用いることで他のホストからのメールを中継してもらうことができる。

これには次のコマンドを使用する。

$ ssh -x -L 2500:localhost:25 remorthost.example.com

「ローカルの1024以下のポートを転送する場合、ローカルのroot権限が必要」なのであり、ここでは2500番ポートをリモートの25番ポートに転送することでroot権限なしに実現している。なお、リモートホストの名前はlocalhostにしないと、loインターフェイス経由での接続にならないので注意が必要。インターフェイスを気にしなければFQDNで指定しても接続できてしまうことがあるから、理解していないことがある。

-Lオプションのまんなかのargは、後で指定するhostが名前解決をし、接続するための名前だ。つまり、localhostを解決するのは、リモートホストで、リモートホストにとっての::1/127.0.0.1に接続される。

-nオプションを使えばバックグラウンド接続が可能なはずだが、ServerMans@VPSではそれができなかった。接続そのものが切られてしまう。タイムアウトして接続は切られてしまうし、不要なターミナルセッションが生まれてしまうが、通常通りのログインとした。

あとはMUAのSMTPサーバーとしてlocalhost:2500を指定すれば、MUAはVPSのPostfixとやりとりをしてメールを送信することになる。通信はssh(通常は22番ポート)を経由するため、25番ポートをブロックするOP25Bにはひっかからない。

VPSの活用方法としては一般ユーザーでも意味のある方法になるのではなかろうか。もっとも、セキュリティ管理などを考えれば一般ユーザーに進められる方法ではないが。

オーディオリスニング/制作環境をありあわせでパーフェクトに

私は、お金はないし、機材にも乏しく、部屋は狭くリスニングにもむかない。そんななかで工夫で音楽家としてやってきたし、継続しようとしている。

もちろん、こだわりのオーディオI/Oにモニタースピーカー、モニターヘッドフォンでラインにまでこだわれればすばらしいのだが、なかなかそうはいかないのが現実だ。そこで、これまでの使えるものをできるだけ再利用して、安くあげる、というのがごく基本的なこととなる。

今回、再利用の柱となったのが、Sony VAIO MX2だ。これは、2000年リリースのマルチメディアデスクトップPCで、Vortexオーディオボード、MDドライブ(!?)、FMチューナー、アンプを内臓し、前面にオーディオコンソールを持ち、専用フォームウェアによってオーディオモードでの起動が可能で、しかもリモコンもつく、というものだ。スピーカーとはスピーカーケーブル接続で、このスピーカーはなかなかいい音を鳴らす。ちなみに、サウンドボードはオーディオケーブル以外にもRCA out, Optical Out, Optical inを持つ。

これはあくまでリスニング用として活かすつもりだったのだが、改めてスピーカーをちゃんと鳴らすとかなり飾り気のない音がして、十分モニタースピーカーとして耐えるものだ。モニターとしての音は複雑な要件を持つが、私の場合基本的にはヘッドフォンで作りこむため、耳がつかれた時や聴こえの確認に利用するため、ないと困るし、ちゃんとモニターの音がしてくれなくてはいけないが、かといって特にこだわらねばならないこともない。

だったらこのスピーカーを再利用してしまえば場所もとらないし、安上がりだ。しかし、MX2はリスニングで使いたいし、そもそもスピーカーケーブル接続だ。そこで、スピーカー-RCAオスのケーブルと、RCAスイッチを使えば、2系統の入力がスピーカーに入るのではないか、と考えた。そして調べると、RCAとスピーカーのケーブルは存在していたが、RCAスイッチというと、AVスイッチ、つまり「3色ケーブルのスイッチ」になるようだ。

ちょっと信頼性に問題があるが、RCAケーブルと、RCAスイッチは据え置き型家庭用ゲーム機のものを再利用することにした。つまり、このコンポーネンツでは、単にRCA-スピーカーケーブルを買い足しただけに過ぎない。

なお、デスクトップPCからのオーディオはリサイクルショップで2000円で購入したNATIVE INSTRUMENTS AUDIO 4 DJだ。機能的には不十分だが、音は非常に良い。問題はMIC INがないという、簡単だがクリティカルな問題だけだ。あとは、24bit/96kHzなことか。

スイッチへは4DJ/VAIO共にRCAで出して入れ、スイッチからスピーカーがRCA-スピーカーケーブルの変換となる。これはビックカメラで購入した。

しかし実際にやってみると、スイッチでの減衰がかなり大きい上に、特にVAIOからの音はMAXにしても「ほとんど鳴らない」。VAIOのスピーカーはVAIO自身がアンプリファイアを持っているため、パッシヴスピーカーだ。どうもVAIOのRCA OUTはアンプにつながっていないのではないか、というところ。4DJにしても、直つなぎなら多少はきこえるが、それでもかなり小さく、スイッチを介しては実用にはほど遠い。

こうなると解決策は以下のいずれか。

  • スイッチでなくアンプを使う
  • パワードスピーカーを追加する
  • 諦める

そこで安い中古アンプを探したが、やはりパワードスピーカーが買えてしまう値段になるし、そもそも非常に大きくて重く困る。しかし、安いパワードスピーカーはやはり壊れるという事象がかなり多く見られる。

だいぶ手間取ってしまったが、今日SOUNDHOUSEに発注していたものが届き、その中に必要なものが含まれていた。

FOSTEX AP05 パーソナルアンプと、classic proのRCAメス/TRSミニSオスのアダプタだ。AP05は最近話題のもので、音は素直で良い、という評判で5000円。アダプタは100円だ。

このアンプは、単純にミニSでいれてスピーカーで出す、というものだ。どちらかというと、ミニSなポータブルオーディオなどの機器でスピーカーケーブル接続のスピーカーをならすもの、という感じがする。もちろん、これだけでは2系統をまとめられない。そこで、スイッチが再び登場する。4DJからはRCAで入り、VAIOからはアンプを介してパワーのある(音量を上げてはならない)スピーカーアウトをスピーカー-RCAでスイッチに入れる。スイッチのOUTはRCAで、このままではアンプにささらないので、アンプのin(ミニS)にアダプタを差すとアンプにRCAで入力できるようになる。これで、スイッチとアンプがRCAでつながる。

アンプのoutはスピーカーなので、スピーカーと問題なく接続可能だ。

試してみたが、バッチリだった。かなり苦労はしたが、考えてやったことで、うまく安くあげて場所もとらず、品質も十分なシステムをくむことができた。

Mail Deliver Utils.

コードはGitHub参照のこと。

かなり苦労した割に実りは少ないものになってしまった。7時間も書いてこれかと私自身情けない。

モデルだけ紹介しておこう。

fetchmailが起点となり、MDAとしてlocaldelivを呼ぶ。localdelivはディスパッチャとなり、アンチウィルスやスパムなどのフィルタにかけ、ソートようプログラムにまわし、セーブ用プログラムに渡る。

ソートプログラムはメールフォルダの名前を返す。spamasssassinの動作が許容できなかったため、コメントアウトしている。

ヘッダ部分はtmpフォルダにセーブされる。これは、全てのメールが受信されてからチェックするためだ。みれにより、受信時にもっとも優先度の高い差出人からのメールにあわせて着メロを鳴らすというケータイのようなことが可能。また、通知することもできる。

多くの部分がハードコーディングされているが、とりあえず動くようになった仕上がり。拡張性は高いはず。細かく分離されていて、様々なところでトラップ/フェッチできるようになっているので、改良の余地は大きく、改良はしやすいはずだ。

今のところフックは用意していないが、将来的には実装予定。

自己管理と自己境界

自己管理ができず、その責を他者に求める人がいる。

電話でもメールでもIMでもTwitterでも、ブログでもSNSでも同じことだが、誰かが話しかけたせいで時間を費やしたというのは明らかに自身で選択するものであり、そのように時間を費やすことを選んだのは自分自身だね誰かに強制されたわけでもなければ、その義務があるわけでもない。そのように相手に合わせるのがポリシーだというのだとしても、そのようなポリシーを(自分の時間を損失するリスクを含めて)選択したのは自分自身であり、またそれに従ったのもまた自身の選択による。

いずれにせよ、それは自己責任において行われるものだ。それによって時間を損失したり、何かの時間、たとえば食事や睡眠を削られたとしても、それを他者に責任を負えというのは無理がある。

それは、自己決定の自由であり、それを他者に負わせようとするのは責任転嫁にもほどがあるということだ。まして、電話のようにベルによって睡眠を阻害されるなどの理由があるものならまだしも、メールやTwitterの返信などは、無視したところでその影響は基本的に当事者間に限られるのであり、潜在的にもその影響力は小さい。上司・部下の関係などの力関係によってそれが困難な場合もありうるが、そうでないケースならばなおさら、それを他者にどうこういうものではない。

それをとがめるくらいならば自己処理する方法はいくらでもあるにもかかわらず、それを選択しておきながら、その責任を他者に求めるというのは、私からすればあきれるほかない。

さらに、相手にもスタイルやマナー(流儀)、嗜好や生活がある、ということ自体が理解できていない。自己中心的で、自分はこうするからそれに合わせて当然、というのだ。人それぞれであり、相手の流儀との調和のために自分で対応を決めるというのが、人として(大人として)の自己責任なのだが、相手が自分にとって都合のいいように、自分のやり方で自分の希望通りにいくように、しかも要求することなく当然のものとして実行して当然というのだ。これは、傲慢というものだろう。

さらに重大なのは、それと同根となる想像力の欠如だ。相手も人であり、やり方や生活があるということが理解できていないために、相手の生活が自分が見えるものが全てだと思い込んでしまう。そのため、相手の生活は自分だけのもののように捉え、極めて失礼な発言をくりかえしもする。

相手がいかなる配慮をしたか、そのためにどれだけの労を払ったか、どのような想いでそのようにしたか、ということも考えない。相手が何を言っているのかということを理解しようという努力もないのだ。

相手のせいで自分の生活が乱されているというほど自己境界をもっていない、主体性が何のにも関わらず、相手のことを斟酌したり、相手の発言を検討したりはしない。その「自分を持っている自分」がいかに皮相で空疎なものか気付く日はくるのだろうか。

なお、「想い」カテゴリの公開が初めてで、その流儀について述べた原稿がまだ公開されていないので補足しておく。

このカテゴリは、あくまで個人的な主張、思想、感想を述べるものである。ただし、基本的には世の中に広く流通している内容の反復は行わない、というのが原則となっている。また、基本的には私の生活上で生じたことに対する思いを述べているのだが、例えarticleのキッカケが個人であるとしても、個人の人格を対象にしているものではない。以上、承知いただきたい。

IC recorderデータのpick upスクリプト

単純に日付でディレクトリをつくり、そこに移動するだけ。mvよりcp+rmのほうが細かく制御することが可能なので分けている。

#!/usr/bin/zsh

target="$HOME/local/usr/media/sound/voice/record/$(date +%y%m%d)"
if [[ ! -e $target ]]
then
mkdir -p $target
fi

cp **/*.(mp3|MP3|wav|WAV|aiff|ogg) $target && rm **/*.(mp3|MP3|wav|WAV|aiff|ogg)

Mikutter

V2C*Twitterの使い心地がいまひとつよくないので、乗り換え先を検索して出てきたのがこのMikutterだ。

Rubyで書かれているとのこと。

Magia4へのインストール手順はhttp://kizaki3969.blog.fc2.com/blog-entry-3.htmlにある通り。これで問題ない。

使い心は、というと、V2cよりははるかに良い。さくさく動くし、タイムラインはリアルタイムに取得される。情報の参照性も良い。Thank you Ruby!

難点は、ユーザー名を指定してのアクションができない、リストやタブが再起動のたびにリセットされるといったことか。

1時間ほどおいておくと、リストは復活した。よくわからない。

yaplogについて

このブログはyaplog ( http://yaplog.jp/reasonset/ )からの移行だ。1ヶ月程度、yaplogを使ってみた感想を述べる。

広告がしんどい
yaplog!に限らずGMOのサービス全般に言えることだが、とにかく広告ががうっとうしいことこの上ない。 1日15-20通程度メールで送られてくるし、しかもその退会や、登録情報の変更が非常に面倒な仕様となっている。非常に悪意を感じる。
デザインは良い
全体的に乙女度がとても高いが、デザインはかなり良いものが揃っている。ただし、全体にそういう演出的乙女なものを使っている人は少ないようだ。ユーザー定義も可能で、フルカスタマイズできるといっていい。
機能と自由度は微妙
機能は、それなりにカスタマイズできて、自由度はそれなりにあるが、フルカスタマイズはできず、また、大幅な変更は手書きでCSSなどを「変更」しなくてはいけないためしんどい。クラス設定の構造を把握するヒントも少ない。
アクセスログが良くない
単純にカウンタだと思った方がいい。yaplogユーザーなら訪問はわかるが、それでもその詳細はわからない。referと、ケータイかどうかは分かるが、UAなども示されない。
容量、1TBはありすぎではないか
ほぼ気にせず画像はアップできるが、そんなには使わないだろう。UIもやや使いにくい。
つながる機能は非常に弱いが、レプロのタレントだけは紹介される
yaplogが提携しているのだろう。maebloなどと違って、それだけだ。かなり激しい特別扱いでrecommendされる。

人数も少ないため、かなり人も限られる。それなりに大々的にプッシュされる。結構うっとうしい。ランダム機能もないため、横につながっていくコミュニティとしては機能しない。

ネガティブな面が強いと私は思うが、これをきっかけに豊岡さんを知ることができたので、私としては、結果オーライ。

結論としては、あの乙女デザインが好きで、特に深く手を入れず、とにかく書いて公開したい、写真をいっぱいアップしたいという人にはよさそうだ。広告が我慢できれば。それによってつながっていこうとか、深く手をいれようとするとしんどめ。

妙に自由度がなくて、何かを強制される傾向も見られる。Twitter/Facebookの連携機能はある。

Twitterについて

元々あまりイメージはよくなかった。何よりも、公器が平気でプロプライエタリなインターネットサービスを使うことを必須とすることに対して否定的だった。

また、publicなメディアであるのにtemporaryという、ネットにおけるコンテンツの在り方を逸脱したものをWWWを用いて、というところもだ。もちろん、それを雑談に使うのか?発信に使うのか?といった点や、保護されるべき個人情報がないがしろにされる、特に弱者が餌食になる構造にも否定的だった。

しかし、メディアとしての大きさには結局のところ抗えない。特に今はかつてのような発展、拡張の時代ではなく、インターネットサービスも集約、生き残りの時代だからなおさらだ。

だから、「Twitterの運営に関すること」と「Twitter上のコミュニティ」の問題は明らかに切り分けて考えなくてはいけない。

Twitterの運営は、設定がどうなっているのか、様々な設定や運営がどういう挙動を示すかということが不透明で、質問もまともに受け付けないサポート、説明になっていない説明など、かなりひどいものだと思う。インターネットサービスとして最低水準も満たしていないように思うだ。カスタマーハッピー思想の欠如ではないか。

また、radioでTVの人が、使えばすぐ理解するが、使わないとわからない、と言っていたが、使って特に機能や仕様や挙動は理解できなかった。かなり調べたり訊いたりすることになった。ゆえにサポートの不十分さも目に付く。

一方で、Twitterは「自分がフォローしている人と、そのつながりしか見えない閉鎖されたコミュニティを形成する」というのが、思った以上に独特な特徴を持っている。つまり、人によって「Twitterの見え方」は全く異なったものになるということだ。

だが、「つながる力」はかなり大きい。だから、「恐い」と思う。普通、どんな発言をするにせよ、例えきちんと発言に責任を持ち、publciなものであることをしっかり意識していたとしても、なかなか面識もない著名な誰かが直接反応するような状況は考えない。しかし、Twitterだと「本人の耳に届き、本人が反応する」ようなことが普通にある。そのつながりや影響が自分でコントロールできない。これは強みでもあると同時に厄介さでもある。

つながるきっかけは意外と少ないように思う。私が使いかたをしっかりと理解していないせいかもしれないが。

しかし、よくchatと比較されるが、全くの別物だと思う。chatは実際の伝播が限定的である、というだけの話ではない。chatは、相手と話すもの、という前提があるのだ。(IRCなどそうではないこともあるが)。しかし、Twitterは会話ではない。会話になることもあるが、やはりpublicなものであり、特定の相手に向けた発信ではない(DMはあるが)。だから、返ってくるとは限らないし、返そうという意識もない。chatのように「ちゃんと向き合って会話する」モードではないし、相手に向けてメッセージを出したり、また相手と会話を希望するのが難しい。加えて、自由発言のpick upはハードルが高い。会話むきのメディアにはなっていないと考える。

また、掲示板のように自由にpublicな発言を向けられるわけでもない。replyを出せば個人むきととられるし、公衆での1:1の発言と捉えられるからだ。これは、ブログのコメントにも言えることで、メッセージを届けたい時にも使いにくい。というより、ブログとTwitterな時代では、publicに特定の対象に向けて何かメッセージを出そう、ということが極めて阻まれる。これによってメールも制限されることが多いのでなおさらだ。

このメディアとしての不自由さは、少々ひっかかる。

VPS * DeleGate によるフロントエンドサーバーを用いたインターネットサーバー

概要

IPv6への移行がこれほどまでに叫ばれているのに、世の中は全くIPv6に移行する気配がない。IPv4の枯渇はであり、そうなるとグローバルアクセス可能なインターネットサーバーというのは極めて難しい。重大な問題は、グローバルIPアドレスの価値が高すぎること、そしてISPが自宅サーバーを阻む方向にあることだ。

そこでよい対応方法のひとつとして、グローバルアクセス可能なVPSをリバースプロキシとして、という方法があり、さらにいえばVPNを汲むことでVPSをフロントエンド(ルーター)とするサイトを構築することも可能だ。

今回はとりあえず、「VPSを使ってインターネットにサービスを公開する」ところまで事を進めた。

事前準備

少なくともVPSと独自ドメインが必要不可欠だ。別に無料サブドメインでも問題はない。ただし、VPSは将来的にはVPNを汲むことが可能な、つまりはpppあるいはtunデバイスが利用可能なrootサーバーである必要がある。

私は今回、サーバーとしてDTI ServerMan、ドメインはXDomainを利用した。契約書を熟読するのに、何より時間がかかった。契約そのものは簡単で、特にクレジットカード決済ができる人ならあっという間だが。

そして、VPSを安全な状態にセットアップするまでがまた一手間。基本的手順としては、

  • 一般ユーザーを作る
  • 一般ユーザーのパスワードを強固なものにする
  • SSHのポートを変える
  • rootパスワードを強固なものにする
  • usermodでwheelグループに追加
  • visudo
  • FirewallをConnected/ICMP/SSHのみ透過するように変更
  • アップデート
  • 不要なサービスを止める

といったところになる。CentOSでのこうした個々の作業は情報が豊富なので、私は繰り返さない。各自調べてほしい。

この状態では基本的に何もできないので、サーバーを停止しておいたほうが安全である。

レジストラの方でリゾルバの設定(DNSレコードの設定)を行えばVPSに名前でアクセスできるようになる。普通はここで、VPS自身でサービスを起動し、ファイアウォールを設定してサービスを提供する。

私はとりあえずXDomain側でサービスを開始した。XDomainで設定しても独自ドメインでのサービスは提供できるのだが、フルカスタマイズはできないし、将来的にフロントエンドの変更が生じる場合があるので、やめておいた。

DeleGate

DeleGateは汎用のプロキシデーモンだ。HTTP/FTP/NTP/NNTP/Socks/SSH/SMTP/POP3/IMAP4などのアプリケーションゲートウェイ(リバースプロキシを含む)として機能するばかりでなく、ネットワークレベルゲートウェイとしても機能する。つまり、TCP/UDPパケットを転送することも可能。単純にこれをリバースプロキシとして動作させるだけでもかなり多くのサービスが提供できる。

ただ、CentOSにはDeleGateのパッケージがない。かつてはプロキシサーバーといえば、というほど有名だったが、今はマイナーなようだ。そこで手動導入したのだが、思わぬ問題が立ちふさがった。テスト環境はx86_64で、本番環境はi586ということが判明し、同じパッケージが導入できないのだ。そこで、本番環境はRPMで導入、一方テスト環境は

yum install gcc gcc-c++ make openssl-devel
# wget URI
# tar xvf file
# cd delegate9.9.8
# make
# cp src/delegated /usr/local/sbin/

これで最低限動作はするようになる。セキュリティや細かな設定は別として。

さて、テスト環境では

delegated -P 80 MOUNT=”/journal/* blogURI/*”

で動作してくれたのだが、本番はそうはいかず、checksum生成をした上で

delegated -P 80 MOUNT=”/journal/* blogURI/*” PERMIT=”http:*:*”

としてあげる必要があった。

おまけ

無事動作したので、一区切りついたということでお祝いに寿司を食べてきた。

さらっと書いているが、結構大変な作業でトラブル続きだったことを報告しておく。