いい加減音に関する記事もひとつぐらい。
私の制作楽曲は基本的に速攻で配信中にマスタリングまでを行い公開しているので全般的に作業が粗く、過去の制作楽曲を再公開するにあたりもう少しまともな状態でアップロードしたいと思いリマスタリング中なのだが、これがなかなか難しい。
全面的に音圧を上げるためには突出した部分を潰すのが基本的なテクニックだとは思うのだが、それをコンプでやる前に手作業である程度丸めておけば波形が歪む割合を多少抑えられるんじゃないかと思い試行錯誤している。
正直なところこの辺の知識は（別にこれに限った話ではないが）初心者相当のものでしかないので、納得できるものが出来上がるまではまだしばらく時間を要しそうな気がする。
バナー広告のほかに有名な広告スタイルとしてはテキスト広告がある。
バナー広告と違い、テキスト広告の場合は基本的に小さいスペースで挿入され、バナー広告ほど主張も強くないのでデザイン重視のサイト運営者にとっては比較的望ましいタイプの広告と言える。
しかし 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 的なデザインにはあまり暖かみを感じず、コミュニティを作るのに適していないのではないかな、と思うのであった。
だからといって旧世代のデザインに戻そうという考えではなくて、何か別な形で親しみやすさを感じさせる方法はないかな、と考えている。
前回の配信により、ついに容量の壁に直面し過去楽曲をサーバ上から退去せざるを得なくなった。
ひとまず機械的に一番古いデータを退去させる事にした。
過去楽曲の再公開にあたり、全ての曲をリマスタリングしてもうちょっと華々しい感じに仕上げようと考えている。
そのためローカルでちょっと弄ってからアップロードすることになるので、少し時間が掛かりそうだ。
RSS 2.0