いい加減音に関する記事もひとつぐらい。
私の制作楽曲は基本的に速攻で配信中にマスタリングまでを行い公開しているので全般的に作業が粗く、過去の制作楽曲を再公開するにあたりもう少しまともな状態でアップロードしたいと思いリマスタリング中なのだが、これがなかなか難しい。
全面的に音圧を上げるためには突出した部分を潰すのが基本的なテクニックだとは思うのだが、それをコンプでやる前に手作業である程度丸めておけば波形が歪む割合を多少抑えられるんじゃないかと思い試行錯誤している。
正直なところこの辺の知識は（別にこれに限った話ではないが）初心者相当のものでしかないので、納得できるものが出来上がるまではまだしばらく時間を要しそうな気がする。
バナー広告のほかに有名な広告スタイルとしてはテキスト広告がある。
バナー広告と違い、テキスト広告の場合は基本的に小さいスペースで挿入され、バナー広告ほど主張も強くないのでデザイン重視のサイト運営者にとっては比較的望ましいタイプの広告と言える。
しかし iframe タグや JavaScript を使わずにサーバサイドで自動挿入されるテキスト広告の場合、基本的に HTML の文字コードに依存し、状況によっては文字化けを起こすことがある。
もちろんアルファベットだけで記述された広告ならば、UTF-16 や UTF-32 などのエンコーディングを用いない限りは大抵の場合正常に表示されるだろうが、日本のレンタルサーバが広告を挿入する場合はそうも行かないだろう。
ところが、この問題は少し考えればすぐに思いつく、簡単な対処方法がある。
それは実体参照（&#XXXX;のような表記をするヤツ）を利用してエンコードに依存する文字を記述すること。
少なくとも UTF-8 や Shift_JIS、EUC-JP など国内で頻繁に使われる文字コードにおいては実体参照を使用することで、多くのケースで日本語が文字化けせずに挿入可能になると思われる。
例えば相当古いブラウザでは実体参照表記をサポートしていなかったり、テキスト広告全体のバイト数が増えるとか些細な問題はあるものの、市場に出回っていて、デバッグ目的以外で実際に利用されているブラウザは全て対応しているように思う。
ただし、携帯用のブラウザについては問題がある。
携帯の場合数値参照はどうやら i-mode の絵文字を参照するために使われるようで、通常の HTML のように Unicode の値で指定するのではなく、Shift_JIS の外字領域を指定することで絵文字を表示出来るようにしているようだ。
そのため通常の文字を書くために通常の HTML と同じ実体参照を使用することはできず、この場合ページに合ったエンコードを適用する必要がありそうだ。
携帯にそのままPCの広告を流し込むこと自体に疑問を感じるところではあるので、ここは個別対応する方向でどちらにしろ進みそうな気がする。
テキスト広告なのに文字化けしないというのは結構魅力を感じるので、どこかが積極的に取り入れてはくれないものだろうか。
様々な人の恥ずかしい過去を暴くためのサイトとして比較的有名な 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 を使って PHP スクリプトによる PDF ドキュメント生成スクリプトを書いた事がある。
そのライブラリは当時日本語のフォントファイルの埋め込みをサポートしておらず（現在もしていないようだ）、PDF を開く環境によってはフォントが変わって表示されてしまう問題があった。
今日では Windows, MacOSX, Linux 系などを始めとした様々なプラットフォームがあるが、残念ながらどの環境でも共通に指定できるフォントというのは存在しないので「深刻な問題だなあ」と思いつつも、埋め込めるようにコーディングする能力も持っておらず何となく消化不良のまま利用してスクリプトを組んでいた記憶がある。
今日思いつきでそのライブラリ周辺を調べてみると、TCPDF という FPDF を拡張したライブラリを発見した。
かなり多数の拡張が施されているようで、その中にはフォントの埋め込み機能もあり少し気になったのでダウンロードして導入してみた。
ネット上の記事を探してみるといくつか改行コード変換に伴ったバグで日本語が化ける問題があったようなのだが、CHANGELOG.TXT を読んでみるとどうやら修正されているようで、確かに化けるといわれていた「名」などをそのまま出力する事ができた。
フォントファイルの埋め込みはそのまま TTF フォントで行う事は出来ないのだが、変換用ツールとスクリプトが同梱されており、それを使う事で簡単に専用形式で出力されるので最初に少し手間は掛かるが利用には差し支えない。
出力フォーマットも HTML である程度指定する事が出来るようになっているので、ちょっとした出力を整形するためならほとんど生コードを書かなくてもよくなっており非常に洗練されたライブラリになっているようだ。
望みの機能は大体実装されていたのだが、些細な不満もなかったわけではなかった。
フォント情報はサブセットではなくそのまま埋め込まれるような設計になっているため、サブセットを使えば 100KB 未満で済むような小さなデータでもフォント情報を全て抱え込むと 3MB ぐらいになってしまった（それでも zlib で圧縮されているので、生の TTF ファイルを抱え込むよりは数倍マシである）。
ビットマップフォントが主流の時代であればノーマルフォントを加工してボールドフォントを生成したりするのも現実的な選択肢だったが、アウトラインフォントが中心となった今では太字には太字専用のフォントが欲しい。しかしフォントファイルを２つ抱え込むと単純に容量が増えるので、こういう状況の時を考えてもフォントのサブセットでの埋め込みに対応してくれる事を心のどこかで期待している自分がいる。
PHP はインターネット経由で使われる事が多いこともあり、ファイルサイズに対しては厳しい目で見てしまう。
もしこのライブラリがローカルな環境でしか使えないものだったなら、それは気にならなかったと思う。
熱心に探していたわけではないのだが、とあるサイトを見ていたらたまたま凄くいいストレージサービスがあるのを見つけたので、公開楽曲の容量が限界に来たらそこへ全てのデータを移転させようと思う。
とある事を始めるにあたり geocities では出来ないことがあり、また貴重な xrea アカウントが余っていたので思い切って Web サイトを移転する事にした。
CompactFM のドキュメント周りや Vector の登録情報など、URL を書き換えなければならない箇所はまだいくつか残っているのだが、記憶が間違っていなければサイトのアドレスはトップページしか記載していないはずなので、ひとまず移転通知を出しておけば移動してもらえるだろうという事で人の判断に甘える方向で進めている。
ブログも何となくチョビチョビと書き始めてしまったのでサイト内からリンクをしようと思いつつも、そろそろメニュー項目数が増えてきてサイトに縦にダラッとコンテンツを並べるのも限界が来ているように思える。
近いうちに上部にメニューを出すなどして、アクセシビリティの向上を図りたいところだ。
サイト運営を始めてからそろそろ4ヶ月ぐらいになるが、おかげさまで楽曲の公開も程ほどに順調に進んでおり、近いうちにアカウントの容量限界である 50MB に到達しそうだ。
正直なところを言うともう少しスペースが長持ちすると思っていたのだが、予想に反して MP3 ファイルが容量を圧迫しており、この先過去の楽曲をどうやって管理していこうか迷っている。
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 上で共有フォルダを作れる環境を用意するために始めたのに、いつのまにか大きく脱線してしまい関係ない部分で時間を取られすぎたから、本来の目的を振り返るとこれ以上時間をかけるのは得策ではないと思ったため。
今度時間があるときにでも再挑戦したい。
RSS 2.0