CompactFM v0.12 で予定されているアップデート

まだリリースしてないのは私が面倒臭がっているからなんですが、ちょっと前に書いたやりたい事を実装する前にリリースしたいと本当は考えています。
以下のアップデートの予定は既にコーディングが終わっているので確実に適用されますが、まだ問題が見つかれば増える可能性もあります。

・プラグイン周辺をタイプライブラリでのインターフェイス定義へ変更。それに伴う定義の若干の変更に追従。 この変更による機能の追加はありませんが、変更作業中のミスによりエンバグしている可能性があります。

・CompactFM のバージョンを返す機能を追加。

・環境設定ダイアログにヘルプ機能を追加。ダイアログのタイトルバーにある「？」を押して疑問に思ったポイントをクリックする事で項目に沿ったヘルプを表示。

・インストーラの問題を再度修正。設定共有インストールの場合問題が起こるケースがあったためその機能自体を廃止。それに応じてアンインストーラで設定ファイルを削除するプロセスを廃止。設定ファイルを削除するためのツールを作成し同梱するように。また、インストール完了後の readme.txt の表示や CompactFM の実行の機能が Administrator 権限に昇格した状態で実行されるためこの機能も廃止。

・MP3 エンコーダのローパスフィルタをデフォルトで有効に変更。

・MP3 エンコーダのエンコーダ品質があまり低いと記録されないのを修正。

・ShellExecute の呼び出しに失敗するため DirectX 関連のヘッダを QuadrupleD のものから Clootie のものに変更。

・環境設定内で表示されるビルドインプラグイン DirectSound の設定ウィンドウでの挙動を修正。

・インストーラスクリプトの細部を変更し、ウィンドウサイズを標準サイズと同じになるように修正。

・一部の処理を最適化されたものに差し替え。

・配信が切断された場合に再接続を待機するアイコンが256色版のみ透過設定が間違っていたのを修正。

・ドキュメント類を若干整理し、回りくどい表現などを若干簡素な表現へ修正。

・OggVorbis エンコード周辺の処理効率を改善。

・バージョン情報ダイアログを差し替え。

・DirectSoundDUAL と WaveIn プラグインを標準で同梱するように変更。

もっと忙しくなりそうだ

バイト先で同じ時間帯に働いていた人が急病でしばらく休みを取らざるを得なくなってしまったので、しばらくはハードスケジュールが続きそうだ。
しかしまあ、忙しいことはいい事だと思うので、しばらくはその環境に身を投じてみようと思う。

近況

最近あんまり記事書けてないのでちょっとだけでも近況報告しようと思う。

友人がバイトしているお店で通信販売を始めたいとのことだったので、そこのWebサイト構築の手伝いのためにちょっと遠いところまで自転車で出かける日が続いた。（始めたい、というかリニューアルしたいが正しい）

HTML と CSS に詳しい人が居らず入門本を片手に作業しているような状況だったみたいなので、色々な面で結構力になれたと自負している。
この辺は癖を知らずに作るとブラウザごとにレンダリング結果に大きな違いが出ることがしばしばあるので、それを考慮しつつ作業できた事もあり「なかなか貢献できたのではないか」と自画自賛したりとかしなかったりとか。

そんなわけでバイトがない休日はそれに時間を費やしていたので結構慌しかった。その他にも地味にやりたいことも溜まりつつあるので、少しずつでも消化していかなくちゃ、という感じ。

あ、ちなみにちょっと前に起きていたスケジュールの遅れは無事に回収できました。よかったよかった。

いい人悪い人

悪い人はいっぱいいるけれど、悪いおっぱいはいません。

別に個人的な被害はないけども

先月末から合計で３回も警察の人たちと会った。

１回目は近所で起こった強盗事件の聞き込み調査に、２回目と３回目はバイト先にきた（しかも連日）。

真夜中でも飛んできたりして大変ご苦労様という感じだった。

Twitter

Twitter を導入してみた。

Twitter はどうやら「What are you doing?（あなたは何をしていますか？）」という質問への解答をするだけのサービスのようで、気が向いたら自分の状況を送信して他の人にも見てもらい、それに対する反応を貰ったりとかするサービスみたいだ。
Web サイト上から普通に利用したりも出来るようなのだが、メッセンジャー系と連動させたり専用クライアントを導入して使ったりして生活に身近なツールというスタンスで触るのが良さそうだ。
メンバーの追加は一方的で、いきなりaddをクリックして追加するのがこのサービスの流儀らしい。個人的には下手な馴れ合いサービスより殺伐としてて好感が持てる。

しばらく使ってみようと思う。

プロフィールはここ。

最近の専らの悩み

音楽業界の進む方向についていけないこと。

スケジュールを取り戻すためにさし当たって問題なのは

やる気だけだ。

GWも終わり昨日は久々に休みだったのだが遅れた分のスケジュールを必死に取り戻していたら一日は一瞬で終わってしまったのでこれといって目立った創作物などは生み出せなかった（まだスケジュールの遅れは取り戻しきれていない）。

今の生活から無駄に時間を奪っているものを極力排除してしまえばそれなりに時間は確保できるような気もするのだが、そうは言っても現実問題としてストレスの発散方法のひとつになっているので無くしたところで結局別のところで時間を消費するような気がしてならない。

山は続く。

mixi のアカウントを作ってみたが

以前作ってちょっと触ったことがあったのだが、つまらなくてすぐに辞めてそれから1年以上経った。
ちょっとは何かが変わっているかと思ってアカウントを作って覗いてみたところ、見た限りまったく進歩してなかった。

GREE のアカウントも作ってみたがやっぱり面白くないので、多分自分にはSNSサービスは肌に合わないのだと思った。

元々馴れ合い嫌いなんだから試すまでもなかったのかも知れない。

忙しい

今週は何故か1週間バイト出っ放しで休みがないので、ゴールデンウィークがないどころかスケジュールに狂いが出始めた。

たすけて。

Next / Back / New / Old

日記や掲示板などでより古い記事を参照するために「次へ」とか「前へ」とか「進む」とか「戻る」っていうのは直感的じゃない気がする。
過去の記事を参照する場合において、今見ている記事の順番に沿って続きを見るという意味では「次へ」、今見ている記事より古いものを見るという意味で「前へ」でも通用するのでどっちの意味で使われているのかわかりにくくはないだろうか。

言い回しはちょっと長いけど「より古い記事へ」とか「より新しい記事へ」的な、もっと意図が汲み取りやすい表現を使った方が見る側にとって親切なのではないだろうか。
「より新鮮な記事へ」などもアリだと思うのだが、「より未来の記事へ」というのは個人的に微妙なところ。結構過去の記事を辿ってきたあとに少し新しい記事に戻る場合、「未来」という言葉は若干トリッキーな感じがする。
時系列的に考えるとその記事から見れば未来の記事であるのは間違いないのだが、私個人が持つイメージでは「未来」は「まだ到達していない時刻」という感覚が強いので、一瞬考えさせられてしまう（もちろん「未来の記事」まで一気に吹っ飛ばされる事は普通考えられないので気付くのだが）。

まとめると古い記事への参照は「より古い記事へ」、新しい記事への参照は「より新しい記事へ」がいいという話。

CompactFM に関して気になる記述

CompactFM は視聴者向けのツールではなく配信者向けツールという旨の記述を Vector の説明欄に書いているのだが、あの書き方だとわかりにくいのでしょうか。

時代の変化と自分の変化

Blog が普及してからというもの、だんだんと個人サイトの運営スタイルも変化してきたように思っていたのだが、よく考えてみると実際には変化したというよりも今までサイトを持っていなかった利用者層が Blog を書くようになっただけなのではないかと思い始めた。

何の話かというと。

今までは個人サイトというのは基本的に借りたりするなどして Web スペースを確保し、そこへ html ファイルをアップロードすることで運営するのが基本的スタイルだったと思うのだが、最近では極端な例では Blog に未来の日付や過去の日付のエントリを作りそこへサイトとしての体裁を保つために必要なページを作ることで、Blog 上で全てを済ませてしまう人が増えたような気がしていた。
しかしそこを掘り下げて考えてみると、Blog の登場によって与えた影響はインターネットベースでの個人の手による情報配信の敷居を下げたことではないかと思う。恐らくずっとそういうものが望まれていたんだろう。そういう視点で見ると、簡単に個を主張できる環境として mixi が流行った理由のひとつとも考えられなくもないように思える。

HTML を覚えなくてもそれなりに使えるし、ブラウザがあれば一通り何でも出来てしまうような感じなので非常に手軽で確かに流行る理由もわからなくはないし、（何のために存在しているのかはわからないが）Blog に関する本もたくさん出ているようで取っ付きやすさも増して、「自分でも何かコンテンツ展開してみたい」と思う人が気軽に始められるような環境は整ったのかも知れない。
そういったいわゆる職人気質的なクリエイターではなく何となくサイト運営を始めるような人に取ってはデジカメの画像が掲載できれば大抵困る事はないと思うので、まさに Blog や mixi の日記などはそういう用途に適していそうな気がする。

で、話を戻すが結局のところ HTML を自分で記述できる人は今でも普通に Web スペースを借りてコンテンツ展開している人は少なくなく、それとは別に新たに Blog だけでサイトを構築するタイプの人が増えただけじゃないか、という話。
もちろん中には Blog に全てのコンテンツを置くように変更した人もいるだろうが、大多数の人が鞍替えをしたというわけではなくてまだまだ従来のスタンスで展開している人は多いんじゃないかな、なーんて。

NIH シンドローム

私はどうも長らくNIHシンドローム気味なところがあった。

中学生ぐらいの頃までさかのぼってみても、自分のサイトで使う日記や掲示板を Perl で作っていたりしていた。
もちろん中学生が書いたようなスクリプトなので高度なことが出来るものではなかったが、それでも日記に関しては過去記事編集、自動リンク、引用文の着色など自分が欲しいと思っていた機能は全て実装していた。掲示板はあまりやる気がなかったので名前と本文が書けるだけでレス機能もないようなものだった（どうせ書き込みなんてほとんどないだろうからその程度のもので十分と考えていた）。

ちなみになぜそこまで自作に拘るのかというと、当時考えていたことはただ「ページ下部に開発元リンクを入れたくなかった」というだけである。色々なサイトを見て回っても当時は自作でやっている人は少なく、そこに小さな憧れがあったのだと思われる。

それからしばらくした頃に PHP に興味を持って、少し触ると最初から用意されている関数の豊富さに惚れ込んで使うようになった。スクリプトの見た目も Perl のように難解な書き方がなくシンプルで理解しやすかったと思う。それ以降 Perl は使う事がなくなってしまったので、今では構文がほとんど理解出来ないところまで舞い戻ってしまった。
また PHP からはデータベースとの通信も容易だったので、過去に作った Perl スクリプトを一通り PHP で再実装した後にデータベースを利用した Wiki のようなものを自作したりした。ローカルに HTML を一切置く必要がなく管理が楽になると思っていたのだが、textarea の中で本文を編集するのは想像していたよりも面倒臭く、また HTML でバックアップを取るのも機能をちゃんと作らなかったため面倒で、更に追い討ちをかけるようにソースが比較的スパゲティだったので使うのはすぐに止めてしまった。

そんな個人的な格闘を繰り広げているうちに、日本にも段々と Blog ブームがやってきた（といっても本格的に流行り出したのは去年、一昨年あたりだと思うので、それより３～４年前で実際にはまだまだ流行っておらず言葉が知られ始めていた時期だった）。
トラックバックシステムや RSS への対応などは構造がシンプルなので実装は簡単だったのだが、いわゆる「ブログパーツ」のような個人で使うために作るものとしてはちょっと荷が重い部分が増えてきていた。

そんなこともあり、NIH シンドロームから少しずつ開放され始めている。
この通り今では Blog も Blogger で書くようになった。

QuadrupleD の DirectSound

QuadrupleD の DirectSound 周りの実装は色々と危ない香りがする。

まず最初に TDDSDCapture の問題。このクラスは一般的にはあまり使われるものではないと思うのでバグを持っているのは仕方がない部分ではあるのだが、相当前にQD3 の正誤表に書いた通りこのクラスにはリソースリークがある。
しかし実はその他に私は原因を発見出来なかった問題があって、このクラスを使うと不定期のタイミングでプログラムが例外を起こして止まる事があるように思える。これは原因がどこにあるのかハッキリと確証が持てなかったので Wiki では言及しなかったのだが、このコンポーネントを使用していると思われるねとらじステーションでは配信中にエラーを起こす問題があるという掲示板の書き込みを見た記憶があるので、恐らく何か抱えているだろうと思う。
実際自分で TDDSDCapture を用いて OggVorbis をリアルタイムレコーディング＋エンコーディングするツールを作った時にも不定期のタイミングで落ちる問題が起きていて、その時に自分で似たようなクラスを作り直した（ちなみに予想はつくと思うのだが、このツールでの経験をもとに CompactFM を作っている）。
それ以来同じトラブルにはまだ遭遇していない。

もうひとつ、さり気ないながら致命的な問題がある。
検索してみると過去に同じ事例があったようなのだが、QuadrupleD の DirectSound ヘッダを組み込むと ShellExecute の呼び出しが失敗するようになるらしい。
QuadrupleD に付属している DirectX のヘッダファイルは参照カウンタの扱いが特殊になっていて、自分で Release などを呼ぶ事でインスタンスの管理をしなければならないようになっている。それに関連しているのか、いくつかの場所で厄介な構造になっている事に起因しているのかも知れない。
この問題は Clootie graphics pages にて配布されているヘッダファイルを利用する事で解決できた。このヘッダファイルでは特に特殊なことはせずに素直に関数と構造体と定数を宣言しているようで、一部引数が var とポインタで違いがある部分や、参照カウンタを自前で扱う必要がなくなったので Release の呼び出しを削除するなど一部コードの修正が必要になったが問題自体は解消できた。
DDPD でもこのヘッダを使うと問題が解決することがあるらしい（未確認）ので、悩むことがあったらヘッダファイルの差し替えを検討してみるといいかも知れない。

TDDSD など頻繁に使われるコンポーネントは問題が露呈しやすく見つかっても大体すぐ修正されると思うのだが、TDDSDCapture など特殊な用途でなければあまり使われないクラスの場合は問題が見つかりにくいのだろう。
また、ShellExecute の場合もゲームなどの場合あまり使うことがないので恐らくあまり気付かれないままずっと使われてきたのだと思う。

以前不定期のタイミングで落ちるトラブルに遭遇した時点で TDDSDCapture を使うのは止めたのでこれ以上の問題追求や修正などを行うつもりはないが、今後同じトラブルに遭遇する人が出た時のために、一応こういう形で明文化しておくことにした。
この記事が役に立つと嬉しい。

CompactFM にあるといいもの

相変わらず妄想段階から抜け出さないのだが、どんな機能があればいいのか考えたりしている。

思いつく中で一番実装して価値がある機能は、配信しているデータのローカル保存機能。
私の配信している内容の場合「あんまり溜め込んでもなあ…」などと思うところがあるのでそれほど実装する事に重要性を感じてはいなかったのだが、他人が使う上で自分の配信を残すことを考えるならこの機能は結構重要な気がする。
まあ RAZIE などを併用することで録音する事はもちろんできるが、頭から欠損のないデータをネットワーク上の負荷ゼロで保存できることは地味ながら結構重要だろう。この辺は実装する事を考えていこうと思う。
録音中に容量が足りなくなった場合などを考慮して、予めドライブの空き容量不足を警告したりする機能があるといいかも知れない。

あと、これは自分でも必要と思いつつもまだ実装できていない部分なのだが、CompactFM の配信音量変更機能は若干問題がある。
もちろん機能的には正常な動作をしているが、音量変更が反映される周期が実は非常に粗い。
つまみを弄りながら「音量このぐらーい？」とかやると上手く行かないし、ミュートする場合などに不親切な部分が間違いなくあるのでここは修正したい。
あと、音量の変更をできれば滑らかになるように自動的にフェード処理をするようにしたい。動作の理想としては音量操作を行うと一定時間で音量変化していく感じで、変化幅が大きい場合は変化速度も速くなる感じで行きたい。
音量変化の実装自体は難しくないのだが、変更させようとした地点の記録をどうすればいいか迷っているのでこの辺はちょっと考え中。

それに関連して外部から音量変更出来るようにするインターフェイスを装備したいと思っている（プラグイン用の機能としてだけではなく CompactFM API としても）。
というのも、BGM を鳴らすためのツールなどをもし外部から準備する場合、PTT（Push to Talk 機能、ボタンひとつで配信中に発言用設定と音楽のみでの配信を切り替えるためのもの）を実装する場合に比較的重要になってくるのではないかと思うからだ。

現時点で BGM 配信のためのツールを外部の人が作ってくれる見込みはないのだが、API でのコントロールはできるようにしておいて損はないのでやろうと思う。
なお DirectSoundDUAL のように複数の音量調節項目を有している場合のために何番目の音量を調節するのか指定できるようにしようと思うので、音量調節に関して外部から変更する場合における制限などは特にない予定。

相変わらずやりたい事は減らない。

カレールーが入っている容器の名前

グレイビーボート、ソースポット、レトルトパウチ、どんぶり、などなど。

カレーうどんは、店によってスープを専用に作っている場合と、ただカレールーを上からかけるだけの場合と２パターンある。
後者の場合その工程の時点であまり期待は出来ないので、あまり胸は膨らませない方がいいと思う。

時間というものは

いくらあっても足りないけれど、無限に欲しいかと言われると決して欲しくない。

不思議。

USB ヘッドセットとサウンドカードでねとらじを放送する

拙作のインターネットラジオ配信ツール CompactFM は、元々は間違って Oddcast を終了してしまう私が自分のために作ったツールだった。

しかし作っている最中に「複数のデバイスから入力できるようにすれば、自分以外にも需要が出るのではないか？」と思い立ち、いつからか入力機能にプラグインシステムを搭載し、複数のデバイスから入力するための DirectSoundDUAL プラグインを作った。

このプラグインを使えば、例えば記事のタイトルにあるように USB ヘッドセット ＋ サウンドカードの音 という二つのデバイスの音をミックスさせて配信する事が出来るようになる。
だから「ただマイクが使いたくてヘッドセットを買ったのに、ラジオから声しか出せない」というしばしば起こりうる状況に対して対処できるようになっている（もちろん設定を変えてUSBヘッドセットからシステムの音声を出力するようにすれば回避できないわけではないが、なにより面倒臭いだろう）。

その他にも、例えば USB ヘッドセットを２つ繋いで放送したりする事も出来る（その場合は BGM などを流すのが手間になるが…）。
２つまでじゃなくて３つでも４つでもミックスできるようにすれば便利だと考える人も恐らく居るとは思うのだが、正直なところ個人的な用途で利用する場合は２つ以上使うケースというのは非常に稀だと思う。
そういう場合は複数のデバイスのバランスを適切に取らないと配信データが酷いことになるだろうし、使い勝手を考えるとミキサーを買ってきてツマミを手で弄ってバランス調節などした方がいいように思える（ついでにコンプとか通せばもっと良さそう）。

構想としては、もっと上を見ている部分はある。
例えば複数のデバイスからの音を入力して、リアルタイムにオーディオにエフェクトを施して声の音量を大体一定にして配信するだとか、そういう。
でも結局その辺は詳しい知識がある人じゃなければ滅多に使わないと思うし、少なくとも自分は使わないので実装にはあまり気が向かない。
（CompactFM のコアは自分で使っている限りでは今現在とても安定しているので、下手に弄らずにそのままで行きたいという考えもあったりする。）

一方で、宣伝や導入の際に敷居が高いように見えてしまっている部分もあるかも知れない。

個人的には CompactFM の初心者に対する手取り足取りのサポートをするつもりはまったくないので、導入方法に関するチュートリアルなどは同梱のヘルプ以外に用意する気はない。
サポートは非常に時間を要することで、自分のために作ったツールでそんなにサポートのために時間を割きたくない、というのが本心。
ただ、自分が使うためのツールなので機能に関しては自分が困らない程度に作りこんでいるし、自分のためにメンテナンスもそれなりにしている。
サードパーティ製ツールや、解説サイトなんかが今後充実してくれればいいのになあ、と思うところだ。

WINAMP を利用したツギハギな配信システムを脱ぎ捨てて、CompactFM を使うようになる時代がきたら、それはとても嬉しいことだ。
そのためには WINAMP で再生中の楽曲タイトルをリアルタイムに CompactFM に送りつけたりするような構造はきっと必要になるだろうし、作らないといけないのかなあ、などと思う。

音圧をあげよう、音圧をあげよう

いい加減音に関する記事もひとつぐらい。

私の制作楽曲は基本的に速攻で配信中にマスタリングまでを行い公開しているので全般的に作業が粗く、過去の制作楽曲を再公開するにあたりもう少しまともな状態でアップロードしたいと思いリマスタリング中なのだが、これがなかなか難しい。

全面的に音圧を上げるためには突出した部分を潰すのが基本的なテクニックだとは思うのだが、それをコンプでやる前に手作業である程度丸めておけば波形が歪む割合を多少抑えられるんじゃないかと思い試行錯誤している。

正直なところこの辺の知識は（別にこれに限った話ではないが）初心者相当のものでしかないので、納得できるものが出来上がるまではまだしばらく時間を要しそうな気がする。

文字化けしないテキスト広告を

バナー広告のほかに有名な広告スタイルとしてはテキスト広告がある。

バナー広告と違い、テキスト広告の場合は基本的に小さいスペースで挿入され、バナー広告ほど主張も強くないのでデザイン重視のサイト運営者にとっては比較的望ましいタイプの広告と言える。

しかし iframe タグや JavaScript を使わずにサーバサイドで自動挿入されるテキスト広告の場合、基本的に HTML の文字コードに依存し、状況によっては文字化けを起こすことがある。
もちろんアルファベットだけで記述された広告ならば、UTF-16 や UTF-32 などのエンコーディングを用いない限りは大抵の場合正常に表示されるだろうが、日本のレンタルサーバが広告を挿入する場合はそうも行かないだろう。

ところが、この問題は少し考えればすぐに思いつく、簡単な対処方法がある。
それは実体参照（&#XXXX;のような表記をするヤツ）を利用してエンコードに依存する文字を記述すること。

少なくとも UTF-8 や Shift_JIS、EUC-JP など国内で頻繁に使われる文字コードにおいては実体参照を使用することで、多くのケースで日本語が文字化けせずに挿入可能になると思われる。
例えば相当古いブラウザでは実体参照表記をサポートしていなかったり、テキスト広告全体のバイト数が増えるとか些細な問題はあるものの、市場に出回っていて、デバッグ目的以外で実際に利用されているブラウザは全て対応しているように思う。

ただし、携帯用のブラウザについては問題がある。

携帯の場合数値参照はどうやら i-mode の絵文字を参照するために使われるようで、通常の HTML のように Unicode の値で指定するのではなく、Shift_JIS の外字領域を指定することで絵文字を表示出来るようにしているようだ。
そのため通常の文字を書くために通常の HTML と同じ実体参照を使用することはできず、この場合ページに合ったエンコードを適用する必要がありそうだ。
携帯にそのままPCの広告を流し込むこと自体に疑問を感じるところではあるので、ここは個別対応する方向でどちらにしろ進みそうな気がする。

テキスト広告なのに文字化けしないというのは結構魅力を感じるので、どこかが積極的に取り入れてはくれないものだろうか。

Internet Archive

様々な人の恥ずかしい過去を暴くためのサイトとして比較的有名な Internet Archive だが、トップページを見ればわかる通りその巨大なストレージ領域を生かして違ったサービスも提供している。
その中で私は Audio に目を付けて、ここを楽曲のアップロード先に使えないものかと考えたのである。

アカウントを作成し試しにアイテムを作り、そこへいくつかのファイルをアップロードして挙動を調べてみた。

MP3(192kbps) をアップロード
　　→ MP3(VBR), MP3(64kbps), OggVorbis を自動生成

OggVorbis をアップロード
　　→ MP3(VBR), MP3(64kbps) を自動生成

Wave をアップロード
　　→ FLAC, OggVorbis, MP3(VBR), MP3(64kbps) を自動生成

FLAC をアップロード
　　→ OggVorbis, MP3(VBR), MP3(64kbps) を自動生成

OggVorbis のクオリティは大体 -q3.0 ～ -q4.0 ぐらい、MP3(VBR) は -V3 ～ -V5 ぐらいのビットレートになっているように思える（状況によってこれは変わるので何ともいえない）。
CD と同等のクオリティのデータを配信する目的の場合、FLAC ファイルをアップロードしても Wave ファイルにデコードして配信してはくれないため、ダウンロードする側の手間を考えれば Wave ファイルをアップロードするのも選択肢のひとつとして考えられる（というか、FLAC で送信したのを Wave にデコードして欲しいというのが本心なのだが……）。もちろんリスナーに FLAC のデコードができることを要求するならば、FLAC でアップロードしても一向に構わないと思うが、面倒臭がりな人にとっては Wave がいい状況も少なくないだろう。

OggVorbis と MP3 は自動生成の場合出力されるビットレートに不満があるかも知れないが、特に変更する方法はなく、自分で MP3 を違うビットレートでエンコードして ファイル名_128kb.mp3 などのファイル名でアップロードしてトラック番号を一緒にしても、ファイル一覧ではまとめてもらえない（Flash の楽曲リストにはまとめてもらえるようだ）。
多くの場合 MP3(VBR) の音質はそこそこのものが出力されるので、妥協してしまった方がいいように思える。

Internet Archive のサーバのダウンロード／アップロード速度は爆速とはいかなくとも結構速いので、贅沢に FLAC か Wave でデータをアップロードして、サーバ側で MP3 に変換してもらう使い方が個人的には一番いいのではないかな、と思う。

その他画像データや PDF データを送信する事もできるので、今までディスク媒体として配布していたものなどを完璧にデジタルベースで配布する事も可能だと思われる。

なおアップロードしたデータに関しては Public Domain や Creative Commons などのライセンスを選択しそれをページ内に表示する事ができるので、ダウンロードする側にとっても明確なライセンスの元でダウンロードできるのである程度の安心感を得られそうだ。

アイテムの削除をする方法はないのだろうか。

サイトデザイン考察

サイトデザインを考える場合、見た目の綺麗さも重要ではあるものの、最重要視しなければならないのはやはりアクセシビリティだと考えている。そして、使い勝手のよさというのは機械的に考えられるほど単純なものではなくて、たくさんのケーススタディを重ねることによって得られるものだと思う。
私はデザイナではないしインターフェイスデザイナでもないので専門的な教養はまったくといっていいほど何も持ち合わせていないのだが、何もないところからでも考えられることは山ほどあり、試行錯誤してとっつきやすいサイトデザインというものを考えている。

ただ、長いこと色々なサイトデザインなどを見てきて思ったのは、「綺麗過ぎるデザイン」「完璧なデザイン」など、サイトそのものが作品としてのまとまりをしっかり感じるものになっていた場合、コンテンツが見るだけのものの場合は特に何も感じなくても、掲示板などのように書き込みできる要素がある場合気軽に書き込みにくいオーラが漂うのではないかと思う（少なくとも私は、出来上がっている人様の「作品」を自分の文章で汚してしまってよいのか躊躇ってしまう）。
そういう意味では１～２世代遡って、テーブルデザインをしているかのようないわゆる「ダサい」デザインの方が親しみやさすが出てくるように思える部分がある。
Web2.0 などという名前でインタラクティブな Web サイトや次世代的なデザインの Web サイトなどが増えてくるようにはなってきたが、繁盛しているようなサイトの多くは未だに旧世代を思わせるデザインだったり、実際昔から長い事見た目が進化していなかったりはしないだろうか。

Web2.0 的なデザインにはあまり暖かみを感じず、コミュニティを作るのに適していないのではないかな、と思うのであった。
だからといって旧世代のデザインに戻そうという考えではなくて、何か別な形で親しみやすさを感じさせる方法はないかな、と考えている。

ついに立ちはだかる容量の壁

前回の配信により、ついに容量の壁に直面し過去楽曲をサーバ上から退去せざるを得なくなった。
ひとまず機械的に一番古いデータを退去させる事にした。

過去楽曲の再公開にあたり、全ての曲をリマスタリングしてもうちょっと華々しい感じに仕上げようと考えている。
そのためローカルでちょっと弄ってからアップロードすることになるので、少し時間が掛かりそうだ。

FPDF から TCPDF へ

以前日本語化された FPDF を使って PHP スクリプトによる PDF ドキュメント生成スクリプトを書いた事がある。

そのライブラリは当時日本語のフォントファイルの埋め込みをサポートしておらず（現在もしていないようだ）、PDF を開く環境によってはフォントが変わって表示されてしまう問題があった。
今日では Windows, MacOSX, Linux 系などを始めとした様々なプラットフォームがあるが、残念ながらどの環境でも共通に指定できるフォントというのは存在しないので「深刻な問題だなあ」と思いつつも、埋め込めるようにコーディングする能力も持っておらず何となく消化不良のまま利用してスクリプトを組んでいた記憶がある。

今日思いつきでそのライブラリ周辺を調べてみると、TCPDF という FPDF を拡張したライブラリを発見した。
かなり多数の拡張が施されているようで、その中にはフォントの埋め込み機能もあり少し気になったのでダウンロードして導入してみた。

ネット上の記事を探してみるといくつか改行コード変換に伴ったバグで日本語が化ける問題があったようなのだが、CHANGELOG.TXT を読んでみるとどうやら修正されているようで、確かに化けるといわれていた「名」などをそのまま出力する事ができた。
フォントファイルの埋め込みはそのまま TTF フォントで行う事は出来ないのだが、変換用ツールとスクリプトが同梱されており、それを使う事で簡単に専用形式で出力されるので最初に少し手間は掛かるが利用には差し支えない。
出力フォーマットも HTML である程度指定する事が出来るようになっているので、ちょっとした出力を整形するためならほとんど生コードを書かなくてもよくなっており非常に洗練されたライブラリになっているようだ。

望みの機能は大体実装されていたのだが、些細な不満もなかったわけではなかった。
フォント情報はサブセットではなくそのまま埋め込まれるような設計になっているため、サブセットを使えば 100KB 未満で済むような小さなデータでもフォント情報を全て抱え込むと 3MB ぐらいになってしまった（それでも zlib で圧縮されているので、生の TTF ファイルを抱え込むよりは数倍マシである）。
ビットマップフォントが主流の時代であればノーマルフォントを加工してボールドフォントを生成したりするのも現実的な選択肢だったが、アウトラインフォントが中心となった今では太字には太字専用のフォントが欲しい。しかしフォントファイルを２つ抱え込むと単純に容量が増えるので、こういう状況の時を考えてもフォントのサブセットでの埋め込みに対応してくれる事を心のどこかで期待している自分がいる。

PHP はインターネット経由で使われる事が多いこともあり、ファイルサイズに対しては厳しい目で見てしまう。
もしこのライブラリがローカルな環境でしか使えないものだったなら、それは気にならなかったと思う。

過去楽曲公開用ストレージ

熱心に探していたわけではないのだが、とあるサイトを見ていたらたまたま凄くいいストレージサービスがあるのを見つけたので、公開楽曲の容量が限界に来たらそこへ全てのデータを移転させようと思う。

ついでに

SEO 対策的なものも少し取り入れてみた。

サイトの移転、その他

とある事を始めるにあたり geocities では出来ないことがあり、また貴重な xrea アカウントが余っていたので思い切って Web サイトを移転する事にした。

CompactFM のドキュメント周りや Vector の登録情報など、URL を書き換えなければならない箇所はまだいくつか残っているのだが、記憶が間違っていなければサイトのアドレスはトップページしか記載していないはずなので、ひとまず移転通知を出しておけば移動してもらえるだろうという事で人の判断に甘える方向で進めている。

ブログも何となくチョビチョビと書き始めてしまったのでサイト内からリンクをしようと思いつつも、そろそろメニュー項目数が増えてきてサイトに縦にダラッとコンテンツを並べるのも限界が来ているように思える。
近いうちに上部にメニューを出すなどして、アクセシビリティの向上を図りたいところだ。

サイト運営を始めてからそろそろ4ヶ月ぐらいになるが、おかげさまで楽曲の公開も程ほどに順調に進んでおり、近いうちにアカウントの容量限界である 50MB に到達しそうだ。
正直なところを言うともう少しスペースが長持ちすると思っていたのだが、予想に反して MP3 ファイルが容量を圧迫しており、この先過去の楽曲をどうやって管理していこうか迷っている。

Windows で Apache2.2 系に WebDAV を導入［未解決］

WebDAV を導入する方法を検索してみたところ、Apache2.0 で行う方法は色々と出てくるのだが Apache2.2 の場合の設定方法はあまり数が見つからなかった。
Apache2.2 からの変化に気付いてしまえば難なく解決できたのだが、気付かない人のためにも一応明文化しておくことにする。

Apache2.2 からは httpd.conf に WebDAV に関する設定を記述するよりも、conf/extra/httpd-dav.conf に設定を記述して、httpd.conf の後ろの方にある #Include conf/extra/httpd-dav.conf のコメントアウトを外して設定する事が推奨されているようだ。
conf/extra/httpd-dav.conf には設定の簡単なテンプレートも存在しているので、それを書き換えることで取り合えず WebDAV を動作させる事ができた。

しかし、日本語フォルダに対応できない問題がまだ残っている。
日本語対応は mod_encoding を導入すれば解決するようなのだが、探した限りでは Apache2.0 系用の mod_encoding しか Windows 用のバイナリは見つからず、どうやら自分でソースコードを落としてコンパイルしなければならなそうな雰囲気がある。
Linux 環境での Apache2.2 対応パッチの内容を見てみると変更箇所はそれほど多くないようなのだが、VC++6.0 片手に Win32 版 Apache のコンパイルを試してみたところどうも失敗する。なので、ひとまず諦めて日本語フォルダ／ファイルは設置しない方向でしばらくは運用してみようと思う。

というのも、元々は Windows 上で共有フォルダを作れる環境を用意するために始めたのに、いつのまにか大きく脱線してしまい関係ない部分で時間を取られすぎたから、本来の目的を振り返るとこれ以上時間をかけるのは得策ではないと思ったため。

今度時間があるときにでも再挑戦したい。

時間がない時は、色々な事を始めたくなる。

そんなわけで、ブログを設置してみた。

何かを思った時に、思ったことを書き綴っていく場所にしようと思います。