  |
はてなキーワード: 周波数とは
「しょぼい音色・音圧ってなに？」について自分なりの解釈を書きたいと思います。
（YOASOBIについてはあまり触れられてないので、ご了承ください）
一概には言えないですが、「低音～高音がバランスよくでる、音の強弱が自然に聞こえる」と良い音かなと思います。
良し悪しは音源の値段に比例することが多く、
特にオーケストラ音源は高いものほど良い楽器・環境で収録した音が鳴ります。
逆に、シンセサイザーなどの電子音はそこまで値段に比例しない印象です。
https://soundcloud.com/samulis/sets/vsco-2-ce-tracks
https://www.youtube.com/watch?v=0XnlFe83_Ag
なお、ボーカル・楽器の録音のクオリティもこちらに該当します。
素材の音量や周波数を修正して、素材の良さを引きだす工程です。
その音自体が持つ良さを引き出す作業となるため、「どういう加工だと良いか」の定義はありません。
また、曲のジャンルや他の楽器のバランスによっても加工の良し悪しが変わるため
１．と違ってこの項目単体だけで評価するのは難しいです。
例えば、音量を加工する場合は以下のような処理をおこないます。
http://digzinc.com/dcc/blog/2016/04/22/post-725/
なお、プリセット（シンセに格納されるサンプル音源群）を加工するのもこの工程になります。
「ボーカルがハッキリ聞こえて、楽器の音はボーカルを邪魔せず引き立てるように鳴らす」
ただし、特にボーカロイドの楽曲は楽器の音量が極端に大きいものが多く、
その顕著な例が以下です。
https://www.youtube.com/watch?v=egvvRpzLcgA
ピアノなどの高音が大きすぎて、聞いていて疲れちゃうようなMIXになっています。
ただ、ボーカロイドを聴くような層にはこれくらい派手なMIXが良いのかもしれません。
以下とかはボーカルを邪魔しないように緻密な音量調整がおこなわれており、キレイなMIXだなと感じます。
https://www.youtube.com/watch?v=RuCB-3YavxA
曲をどれくらいのボリュームで聞かせるのかを調整する工程です。
１～３は素材ごとに処理するのに対し、この工程は楽曲全体に処理をかけるものになります。
「音圧戦争」「海苔波形」という言葉を聞いたことがある方は多いと思いますが、
音を大きく聞かせようとすると音量のメリハリがなくなったりノイズが入ったりなど、デメリットがあります。
そのため、デメリットを生じずにほどほどの音量で聞こえるのが、良い音圧調整となります。
音質では度々問題になるのがキングレコードですが、特に酷いのはこの曲とかですかね。
音量を大きくしようとしすぎて、ボーカルもシンセの音も潰れちゃってます。。
水樹奈々「Synchrogazer」MUSIC CLIP
https://www.youtube.com/watch?v=2DKCoLZAGvQ
同じアーティストでも、こちらの楽曲は割と元の音を保っているので、マスタリングをする人の腕によって大きく左右されるのが良くわかります。
水樹奈々『禁断のレジスタンス』MUSIC CLIP（Full Ver.）
https://www.youtube.com/watch?v=YHxSSEYA7_E
分類は以上です。
で、例のジャーナリストがしょぼいと言っているのは
「音圧のしょぼさ」→「４．」
にあたるかなと思います。
「このビートの単調さ」の部分はアレンジに関わるところなので、また違う話ですね。
長くなってしまったので、YOASOBIの音色・音圧がしょぼいかどうかは別記事で改めて書こうと思いますが、
正直、音色・音圧のクオリティは聴く方からしたら些末なことと思います。
音色・音圧の良し悪しがわかるようなスピーカーで音楽を聞く人は少数でしょうし。
ヒットの要因はメロディ・歌詞・ボーカルによるものが圧倒的に大きいと思うので、
＞音楽素人の素朴な疑問と思ってもらいたいんだけど、音色にショボいとかあんの？
＞どんな音色もみんな違ってみんな良いんじゃないの？
＞YOASOBIの音色の「ショボさ」というのはどういう部分に起因しているんだろう？
「◆１．」に記載したように、重厚感のあるオーケストラを作りたい場合にはどうしても高い音源が必要で、
それを無料版のような細い音源で制作しようとすると「ショボい」音色になってしまいます。
また、高い音源の方が音の鳴り方や強弱、演奏方法などカスタマイズが自由に効くものが多いため、
曲調に合わせて自然に鳴らすことができる、という利点もあります。
ただ、逆に「ショボさ」を敢えて活かして音作りをすることもありますので、
必ずしも高い音源を使えば良いという訳ではありません。
ただし、高い音源の中には高スペックなPCが必要なものがあります。
オーケストラを作るような人は64GB,Core 9iはマストだと聞いたことがあります。
最近のシンセサイザーはプリセットでも優れた音が鳴るものも多く、
プリセット音しか使ってないことが必ずしも悪いことではないと考えてます。
楽器の弾き方～、のところは音作りではなくアレンジの仕方を指しており、この記事で書いたのとは別の話になります。
このあたりも別で書けたらと思ってます。
日本でヒットする楽曲は様々な楽器を鳴らしたものが多い印象ですので、ギター一本だと「ショボい」と感じる人は一定数いるのかもしれません。
以下のような超シンプルなアレンジでヒットするものは日本ではあまり見ないですね。。
Pharrell Williams - Happy (Official Music Video)
https://www.youtube.com/watch?v=ZbZSe6N_BXs
＞あと音圧ってのもよく分かってなかったけど、基本的には「音量」とイコールでいい？
＞「最大音量と最小音量の差を少なくした上で平均音量を上げること」みたいな感じで理解したけど。
＞となると「音圧がショボい」というのは「音量が小さい」という話なのかな。
＞でも、音圧って上げれば上げるほど良いってわけでもないだろうし。
YOASOBIの楽曲は確かに最近の音圧バリバリの楽曲と比べると低めな方ですが、
全然許容できる範囲ですので、音圧戦争には巻きまれないぞ、という意思を自分は感じました。
あー！なるほど！
「豊かな音色」と感じるためには、
高音域がこれくらい鳴って、中音域はこれくらい、低音域も十分に、と感じるようなバランスが必要なわけね。
そういうのを普通の場合はイコライザっていう、音域ごとのバランスを調整する機材（であってる？）で調整するんだけど、これは、それをしていないから、大きいスピーカーとか高音質のヘッドフォンで聴いたときに見劣りするってことね。
高級ではない普通のイヤホンとか、スマホのスピーカーとか、パソコン付属の小さいスピーカーでは違いがわからない。
会った件数：0
これらが女性側の求めるもの以上だったときにはじめてマッチングすることができ、更に
が適切な内容だった場合のみメッセージのやり取りを開始することが出来るのですが、自分はそのハードルを越えることがほとんどできませんでした。
ちなみに、いいねを送っている女性の系統はインドア系の趣味も許容できるとプロフィールに書いてある、もしくは女性もインドア系の趣味、デート代が割り勘になっている人たちです。
友人や家族からは評判がよかったプロフィール写真なのですが、自分がいいねを送っている人たちにはあまり印象のよくない写真らしくほとんど足跡が付きませんでした。
（パソコンで作業をしている時に「こっち向いて〜」と言われたのでそっちを向いたらカメラを向けられてたので思わず笑顔になった瞬間が収められている写真です。
いろいろ試行錯誤を繰り返しているので、もしよければ「こんな写真がいいよ！」とかあれば教えてください。）
自己紹介の文章や詳細プロフィールについてもあまり印象がよくないのか、足跡がついてもほとんどがブロックされてしまいます。
後で話を広げられるように趣味は広い定義で書いているのですが、もし詳細にプロフィールに書いたほうがいいことなどあれば出来れば教えてください！
アマチュア無線やラジオを聴いています。基本的にスケルチ全開な為、特定周波数をワッチしているときには数時間ホワイトノイズのみを聴いていることもあります。（受信にはVR160を使っています。）
一応アマチュア無線の免許も持っているのですが、ハンディ機しか持っていないので電波を出すことはほとんどないです。
いつかBCLラジオを買って海外の局にベリカードを送ることが夢です。
ThinkPadのジャンク品からパーツを取って自分のThinkPadを整備したりしています。
他にも自分の開発用マシンのjournalを確認してエラーメッセージを調べてみたり、launchpadのバグ情報を確認したりしています。
いろんなWEBサイトを巡回して面白い動きや表現があれば自分用にメモしています。
また、APIに送信されている情報を見て、こういうAPIの作りもいいな〜とかもメモしています。
あとは自分用にちょっとしたツールを作成したり、言語のリファレンスを読んだり、最近はクラウドサービスのドキュメントも読んだりしています。
間違った情報や古い情報を書いているサイト、既存の脆弱性が放置されたままのサイトを撲滅させることが夢です。
どうやったら一番効率よく勝てるのかを考えています。身近なところだとパチンコの勝ち方を調べたり計算したりしています。
オーバー入賞の方法や期待値の計算など、なかなか奥が深くて楽しいです。
日本にカジノが出来たらブラックジャックでチキン・ディナーを体験してみるのが夢です。
子持ちの人、年齢が10以上離れている人にはどうせ相手にされないだろうと思ったので最初はいいねを送っていなかったのですが、
「いいねを送り返すかどうかは相手が決めることだから気にせずどんどん送った方がいいよ」とのアドバイスを友人に貰ってからは気にせずいいねを送るようにしていました。
結局そういう人たちにはいいねを送ってもブロックされたのですが。。。
マッチングアプリ、奥が深い。
音楽は聴いたときの体調とか周囲の環境とかでまったく印象が変わってしまうことがある
同じ曲を毎日聴くとしても、あれ？こんなに速かったっけ？と思うこともあれば、なんか遅すぎないか？と思うこともある
コンサートなどでメンバーに同じ拍子が電子音で聴こえる耳に装着する機器、クリッカーと呼んだりもした気がする、があるが、
あれがないとドラムやベースから加速していってしまうことがある
思うにずっと弾いていると色々と音の感覚が麻痺してくるというのもあるし、心拍数が上がるからでもあるんだろう
だから、最初から弾いていってアクセルが入って速くなっていくのは違和感がなくて問題がないが、
途中参加で演奏する人からすれば、こいつらなんでこんなに速いんだ？みたいに思うこととかあるのではないだろうか
商業音楽だろうがクラッシックだろうが何だろうが、すべての音楽の原点は原始人が炎の周りで踊るようなものだったはずである
それは基本的に太鼓がベースであり、音階はないがリズムがあり、規則性があった
規則性はリズムだけでなく音階にも当てはめられ、それが数学と音楽の関係に結びついた
しかし、なぜこの周波数の音が気持ちが良く、なぜ不協和音が不快なのか、
一方で半音ずれたことによる不快な和音が気持ち良く感じる人がいる、もしくはディミニッシュパッシングだっただろうか、
音が上昇、下降するときに半音で移動するというのは非常に心地よく感じられる、ことがある
これはベース音が単音であれば単なる半音であるが、コードとしての当てはめ方はいくつかあると思う
それがいわゆる５度進行であったり、ディミニッシュコードで補間するというものである
このディミニッシュコードは単体では深いな音に属するように思われるが、安定したコードの間に挟むと美しくさえ感じるのである
ある局所的なエネルギー最小値から別の最小値、凹みから凹みへ移動するには山を越えなければならない
音によって感情が作り出されることがある
逆にそのときの感情によって音に対する感想が大きく変わるのである
そういう点から考えるならば、職場に最適な音、音楽、食事中に最適な音楽、
フィリップ・K・ディックの小説「アンドロイドは電気羊の…」のムードオルガンではないが、望ましい感情を音楽から作ることもある程度は可能であろう
偶然にも ahamo 発表前に au 脱出していたから書く。
au は月末夜とかだと、適用が翌々月とかになるから前もってやったほうがいい。デメリットは（2年契約のカウントがリセットされて"更新月"が延びるくらいだから）ほぼない。
my au からも変更できるが、「2年契約N」というプランを選ぶ訳ではないので注意。「ピタットプラン 4G LTE」にしておけば2年契約の方も変更される。
これも my au からやれるが、契約しているプランによっては電話か店舗でになる。引き留められるがそこは不屈の意志でやろう。自分は「欲しい機種がない」とかにした。
ちなみに UQ への移行も提案されるが、ネットに出ているポイントキャッシュバックとどこが違うのかわからなかった。まあお好みで。
あと、転出後は my au へのログインが SIM 認証でできなくなるので、分割が残っている場合はパスワードでログインできるようにする、キャリアメール以外のメールアドレスを登録するなど気をつけたい。
元増田は LinksMate を勧めている。これはこれで悪くない選択肢だが、 LinksMate は転出の際に「SIM カード削除事務手数料」と言って3,000円+税をとってくるから注意が必要だ。
自分は OCN モバイル ONE にした。端末が激安なのと、新プランになってからは比較的速度が出る、MNP による回線切り替えのタイミングが任意というメリットがある。
ただし au の端末をそのまま OCN や LinksMate で使いたい場合、docomo が使っている電波の周波数帯に端末が対応していない場合がある。iPhone ならまだしも Android はだいたいひっかかる。まあ ahamo も同様だと考えられるので、いっそのこと端末も SIM フリーにしちゃうのをおすすめしたい。これこそ「選べる自由」。時間はあるので落ち着いて検討しよう。
プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
とてつもなく複雑で冗長な処理によって実行されている。
わかりやすいので画像処理でいうと、数十万から数百万の画素（RGBAの24bitで表される数値）を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。
「まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。
だからそれをどう書くんだよ。という答えはコレ。有名なjpegの実装だ。
libjpeg というライブラリを書くことはできるだろうか？画像の圧縮の理論から考え始めることはできるか？
正直無理だ。自分はプログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。
例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業が必要になる。
「とてつもなくて想像もできないので流石に無理だろう？」
いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。
「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。
「どういう風になっているのか」
外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要だからだ。
この2つは分けて考えなければならない。
ちなみに、たとえばChromeのコアであるChromiumはのコードはコレだ。
つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。
「これで判定と繰り返しという基礎ができます」というのが基本的な理論（定理的なもの）で、その他に必然的だが唯一無二ではないベストプラクティスというものがある（法則的なもの）。
後者をうまく説明する入門書に出会っていないんだろうな。という印象。イライラはやめよう。つかれる。
ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要なアイデアだ。
libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。
ブラウザではjpeg画像の圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegのコードを利用することで真の意味で0から実装しないようにしている。
この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり「仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。
完成しているプログラムは二例ほど挙げたがどうですかね？
複雑なことをする、特に低レイヤーのコードはとてつもなく難しい。
でも、とりあえずこんな感じのコードなら解るよね？
こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。
ハードルは高いんですよ。実際。
なので、木材からだと難しいからプレハブのキット的なものを探すとか、ログハウスのカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。
それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。
「テキシコー」https://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事なものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。
unityはコードが公開されているので、本当に読みたいなら。。
オブジェクト指向は一旦忘れよう。
オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的な作戦だという理解の方が重要だ。
前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。
そして本当に作るべきものに関しては、利用する下のレイヤーのライブラリなりを探して・仕様を理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。
単に翻訳がしたいのか？表示に割り込む方法を知りたい？日本語に翻訳するのは実行時なのか開発時なのか？
要求される表示エリアが言語によって異なるために、デザイン調整が必要になる問題をどうするか？
分解が甘いので何をしたらいいか調べることができないんだと思う。
ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。
AndroidなりiOSの仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。
アプリの開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的な問題はあるのよね。
この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。
ついでに。ウェブサイトやウェブサービスの翻訳だとこういうサービスがあったりする。
ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。
個人的に気に入らない話はOSのアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。
まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。
現在のクライアントOSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。
そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。
これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。
オブジェクト指向好きですな...。ここではオブジェクト指向は特に気にしなくていいですよ。
とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。
それよりバグは未来を先取りするコストと考えて、本質的に価値のある機能を増やしていくというのが基本的な方向になっている。
だからパソコンはたまに不具合を引き起こすんです。しゃーない。
しかし中途半端に理解している老人などは、そんなことじゃ分からん。自分に分かるように説明しろと言い出す。
説明は出来る。しかし相手はイライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。
ここでどうすればいいのだと理解不能に陥る。
まあ、説明って得てして難しいよ。しゃーない。
そのとおりです。
オープンソースのプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。
それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。
「把握・理解可能な範囲」に留めていたら、数十年前のコンピュータの世界から抜け出せなかった。
deep learningの世界ではそれがより一層進むかも。この辺は詳しくないけど。
ここでの「理解」についてはそのとおり。これはもう諦めるしかない。
これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。
なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる
面倒くさがらない人が向いている。
「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。
同時にくじけないとか諦めない、しつこいみたいな素養は必要かも。
応用まではとろうな。がんばれ。
このへん自分も知らんですよ。べつに全部知っている必要はない。
（追記: はてな記法の引用すらもさっきまで知らなかったしな！そんなもん）
層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。
でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。
そして、メンテのコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。
あるいは「（多少の問題はあっても）動いているものは変えるな」という経験則から意図的に残す場合もある。
西暦2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。
それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。
勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。
「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。
「オブジェクト指向のおかげ様」じゃないんです。（もちろんオブジェクト指向というのも大きな発明の一つですが）
そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。
でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術や思考の蓄積に感動してほしいなと思う。
人類がこんなもん作れたのって、かなりすごいよ？
数学もそうだけど、実は物理学と化学と生物学にも律速されてんのやで。以下順に説明するで。
【物理学】光の速さが30万キロ per sec なのはしっているかい？よって、我々は高速を超えられない。ところで君のパソコンの周波数はいくらかな？3GHz と仮定しようか。するとどうだろう？1サイクルで10cmしか進めない。よって計算量は資源なんだ。もっと知りたければ「ハミングバードプロジェクト」でも読んてくれ。
【化学】主に信越化学工業と SUMCO が頑張っている。ネトウヨがフッ化水素酸についてうるさいのも半導体製造には必須だからだ。化学の進化なしに、計算機科学は存在しない。
【生物学】我々の扱うものは、人が作っている。人とは何か？生物じゃろ？よって、コードされているものには限界がある。つまり、バグとされるものは、人間の認識の限界から来ていると思わないかい？人工知能が偏見を持つのでなく、偏見があるから、人工知能が真似をしてしまうのだ。
と、まあ、こんな感じかな。とりあえず元増田には『数学＝IT』という発想はやめてもらいたいと思った。こんなんで答えになってるかな？
一日の終わりにはできるだけ目を使わないようにしようと思った。
目が覚めてから寝るまで、常に何かを注意して見ている。スマートフォンやタブレットが生活の中に入り込んで来てから、画面を見て何かを読むのをやめられなくなっている。人間は視覚を好むと言っていたのはアリストテレスだったか。大学で哲学の授業に出たのはだいぶ前のことだからうろ覚えだが、現代人は視覚を好みすぎて酷使しているような気もする。
仕事帰りに新宿の西口でラーメンを食べた後、ヨドバシカメラに寄って、小さなラジオを買ってきた。ラジオしか聴けないようにするためにラジオが欲しかった。
ベッドに入って電気を消し、ラジオの電源を入れる。小さな液晶にオレンジ色の光が灯り、周波数を表示する。ダイヤルを回すと、ザーッという音が聞こえる。
そういえば、番組と番組のあいだ、周波数と周波数のあいだには、意味をなさない、あるいは意味を読み取れない雑音の海があった。アプリで文字や画像をタップするといつも目的のコンテンツに一瞬でたどり着くことに最近はすっかり慣れていたから、そんなことも忘れていた。
ダイヤルを回し続けると、雑音は不意に音楽に変わる。この、無秩序から秩序への移行を一瞬に知覚する時の感じも、ずっと忘れていたことが信じられない。
ボサノバの旋律が、やけに遠くから聞こえてくる。チェーン店のカフェでお昼を食べるときに天井から降ってくる、ありきたりで空疎な環境音のボサノバ。それが今はどこか遠くから、大切に、丁寧にこの小さな箱まで届けられた音楽のように聞こえる。これはきっと、もともとはそういう音楽だったのだという気さえしてくる。
音量のツマミを回して次第に音を小さくすると、かなり小さな音でも音楽や人の声は識別できることに気づく。スピーカーに耳をつけてようやく聞こえる程度でもそれはさほど変わらないことにも。暗くした部屋でラジオの微かな音に耳をすませていると、落ち着く。
音楽よりも好きなのは、天気予報だ。各地の天気や気温をアナウンサーが静かに読み上げていくのを聞いていると、ただ時間が経っていくのを感じられるというか、なんだか豊かな気持ちになる。さらに好きなのは各地の気圧で、ヘクトパスカルがただ読み上げられていくのに暗闇で聴き入っていると、世界はすでに戦争で滅びかけ、自分はシェルターで生き延び、よく知らない政府の発表に立ち会っているかのような、何かに包み込まれた不思議な隔離感がある。
感じられている暗さが室内の暗さなのか、まぶたを閉じているときの暗さなのか、音の途切れは電波のせいなのか、自分の意識が飛び飛びになってきているせいなのか、もうわからなくなってきたら、ツマミを回し、音を完全に消す。
久しぶりに、薬を飲まずに眠ることができた。
