サウンドプログラミング４

1 名前：デフォルトの名無しさん [2007/07/25(水) 14:07:56 ] 音のプログラミング処理について語りましょう 各エフェクタの組み合わせとか、 プログラミング外の話題はDTM板の方がいいよ サウンドプログラミング3 pc11.2ch.net/test/read.cgi/tech/1145573675/ サウンドプログラミング2 pc8.2ch.net/test/read.cgi/tech/1091054082/ サウンドプログラミング pc5.2ch.net/tech/kako/996/996171508.html 159 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:12:58 ] >>158 んなことねーよ 作業中の演算精度が高くて少なくとも時間以外の損は無い 160 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:14:44 ] まあ、0から255までの結果しかいらないやつで わざわざintを使わず演算するやつもいないしな 161 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:15:24 ] 結論 ・それぞれ好きにやれ 162 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:54:50 ] >>159 メモリサイズも当然違ってくるだろ。 あと、パソコン以外の環境にも移動させ易いのは大きなメリットだよ 163 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:57:37 ] 逆に言えば、PC環境では全く問題ないってことだろそれ 164 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 17:59:30 ] もう、>>161が結論でいいよもう 165 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 18:34:04 ] 確かに FADD命令　レイテンシ3、スループット1/サイクル FMUL命令　レイテンシ5、スループット1/2サイクル1,2 FDIV命令　レイテンシ-単精度17サイクル、倍精度36サイクル、拡張精度56サイクル 割算以外では単精度にしても早くならないね。 166 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 08:01:46 ] >153 お前の使ってるコンパイラが世の全てだと思ってるなら大間違い。 >157,>161でFAだな。 167 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 08:32:08 ] >>165 今がそうだとしても、過去そうでなかったし、 将来　単精度ならレイテンシが短くなるかもしれないし、 使ってるコンパイラが将来SSE命令をサポートするかもしれない。 何でも倍精度は楽かもしれないが、不必要に使うのはどうかと思う。 IIRならともかく、16bit入力16bit出力のFIRで倍精度にするメリットはまったくないのだから 168 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 10:08:36 ] >>167 将来doubleならレイテンシが短くなるかもしれない可能性もあるし、 将来も入出力が整数型16bitであり続ける保証も無いんだが？ 今現在だって入出力形式でfloatはありうる。 未来の仮定の話をしたいのか、現状の話をしたいのかターゲットくらい絞れ。 169 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 10:48:55 ] 単精度だ倍精度だと騒げるのが羨ましいよ。ホント贅沢な悩みだと思うよ MP3あたりだと16ビット、高級なもので24bit　DSPの世界はまだそんなもの 170 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 11:05:00 ] FA >>161 171 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:40:54 ] なんかよう分からんけど、これ関係してる？ ttp://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.4.4.html 172 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:59:25 ] >>171 ＞ほとんどのＣでは、float型よりdouble型で計算した方が数倍高速になります といいながら　基準にしてるのは SPARCだけ SPARCは倍精度どころか128bit幅の浮動小数点演算器を持っているわけで それを基準にするというのもどうかと思うよ。 ゲーム機や組込用のCPUのコンパイラの殆どは当然のように単精度が早い。 173 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 19:56:17 ] >ゲーム機や組込用のCPUのコンパイラの殆どは当然のように単精度が早い。 そもそも浮動小数点演算装置がなかったり(全部ソフト）倍精度はソフトとかそんなのばっかりだからね 倍精度がハードウェア実装されている今時のCPUだとメモリアクセスが律速になることはあるかもしれないけど double,floatどちらもそれほど速度に違いはでないよ。（int,double,floatの間を行ったり来たりするような型変換する方が単純な演算より遅いし） 結論としちゃ、自分が使いたいターゲットで使い易い型を使うってことでいいんじゃないの？ 174 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:54:08 ] それでも IIRフィルタの遅延器は単精度では厳しいからなあ 計算方法を工夫すればある程度カバー出来るけど 175 名前：（ ´∀｀） mailto:sage [2007/09/06(木) 21:05:28 ] ( ´∀｀)ノ 先生！ IIRフィルタの遅延器って、なんで高い精度必要なんですか？ 精度低いとどうなるのですか？ 176 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 21:08:27 ] 無限インパルス応答だから 177 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 23:58:36 ] フィードバック＝計算誤差が累積 でもま普通は（要求がシビアでなけりゃ）単精度でも十分じゃない？ 178 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 00:09:54 ] なんでもいいよ 場合によっては固定小数点数でも可 179 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:26:55 ] >>175 たとえばf0の低い　1次のLPF　 y := y*(1-r) +x*r; 　とやると、rが小さいので(1-r)の精度が悪くなる y := y +(x-y)*r;　とやればソレは解決する。 1次の場合は、yが単精度でも単に誤差が累積するだけだけど 2次になると、yが単精度だとf0が低かったりＱが高いとノイズが出てくる。 　それも　ピーとかいう類のノイズ 180 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 16:35:54 ] >171 この人こんな記事書いてたのか、ターゲット絞れないバカの典型だな。 用途や環境にあわせられない奴は最適化語るなよ・・・ 181 名前：最早厭われてはいるが mailto:sage [2007/09/07(金) 22:19:07 ] >>180 あの本を書いた時点で既に、自称翁だ。バカだなんてとんでもない。年寄りは労われ。 182 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 03:05:32 ] 多少配慮足らずでも、誰かの参考にはなる記事をネット上で公開してるんだし それをバカの典型と言い切れるやつよりは敬われる権利あるよ。 183 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 06:29:03 ] 90年台に「floatよりdoubleの方が速い」とか嘘かかれても、参考にならないと思いまーすｗ ましてや「敬われる」とかありえませーんｗｗｗ 184 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 06:41:17 ] floatよりdoubleの方が速いって言うのは、昔のプロセッサはfloatを内部で動的にdoubleに変換してたからだろ。 今はそういうのが無いからどう考えてもfloatの方が速いし、データが短い分キャッシュにも残りやすいから最適化も効き易い。 185 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:25:16 ] どうでもいい。結局処理系による。 つか180の食いつきかた見ry 186 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:33:02 ] うちのMacBook Pro (CoreDuo 2.0GHz) で試してみたけど、 floatよりdoubleのほうが速いぉ。 187 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:34:34 ] Mac（笑） 188 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:41:17 ] >>184 専用機はしらないけど、96年当時主流だったインテルもモトローラも内部80bitだよ。 内部で動的にdoubleに変換してる石って何？ 189 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:42:30 ] >>179 2次でノイズが出るのは　リミットサイクルって現象だろ？ なんかリミットサイクルの出ないフィルタとか論文があるけど、理解出来ないんだよな 190 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 08:09:02 ] >>188 内部80bitの場合も、floatよりdoubleの方がしばしば速い。 で、翁が想定しているのはSparcとx86だろ。 191 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:37:39 ] 処理速度が問題になるほどのタップ数の多い FIRフィルタならキャッシュに収まるかどうかの方が 速度を決めてしまうと思うけどな　命令サイクルがギガに対してメモリは1桁下なんだから 192 名前：（ ´∀｀） mailto:sage [2007/09/08(土) 13:21:01 ] ( ´∀｀)ノ >>175-179 先生、有難うございました。 無限インパルス応答だからの回答に超感動しました。 精度が低いと、無限の過去の影響を細かく現代に反映できない。反映できないものは誤差として累積され、 現代を惑わす魍魎を生み出すことになる。怖いですね。 193 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 14:48:57 ] double が速いのはC言語の math.h が double に対してしか定義されていなかったり、 自動昇格が多数発生するためでしょ x87 の FPU は内部で 80bit に昇格するのがデフォだけど、それにしたって内部精度は命令を 発行して設定できるわけで、慎重に書かれたソースなら当時から float の方が速かったよ 194 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:11:02 ] 今ならc99のお蔭でhypotf()なんかが使えるからねぇ。 195 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:30:39 ] 今がどうだとか昔はどうだとかこのCPUではとかいつまでやってんだ？馬鹿馬鹿しい 196 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 17:58:56 ] >>161 197 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:14:47 ] >>195 じゃネタだしてよ。　>>189の話を膨らませるとかさ 198 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:21:01 ] >>197 じゃあ>>189の話を膨らませろ馬鹿 199 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 20:23:28 ] ようし、じゃグーグルさん使ってふくらませるぞ。 リミットサイクル＋フィルタ　でポチっとな www38.tok2.com/home/shigaarch/OldBBS/15nextformat.html ＞ ＩＩＲなんかでフィルタ等の信号処理をすると３８４ｋＦｓだと係数 語調は３２ビットでは ＞低域でリミットサイクルによる発振現象の影響が出てきますので不足で４８ビットもしくは６４ビット必要になりますな。 なるほどな。　 お！これだ www.mk.ecei.tohoku.ac.jp/~yamaki/Publications/Sougou2007.pdf ＞リミットサイクルのない 感度最小形ディジタルフィルタの合成 えと？　状態空間ディジタルフィルタ？　って何？　もいちどグーグルさんお願い。ポチっとな カルマンフィルタ？　いや応用カルマンフィルタ って本は持ってるんだが・・・・こりゃ退散だ 200 名前：（ ´∀｀） mailto:sage [2007/09/12(水) 21:38:18 ] ( ´∀｀)ノ 、先生 WindowsメッセージMM_WIM_DATA（録音バッファの録音完了）を受けての処理手順について何ですけど 下記の1,2のどちらが正しいですか？　 1.waveInUnprepareHeader,waveInPrepareHeaderを用いる // 録音バッファの登録解除 waveInUnprepareHeader 録音データ、lpDataを処理する // 録音バッファの再登録 waveInPrepareHeader waveInAddBuffer 2.waveInUnprepareHeader,waveInPrepareHeaderを用いない 録音データ、lpDataを処理する // 録音バッファの再登録 waveInAddBuffer 201 名前：デフォルトの名無しさん mailto:sage [2007/09/13(木) 07:32:05 ] >>200 さあ？　どっちが正しいかはしらないけど　２でやってて不具合にあたった事はないな 202 名前：（ ´∀｀） mailto:sage [2007/09/16(日) 12:46:06 ] ( ´∀｀)ノ >>201、先生、ども、ども、有難うございました。そっそうなんですか... なんか、waveInもwaveOut処理同様に>>200の1.のようにするのが正しいのかなと思たですけど 203 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:16:46 ] up2.viploader.net/upphp/src/vlphp069198.jpg 204 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:42:54 ] >>203 毎年見れば無問題 205 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:50:12 ] それなんて3年峠？ 206 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:35:02 ] どうして周波数が低いと大きな音を出すのに、高周波と比べて指数的に高いエネルギーが必要なの？ 蝸牛が低音を捕らえようとするとどうしても指数的に音量が小さくなってしまうからなの？ だったら低音は凄く耳に悪いね。難聴の原因だ。 207 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:58:19 ] 動かす媒質の量 208 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 16:34:37 ] 同じエネルギーを出すのに低いほどストロークが必要という事じゃないて 同じエネルギーを与えても、小さく感じるという事ならその通り www.yacmo.co.jp/document/mame/images/mame07_2.gif 209 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:58:06 ] １００人飛べる大縄跳びで二重飛びしようとするとものすごく大変なのと一緒・・・ではないな 210 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 01:52:12 ] >>207 マジレスありがとう。 1Hzで動く量と100Hzで動く量が違うのは当たり前ですね。 211 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 06:37:18 ] >206 真面目に低音は耳に悪いので注意。 スピーカー飛ばす原因も低音の出力が高すぎるってのが多いし。 212 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 07:12:34 ] スピーカーが飛ぶのは２つの現象 電力は 電流*電圧だけど、ボイスコイルは、コイルと名前が付くようにL成分を持ってるから 同じ電圧振幅でも電流は低周波程流れてしまう。　発熱は電流の２乗に比例するので、低音程　焼損し易い また、コントロールして同じV*Aを与えたとしても、ボイスコイルには質量があるから 同じV*Aを与えても振幅は低周波程大きくなる。　結果、大振幅で可動域を外れ物理的に変形してしまう。 213 名前：デフォルトの名無しさん [2007/10/05(金) 21:15:13 ] waveOutOpenの引数にコールバックを指定した場合、waveOutProcはスレッドセーフっぽくないんですが。 なんか現在のスレッドの処理に割り込んで呼び出されませんか？ WM_DONEで再びWaveOutWriteしようとするとかなりの割合でスタックが破壊されています。 214 名前：デフォルトの名無しさん mailto:sage [2007/10/06(土) 10:20:53 ] 手順が間違ってる 215 名前：デフォルトの名無しさん [2007/10/06(土) 13:40:55 ] >>213 そういうもんだよ。 waveOutProcはスレッドセーフじゃないと、しっかり覚えておくといいんじゃない。 216 名前：デフォルトの名無しさん [2007/10/07(日) 01:54:40 ] どこにもスレッドに関わることが書かれてなかったような気がするんですが、スレッドセーフではないんですね サウンド関連の生APIはむずかしいです 217 名前：デフォルトの名無しさん mailto:sage [2007/10/07(日) 05:24:12 ] でもそんなの関係ねぇ 218 名前：デフォルトの名無しさん [2007/10/07(日) 14:00:21 ] >>216 サウンド関連の生APIはむずかしいです じゃなく APIでプログラム作るのはとてもむずかしいです が正しい。 219 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 20:27:23 ] 極めてどうでもいい揚げ足取りだな 220 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:02:30 ] >>212 ブラウン管モニタを壊すにはデバイスドライバレベルでの制御が必要だけど ひょっとすると、スピーカーはユーザープログラムで壊せてしまう可能性がある? 超低周波を出すとか、DCオフセットをかけ続けるとか。 221 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:09:13 ] ドライバレベルで保護してないかな。してなきゃまずいね。 222 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:26:59 ] ユーザープログラムも何も 曲作ってるときうっかり変な音を鳴らしてスピーカ飛ばすって時々あるもんじゃないの？ 223 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 22:51:08 ] ない 224 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 23:03:21 ] 俺もそんなに詳しいわけじゃないが、もちっとだけアナログの勉強をしてもいいと思うんだ。 スピーカーが飛ぶのは>212にあるようにスピーカーが想定以上の入力を受けた時。 なので出力波形だけでなく、アンプのパワーやボリュームによる所が大きい。 225 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 23:16:44 ] >>220 直流を通すオーディオアンプなんてほとんど存在しないだろ。 アンプにデジタルで直結したとしても、 普通はスピーカ出力の直前にコンデンサが入ってたりしてHPF特性がかかるから、 スピーカに超低周波や直流がかかることはない。 226 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 23:22:58 ] ああ、でも、直流そのものは通さないとしても、 ステップ関数とかガンと入れられたら階段部分はスピーカ的に結構きついかもな。 227 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 20:02:28 ] ステップ関数は階段部分ではなく、その後のフラットな部分がキツイわけで 228 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 20:33:14 ] フラットな部分はHPFで除去されるんじゃね？ 229 名前：デフォルトの名無しさん [2007/10/09(火) 22:05:52 ] インパルス連続攻撃で敵を倒せないですか？ 230 名前：デフォルトの名無しさん mailto:age [2007/10/09(火) 22:10:36 ] premiumtv.12gbfree.com/?RTV+4440 231 名前：デフォルトの名無しさん mailto:age [2007/10/09(火) 22:11:43 ] proforceone.web.fc2.com/ ⇒ Processed input data Chick+Corea[777] Herbie+Hancock[999] proforceone.web.fc2.com/ ⇒ Calculation processing d=$.split("\n");for(j=0;d.length>j;j++){s=d[j].substring(0,l=d[j].indexOf("[")); s=encodeURIComponent(s).split("%2B").join("+"); n=d[j].substring(l+1,d[j].indexOf("]")).split("."); n=eval(n[0].split(",").join(""));n=(n-n%20)/20+(n%20>0);br(); for(i=0;n>i;i++){write("http"+"://youtube.com/results?search_query="); write(s+"&search_sort=video_date_uploaded&page="+(i+1));br();}}br(); 232 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 22:12:53 ] >>227-228 カットオフ周波数10Hzの1次HPFの場合、 ステップ関数のフラット部分は時定数0.016秒であっという間に指数減衰するね 233 名前：デフォルトの名無しさん mailto:age [2007/10/09(火) 22:13:06 ] デジタルピークメーターテスト用　−１２ｄｂ標準音量サンプル www.barks.jp/watch/?id=1000006257&wpl=wm&wbw=1m www.barks.jp/watch/?id=1000006257&wpl=wm&wbw=300k www.barks.jp/listen/?id=1000006259&lpl=wm&lbw=56k フリーソフトの音量確認用　ステレオ・デジタル・メーターを使おう 赤い●をクリックする　次にスピーカーマークをクリックする　 標準のは−１２ｄｂぐらいで、−６ｄｂを超えない様に音量調節する。 www.forest.impress.co.jp/lib/pic/music/soundedit/soundengine.html 234 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 23:52:44 ] ageんなカス 235 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 09:04:46 ] あのー、非常に初歩的なことなんですが、 このページでバッファは441000bytesといいつつ441000*2bytes 確保しているのはなぜなんでしょう？ homepage3.nifty.com/rio_i/lab/oss/002sound.htm ただのミスだと思い、ループのところを for ( i = 0; i < BUFSIZE/2; i ++ ) { t = ( total / (BUFSIZE/2) ) * i; と変えてみると、出力周波数が880Hzになってしまいますし。 236 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 10:57:38 ] ただのミスだと思うよ。　でもあなたの修正が間違っている 237 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 11:29:54 ] >>235 量子化ビット数が16だから3528000[bits]なら441000[bytes]だけれど、こう計算した方がわかりやすい。 44100[Hz] * 5[sec] = 220500[samples] だから、#define BUFSIZE 220500 とすればいい。 238 名前：デフォルトの名無しさん [2007/11/01(木) 04:02:20 ] リアルタイムのスペアナ表示を作りたい。 FFTしてlog(re*re+im*im)的なことをして振幅を対数軸にするのはok。 問題は、周波数軸を対数にしたいのだが、どうするべき? 低い方は補完なので適当にごまかすとして、高い方は間引いてしまうと情報が失われるのが いやなので避けたい。 好みとしては、ピンクノイズ(-3dB/oct)を入力したときに表示がフラットになりたい のだが(きっと聴感に近いので) 絶対値の和? 平均? 239 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 04:42:24 ] 普通、Octave band pass filter bank をかけるかな。 240 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 06:44:19 ] >238 ロスしないってんなら最大使うとか。 241 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 07:50:06 ] >>238 前半、俺は、 たとえば５点あったら、その最大と最小と5個平均の３つを求めて 最大から最小への薄い垂直線を引いておいて その上から平均を結んた線を引いてる。 こうやるとホワイトノイズでフラットになる。 ピンクノイズでフラットにするのは気持ち悪いように思うけど、 実現したいなら-3dB/Octの補正をかければいいのでは？ 242 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 09:49:01 ] >>238 用途によると思うよ。 ピーク検出したいなら、ピクセルに対応するバンド内で最大値かな。 逆に荒く(1/6octとか1/3とか)で全体的な特性を見たいなら、両対数にしてからバンド内で 平均とか。ただその場合、各バンド内でデータのある周波数点に偏りが出る(バンド内で高域に 集まる)んで、平均した場合は必ずしもバンド中央の周波数での値にならないことに注意。 >>241 Windows Media Playerのバー表示がそんな仕様じゃなかったけか 243 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 13:47:13 ] >Octave band pass filter bank なるほど、FFT以外のやりかたもあるのね。検討してみます。 ピンクノイズは各オクターブ(とかの対数で等間隔の帯域)のエネルギーの密度が等しいと 何かで読んだので、正しく計算すれば自ずとフラットになるのではないかと思ったのです。 でもどう計算するとそうなるのかわからない。 logとる前の絶対値かその2乗を足すか平均するかしたあと√とる? 244 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 14:07:08 ] > ピンクノイズは各オクターブ(とかの対数で等間隔の帯域)のエネルギーの密度が等しいと > 何かで読んだので、正しく計算すれば自ずとフラットになるのではないかと思ったのです。 その考えで問題ないと思います。 こっちで実験したところ、ホワイトノイズのFFT値を1/3octで絶対値合計→フラット > logとる前の絶対値かその2乗を足すか平均するかしたあと√とる? バンド毎に log(sum(sqrt(re*re+im*im))) で大丈夫なはず。 DCTなら log(sum(abs(re))) 245 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 21:02:04 ] >こっちで実験したところ、ホワイトノイズのFFT値を1/3octで絶対値合計→フラット ピンクノイズの、だよね。 ありがとう〜 246 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 21:46:59 ] >>245 > ピンクノイズの、だよね。 いや、ホワイトノイズ 247 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 21:52:15 ] 説明不足だったかも。すまん フラットの意味によるんだけど、両対数軸上で直線って 意味なら>>245でホワイトでもピンクでもフラット。 直線かつ水平って意味なら>>245ではホワイトのみフラット。 248 名前：デフォルトの名無しさん mailto:sage [2007/11/01(木) 23:22:35 ] 直線かつ水平のつもりでした。>フラット あいまいな言葉を使ってごめんね。 > 直線かつ水平って意味なら>>245ではホワイトのみフラット。 高域にいくにしたがって加算する数が増えるからホワイトノイズは右上がりに なりませんか? 249 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 01:10:35 ] ↑からさらに自分で考えてみた。 >>244 log(sum(sqrt(re*re+im*im))) の方式で仮に1バンド=1octで出力することを考える。 1個上のバンドに行くに従って加算するデータ数が2倍になっていくわけだから、 結果は+6dB/octの右上がりになるはず。 問題は、ホワイトノイズを入れると+3dB/octの右上がりになってほしい。 sqrtとsumの順番を入れ替えると(sqrtを消して20→10でも等価)、 数が2倍になると3dB上がるので+3dB/octになる。 つまり、20*log10(sqrt(sum(re*re+im*im))) 最初に書いた、絶対値の2乗で足して平方根をとる、でいいみたい。 ピンクノイズの各バンドの平均値は1バンド上がると-3dBずつ下がっていくはず つまり1/√2に減っていくはずで、これの2乗の次元(1/2ずつ減ってく)で 数が2倍になっていくものを合計していくと皆同じになるという理屈。 ちなみに、素直に(?)、ホワイトで水平、ピンクで右下がりにするには、 sumのところを平均にすればいいはず。 (1バンド上がるごとに2倍になる個数で割ったやつをsqrtするので、1バンド上がると 1/√2つまり-3dBさがっていく) root mean squareってやつですね。 あ〜すっきりした。 250 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 02:46:03 ] >>249 > 1個上のバンドに行くに従って加算するデータ数が2倍になっていくわけだから、 > 結果は+6dB/octの右上がりになるはず。 データ数が増えてもデータ値は高域に従って指数的に減っていくので、 よほど高域強調されてない限り合計しても右上がりにはなりません。 251 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 09:22:34 ] >>249 > sqrtとsumの順番を入れ替えると 平方根の合計と合計の平方根は別のものなので入れ替えられません。 平方根の合計 sqrt(1)+sqrt(2) = 1 + 2 = 3 合計の平方根 sqrt(1 + 2) = sqrt(3) = 1.732... 素直に 20log10(sum(sqrt(re*re+im*im))) で各バンド計算して +3dB/oct補正掛けた方が実装の見通しも良くなるような。 252 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 09:47:43 ] まちがえた、20log10(ave(sqrt(re*re+im*im)))です。 あとsqrt(re*re+im*im)の部分は複素数の絶対値計算なので、 RMS以前のデータ準備の段階。|z|^2=re*re+im*im RMSやりたいなら、|z|=sqrt(re*re+im*im)の各値の二乗平均平方根、 つまりsqrt(ave(|z|^2)) = sqrt(ave(re*re+im*im))にしないと変なことになる。 253 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 21:32:20 ] > データ数が増えてもデータ値は高域に従って指数的に減っていくので、 > よほど高域強調されてない限り合計しても右上がりにはなりません。 なんか根本的な勘違い? >自分 ホワイトノイズはデータ値が(確率的には)全部等しいと思ってたのですが? > 平方根の合計と合計の平方根は別のものなので入れ替えられません。 もちろんそうです。計算方法を変えるという意味です。 > あとsqrt(re*re+im*im)の部分は複素数の絶対値計算なので、 > RMS以前のデータ準備の段階。|z|^2=re*re+im*im > RMSやりたいなら、|z|=sqrt(re*re+im*im)の各値の二乗平均平方根、 > つまりsqrt(ave(|z|^2)) = sqrt(ave(re*re+im*im))にしないと変なことになる。 >>249でRMSといってるのは、 20*log10(sqrt(sum(re*re+im*im))) のsumを平均に 変えたもののことで、あなたの式と同じです。 254 名前：デフォルトの名無しさん [2007/11/10(土) 11:42:09 ] CD-TEXT の規格か仕様か、これを読み込むサンプルのあるサイトか分かりませんか。 ぐぐる用語でも分かると助かります。お願いします。 255 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 12:00:14 ] >>254 REDBOOK 256 名前：254 mailto:sage [2007/11/10(土) 22:29:04 ] >>255 有難うございます。お陰で参考になりそうなのを１つ見つけました。 英語版で 1996/12月ソニーが配布したものですが、データ構造についても 書いてあるようです。 余談ながら、ソニーは普及させたかったような雰囲気。 添付のソフト（３本）用に VB4 runtime routine が付いている。 257 名前：すみません素人です [2007/11/20(火) 11:00:15 ] 最近卒研でＤＳＫ使って音声処理する実験始めたんですけど、 高周波や低周波だけカットするＬＰＦやＨＰＦのプログラム（Ｃ言語）を組んだんですが、 逆に高周波とか低周波だけ増幅させるプログラムって書けるんでしょうか。 本やネットではちょっとわからなかったので、式とかサイトとか知ってる人がいたらどうかお願いします。 258 名前：デフォルトの名無しさん mailto:sage [2007/11/20(火) 11:10:17 ] カットしたのを元のに足す引く 259 名前：デフォルトの名無しさん mailto:sage [2007/11/20(火) 12:28:09 ] >>258さんの通り、 高周波だけをカットした結果を元の信号に（遅延・位相を合わせて）足せば低周波だけ増幅出来るわけだけど どうして、普通はカットしか書かないのかというと、 ゲインが１を超えると、固定小数点演算だとオーバーフローするし そもそも出力DACのレンジを越えてしまうと歪ませるしかなくなるからさ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef