RSS Twitter Facebook


« 2017年06月 | 2017年07月のアーカイブ |

2017/07/20

黒板をひっかく音はシンセ的に合成できるのか?


誰でも経験があると思うのだけど、黒板をひっかく音を聴いた時の背中がぞわぞわする感覚、何なんでしょうね?

一説には、とある種類の猿が危険を知らせる時の叫び声に近く、人間のDNAに刻まれた太古の記憶なんていう話もあるみたいですが、実際の所どういうメカニズムで起こっているのかは良くわかっていないようです。

2.5kHz-4.0kHz付近で起こるという分析もあるようですが、その辺の周波数の音はどこにでもありふれたものですし、単なる周波数成分的な要因ではないという事なんでしょうね。ただ、2.5kHz-4.0kHzというと人間の外耳道で共振によるピークが起きやすい周波数ではあり、ざっくり外耳道をl = 25mm~30mmとすると λ/4 共振の周波数は 340/(l*4) = 3.4kHz-2.8kHz くらいにピークが発生しますので思った以上に大きく聴こえる音ではあります。

不思議な事にあの音をサンプリングして持続音として再生してもいまいちあのぞわぞわ感が出ないんですよね。というか、録音して再生しているという状況を認識している時点であのぞわぞわ効果はかなり薄れている気がします。どういう事でしょうか? 音響的なレベルよりももう少し上のレイヤーで避けなくてはならない何かだと脳が認識しているという事でしょうか。

どうもランダムな感じで断続するというのが要因の1つではないかという気がします。それが猿の叫び声っぽいのかどうかは良くわかりませんが。という事で、敢えてあれっぽい音をアルゴリズミックに合成しようとしたのが下のリンクです。個人差もあると思いますが「ちょっとぞわっとする感じがするかな」という程度の出来で、まだ何かが足りないような気もします。

感じ方は個人差もあると思いますので苦手な人は気を付けてください。

黒板をひっかく音っぽい奴


posted by g200kg : 2:30 PM : PermaLink

2017/07/17

WebAudio APIでの過大振幅信号処理の闇


とある WebAudio を使ったアプリで思うような音が出ない現象があり、少し調べた所信号がレベルオーバーした時の挙動がブラウザによって違うのが原因のようです。

WebAudio API では通常、音声信号を -1.0 ~ +1.0 の範囲の値で扱います。これは単なる数値データですのでオーディオグラフの処理の途中段階ではどのような値になっても良いのですが、最終的に AudioContext の destination に接続する際には -1.0~+1.0 が 0dBFS つまりフルスイングの信号となります。

問題はこの範囲外のデータを生成してしまった時にその値がどう扱われるかなのですが、WebAudio API のスペックでは今の所規定されておらず実装依存になっています。実際にはクリップしてしまったり強制的に振幅を調整するなど、ブラウザや OS によって処理の仕方がバラバラで場合によってはまずい事になる可能性があります。

ざっとまとめたのが次の表です。

OS Browser Description
Windows Chrome 長い時定数でコンプレッションがかかり振幅が強制的に調整される
Firefox 短い時定数でコンプレッションがかかり振幅が強制的に調整される
Edge destinationに接続された時点で信号が -1.0 ~ +1.0 の範囲にクリップされる
Mac(内蔵スピーカー) Chrome そのままMacの音量調整を通して出力可能な範囲で出力される
Firefox そのままMacの音量調整を通して出力可能な範囲で出力される
Safari destinationに接続された時点で信号が -1.0 ~ +1.0 の範囲にクリップされる
Mac(USB-I/F) Chrome destinationに接続された時点で信号が -1.0 ~ +1.0 の範囲にクリップされる
Firefox destinationに接続された時点で信号が -1.0 ~ +1.0 の範囲にクリップされる
Safari destinationに接続された時点で信号が -1.0 ~ +1.0 の範囲にクリップされる

Edge と Safari の処理が素直と言えば素直なのですが、WebAudio API の処理グラフから destination に出力される時点で信号が範囲を超えているとハードクリップされ、歪みが発生します。アプリとしてはこの Edge、Safari で歪みが発生しないようにオーディオグラフ内で適切に信号の振幅を管理するのが本来の姿だと思います。

Mac での Chrome、Firefox の場合は、内蔵スピーカーか USB 接続オーディオI/Fかによって挙動が異なるようです。USB 接続のオーディオI/Fの場合は Safari や Windows の Edge 同様に destination に接続された出力が -1.0~+1.0 の範囲にクリッピングされ、それ以上の振幅の信号は歪みが発生します。しかしどういうわけか内蔵スピーカーを選択している場合はクリッピングされず、信号の振幅が大きくてもそれに合わせて Mac のボリュームを下げていると歪みが発生しません。もちろんこの状態で Mac のボリュームを上げていくと歪みが発生しますが、これはアナログ回路的な出力振幅の限界のようです。

Windows の Chrome および Firefox の場合はまた少し違った挙動があります。出力信号が範囲を超えている場合は自動的にコンプレッションがかかり、ピークがクリップしないように自動的に調整されるようです。Windows でだけ起こる現象のため、OS 側のカーネルミキサー等が関わっているのかも知れませんが、Chrome と Firefox では過大信号がなくなった後の復帰時間、いわゆるコンプレッサーのリリースタイムが明らかに異なるので、どこでこの処理が行われているのかは良くわかりません。

と言う事で、とにかく気を付けないといけないのは、Windows で Chrome / Firefox を使っている場合、また Mac で内蔵スピーカーを使っている場合には、信号の振幅が -1.0 ~ +1.0 を超えていても歪まないので気が付かない可能性があるという事です。いい感じに鳴っていると思ってもブラウザや再生環境が変わるとバリバリに歪んでいるという事が起こるかも知れません。

割とやりがちなのが下の図のように複数のオシレータを並列に繋いでしまった時のピークの最大値をちゃんと考えていない、とかですね。そもそもオシレータの出力は -1.0~+1.0 のフルスイング信号で、並列接続した場合には単純に加算されますので、ワーストケースではピークが重なるとオシレータの数だけ出力ピークが上昇します。

なお、ポリフォニックシンセのような同時発音数が多い音を扱う場合は全てのサウンドソースのピークが重なるようなワーストケースを考えると1音あたりの音量が取れなくなってしまいますのである程度のヘッドルームを作りつつワーストケースではソフトサチュレーションさせたり、ゲーム系の音処理のような場合には明示的に DynamicsCompressor を使ってピークを抑えたりするのが一般的かと思います。

posted by g200kg : 3:51 AM : PermaLink

2017/07/13

RedLine SUSHI


DSP搭載のユーロラックモジュール「RedLine SUSHI」を高円寺の前衛派珈琲処マッチングモヲル様で取り扱い開始しました。

  • Glitch Oscillator
  • Osc+Lpf
  • Vocoder
  • Chrus/Flanger+Delay
の4種類の顔を持つマルチファンクションモジュールです。デモ機もありますので是非どうぞ。

仕様詳細はこちら


posted by g200kg : 3:47 AM : PermaLink

2017/07/05

たかがピンヘッダー...


同じ2.54mmピッチのものなら何を使っても変わらんだろ...と思いきや
入らねえ...

やっちまったなぁ。

ちなみに2.54mmピッチピンヘッダーのコンタクト部分は0.64mm角で規格化されていて同じようなピンヘッダーに見えますが、基板側に出ている足の部分はメーカーによって微妙に違いがあります。

ヒロセのボックスヘッダーは基板側に出ている部分は0.5mm角なので対角0.707mm、基板の推奨穴径はφ0.8。
秋月なんかでよく売ってるヘッダーだと基板側も0.64mm角のままで対角0.905mm、推奨穴径はφ1.02。
JSTなんかは精度に自信があるのか0.64mm角ですが推奨穴径はφ0.9だったりします。

推奨サイズだと余裕を見て結構ゆるゆるなので、差し込んだだけでは固定されずに裏返すと落ちてくるのですが、ギリギリの所を狙うと差し込んだだけで結構かっちりはまって作業性がとても良いので狙いすぎたというのもあるんですが、こんな事で余計な仕事が増える。

posted by g200kg : 12:22 AM : PermaLink


« 2017年06月 | 2017年07月のアーカイブ |

g200kg