10/03/01 03:52:18
FFTを勉強中です
基本的な質問で悪いんだけども
周波数ごとの音量ってのは
実部のスペクトル？
それとも実部と虚部から求めるパワースペクトル？
308:デフォルトの名無しさん
10/03/01 03:57:21
補足です
パワースペクトルが音量に相当するなら
実部=0、虚部≠0の場合
周波数は無いのに、音量はあるのか？
実部が音量に相当するなら、パワースペクトルの意味ってなに？
とか、よくわかんなくなっちゃったのです
309:デフォルトの名無しさん
10/03/01 05:09:56
URLﾘﾝｸ(laputa.cs.shinshu-u.ac.jp)
アニメで見ると分かりやすいね
310:デフォルトの名無しさん
10/03/03 01:10:53
>>309
読みました。
たしかにアニメーションついててわかりやすいですね。
んで、周波数ごとの音量に相当するのは、
パワースペクトルってことですね。
ありがとうございました。
311:デフォルトの名無しさん
10/04/23 22:54:20
SIMDなフィルタプログラムの英語か日本語のチュートリアル、どこかにありませんか？CPUには拘りません。
312:デフォルトの名無しさん
10/05/11 22:50:57
アップサンプリング時にゼロ補間してもスペクトルが変化しない理由ってなんでしょうか？
313:デフォルトの名無しさん
10/05/13 23:02:00
補間のあとのLPFで鏡像になって出てくるスペクトルをカットしてるから。
314:デフォルトの名無しさん
10/06/03 09:06:10
wavファイルの合成について相談です。
現在2つのwavファイルを読み込み、データ部を足し算することで「両方同時になっているwavファイル」を作成、出力することができました。
ここで疑問なのですが、16bitWAVの場合、データ部の値は
-32768～32767
となりますが、2つの足し算なら「int型に変えたあと足して、限界を超えたら丸めこみ、shortの範囲に戻す」すればいいとわかります。
ですが、3つの音を足すとなると、丸めこみを最後に一括してやるか、足すたびにやるかで結果が変わってしまいます。
例：
丸め(30000 + 30000 - 10000) = 32767
丸め(丸め(30000 + 30000) - 10000) = 22767
今はまだ、足す音が3つと決まっているから1単位時間毎にintで計算＞shortで吐き出しで問題ないのです。
が、もし「任意にユーザーの選択により次々音を足し算できるツール」のようなものを作る場合
やはり単位時間毎に一旦intとしてバッファを作り、WAVファイルとして出力する際に丸めこむべきなのでしょうか？
315:デフォルトの名無しさん
10/06/03 11:52:39
先に個数で割ればいいだろう
316:デフォルトの名無しさん
10/06/03 13:11:05
>>315
個数で割る。というのがよくわかりませんが、任意に追加できるため個数はその場その場で定まらないのを想定しています。
例えばAとBを合成して、とりあえずそれを再生。
ユーザーがそれを聞き、「やっぱりCも合成しよう」となった時などを想定しています。
AとBの合成音を再生するために、合成音を出力するバッファを用意しますよね。
その後Cを合成するのが決定した時、
・再度A、Bのデータもひっぱってきて、3音合成する
というよりは
・A+Bの合成音にCを合成する
ほうがメモリー効率や処理速度などで有利そうです。
ですがそれだと丸めこみ問題がでてしまいます。
317:デフォルトの名無しさん
10/06/03 13:35:55
普通は64bitとか128bitで計算して最後に戻すのよ。
318:デフォルトの名無しさん
10/06/03 14:55:02
>>普通は64bit
一体16bit音源を何万個合成するつもりだよｗ
319:デフォルトの名無しさん
10/06/04 00:22:21
>>316
> その後Cを合成するのが決定した時、
そんだけ仕様が未確定だと汎用的にプログラム書くしかないから効率もクソもない。
数百万サンプル程度の加算が問題になるような環境ならできることの自由度を下げる以外ない。
あと「～そう」で目についたところを最適化するのはほぼ最悪の戦略。
かなりの確率で最適化ポイントを間違う
320:デフォルトの名無しさん
10/06/04 17:33:01
ごめんねぼくはdouble厨なので
321:デフォルトの名無しさん
10/06/04 20:45:17
コンプレッサ実装すれば？
r = 初期値1.0
出力サンプル = 合成サンプル * r
出力サンプルが16bit幅超えたら、r = abs(合成サンプル) / 32768.0 で更新
r < 1.0 なら時間経過と共に少しずつ1.0へ戻してやる
実用レベルで実装するなら細かいノウハウとかあるからDSP関係の文献自分で調べて
322:デフォルトの名無しさん
10/06/05 00:00:11
>>314は「丸め」とか用語が適切じゃないからちょっと知識が不足してる感じがするね。
俺もコンプレッサ/リミッタ関連について調べてみることをお勧めする。
323:デフォルトの名無しさん
10/06/08 11:34:15
コンプレッサーはデータを改変してしまうからよくないだろ。
ノーマライズすればいい。
324:デフォルトの名無しさん
10/06/08 18:08:07
いまどき整数とか面倒
不動明王を使うだろ普通
325:デフォルトの名無しさん
10/06/09 09:59:47
恐れ入谷の鬼子母神
326:デフォルトの名無しさん
10/06/11 21:27:02
>>314
分解能32ビットとかで作業用データ配列を作成すると良い。すべて加算した後16ビットレンジに収まるよう最適化する。
一旦WAVファイルをセーブした後、さらに別のWAVファイル加算したいときは、16ビットでは精度が不足するので、
以下の方法を取る。
WAVファイルの分解能をfloatか24ビットとする。フォーマットの設定が16ビットと異なるがちゃんと再生されるWAVファイル
を作成することができる。
参考：
WAVEFORMATEX構造体
WAVE_FORMAT_IEEE_FLOAT
327:デフォルトの名無しさん
10/06/11 21:35:42
float
-> WAVEFORMATEX
24ビット
-> WAVEFORMATEXTENSIBLE