サウンドプログラミン ..
[2ch|▼Menu]
371:デフォルトの名無しさん
06/12/25 22:03:51
ゲームに関して何だけどPCにマイクを接続して喋ってるんだけど
EAXを使ったゲームを起動するととたんに俺のヴォイスにエコーが
かかるようになる。どうもそのPCゲームがEAXを使っているとそれに
つられてマイク入力の音声にもエコーみたいな効果が強制的に
かけられてしまうらしい。これって現状仕方がないことなん(´・ω・`)?

372:デフォルトの名無しさん
06/12/26 00:08:53
>>371
板違い。

373:デフォルトの名無しさん
06/12/26 02:36:50
>>372
ゲーム系のサウンドプログラムもこのスレの範疇かと。

374:デフォルトの名無しさん
06/12/26 05:49:50
サウンドプログラム? どこが?
ゲームの設定かOSの設定だろ?

375:デフォルトの名無しさん
06/12/26 07:49:50
>>371
ゲーム作ってるの?

376:デフォルトの名無しさん
06/12/26 10:06:05
>>371
非サラウンド環境でEAXを使ったら、そらエコーがかかっただけみたいになるがな。

377:デフォルトの名無しさん
06/12/26 15:12:35
>>371
クリエイティブのサウンドカードだろ?
仕様だ。

市場を一社独占させるとどうなるかの好例だな。

378: 【吉】
07/01/01 03:43:35
あけおめ♪

379:デフォルトの名無しさん
07/01/01 13:25:07
黙れよ

380:デフォルトの名無しさん
07/01/11 20:06:07
…FFTで… いや、ごめん。 いいや……。(´・ω・`)

381:デフォルトの名無しさん
07/01/15 21:13:43
ぉぃぉぃ…

382:デフォルトの名無しさん
07/01/16 20:41:58
低速フーリエ変換ってないの?

383:デフォルトの名無しさん
07/01/16 23:35:48
DFT?

384:デフォルトの名無しさん
07/01/17 00:14:21
筆算

385:デフォルトの名無しさん
07/01/17 10:20:29
>>382
バタフライ演算をしなけりゃ低速だよ。

386:デフォルトの名無しさん
07/01/17 16:11:17
普通にDFTでええんちゃう?

387:デフォルトの名無しさん
07/01/18 21:42:16
>>6 >>13 >>17
/*
    Risa [りさ]   alias 吉里吉里3 [kirikiri-3]
     stands for "Risa Is a Stagecraft Architecture"
    Copyright (C) 2000-2007 W.Dee <dee@kikyou.info> and contributors

    See details of license at "license.txt"
*/
/*
     Phase Vocoder (フェーズ ボコーダ ; 位相ボコーダ)の実装
 
     参考資料:
 
         URLリンク(www.panix.com)
             Phase Vocoder のチュートリアル。「ミュージシャンにもわかるように」
             書かれており、数学音痴フレンドリー。
 
         URLリンク(www.dspdimension.com)
             無料(オープンソースではない)の Time Stretcher/Pitch Shifterの
             DIRACや、各種アルゴリズムの説明、
             Pitch Shifter の説明的なソースコードなど。
 
         URLリンク(soundlab.cs.princeton.edu)
             real-time phase vocoder analysis/synthesis library + visualization
             ソースあり。
*/

388:デフォルトの名無しさん
07/02/13 23:56:25
WAVで16bitの場合はサンプルごとにshort型にいれてるんだけど、
24bitの場合はどうすんの?
32bitは各サンプルをfloatにぶち込めばOK?


389:デフォルトの名無しさん
07/02/14 00:31:38
longでええやん

390:デフォルトの名無しさん
07/02/15 07:11:45
パソコンで処理をする目的なら、入力が何bitだろうと64bit浮動小数点で処理するのが楽だろう

・・・・整数演算の方が早いというような事を言いたい人なら別だが


391:デフォルトの名無しさん
07/02/15 11:31:37
>>390
16bitはshortに入れているのに?

392:デフォルトの名無しさん
07/02/15 12:19:02
wavファイル(RIFFフォーマット)の話だろ?
WAVE_FORMAT_PCM(=1)は整数の8bit,16bitしか定義されてないんじゃね?

393:デフォルトの名無しさん
07/02/15 13:29:51
しかしBitsPerSampleにはいくらでも入れられる
入れるだけなら自由だ

394:デフォルトの名無しさん
07/02/15 17:36:11
本気で言ってるなら池沼。

395:デフォルトの名無しさん
07/02/16 00:41:30
内部は64bit浮動小数点、外部とのやりとりは24bit整数、あたりが標準的?

396:デフォルトの名無しさん
07/02/16 04:09:13
>>395
全然。
例えばそこらのアプリの音声再生プラグインは、音質よりも軽くしたい場合が多いでしょ。

397:デフォルトの名無しさん
07/02/16 04:11:09
逆に、音声処理で精度が欲しいってんなら、内部80bit浮動小数点が使える環境を利用するだろうしさ。

398:デフォルトの名無しさん
07/02/22 20:54:32
複数のPCMを単一のPCMにミックスしたいんだけどどうすりゃいいのかわからない。

399:デフォルトの名無しさん
07/02/22 22:06:11
>>398
加算した後でレベル調整でもすればいいんじゃね?

400:デフォルトの名無しさん
07/02/22 23:50:53
レベル調整は先にやったほうが良くない?

401:デフォルトの名無しさん
07/02/23 07:55:27
PCMは8bitか16bitだから 32bit型に一度入れてから割り算すればいい

たとえばA,B,Cを 30%:20%:20% でMIXする場合
int vrA=30;
int vrB=20;
int vrC=20;
int total=vrA+vrB+vrC;

int w= A*vrA+B*vrB+C*vrC;
return w / total;
}




402:デフォルトの名無しさん
07/02/25 13:09:25
>>399-401
みんなありがとう。
やっぱ足して割ればいいのか。

403:デフォルトの名無しさん
07/03/15 11:42:48
ステレオWavデータのPAN設定のやり方教えてくださ
ぐぐったけど、どうも該当するものが発見できなかったんで

404:デフォルトの名無しさん
07/03/15 20:48:50
左右に振るだけじゃないの?

405:デフォルトの名無しさん
07/03/15 21:06:13
たぶんパンを振るとき左右それぞれにどういう演算するかって話だろ
その辺のシンセとかだと、右チャンネルの場合 L 0% - C 50% - R 100% って変化してたと思う
この場合だとセンターの時音量下がって聞こえるけどね。
DirectXだとセンターが両方とも100%で、右に寄せるときは左を下げてくんじゃなかったかな。
この場合センターの時音が大きく聞こえる

406:デフォルトの名無しさん
07/03/15 21:22:13
>>405
> その辺のシンセとかだと、右チャンネルの場合 L 0% - C 50% - R 100% って変化してたと思う
> この場合だとセンターの時音量下がって聞こえるけどね。

つか、左寄せの場合もセンターの場合も右寄せの場合も同じ音量

> DirectXだとセンターが両方とも100%で、右に寄せるときは左を下げてくんじゃなかったかな。
> この場合センターの時音が大きく聞こえる

この場合は正解。センターの時は、左寄せ, 右寄せの時の倍 (+6dB) になる

407:デフォルトの名無しさん
07/03/15 21:29:00
>>405
・音のエネルギーは振幅の2乗に比例する
・聴覚は対数特性
この辺がヒントになるかも。

408:デフォルトの名無しさん
07/03/15 22:24:48
ハードウェア・ミキサーだとセンターは3dB落ちがデフォ。
PAN振りっきりならスピーカーは1本しか鳴らないけど
センター時は2本同音量で鳴るから音量は3dBアップ。
これを補正するための3dBダウン。
これでL-C-RとPAN移動させても横一直線で移動する。

6dBダウンは再生/演奏時にモノ・ミックスされるケースを想定してのもの。
(回路内のミックスは電圧なので6dBアップ)
ハードウェア・シンセはモノ・アウトも装備する関係でそうしてあると。

409:デフォルトの名無しさん
07/03/15 22:36:58
>>406
ん?センターは-3dbでしょ?
20*log(sqrt(0.5^2 + 0.5^2)) = -3.010299956639811
でいいんだよね?
だからDirectXの場合だと+3dbだったと前勉強したときは思ったんだけど・・・
間違ってる?

410:デフォルトの名無しさん
07/03/16 02:09:49
正解は >>407-408

411:デフォルトの名無しさん
07/03/19 12:27:37
誰かDAW作ってくれ

412:デフォルトの名無しさん
07/03/20 10:48:51
>>411
frieve

413:デフォルトの名無しさん
07/03/31 10:17:20
エフェクトのコーラスのうねりは時間で変化させるんですか?
それともpitchを変化させるんですか。

414:デフォルトの名無しさん
07/03/31 10:39:30
コーラス:
入力音を二つに分岐させる。
片方にモジュレーション(周波数変調)をかける。
二つを加算して出力。

415:413
07/03/31 10:55:39
コーラスとフランジャーは モジュレーション大きさだけの違いだけなんですか?


416:デフォルトの名無しさん
07/03/31 11:45:55
・モジュレーション幅
・モジュレーション速度
・フィードバック量
・分岐させた二つの加算割合
などを変化させることによってコーラス/ビブラート/フランジャーなどが作れる。

417:デフォルトの名無しさん
07/03/31 11:50:26
>>416
それの大きさで呼び名が変わるってこと?
なんどもすんません。

418:デフォルトの名無しさん
07/03/31 12:30:34
そういうこと。
モジュレーション幅が広めで速度が速いとコーラスっぽくて、
モジュレーション幅が狭めで速度が遅いとフランジャーっぽい。
フランジャーの場合はフィードバック量も関係してくることが多い。


419:413
07/03/31 12:34:58
サンキュです

420:デフォルトの名無しさん
07/03/31 12:36:08
いえいえ。

421:デフォルトの名無しさん
07/04/01 18:59:37
ぉぃぉぃ

一応混じれ酢すると
ふらんじゃー: 数ms以下の短いディレイに変調をかけ、元音とミックスして、
         中〜高音域のコムフィルター効果でメタリックな響きを出す
こーらす   :数十〜ms程度の比較的長いディレイに変調をかけ、元音とミックスして、
         (たぶん超低域のコムフィルター効果で)アンビエントな音のウネリを出す


422:418
07/04/01 22:34:53
>>421
補足サンキュ。418では変調速度と変調幅だけしか言及してなかった。
(変調幅を大きくする≒ディレイ値を大きくしないといけない
 という勝手な理解をしてしまったよ。)
確かにディレイ値のほうが大きな影響があるな。

423:デフォルトの名無しさん
07/04/02 00:32:07
だけど、コーラスのきついやつがフランジャー、って理解でそう間違ってないでしょ?

424:デフォルトの名無しさん
07/04/02 00:33:53
おまぃに関してはおまぃの判断に任せる

425:デフォルトの名無しさん
07/04/02 01:31:19
コーラスのディレイの短いやつがフランジャー、って理解で間違ってない。

426:413
07/04/02 12:28:37
勉強になります。

427:418
07/04/02 16:25:13
理工系の大学とかで学術論文にアクセスできるのであれば、
Jon Dattorro. "Effect Design, Part 2: Delay-Line Modulation and Chorus". Journal of Audio Engineering Society, October 1997.
とか、あとは「DAFx」という書籍もエフェクト関係の勉強になる。

両方とも英語なのがタマニキズ。

428:デフォルトの名無しさん
07/04/02 17:10:08
>>425
登場経緯的には、フランジャーが先だよね? 浅めに(?)かけてみたら 12 弦っぽい
効果があって、それ目的でパラメーター調整しやすいようにアレンジして製品化した、と。

429:413
07/04/04 09:16:25
>>427
DAFxはいろいろ載ってておもしろそうですね。
Jon Dattorro  Effect Designは見れなかった。残念
ただ、英語はダメなので気長にみてみます。

430:デフォルトの名無しさん
07/04/04 09:21:13
基本的にはパラメーターのレンジを変えた、同じエフェクトと思っていいと思うけど、
実際には目的の違いから異なるアイデアを盛り込んでる場合が多いと思うよ。
たとえばコーラスはぶ厚く広げるのが目的だからディレイラインがすごく多いものとか、
変調が周期波形じゃないものとか、イロイロと。
そのへんがエフェクターの個性になってくわけだが。

431:デフォルトの名無しさん
07/04/06 04:03:47
今までDSP買ってエフェクターやら作ってたんだけど、ふと思った。
いい加減今のPCならリアルタイム入出力のFIR処理くらい出来るんじゃないかと。
これが出来ればあらかじめフィルタ係数用意して切り替えるようにすれば
ソフトウェアエフェクターってできそうだし。
で、作って見たがあえなく撃沈。音途切れ途切れ。

何が問題なんでしょう??
100万タップくらいのFIRなら余裕で動くと思ってたのに。

432:デフォルトの名無しさん
07/04/06 07:58:42
あまり詳しくないのであれなんだが
とりあえずSSEは使った?(PowerPCならAltivec
大きいFIRはFFT利用して劇的に計算コスト減らした実装ができるんじゃなかったけか?

433:デフォルトの名無しさん
07/04/06 08:02:06
ちなみにリアルタイム入出力のコンボリューションリバーブとか普通にありますよ。

434:デフォルトの名無しさん
07/04/06 09:20:49
たいてい432の言うようにFFTかましてるよね。だからレイテンシーが問題になることも。

435:デフォルトの名無しさん
07/04/06 12:33:04
>>431
ハードウェアのことあんまり詳しくないんだけどフィルタ係数や入力信号のバッファ
がL1 L2 超えて外部になると一気にメモリ転送の問題が発生する気がする
メモリのレイテンシーって結構デカイ気がするけど詳しい人教えて

>>433
ちょっと俺も興味あるんだけど そのソフトの詳細希望

>>434
リアルタイムでFFTだとレイテンシーもだけどブロック間の繋ぎがどうなるんだろ


436:デフォルトの名無しさん
07/04/06 13:31:52
>そのソフトの詳細
今時のPCの音楽制作環境のことまるで知らないの??
コンボリューションリバーブなんかはここ数年流行っててすでに一般的。たくさんあるぞ。
「コンボリューション VST」とかでぐぐってみなはれ

437:デフォルトの名無しさん
07/04/06 14:05:58
>>436
こういうのってリアルタイム入出力できるの?

438:デフォルトの名無しさん
07/04/07 00:06:50
>>435
ブロック間のつなぎはoverlap-and-addでやるだけなので、大丈夫。

439:デフォルトの名無しさん
07/04/07 07:49:56
>>437
DSPプログラミングやってて、今時そうゆうの知らないことのほうが驚きですよ。
音楽制作と無関係な業界でやってる技術者だったりすると案外そうゆうもんですかね。

「DSP」っていう言葉も昔は主に専用チップ、Digital Signal Processorのことを指していたけど、
汎用PCによるリアルタイム処理が台頭してきた今は、
意味が広がってデジタル信号処理全般、Digital Signal Processingというニュアンスですよ。

440:デフォルトの名無しさん
07/04/07 08:12:27
FIRネタの書き込みは、どの板も具体的な話が欠落してるなw

厨?

441:デフォルトの名無しさん
07/04/07 08:18:37
>440
単純に大量のかけ算するだけなら簡単だが、
FFT応用するとかいうと詳しい人なかなかいないんでしょ。
そうゆうおまいは?

442:デフォルトの名無しさん
07/04/07 08:23:46
>>441
それも既出。

443:デフォルトの名無しさん
07/04/07 10:12:17
>>435

ここでは板違いかもしれないけど、
たとえば、foobar2000のイコライザは8192Tapの
firフィルタで、畳み込みにfftを利用している。

foobar2000のプラグインのconvolverは、大きな
インパルスファイルを指定してやれば、
数万Tapの畳み込みも音がとぎれず再生する
こちらも畳み込みにfftを利用。
(Tap数は表示されるFFT Length の半分)

firフィルタはどうしてもレイテンシがでかくなるから
リアルタイムの演奏や画像との同期は難しいけど
パソコン上のファイルを変形させるならかなり使える。

「fft overlap save」でググるよろし。

こことかは、お勉強の過程が書いてあって
参考になるかも。

URLリンク(junzo.10gallon.jp)





444:デフォルトの名無しさん
07/04/07 15:15:53
結局のところ今のPCじゃ時間軸での畳み込みはまだ無理ってことでFA?

多分 436はその辺は考えてなかったんだろな
知識ひけらかす前に 431の質問を汲み取ってやれ

445:デフォルトの名無しさん
07/04/07 15:43:51
すいません、畳み込みリバーブのプラグインとかは時間軸での畳み込みとは違うんですか?

446:デフォルトの名無しさん
07/04/07 16:45:19
今手元に可逆圧縮済みrawがあって、これをwavにしなければならないんですけど、
・rawデータはwavのヘッダ無し波形
・どういう形で圧縮されているのか分からないのでデコードしようがない

一体圧縮済みrawはどういうフォーマットなんでしょうか?

447:デフォルトの名無しさん
07/04/07 17:22:42
>>445
畳み込みリバーブと書いてあっても
実際はインパルス応答 入力信号を両方FFTしてオーバーラップ法を使った
周波数軸での畳み込みをしているのでは無いかということ

この辺りは説明書とかみると書いてあるのかな?

実際に最近のCPUで誰か真っ当な時間軸での畳み込みやって
何タップくらいいけるのか測定してみてくれYO

ぉ サウンドプログラミグっぽくなってきたなおぃ

448:デフォルトの名無しさん
07/04/07 17:25:30
あ もちろんリアルタイム入出力での話ね
オフラインなら何億タップだろうがメモリがあるかぎりいけるだろうからw

449:445
07/04/07 19:29:09
>>447
さらにすいません、
真っ当な時間軸での畳み込みというのと、FFTを使った周波数軸での畳み込み、
というのは結果が違うのですか?
FFTを使った方法は軽いけどあくまで別物なんですか?

450:デフォルトの名無しさん
07/04/07 21:14:20
>>449
(精度の問題を除いて)時間軸畳み込みと全く同じ結果が得られる方法がある。

451:デフォルトの名無しさん
07/04/07 21:32:48
素人談義状態だな

452:445
07/04/07 22:14:09
>>450
なるほどです。
ちょっと調べてたらなぜ畳み込みにFFTが使われるのか、とてもわかりやすい説明みつけました。
URLリンク(www.nextftp.com)

周波数軸での畳み込み?、、、というのにあたるのかどうかよく理解できないのですが、
とにかく概算で約200倍速く計算できるようなこと書いてありました。
自分はFFT自体あまり理解できてないのですが、これ読むと魔法のようすね。

453:デフォルトの名無しさん
07/04/08 02:24:08
>>452
オーダーが違うからね。
FIR 長を N として、
普通に時間領域で畳み込みすると、O(N^2)
FFT 使うと、O(N lon N)。

長さ N で FFT しちゃうと、そのサイトにある通り、循環畳み込みになっちゃうから、
実際には長さ2倍にして、半分 0 埋めてとかやる。
で、FFT + 周波数領域で掛け算 + 逆FFT ってなるんだけど、
2N log 2N + N + 2N log 2N とかで演算回数かかるけど、
O(N log N) だから、何千・何万タップとかになると圧倒的にこっちが早い。


454:デフォルトの名無しさん
07/04/08 05:27:24
>>451
煽りはいいから >>447 の試してソース公開してみろって

455:デフォルトの名無しさん
07/04/08 10:04:31
>>447
わざわざ最新のCPUを買わなくなって計算の見積もりは出来るだろ。
そりゃ、DSPと違って、PCの場合は演算能力の見積もりは難しいけど
44.1Kで 100万(1M)となると、モノラルで44.1G/Sの積和能力が必要になる
ゲーム機のGPUなんかでは、無理に思えない数字に見えるだろうが
パソコンだと、あと10年程先だろうね

確かに100万となると20bitにもなるわけでゲーム機のような単精度でいくら
高速でも意味はないわけだけどさ。

あ、FFTを補助的に使ってリアルタイムに実現する方法もあるんで


456:デフォルトの名無しさん
07/04/08 11:01:08
聞きかじり&妄想が延々と続きます・・・

457:デフォルトの名無しさん
07/04/08 11:30:08
2^20のFFTを使うとすると 1048576-1000000 = 48576 サンプルが丁度いいサイズになる
1.1秒毎に22秒ほどのデータをFFTして処理するので、計算時間を無視して1.1秒の遅延が必要になる。
計算時間はこのシステムが動く最悪値と考えれば2.2秒の遅延が必要になる

別けて計算する方法は、1サンプルあたりのFIRフィルタの計算は
Σ C[i]*D[i]
たとえば 現在から1万サンプルのデータDaと 99万Dbに別けると
Σ C[i]*D[i] = ΣC[i]*Da[i] + ΣC[i]*Db[i]
ΣC[i]*Db[i]は1万サンプル以上前のデータなので、FFTを使う方法で1万サンプル分を先に計算出来る
残った1万サンプルだけをリアルタイムに計算すればいい
計算量は44100*10000 = 441M/Secなので、今のPCなら不可能な数字ではない

458:デフォルトの名無しさん
07/04/08 12:01:09
URLリンク(www.knufinke.de)

459:デフォルトの名無しさん
07/04/08 15:18:43
>>449

直線畳み込みと循環畳み込みをfftを利用して行うこととは
数学的に完全に等価です。

ですから、数千Tappを超えるfirフィルタの処理を行うとき
時間軸での畳み込み(直線畳み込み)をやるのは
無意味だと思いますね。

これが最強、最有名です。

URLリンク(www.ludd.luth.se)


460:デフォルトの名無しさん
07/04/08 15:53:22
ひたすらゴッグルさんのご神託を貼り付けるだけのスレw

461:デフォルトの名無しさん
07/04/08 15:57:07
この議論、数ヶ月前にも見たw

462:デフォルトの名無しさん
07/04/08 16:32:43
FFTを使う方法でもリアルタイムに出来るというのは前回無かったように思うが?

463:デフォルトの名無しさん
07/04/08 16:49:50
で、この議論のどこら辺でリアルタイム手法が提案されたって?


464:デフォルトの名無しさん
07/04/08 16:54:40
じゃあ 俺も妄想ね。

単精度32bitステレオで扱おうと思うとデータ量だけで
フィルタ係数分左右で1タップ8byte 入力信号とあわせると16byteの記憶領域が必要。
10万タップの時点で既に1.6Mの記憶領域が必要になってしまう。

それがどうしたという感じだが、もしこのデータを外部メモリから読み出そうとすると
最近のメモリで読み出しレイテンシーが10nsくらいだから
信号と係数を逐次読み込んで毎回積和をとるとしたら
1/10000sec が毎回読み出しだけで消費されてしまう時間。
さらにこれに積和時間と入力信号保持用にリングバッファなりしなければならない。
MMXにシフトレジスタ命令はあったはずだが。
まぁこれ考えるとCPUキャッシュから外れるとメモリ読み出し時間
が一番のボトルネックになる気がするんだけど。
10万タップもまったく現実的じゃないよな。
サンプリング8kでギリギリ読み出しが間に合う速度くらいw

とするとL1最低でもL2にデータ保持できる量=最大次数 くらいのノリにならねぇか?

キャッシュも自分でフルに使える分けじゃないし
かなりローレベルなプログラミング技術が要求されるよなぁ


465:デフォルトの名無しさん
07/04/08 17:01:39
何msまでの遅延ならリアルタイムと見なせるだろうか。
30msくらい遅れると明らかに違和感が出るよな。
10msくらいならおk?

466:デフォルトの名無しさん
07/04/08 17:05:21
>>465
そもそも今いっているリアルタイムはそういう意味ではない。

一定量の遅延があるだけで出力し続けれるのならそれはリアルタイム処理。
 入力→演算→出力 
の流れが次の入力が来るまでに終っているかどうか(1サンプル内で演算が終っているかどうか)
がリアルタイム処理の定義だと思われ

467:デフォルトの名無しさん
07/04/08 17:26:36
レイテンシー以前の話かよw

468:デフォルトの名無しさん
07/04/08 17:35:23
>>463
もちろんPCの場合はCODECとの通信がブロックでやってくるから、意味はないのだけど
1サンプル毎に答えを出す手法について提案されているじゃないか?

でも、コレ計算量の削減になるのかな?

256点で考えてみよう。
64点を時間領域で 残りの192点をFFTで行うとする
c0*d0+ ・・・ +c63*d63 とc64*d64+・・・c255*d255
前半は O((N/4)^2)=O(N^2/16) =4096
後半は、64サンプル毎に256点のデータで行えば 64サンプル毎に1回処理するので
4*(2N log 2N + N + 2N log 2N )=4*2*N*( 1+2*log2N) = 4*2*256*17= 34816

うーん

469:デフォルトの名無しさん
07/04/08 17:42:11
>>464
単精度でFFT方式を10万タップで使うと、結果は上位8bitまでしか信用出来なくなる
浮動小数点なので、相対誤差だから十分良いといえば良いのだけどね

あと10万タップくらいならFFTでやれば今のPCならリアルタイム処理は行えるよ
実際やってるし。

だって2秒に1回計算すりゃいいんだから余裕。
素直に書いたルーチンでも1秒に10回くらいは計算出来てるよ。



470:デフォルトの名無しさん
07/04/08 17:56:28
256点でなく、一般化して考えてみる
M分割した1/Mを時間領域で 残りをFFTで行うとする
この方式との比率は、
((N/M)^2 + M*2*N*( 1+2*log(N)/log(2)))/(N^2)

N=2^8ではダメだったが、
N=2^16 M=16を代入すると 約1/50
N=2^20 にすると 1/200 と大きいほど改善するようだ

さらに、細かく分割して効率化すれば、もっと効率上がるのかも

471:デフォルトの名無しさん
07/04/08 18:15:45
計算間違いしてた
こうか?
 (((N/M)+M*( 1+4*log(N)/log(2)))/(N)

N=2^16 M=16を代入すると 約1/12 でしかない


472:デフォルトの名無しさん
07/04/08 18:24:13
10万タップにあてはめてみるとN=16 M=32で約1/20
この時の負荷はFFTだけで計算した場合の100倍近い


473:デフォルトの名無しさん
07/04/08 19:50:03
>>464
確かに時間軸での畳み込みをプログラムで実装するとそこが問題になりそうだ。
ハードのこと全然詳しくないんだが。
というかその後の話が全部周波数軸での話しになってるのが妙にうけた。
あきらかに>>464の話は時間軸での計算なのになw

FFTでの畳み込みは確かに早いんだけど精度とかアルゴリズム的なこと考慮しないといけないから面倒だな。
そういった意味では時間軸での畳み込みの限界を俺も見てみたい気がする。

474:デフォルトの名無しさん
07/04/08 19:55:58
> 最近のメモリで読み出しレイテンシーが10nsくらいだから
> 信号と係数を逐次読み込んで毎回積和をとるとしたら
> 1/10000sec が毎回読み出しだけで消費されてしまう時間。

1/10000[sec]/10[ns]=10^-4/10^-8=10^4[word]

1/10000secって一体なんの話?

475:デフォルトの名無しさん
07/04/08 19:59:18
10万個読み出し * 10ns と思われ リードタイム?

476:デフォルトの名無しさん
07/04/08 20:03:51
10^5[個]×10^-8[sec]=10^-3
10万個なら1/1000がメモリ読み込み時間
10^6[個]×10^-8[sec]=10^-2
100万個なら1/100がメモリ読み込み時間


477:デフォルトの名無しさん
07/04/08 20:28:02
FFTを使おうが、Σdt[i]*c[i]の演算は時間軸での計算だと思うけどな
単にFFTを使って掛け算を高速化しているのにすぎないわけで

>>464
まず、
係数については柔軟性を持たせる為に浮動小数点というのは悪くないが
データは16bit固定小数点で保持すれば十分だろう。
実用的には係数も16bit で十分。
(この場合でも積和累計レジスタには 16+16-1+17=48bit が必要)
その場合、途中係数が0が続く部分が大量に出る。
なぜなら全部が1のデータでも計算結果は2bitオーバフローしてしまうのだから。
だから0の部分をリスト形式でスキップすれば計算量は多少小さくなるかもね

キャッシュについては、
Σc[i]*d[i] は 分解出来るわけだから、たとえば256サンプル毎に
キャッシュに入るサイズで分割して計算すれば、問題ないだろう

478:デフォルトの名無しさん
07/04/08 20:31:31
> データは16bit固定小数点で保持すれば十分だろう。
> 実用的には係数も16bit で十分。

ゲーム用途なら実用的かも。
音楽用途だと精度が低すぎ。
例えばリバーブの消えかけ部分のS/N比が低くなるだろう。

479:デフォルトの名無しさん
07/04/08 20:38:18
>>478
リバーブの場合でも全体にスケーリングすれば十分さ。
逆にどこもかしこも係数が大きい100Kワードの係数があったとすれば
結果は簡単にオーバーフローしてしまう。

全部の係数が+1か-1であってもオバーフローするんだからさ

480:デフォルトの名無しさん
07/04/08 20:41:18
ふーん。
固定小数点+スケーリングって事は、
トータルでは浮動小数点演算なわけだ。

481:デフォルトの名無しさん
07/04/08 20:42:56
あ、ごめん。
データと係数は16bit固定小数でも
内部演算結果は48bitになるっつう話ね。了解。

482:デフォルトの名無しさん
07/04/08 20:46:55
64bitマシンならともかく、現行CPUだと16+16-1+17=48bitを固定小数点で計算するには
桁上げが必要になるわけで、浮動小数点レジスタで計算させた方がいいと思うよ

483:デフォルトの名無しさん
07/04/08 20:48:45
おk

一体なんのための固定小数点だったんだろうね?

484:デフォルトの名無しさん
07/04/08 20:52:21
PCのインターフェースは44.1K 16bitステレオなのだから
16bit固定小数点の選択で何の過不足も無いと思うのだが?

485:デフォルトの名無しさん
07/04/08 20:55:01
もーどーでもいいや。
結論出たら教えてくれ。

486:デフォルトの名無しさん
07/04/08 21:05:08
じゃ、ここまでの勝手なまとめ
1、FFTを使う場合でもレイテンシ1のフィルタは実現可能
   ただし計算量はそれなりに増える
   それでも係数器が巨大ならFFTを使わない方法よりもずっと高速

2、FFTを使わない場合でもキャッシュサイズが溢れる心配については不要
  キャッシュに入るサイズにFFTでレイテンシ1のフィルタを作る時と同じように分割すればいいだけ
  だったらFFT使えよと

487:デフォルトの名無しさん
07/04/08 21:06:57
DSPだと積和を1クロックで処理できるって売りを良く聞くけど
Intel入ってるとかだとどうなの? 例えば10クロック必要なら単純に
3GのCPUでも300M個の処理しかできないよね。
3億タップ!?って感じはするけど実際に使えるリソース考えると
>>464の言うリード時間の問題がほとんどになる気がする。

>>477
何個分割して処理しようが結局メモリからキャッシュにフィルタ係数なり入力信号なりを
リードしてから計算しないといけなくなるから無意味。
始めからCPUキャッシュ上に係数も信号も保持していないと駄目ぽ。

>>464
の言う1/10000sec が 1/1000sec の間違いだという仮定ならますますPCでの
リアルタイム畳み込みは時間軸では厳しくなりそうですね。
あと揚げ足とるようだけど10万個の係数読むなら10万個の入力信号も
読まないといけないわけで合計20万個のデータリードになるよ^^;
ということは 1/500sec が一度の積和に必要なメモリリード時間になるが。。。

キャッシュから外れたら無理だね。と思わせる時間だよなこれw

逆に質問、キャッシュ内データのアクセスタイムってどれくらいなんだろ。
ナノのオーダーじゃ全然遅いよね。ピコとかのオーダーなのかな

488:デフォルトの名無しさん
07/04/08 21:09:20
>>486 の結論2は明らかに間違っている。

489:デフォルトの名無しさん
07/04/08 21:10:01
って書いたら真上で 487が指摘していた うぇw

490:デフォルトの名無しさん
07/04/08 21:20:08
>>487 もしかして、話についていけない?

フィルタの計算は、1サンプル毎にデータがズレて
t0↓ d  e  f  g  h  i  j  k
t1↓ c  d  e  f  g  h  i  j
t2↓ b  c  d  e  f  g  h  i
t3↓ a  b  c  d  e  f  g  h
係数器は同じ係数が使われる。
   c0 c1 c2 c3 c4 c6  c7

f0の時点で、 d*c0+e*c1+ ・・・・ だけでなく
d*c1+e*c2+・・・・ や
d*c2+e*c3+・・・・ を先に計算しておけば
t1の時点では c*c0だけを
t2の時点では b*c0+c*c1を計算するだけでいい というわけ

で、先に計算する時に計算順をキャッシュのサイズで分割すればいいだろ?
って話をしてるわけさ

491:デフォルトの名無しさん
07/04/08 22:00:44
ようするに、
遅延器の後ろの部分は、先に計算出来るから
計算順を変更してしまって、
1サンプルでは同じ遅延器部分を何度も計算してしまうようにしちゃえばいいって事だな

で、細かく分割して計算順を変更する手間を考えたら、
だったらFFTで計算しちゃえよと

492:デフォルトの名無しさん
07/04/08 22:03:03
スルー

493:デフォルトの名無しさん
07/04/08 22:05:51
>>490全然計算量減ってないあたりが笑えた


494:デフォルトの名無しさん
07/04/08 22:11:37
ん?  計算量は同じだけど、t0に計算が集中してしまうね



495:デフォルトの名無しさん
07/04/08 22:18:05
しかもt8以降は計算量一定

一体何を言いたかったの?

496:デフォルトの名無しさん
07/04/08 22:28:23
こんだけ説明されて判らんのか? どこが判らんの?

497:デフォルトの名無しさん
07/04/08 22:32:40
>>494
例ではそうなってるけど、
実際は、これを分割するわけ、キャッシュに入るサイズで分割すれば
キャッシュの出入り回数はそれだけ実質へらせられる

498:デフォルトの名無しさん
07/04/08 22:46:22
とりあえず誰かこれプログラムにしてみてよ
話それから

499:デフォルトの名無しさん
07/04/08 23:18:17
1/2分割の手順

N2=N/2-1
Σ(0..N){c[i]*d[i]} =c[0]*d[0]+c[1]*d[1] +・・・c[N]*d[N]

R1=Σ(2..N2) {c[i]*d[i]} S1=Σ(N2..N) {c[i]*d[i]}
R2=Σ(2..N2) {c[i]*d[i-1]} S2=Σ(N2..N) {c[i]*d[i-1]}


2サンプル毎に
偶数目では S1=Σ(N2..N) {c[i]*d[i]} と S2=Σ(N2..N) {c[i]*d[i-1]} を計算 
Σ(0..N){c[i]*d[i]} =c[0]*d[0]+c[1]*d[1] +R1+S1で求める

奇数目では R1=Σ(2..N2) {c[i]*d[i]} と R2=Σ(2..N2) {c[i]*d[i-1]} を計算
新しいサンプリングデータがdnewとして
c[0]*dnew+Σ(1..N){c[i]*d[i]} =c[0]*dnew+c[1]*d[0] +R2+S2 で求める

そしてデータは2ワードシフトする

500:デフォルトの名無しさん
07/04/08 23:19:36
訂正
× c[0]*dnew+Σ(1..N){c[i]*d[i]} =c[0]*dnew+c[1]*d[0] +R2+S2 で求める
○ c[0]*dnew+Σ(1..N){c[i]*d[i-1]} =c[0]*dnew+c[1]*d[0] +R2+S2 で求める


501:デフォルトの名無しさん
07/04/08 23:51:28
こういう計算する時の遅延器ってみんなどう実現してるのかな
DSPの場合はモジュラアドレッシングがあるからいいけど
PCの場合、俺がやった事があるのは

1、2のべき乗のサイズのバッファ取って and 演算で計算
   [(wp+i) & (BufSize-1) ]
  案外、効率が悪い

2、メモリを2倍とって wpの位置に書く時 [wp]と[wp+N] の2箇所に書いて
 読む時はそのまま [wp+i] でアクセス
  効率はいいけど、メモリが2倍必要
  仮想記憶用のテーブルにアクセス出来れば、メモリを2度割り付ければいいんだろけど

他にいい方法ある?
 メモリをその都度moveするコードはありえないとして


502:デフォルトの名無しさん
07/04/09 01:03:17
何この流れ。
最近は、リアルタイムの意味を取り違えている人がいるから困ったもんだ。 (あのドラマ、リアルタイムで見た とか。お前の視覚神経はコンピューターか)

503:デフォルトの名無しさん
07/04/09 01:04:27
スルー推奨

504:デフォルトの名無しさん
07/04/09 10:47:29
リアルだったら殴ってるよタイム

505:デフォルトの名無しさん
07/04/09 13:29:27
流れぶったぎって初歩的な質問を・・・
0〜1のリニアなスロープを聴感上リニアにしたいのですが、いい方法ありますか?
-96〜0などとしてデシベル換算だと、0が0にならないですよね。
あるいは良く近似するカーブを得る軽い方法などありますか?
(自分は累乗をよく使うのですが、近似というところではイマイチで・・・)

506:デフォルトの名無しさん
07/04/09 13:38:18
指数カーブに適当に0を通る関数を掛け算したら?
(a^x)*x^b
とか bを 1/2 つまり平方根なんて良く使うよ

507:デフォルトの名無しさん
07/04/09 14:44:14
平方根掛けいいですね。
試してみましたが、かなり近似しつつ0を通るようにできますね。いいこと教わりました。
リアルタイムで毎回計算する用途だと平方根はちょっと重いですかね?
類似した方法も、いろいろ試してみたいとおもいます

508:デフォルトの名無しさん
07/04/09 18:34:32
a^x と √x のどっちが重いかという話なら、同じ程度だと思うが
PCならテーブル作って間を直線補間するし
DSPなら4〜5次くらいに級数近似するし

509:デフォルトの名無しさん
07/04/10 01:18:11
パッタリ止まったなぁw

で、ソースまだ?

510:デフォルトの名無しさん
07/04/10 02:05:59
クレ房きました

511:デフォルトの名無しさん
07/04/10 02:08:10
オレ、勝手にやってる

512:デフォルトの名無しさん
07/04/10 05:37:57
流れが止まった・ ∪´∀`)モキュ

513:デフォルトの名無しさん
07/04/10 06:44:22
ソースって・・・・ >>499の以上に必要か?

FFTを使えば、計算量もメモリアクセスも激減するのに、
こっちは計算量は減らない。 当然メモリアクセスも。
ただ同じ領域を2度使うからキャッシュが効き易いというだけじゃ、試す必要もない
理論的に可能かどうかは式みれば判るだろ

514:デフォルトの名無しさん
07/04/11 06:08:28
>>501
モジュラアドレッシングって巡回アドレッシングの事だよね?
Tiでいうところのサーキュラドレッシングモードみたいな。

最近のPCだとSSEでシフトレジスタ用意されてるからほぼ同じことできるよ。
そうじゃなかったらメモリ2倍使う2番目の方法が一番現実的な気がする

>>513
まぁまぁそう言わないで。
初心者さんにしてみたらFFTなんか使う方法よりもサクッとフィルタ係数畳み込める
時間軸での方が分かりやすいし書きやすいってのはあるんじゃない?
溢れさえ気にしなければそのままソースかけるし。

515:デフォルトの名無しさん
07/04/11 08:32:25
モジュラアドレッシング は モジュロ(modulo)アドレッシング の typo だろけど
SSEで モジュロアドレッシングってどうやるの?

516:デフォルトの名無しさん
07/04/18 03:20:32
すごい止まったなぁ。。。

517:デフォルトの名無しさん
07/04/18 10:15:41
DSPじゃないんだから、モジュロ・アドレッシングなんてできるわけない、
ムリに再現しようとしても動作が重くなるだけで意味ない、って誰か書けよ。

518:デフォルトの名無しさん
07/04/18 10:46:28
直前まで、FIRフィルタ処理の話をしてるんだろ?
モジュロアドレッシングつかわずにどう実装するんだ?

519:デフォルトの名無しさん
07/04/18 11:43:45
>>518
単純に、ループと配列を使って、掛け算したのを足していく。
逆になんでモジュロアドレッシングがなきゃできないんだ?

520:デフォルトの名無しさん
07/04/18 11:58:13
>>519
ソレはバッチ処理の場合だろ?

1サンプルづつデータを受信して、処理する場合、モジュロで処理しないの?

521:デフォルトの名無しさん
07/04/18 12:29:19
普通に書いたら、

wp := ( wp-1+length(data) ) mod length(data);
data[wp]:= 新データ;

sum:=0;
for i:=low(c) to High(c) do sum:=sum+ c[i] * data[ (i + wp) mod length(data) )] ;


だな。 もしかして、この mod がモジュロアドレッシングなのか?


522:デフォルトの名無しさん
07/04/18 12:32:07
それなんていう言語の擬似コード?

523:デフォルトの名無しさん
07/04/18 14:02:00
   // :/:::::/::::::.!:::|:::: !::::::::、:::::::::::::::::、::ヽ::::::::ヽ
   !|:::/::::::.!:::::::|:::∧::::|、::::::::!.、:::::::::::::ヽ: !:::::::::: !
  i:l: ::|:/:::.!::::::ii|_:| ヽ:::!l\:::!'、\::::::::::::!::!::::::::::::.!
.  |/l:::.!|, :::ヽ::::l'l:lヽ、ヽ:|l'´ヾr==ミ、:::::::|::|:::::::!::::: !
   |::.!l:.!::::::lヽ|,==、 `'    ヽ   \:|:: !: ::: !::::::.!   うるさいうるさいうるさい!
   l/ `ヽ::|:::l     , - 、       ll'::::!.l:::::.!:::::::.!
       l`l::.!!     l/ ̄ ヽ    /.!::::.!:|::::::.!:::::::l
       !::::.!.!ヽ   ヽ   ノ  /::::|:::::|::.!:::::.!:::::::.!
      .!::::| !::::.` ー 、._ ´ ,/  |::: !:::::|:::l::::::.!:::::::|
       |:::::|.!::::.!:::::.!:::::::::`Г    l-,|::::.!::::|::::::.!:::::::|
      |::::::l':::::.!::::::|:::::_, -/}    /:l:::::lー-: !:::::::.!
      !::::::|:::::_!, .‐' ´.:.:.:!r- 、_ /.:.:.:!::::l// /`ヽ:: !
.     |::::::|/ ヽヽ.:.:.:.:.:.lィーミ./.:. :.:.:.!:::.!/  /   !::.!
.     |:::::::! ヽ ヽヽ.:.:.:.ヽ  / .:.:/ !::::|   /   |::::!

524:デフォルトの名無しさん
07/04/18 15:22:39
>>522
PascalとかSmalltalkとかじゃないか?

525:デフォルトの名無しさん
07/04/18 15:50:35
>>501
3、積和を2度に別ける
wp〜最後までと
 先頭〜 に


526:デフォルトの名無しさん
07/04/19 01:57:52
久しぶりにパスカルチックな言語書く人みたわwwwwwwwww
:= なんてほんま涙がでそうやわ。

ここ見てる人はシフトレジスタ知らない人なんだねと心底思った。

527:デフォルトの名無しさん
07/04/19 07:12:04
シフトレジスタ?
シフト命令の間違いか? だとしても、この話題のどこにシフト命令が?

528:デフォルトの名無しさん
07/04/19 10:20:39
>>526
コンパイラが勝手にやってくれるところだろ。

529:デフォルトの名無しさん
07/04/19 12:51:26
>>526
このスレと過去ログを := で検索してごらん
URLリンク(www.2chdat.net)

たぶんあなたが思うより多かった筈だ。
たぶん、スレ参加者の半数くらいは windowsではDelphi使ってるカモ

530:デフォルトの名無しさん
07/04/19 13:07:03
×スレ参加者の半数くらいは windowsではDelphi使ってる
○Delphi使ってる香具師が一人で頑張っている

531:デフォルトの名無しさん
07/04/19 13:35:49
":= "が登場したのはフィルター計算とサイン波音源の話くらいかな

532:デフォルトの名無しさん
07/04/20 05:00:43
:= 書いてるの明らかに一人だけじゃないかww

>>530に禿げ同

533:デフォルトの名無しさん
07/04/20 07:28:59
Delphiは良いと思うよ

534:デフォルトの名無しさん
07/04/20 07:38:28
うん。低レベルAPIのラッパコンポ作っておけば、
実験するときはポトペタで簡単にコード試せるし
GUI付けて、他人に試してもらうの便利。
BCBもいいけどコンパイルの早さでDelphiだな

535:デフォルトの名無しさん
07/04/20 10:13:19
Delphiは完成品が重いし、コンポーネントはバグ抱えてるし、
意外とほかでの応用がきかないし、どうかな…。

536:デフォルトの名無しさん
07/04/20 10:23:18
自分の場合、windows上だけで完成するわけじゃないからテスト用
アルゴリズムを評価してもらうためと自分のテスト用ね。
コンポーネントのバグは知らない。テスト用だから気にもしてないのかもね

537:デフォルトの名無しさん
07/04/20 10:32:50
>>534
お前はまずPCを買い換えろ。
テストコード程度でコンパイル速度に顕著な差が出るってどんなマシン使ってんだ・・・

538:デフォルトの名無しさん
07/04/20 10:51:14
Delphiは完成品がとても軽いのだが・・・・もしかしていまだにDelphi5使ってるから?

>>535はどのバージョンが何と比べて重いの?

539:デフォルトの名無しさん
07/04/20 19:16:28
PC を買い換えたら Delphi の完成品の速度も、BCB のコンパイル速度も上がるな(w

540:デフォルトの名無しさん
07/04/21 12:42:36
パソコンが速くなっても、BCBだとF9押して3秒くらい
Delphiは1秒以内。 実行ファイルそのままクリックしてる感覚と変わらない
だからCで書いたコードのテストでもDelphiからコマンドラインでBCCでコンパイルして
pascalでテスト部は書いてるな

541:デフォルトの名無しさん
07/04/21 12:45:38
Delphi派は判ったから、他の人は何で書いてるのか知りたいな。
MATLABとか多そうだけど

542:デフォルトの名無しさん
07/04/21 16:35:04
ノシ
MatlabとJava

543:デフォルトの名無しさん
07/04/21 18:22:31
それ以前にこのスレはどうゆう人が多いのかな
DSP使った組み込み向け信号処理屋みたいな人とか、
PC向けリアルタイム処理(音楽関連アプリやVSTとかDXプラグインとか)やってるひととかさ。
それによってだいぶ違うよね?
前々からそれによって微妙に話しが食い違うときがあった気が。
いわゆるゲーム屋とかでは、このスレみたいなやれFIRとかFFTとかいう話題にならないし

544:デフォルトの名無しさん
07/04/21 18:54:32
音を利用するプログラムを作ろうとしてるか、音データを処理するプログラムを作ろうとしてるかだけでもだいぶ違うな。

545:デフォルトの名無しさん
07/04/21 19:22:09
>>543
ところがどっこい
エンタメ系サーバ書いてる奴がPhaseVocoder使ってたりするw

546:デフォルトの名無しさん
07/04/21 21:06:25
私ゃ信号処理屋だから参考にしてるだけ。
まぁでも、光もナノテクの世界では音みたいなもんだしね。

547:デフォルトの名無しさん
07/04/21 21:11:30
非現実的な妄想発言を見てしまった

548:デフォルトの名無しさん
07/04/21 21:13:00
>>185書いた人?

549:デフォルトの名無しさん
07/04/21 21:13:00
低学歴が犯しがちなトンでも発言だな

550:デフォルトの名無しさん
07/04/21 21:37:05
このスレ 面白いんだけど、ドレが正解かよく判らん所もあるな

551:546
07/04/21 21:37:39
私ゃ>185じゃないよ。

光の回折でエッジが暈けるから位相を反転して合成しようとか、
光の密度が均一じゃないから反射を利用して均一にしようとか、
そういう話を実際の光源でテストする前にシミュレーションする仕事が
よく来るのよ。実際何がどうしてそうなるのかなんてよく判らんけどね。

552:デフォルトの名無しさん
07/04/21 21:40:29
じゃ>>185は正解なの? 
あと >>109は?

553:デフォルトの名無しさん
07/04/21 22:52:39
低学歴なんでよくわからないけど、
スペクトル分解(フーリエ解析)なんかは、
電磁波でも音波でも全く同じ数学なんじゃないの?

554:デフォルトの名無しさん
07/04/21 23:09:21
>>553
光と音は波としての性質は同じだが、目と耳は構造も機能も全く違うからな。

555:デフォルトの名無しさん
07/04/21 23:30:56
> 光もナノテクの世界では音みたいなもんだしね

どんなナノテクwをやっているのかkwskw

556:デフォルトの名無しさん
07/04/21 23:52:11
まあいいじゃないの、そんなとこに食いつかなくても

557:デフォルトの名無しさん
07/04/22 00:04:21
はいやっぱり逃げたね
いくらなんでも愚かすぎる光学技術者だと思ったら
やっぱネタか


558:デフォルトの名無しさん
07/04/22 00:17:39
画像処理と音声処理の共通点の無さは異常

559:デフォルトの名無しさん
07/04/22 00:21:20
決まり文句も出たところでこのへんで

560:546
07/04/22 05:54:18
面白いなぁ、勝手放題で。
信号としての特性に似たところがあるってのを似たようなもんだって書き間違えただけでこれだ。
それに私は自分が光学技術者だなんて一言も書いてないのだけれど。

561:デフォルトの名無しさん
07/04/22 08:06:15
だいじょぶ、俺は信じるよ

562:デフォルトの名無しさん
07/04/22 08:35:52
> 光もナノテクの世界では音みたいなもんだしね

どんなナノテクをやっているのかちゃんと言ってごらん


563:デフォルトの名無しさん
07/04/22 08:37:10
>>545
PhaseVocoderを何に使うんだろうね

564:デフォルトの名無しさん
07/04/22 10:04:38
>>109の音は干渉しても消えないというのは

・光の波は進行方向に垂直だから進行方向が異なっても
 合成した場合、電界変化がゼロになった場所は磁界変化もゼロで、その場所では検出出来ない


音の波は、
URLリンク(tmhf.eng.shizuoka.ac.jp)
・進行波は運動量変化が進行方向に生じるので、方向が違うならベクトル加算しても消えない
・定在波は、運動量変化と圧力は90度位相がズレているので、圧力変化が最小の場所は運動量最大である

だから音の波は干渉では消えない。 
>>181 のように仮想の壁で反射する事でダクト消音は出来るが、これは干渉ではない。


・・・という理解で正しい?

565:デフォルトの名無しさん
07/04/22 10:25:13
高卒かよw

566:デフォルトの名無しさん
07/04/22 10:35:27
V

567:デフォルトの名無しさん
07/04/22 10:37:43
> 光もナノテクの世界では音みたいなもんだしね

どんなナノテクをやっているのかちゃんと言ってごらん

568:546
07/04/22 11:49:46
私自身はナノテク技術者やってるわけじゃないんだけどな。
まぁ、同じレスがコピペされている段階で相手にするだけ無駄か。

569:デフォルトの名無しさん
07/04/22 12:03:50
お前は自分の発言に責任を持っていない。
まともな神経を持った人間とは言い難いな

570:デフォルトの名無しさん
07/04/22 12:09:18
この人は2ちゃんに何を期待しているのだろう・・・

571:546
07/04/22 12:09:31
みんなごめんね☆

何か寂しくなっちゃって全然関係ないこと書き込みしちゃいました。

反省したので明日ボウズにしてきます。

(;_;)




次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

4934日前に更新/170 KB
担当:undef