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

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

1:デフォルトの名無しさん
07/07/25 14:07:56
音のプログラミング処理について語りましょう

各エフェクタの組み合わせとか、
プログラミング外の話題はDTM板の方がいいよ

サウンドプログラミング3
ｽﾚﾘﾝｸ(tech板)

サウンドプログラミング2
ｽﾚﾘﾝｸ(tech板)

サウンドプログラミング
URLﾘﾝｸ(pc5.2ch.net)

2:デフォルトの名無しさん
07/07/25 14:52:49
2get

3:デフォルトの名無しさん
07/07/25 16:24:53
用語を統一するために

リアルタイム
　バッチ処理の対語で、ゼロレイテンシの事ではない。　
　遅延はあっても途切れずに処理する事をいう

レイテンシ
　ADCからDACまでにかかる時間の事だったり
　ＤＳＰの掛け算なんかで命令から実際に答えが出るまでの命令サイクル数の事だったり

ＤＳＰ
　デジタル・シグナル・プロセッサ　の場合は信号処理用のMPUの事
　デジタル信号処理の事を言う場合もある

4:デフォルトの名無しさん
07/07/25 16:41:43
最近サウンドプログラミングに目を向け始めたんだけど
ソフトシンセに関して書かれた本とかってないの？

5:デフォルトの名無しさん
07/07/26 07:35:52
　　　　　　　　　　　 ,,.-‐'''"´￣￣￣｀`丶､
　　　　　　　　,,.-'"´　　　　　　　　　　　　｀`丶､
　　　　　　／　　　　:／　　　　.､　　　､　　　　　丶
　　　　　／　 :::.:/! :::/　:|. 　　　T:､_.:::.:ヽヽ.:::.:::　　ヽ
　　　　 /:/　::::ｌ:ｱ.:::/|.::::|! ::.:::.::: 　|.:::ｌ､.:::.::丶.:::.:::.:::.:::.　ヽ
　　　 /.::/　.:::.:ｌ|!.::/ .|.:::|!.:::.:::.:::.:::.:|:.:::ｌヽ.:::.:::.:ﾄ､.:::.:::.:::.:::.::::ｌ
　　　ｌ.::/! .:.:::.:::|!.:::|　 |.::|」 .:i:.:::.:::.::|.:::ﾒ､_ ヽ.::::ｌヽ.:::.:::.:::.i::.::ｌ
　　 .|::/ |:::::::::::::|!::| _,,.イ!_ヽ:::ｌ::::::::::|!ｿr　_二ﾆｧi- ｌ::::::::::::ｌ:ｌ:::ﾄ
　　 |!:ｌ　|::::::::::_,.ｨ匕.r=ﾃﾐ､ヽ:ｌ:::::::| !　イ于ミヽ､ |:::::::::::|ｱ!:|:ヽ　　　出席番号5番
　　ｌ!　 |::::::::､:::ｌ::|'´i'丿;;ヽ　ヽ::::| 　　l‐'´;;;::|!　`|:::/:::::ｌ|::ｌ:ｌt､::ｌ　　和泉亜子が5get
　　　!　　ﾄ､:::::ｌ::::ｌ! _|_::::::::_i!.　　ヾ!　　丶--≡‐､ｌ::ｲ::::/.｀l!ｌ::ｌ!ヽｌ
　　　　 |::ヽ:::ヽ:|.ｲ-'￣　　　丶　　　　　　　｀´ｿﾉ/::/　ﾉ!ヽ::ｌ　丶､
　　　　　.|:::::入:ヽヽ　　　　　　　　＿,,.--､　　　ｿｌ∠ｨ'ｌ´j　ヽ!
　　　　　|:／ヽヽヽ.Y-､_　「￣￣　　　ﾝ‐､ ,.イｿ/　.ﾚ'　　　!
　　　　 '´　　ヽ／_,,.-‐'''`L　　　　_,,.∠＿＿＼!ｌ/ 　 !
　　　　　,r─‐ｧ'´　　.-‐'''"ヽﾍ＿_/,⊥,,＿_　　　ヽr──‐-､
　　　／.|　　ヽ　　　 -‐'''"´┤　〉L＿＿　　　　/　　　　　　入
　　／　　ヽ　　＼　　　　 | 　 {　　　　　　　/　　　　　／　　ヽ

6:デフォルトの名無しさん
07/07/26 09:25:38
>>3
リアルタイムじゃなくてインタラクティブと呼ぶと良さげ

7:デフォルトの名無しさん
07/07/26 11:19:38
マルチメディアなスレみーっけ！

8:デフォルトの名無しさん
07/07/26 11:45:14
　　 __i.＼,／!_
　　ゝ, ''´⌒｀ヽ　　　
　　ﾉノメﾉﾊﾉ〉〉　　
　|＼ﾙﾘ!ﾟヮﾟﾉ∩　やっぱり最強なあたいが⑨ゲットよ！
　＼と)ｉ｀\´ｉノ　　
　 ∠ ,く／/ i ゝ
　　　'｀"!ﾝｨﾝ'´

9:デフォルトの名無しさん
07/07/28 22:35:32
とある音源Aと、イコライザなどを使いAの特定の部分の周波数を強調した音源Bから
周波数のどの部分が加工されたかを知るにはどうすればいいんでしょうか。

10:デフォルトの名無しさん
07/07/28 22:57:20
Spectrogram　を　PrintScreen　して　Photoshop　に　hariko　して　XOR　を掛ける

11:デフォルトの名無しさん
07/07/28 23:01:40
☆SHI☆NE☆YO☆

12:名無しさん＠そうだ選挙に行こう
07/07/29 07:42:58
周波数の強調などのフィルタは普通は線形だから
入力Ａ　出力Ｂ　フィルタF なら B = F*A

だからＦを求めて、このＦの周波数特性を求めるという事になる。

方法は
１、A,BをＦＦＴして、周波数軸上でB/Aを求める

２、適応フィルタ PARCORフィルタなどで、Ｆの近似値を求めて
　このＦの係数から特性を出したり、
　Ｆにホワイトノイズや周波数スイープを入れて特性を出す

13:名無しさん＠そうだ選挙に行こう
07/07/29 09:37:50
単純にB-AをやってからFFTして、
一番でかかった周波数帯を見れば良いんじゃないかしら？

14:名無しさん＠そうだ選挙に行こう
07/07/29 12:49:30
それは旨くゆかない。イコライザーなどはIIRフィルターなので、位相も変化してるし
FIRフィルターであっても、BとA間には遅延があるので B-Aではダメだよ

15:デフォルトの名無しさん
07/08/03 21:11:19
即死判定予防

16:デフォルトの名無しさん
07/08/03 22:32:46
サウンドカードの入出力を利用してオーディオ用のディジタルフィルタ（リアルタイム）を
実現してみたいので参考になるホームページお願いします。

17:デフォルトの名無しさん
07/08/04 08:42:33
基本的にサウンドカードの入出力でエフェクトするのは環境依存。

最近のマザー付属のものでは、入出力を同時に出来るものも増えてきてるけど
一昔前は、入出力を同時にすると、入力がそのままハード的に出力に出て来たりとかのが多かった。

２枚刺しなどで入力と出力を別ボードとなると、サンプリングレートの微妙なずれでだんだんとズレてゆく
あるいは１枚のものでもズレるものが多かった。

つまり、エフェクトするには、まず入出力でサンプリングが同期して、
かつ入出力がハード的に分離してるハードである事が条件だ。

それを解決していれば、あとはwindowsなら低レベルオーディオＡＰＩで　-->ヘルプ【低レベルオーディオの概要】

WAVEHDR 構造体を、in/out用に複数用意して　それをコールバックかメッセージ駆動で
順に再利用してやればいい。

C++でもDelphiでもそういうコンポーネントを１回作っておけば、後はとても楽チン

18:デフォルトの名無しさん
07/08/04 22:22:51
アドバイス有難うございます。
開発環境はBCC5.5.1（C言語）とWin32APIを使ってます。
ハードは比較的新しいマザーP5Bですので対応大丈夫と思います。
ただ、ゴーグル検索でオーディオ入出力を同時に行っているサンプルが見つからず？？？な状態です。
良いサンプル落ちてないですか？

19:デフォルトの名無しさん
07/08/05 11:41:57
たとえば、ここは２個用意して交互に利用してるけど、
URLﾘﾝｸ(www13.plala.or.jp)
こんな感じで２個３個を順に利用させる。
URLﾘﾝｸ(www7a.biglobe.ne.jp)

入力側も同じように、マルチバッファリングで処理する。

入力--WAVEHDRのマルチバッファリング-->FIFO-->出力のWAVEHDRのマルチバッファリング

プログラムの開始時は、
1waveOutPrepareHeade/waveInPrepareHeade で WAVEHDRを全部登録
2,waveOutPause
3,出力のWAVEHDRによるマルチバッファをwaveOutWriteで全部埋めて
4,入力のWAVEHDRによるマルチバッファを連続してwaveInAddBuffer
5,waveInStart

以後は、コールバックか窓メッセージで
最初の MM_WIM_DATA で waveOutRestar

入力はMM_WIM_DATA$3C0　出力はMM_WOM_DONE　$3BD
それぞれ　帰ってくる WAVEHDRを再利用する
片方ではFIFOに書き出し、片方ではFIFOから読み出す。
どっちかの処理でエフェクトをかければいい

20:18
07/08/05 16:44:55
>>19 すごい親切な方熱烈感謝です。
先ははるかに遠いですが、なんとなく流れの概要がつかめました
（全体の流れがつかめないとどうしようもないですから助かりました）
先ずは入力を出力に出すだけの音声スルーを実現にしたいと思います。

3.で出力用データが用意されてないのにwaveOutWriteしてますが、
出力用データはどうするのでしょうか？

MM_WIM_DATA、MM_WOM_DONE処理はこんな感じでよいですか？
*MM_WIM_DATAを受け取ったら、
最初のMM_WIM_DATA ならwaveOutRestartする
入力データに対するを処理する（エフェクト）
それFIFOに書き込む
受け取ったWAVEHDRをwaveInAddBufferする（WAVEHDRの再利用処理）

*MM_WOM_DONEを受け取ったら、
受け取ったWAVEHDRをwaveOutUnprepareHeaderする
出力データをFIFOから読み込み、受け取ったWAVEHDRのlpDataバッファに転送する
そのWAVEHDRをwaveOutPrepareHeaderする
waveOutWriteする

21:デフォルトの名無しさん
07/08/05 20:00:02
＞3.で出力用データが用意されてないのにwaveOutWriteしてますが

まあ途中のFIFOがいっぱいになってから、出力WAVEHDRを書いてもいいんだけど
＞入力--WAVEHDRのマルチバッファリング-->FIFO-->出力のWAVEHDRのマルチバッファリング
と、全部が遅延要素だから、出力側のマルチバッファリングにはゼロでも埋めて
出力をスタートしようって事

後はＯＫ

22:デフォルトの名無しさん
07/08/06 10:51:32
すみません。
wavOutWriteで2つ以上の波形をミックスした音を出したいのですが、合成のやり方がわかりません。
データは16ビットモノラルです。

char* buf1,buf2,out_buf;//元データ

short* in1 = (short*)buf1;
short* in2 = (short*)buf2;
short* Out = (short*)out_buf;

for(int i=0;i<BUFFER_SIZE/2;i++)
{
Out[i] = in1[i] + in2[i];
}

こんな風にすると、音割れが発生してしまいます。どうすればよいのでしょう。

23:デフォルトの名無しさん
07/08/06 11:04:15
そりゃぁ、単純に足しちゃダメだろ。安直にやるなら平均だけど、それで事が足りないなら調べて工夫すればいい。

24:デフォルトの名無しさん
07/08/06 14:18:20
>22
in1[i] + in2[i] の結果を -32768 ～ 32767 でクリップするだけでもだいぶマシになる。
真面目にやるならソースの音量を調整するなりコンプレッサつけるなりしないとダメ。

25:デフォルトの名無しさん
07/08/06 15:49:16
サウンドプログラムってやったことないおれがいいかげんレスすると
演算のオーバーフローで音割れ発生なら
Out[i] = in1[i]/2 + in2[i]/2;
や
int tmp = in1[i] + in2[i];
Out[i] = tmp/2;
したらどう？

26:デフォルトの名無しさん
07/08/06 16:14:25
>>25
それ、>23で指摘している平均ですから。

27:デフォルトの名無しさん
07/08/06 16:15:19
俺は夏の間だけ２乗平均するゼ

28:デフォルトの名無しさん
07/08/06 17:56:35
平均てか、オーバーフローしないように音量下げてるだけでしょ。

単純に足すの自体は正しいけど、フルボリュームの音２つ混ぜればレベルオーバーして割れる、ってあたりまえの話し。
割れないようにするには基本音量調節だけど、
クリップ処理はしといたほうがいい。でないとクリップしたとき醜いことになる。
整数処理の場合、混ぜた結果をクリップ処理するならshortじゃなくてlongとかで足し算しないとね。

29:デフォルトの名無しさん
07/08/06 18:11:40
色々と突っ込みどころだらけだな。

＞単純に足すの自体は正しいけど、フルボリュームの音２つ混ぜればレベルオーバーして割れる、ってあたりまえの話し。
「混ぜる」が「足す」であることが前提となっているが、「混ぜる」ことと「足す」ことはイコールではないぞ。
フルボリュームの音を足すとレベルオーバーするから、そうならないように混ぜないといけないという、当たり前の話だね。
×話し
○話

＞クリップ処理はしといたほうがいい。でないとクリップしたとき醜いことになる。
何が言いたい。字義通りに解釈すると、「クリップしないとクリップしたときに醜い」となって意味不明なのだが。

30:デフォルトの名無しさん
07/08/06 19:29:40
重箱の隅

31:デフォルトの名無しさん
07/08/06 19:36:32
隅の多い重箱だな

32:デフォルトの名無しさん
07/08/06 19:43:20
石頭

33:デフォルトの名無しさん
07/08/06 20:14:12
>28
アホだコイツｗ
レベルオーバーで割れるのはクリップしても割れるだろうが、嘘教えてんな
それを言うならオーバーフローだろボケ
用語は正しく使え、知らないなら黙ってろ

34:デフォルトの名無しさん
07/08/06 21:23:01
クリップ処理すればレベルオーバーしても割れないなんてだれも書いてないと思うけど、
とりあえず、君が正確な用語で簡潔に説明してやればいいんじゃない？

35:18
07/08/06 21:32:43
>>21 有難うございました。
また、質問すると思いますが、そのときはよろしくです。

36:デフォルトの名無しさん
07/08/06 23:15:12
>>25
細かいことだけど、CやC++の仕様ではintより短い整数型は演算中は自動的にintに格上げされるから、
intが32ビット以上の環境なら単純に Out[i] = (in1[i]/2 + in2[i])/2; と書いてもオーバーフローしないよ。
これは Out[i] = (int)(in1[i]/2 + in2[i])/2; とまったく同じ挙動になる。

37:36
07/08/06 23:17:48
コピペしたら /2 消し忘れた・・・orz
正しくは Out[i] = (in1[i] + in2[i])/2; と Out[i] = (int)(in1[i] + in2[i])/2; です。

38:デフォルトの名無しさん
07/08/06 23:20:06
>>36
それって仕様でなくて、処理系によるんでない？

39:デフォルトの名無しさん
07/08/06 23:36:17
てかシンプルなことなのに、やたら難しいことみたいにじれったいやりとりだなw

40:デフォルトの名無しさん
07/08/06 23:44:20
>>38
charやshortが被演算数になったときのintへの自動格上げはANSI Cの言語仕様だよ。
K&R第2版のA6.1節に書いてある。

41:デフォルトの名無しさん
07/08/07 01:55:28
自動作曲ソフトのようなものを作りたいです
そこでまず何を勉強すればいいですか？

42:デフォルトの名無しさん
07/08/07 01:56:32
midi(笑)

43:デフォルトの名無しさん
07/08/07 01:57:41
>>41
ｽﾚﾘﾝｸ(tech板)

44:デフォルトの名無しさん
07/08/10 13:03:58
音源Aが　波形x + 波形a
音源Bが　波形y + 波形a
で構成されている時、
A - B = (x + a) - (y + a) = x - y
でaを消す事が可能ですけど、逆にxとyを消してaだけで構成された音源を作る事は不可能ですよね？

45:デフォルトの名無しさん
07/08/10 13:13:09
変数が3つあって方程式が2つしかない場合、一般的に全ての変数は求まりません。

46:デフォルトの名無しさん
07/08/10 14:44:43
>>44
x と y が無相関なら、A, B の無相関化である程度の除去はできるかも。
x, y がそのままとりだせるかどうかは知らないけど。

47:デフォルトの名無しさん
07/08/10 15:23:04
歌がセンター定位である事を利用した　カラオケ器　なんてのが趣味の工作で流行ったけど

その逆にセンターの歌だけ取り出すのは　まだまだ無理だよ。
リアルタイムに音声認識⇒音声合成をやらないといけないからね

48:デフォルトの名無しさん
07/08/10 16:18:18
>>47
それは、センターにボーカル以外の音も混ざってるからでは。
左右の音の、ボーカル以外の部分が完全に無相関なら
結構いいせんで分離できると思う。

まあ、「完全に無相関」なんて仮定が通じるわけもなく、
結局、ボーカル抽出は音声認識的な技術も使わないと無理くさい
ってことだと思う。

49:デフォルトの名無しさん
07/08/10 16:55:02
完全に無相関かどうかは、この場合関係ないでしょ。

L(x)+S(x) と　R(x)+S(x)から、どうやってS(x)を分離するというのだい？

50:デフォルトの名無しさん
07/08/10 17:01:26
うん

51:デフォルトの名無しさん
07/08/10 17:29:44
相関ベースのブラインド信号処理でも、
2チャネルだと分離できるのは2信号までか。

52:デフォルトの名無しさん
07/08/11 00:34:44
歌声りっぷで同名ファイル選んで中央定位抽出できるけど
FFTでなんとかかんとか

53:デフォルトの名無しさん
07/08/11 00:53:48
ノーマルバージョンからカラオケバージョンを減算すればいいんじゃね

54:デフォルトの名無しさん
07/08/11 02:44:09
歌声りっぷでググれって

55:デフォルトの名無しさん
07/08/11 03:00:45
誰もツールの話なんかしてねー

56:デフォルトの名無しさん
07/08/11 03:48:49
FFTでなんとかかんとか

57:デフォルトの名無しさん
07/08/11 06:11:53
離散フーリエ変換なんて糞

58:デフォルトの名無しさん
07/08/11 07:52:14
>>57
具体的に書かないと、ただの「自分に判らないものは糞ってことにしておきたい人｣にしか見えませんよ。

59:デフォルトの名無しさん
07/08/11 07:59:34
A = a + x, B = b + x から得られるのは a - b, b - a しかないけれど、そのどちらかをFFTで何とか何とかすることにより、a + b の周波数が得られる。
あとは A + B = a + b + 2x = C, C - (a + b) = 2x, 2x / 2 = x で終了。

60:デフォルトの名無しさん
07/08/11 08:08:14
FFTを魔法の道具と思ってないかい？
a+b +2*x から、 2*x をどうやって消せるの？

それが出来るなら自動車の運転中の音声認識なんかに威力を発揮する大発明さ。
他にも、携帯電話で話者の声だけ取り出して送信するとか応用はすごいぞ。

大金持ちになれるチャンスだよ。　がんばれ

61:デフォルトの名無しさん
07/08/11 08:37:37
だから離散フーリエ変換なんて糞なんだよ。
アナログ回路最強。

62:デフォルトの名無しさん
07/08/11 12:36:56
DFT単体で考えてる人が多いな
あれはツールなんであって、何かと組み合わせんとね

で、到達方向が違うならビームフォーミングでいけるんちゃうの？と適当に言ってみる

63:デフォルトの名無しさん
07/08/11 14:36:32
>>62
ビームフォーミングって、分離の精度上げようと思うと、
>>51 あたりで言ってる相関ベースのブラインド信号処理になるんだけど、
マイク2本だと2音源までしか分離できないよ。

フーリエ変換でどうこうって言ってるのは、
a, b, x のそれぞれが、違う基本周波数のハーモニックトーンだとすると、
周波数領域でその倍音成分だけとれば分離できるかもって話かと。

64:デフォルトの名無しさん
07/08/11 20:18:37
>61
板違い

>63
ぶっちゃけ出来ないけどな。
そりゃソース次第では出来るだろうけど、汎用は出来ない。

65:デフォルトの名無しさん
07/08/12 14:58:50

555 名前：名無しさん＠そうだ選挙に行こう投稿日：2005/09/11(日) 07:27:19
簡単そうに見えて簡単に出来ない事がある

１．CDをかけるとカラオケで再生してくれるプレイヤーってあるよね。
　　逆に歌手だけ抜き出すってのも簡単？

２．アナログ時代の電話線のエコーキャンセラーってあったよね？あれと同じで
　ビデオカメラにメカノイズが載るのはカメラ上に別のマイクつけて適応処理したら簡単に消せるよね？

３．最近３Dサウンドってあるよね。　2スピーカーなのにヘリコプターが立体的に飛び回って聞こえるよ。
　　だから、狭い間隔でおいた２スピーカーを広げて置いたように聞かせるのも簡単だよね

４．ホール効果とか残響のある部屋を再現する機能がついてるじゃん。　アレの逆でさ
　　残響の多い部屋から残響を消すのは、マイク付ければ簡単だろ？
　　マイクで部屋の特性取りながら逆位相の信号を足せばいいだけだろ？

---------------------------
前スレにあった話の、この１の問題だね。　この４つとも、とても難しいのだけど、難しさを説明するのも難しい

66:デフォルトの名無しさん
07/08/12 17:08:41
ボーカルのみを消去するソフトがあったけど、出来はどんなもんだろ？

67:デフォルトの名無しさん
07/08/12 17:50:19
ヒロフのやつ？

68:デフォルトの名無しさん
07/08/13 03:46:01
>>55
FFTで中央定位抽出が一応出来る
どうやってるかはしらん

69:デフォルトの名無しさん
07/08/13 04:23:58
誰もツールの話なんかしてねー

70:デフォルトの名無しさん
07/08/13 10:15:09
定位が中央、右、左の3点だけって状態はまずない、ってので説明終わりにならない？

71:デフォルトの名無しさん
07/08/13 10:34:47
無理だろうな
L(t) := A1*sin(w1t+C1)*D(r1*t,T1) + A0*sin(w0t+C0)*D(r0*t,T0)
R(t) := A2*sin(w2t+C2)*D(r2*t,T2) + A0*sin(w0t+C0)*D(r0*t,T0) 関数Dはアタック＋リリース

みたいな単純モデルがタマタマあてはあまるなら別だろうけど

72:デフォルトの名無しさん
07/08/13 15:33:02
動的フィルタ使えば？　このあいだAESとかいう学会で展示されてたのが単純な仕組みでなかなかの効果だったよ。

73:デフォルトの名無しさん
07/08/14 06:32:06
動的フィルタってどうゆうの？

74:デフォルトの名無しさん
07/08/14 06:54:00
えっ

75:デフォルトの名無しさん
07/08/16 13:25:50
>>73
Adaptive Filter のことかな。
入力によって、係数をどんどん更新していくようなタイプのフィルタ。

伝播路推定とか、音源推定に使えたりするんで、
それで、音源分離しようって話かも。
もちろん、入力信号の種類にまったく過程を置かない場合は
2マイクだと2信号までしか分離できないんだけど、
ある程度、信号が独立だとか、基底周波数が違うとかの条件があればいい線いくかも。

76:デフォルトの名無しさん
07/08/16 21:28:08
東京から大阪まで行きたいんだ
↓
新幹線使うといいよ
↓
電車ってのに乗るといいらしいよ

そんな流れ…？

77:デフォルトの名無しさん
07/08/17 14:01:38
目的地は大阪じゃなく月だな

78:デフォルトの名無しさん
07/08/17 14:12:55
まあ、今の所不可能という点じゃ火星に有人飛行くらいじゃないかな

79:デフォルトの名無しさん
07/08/17 16:57:03
遠いお星に行きたいよ
↓
ロケット使えば何とかなるかもよ、でも難しい
↓
ちょっとそこで目をつぶって拝んでろ

80:デフォルトの名無しさん
07/08/17 17:15:15
そして79は星になった

81:デフォルトの名無しさん
07/08/17 18:22:38
２信号ってのは、f1(t) と f2(t) の２信号が

L = L1 * f1(t) + L2 * f2(t)
R = R1 * f1(t) + R2 * f2(t) という関係になって L1..R2が定数（畳み込み）なら分離出来るか

というような問題　って事？

82:デフォルトの名無しさん
07/08/20 22:40:29
フーリエ変換ってものすごく簡単なことなんだろうけど、大學の教科書のわざわざアホみたいに難しい形に書いてる数式見たらやる気なくします(^^)

83:デフォルトの名無しさん
07/08/20 22:42:42
一応、理論自体はそれなりに難しいと思うがな。

84:デフォルトの名無しさん
07/08/20 22:43:38
理論をちゃんと理解できてる人の方が少ないと思う

85:デフォルトの名無しさん
07/08/21 00:22:06
あの難しい形の式も、数学の発展には大きく寄与してるのよ。
音響関係ではというか、工学系ではあんまり役に立たないけど、
理学系、特に数学科とかにいくとあれが必須。

86:デフォルトの名無しさん
07/08/21 00:56:53
直交変換（とその考え方）は工学系全般で役に立ちまくってるがな

87:デフォルトの名無しさん
07/08/21 04:18:24
>>86
ここの先生連中は正規直交基底については博士級の知識がある。
直交基底を用いた変換を理解しないで音プログラムは開発できないからな。

88:デフォルトの名無しさん
07/08/21 05:34:25
博士級（笑）

89:デフォルトの名無しさん
07/08/21 06:56:05
...を理解しないで音プログラムは開発できない？
どんだけ狭い意味での音プログラムなのさ

90:デフォルトの名無しさん
07/08/21 09:17:06
直交（笑）座標変換

91:デフォルトの名無しさん
07/08/21 09:35:10
>>82
ミクシンスキーの演算子法なんて読んでないなら読むといいかも

92:デフォルトの名無しさん
07/08/21 10:05:26
直交基底の説明ってなんで揃いも揃ってあんなに日本語が不自由なんですか。
国語能力に優れている人間だけが数学に関する書物を書けるようにする法律を作るべきだと思います。
あと、数学に非直観的でわけわからん記号を導入した人間や、人間の名前を法則につけた人間も死刑。
そして、心理学や人間工学の見地から数学記号のデザインを一新するべきですね。
あんなアリの這ったようなギリシャ文字は人類の負の遺産ですよ。

93:デフォルトの名無しさん
07/08/21 10:35:55
必要は発明の母と申しますが

改善点を見つけられた貴方は幸せですね。
直交基底の判り易い日本語説明をすれば、きっと大ヒット間違い無しですよ
そして人間工学に基づいた数学記号のデザインを一新すればきっと神と崇められますよ。

これは発案者の貴方の権利であり義務ですから私たちは見てるだけしか出来ませんが
頑張って下さいね。　

94:デフォルトの名無しさん
07/08/21 11:32:28
「オレが理解できないのはあんたの説明が悪いからだ！」と堂々と言うのは最近の風潮だねえ。
その図太さが羨ましくもある今日この頃…

日本語で書かれた理工学書の分け分からん度の高さには同意ですが、
己の意識改善も必要だと思いますよ。

金谷さんの本なんかは結構噛み砕いて書いてあるんで読んでみたらどう？

95:デフォルトの名無しさん
07/08/21 12:12:57
"最近の風潮"ではない。2chは当初からそういう風潮

96:デフォルトの名無しさん
07/08/21 12:20:04
内積・外積とか直交基底とか、ネーミングセンスゼロだな
大昔のオッサンが勝手に決めた不可解な和訳の用語をそのまま現代でも使っていいものか
異議を唱える者は居ないのか

97:デフォルトの名無しさん
07/08/21 12:40:51
>>96 そりゃ皆んなその言葉で考えたり仕事したりしてるからね。
新人は常に少数派だから、受け入れるのが普通。

圧力単位を急にパスカルに変えられても、水柱につい換算してしまうように、変更にはコストが伴うからね。

まあ、あなたが素晴らしい小学生でも高等概念が身に付くような総合入門書を作れば皆んな解決

98:デフォルトの名無しさん
07/08/21 12:57:43
素晴らしい小学生でも

99:デフォルトの名無しさん
07/08/21 13:16:39
クソネーミングをした大昔のオッサンは大罪人だな
後の人間のことを考えない自分勝手な考えでつけた名前のせいでみんなが迷惑している

100:デフォルトの名無しさん
07/08/21 13:30:35
あ、そのみんなってどこにいるの？

101:デフォルトの名無しさん
07/08/21 13:32:44
物理学において、最大の罪人は電流の向きを決めた香具師だと思うんだ。
もし逆にしておいてくれたら電子の流れと同じ向きになってどれだけ理解しやすかったことか。

102:デフォルトの名無しさん
07/08/21 13:55:49
それはそれで頭が固くならなくていいじゃない。
begin ～ end を嫌う { ～ } 派じゃあるまいし

103:デフォルトの名無しさん
07/08/21 14:07:08
if (...)
end
...;
begin
って書いてあったら嫌だけどなぁ。

104:デフォルトの名無しさん
07/08/21 14:49:08
ほほう
それはどういうコードかね

105:デフォルトの名無しさん
07/08/21 14:58:41
なんだこのスレ

106:デフォルトの名無しさん
07/08/21 15:31:06
摂氏は当初の様に0度を水の沸点とし、100度を水の凝固点にすべきだ！！！！１１！！！！１！！

107:デフォルトの名無しさん
07/08/21 15:38:30
摂氏ｲﾗﾈ
1リットル=1キログラムとか、なんでもかんでも水中心て

108:デフォルトの名無しさん
07/08/21 15:47:55
博士級だかなんだか知らんが、数学や理論一辺倒の人ばっかりで
人の耳で聴く音を扱うソフトウェア書いてなさそう

109:デフォルトの名無しさん
07/08/21 15:53:37
理論のないサウンドプログラミングってどんなん？

アナログ回帰？

110:デフォルトの名無しさん
07/08/21 16:23:09
アナログフィルタも理論バリバリじゃん

111:デフォルトの名無しさん
07/08/21 17:35:36
フーリエってどの学年で習うんでしょう？　高校？大学？
高校で、統計と確率を勉強しなかったのが悔やまれる。

112:デフォルトの名無しさん
07/08/21 18:01:33
今勉強すれば悔やまなくてもよくなるよ

113:デフォルトの名無しさん
07/08/21 18:20:16
高2だけどフーリエ習ったよ

114:デフォルトの名無しさん
07/08/21 18:41:33
理論はもちろん必要だけど、
感覚的なものを扱うのに理論一辺倒じゃろくなもん作れんってことですよ

115:デフォルトの名無しさん
07/08/21 19:18:33
>>114
失礼を承知で申し上げますが、そのまま逆にも同じことが言えます。
感覚的なものだけで音のプログラミングができれば皆さん苦労しません。

スレの主旨もアルゴリズムに関わる議論なはずですよね？

不毛な煽り合いはエネルギーの無駄な気がします。

116:デフォルトの名無しさん
07/08/21 19:33:47
音吉陽一を思い出した

117:デフォルトの名無しさん
07/08/21 20:20:02
なんかずれてるけどまあいいや

118:デフォルトの名無しさん
07/08/21 21:04:52
え？あっ！
俺のカツラずれてるのなんで分かった！？

119:デフォルトの名無しさん
07/08/21 21:31:53
面白くないよ

120:デフォルトの名無しさん
07/08/21 21:38:54
115が不毛といったとこで確信したよ

121:デフォルトの名無しさん
07/08/21 21:43:49
何を？

122:デフォルトの名無しさん
07/08/21 21:52:57
だからズラだよもう

123:デフォルトの名無しさん
07/08/21 21:54:09
あ、なるほどね

124:デフォルトの名無しさん
07/08/23 00:22:33
>>113
今はフーリエって高校で習うのか.....
ということは、内積・外積・直交基底なんかも高校で習てるってことか
ひょっとしてZ変換やマキシマムエントロピーメソッド(MEM)も優秀な工業高校なら教えてるのかな？
なら、ゆとり世代って、超すごないな

125:デフォルトの名無しさん
07/08/23 16:03:42
SoundEngine FreeっていうFreeのWave編集ソフトにある
マスタリングプロセスCV制限ってどういった処理をしてるんでしょう ?

126:デフォルトの名無しさん
07/08/24 19:02:20
スレ違いじゃないか？
実際にどうゆう処理をしてるかは作者に聞かなきゃわからないだろうし。

127:デフォルトの名無しさん
07/08/24 19:07:32
どうでもいいけど、そのCV制限とやらのCVって何？

128:デフォルトの名無しさん
07/08/25 02:03:06
Constant Voltage(定流電圧)のことだろうなぁ

129:デフォルトの名無しさん
07/08/25 10:55:48
"定流電圧" に一致するページは見つかりませんでした。

130:デフォルトの名無しさん
07/08/25 11:11:36
定電圧
定電流

131:デフォルトの名無しさん
07/08/25 11:32:02
conは女性性器の俗称

132:デフォルトの名無しさん
07/08/31 19:36:44
FFTAnalyzerというwaveファイルのスペクトラムを表示してくれるソフトがあるんだけど↓

URLﾘﾝｸ(www2.tky.3web.ne.jp)

残念なのはシェアウェアという点なんだよね。フリーウェアで似たようなスペクトラムを
表示してくれるツールって無いだろうか？

133:デフォルトの名無しさん
07/08/31 21:19:49
ここはいつからツールのスレになったんだ？

134:デフォルトの名無しさん
07/08/31 21:23:00
Audacity

135:デフォルトの名無しさん
07/08/31 21:58:47
>>134
サンクス（ ´∀｀）

136:（ ´∀｀）
07/09/01 00:13:16
( ´∀｀)ノ
16bitの音用濾波器の係数ってfloat,doubleのどちっがいいの？
みんなはどっちつかてるの？

137:デフォルトの名無しさん
07/09/01 01:29:57
doubleのどちっ

138:デフォルトの名無しさん
07/09/01 07:41:14
FIRでもIIRでもフィルタの係数なら単精度で十分

IIRの場合は帰還用メモリは倍精度が欲しいのと

ただ、IIRの構成によっては (1-w) のようなのをそのまま持たせないなら wは単精度でも (1-w)は倍精度欲しい
でも wのまま掛け算させたらいいと思うけどな

139:デフォルトの名無しさん
07/09/03 18:08:49
MP3をWAVに変換するデコーダを作ってるのですが、
ID3タグの情報をWAVのチャンクに収めたいと思います。
ID3を入れるチャンク名などは仕様で決まってるのでしょうか？

140:デフォルトの名無しさん
07/09/03 18:44:01
ああ、ここは「音楽」ではなく、ただの「音」のプログラムをするスレでしたか。
スレ違いすみませんでした。

141:デフォルトの名無しさん
07/09/03 19:24:13
>>139-140
URLﾘﾝｸ(www.geocities.co.jp)

142:デフォルトの名無しさん
07/09/03 20:07:29
仮にミュージックプログラミングだとすると、純粋に音芸的な話になったり、
あるいは自動で曲をつくｔｔあｒい

143:デフォルトの名無しさん
07/09/03 20:42:44
いやDTM板を教えてやりなよ

144:（ ´∀｀）
07/09/03 21:02:59
( ´∀｀)ノ
>>138　非常感謝
あいやー、おら、doubleでしてたよ

145:デフォルトの名無しさん
07/09/03 21:50:15
別に全部doubleでも全然問題ないよ

146:（ ´∀｀）
07/09/03 22:27:50
( ´∀｀)ノ
>>145
floatに比べでぶでのろまにならないの？

147:デフォルトの名無しさん
07/09/03 22:40:33
実測すれば済む事。
些細な事だ。

148:デフォルトの名無しさん
07/09/03 23:38:01
むしろVCなんかだと
floatを勝手にDoubleに最適化しやがったりするしな

149:デフォルトの名無しさん
07/09/04 01:59:06
CPU的にdoubleの方が速けりゃその方がいいだろ

150:デフォルトの名無しさん
07/09/04 06:39:59
やってみればわかる事。　きっとメモリが少ない方が勝つよ

151:デフォルトの名無しさん
07/09/04 10:42:55
intel系CPUなら浮動小数点命令は確か80bitだし、
メモリへのアクセスもキャッシュ効くから、フィルタの係数程度なら目に見えての差は出ないと思われ。

152:デフォルトの名無しさん
07/09/04 12:45:17
だったらdoubleでいいや
実測しても全然かわらんかったというか
コンパイラがdoubleにしやがるし

153:デフォルトの名無しさん
07/09/04 15:42:41
処がだ、SSE命令における浮動小数点ニモニックは64/32ビットしかないんだな。
でもって、超越関数を使わない限り基本的にはFPUなんて要らないから最近のコンパイラは
80ビットニモニックは殆ど使わなくなっていたりするわけで。
勿論、ベクタ化を期待するようなパフォーマンスを目的とするなら、2並列より4並列の方がずっと
速いからfloatで済むならそれに越したことはないし。
# ということで、簡単なサンプルで速い遅いと言っても無駄。

154:デフォルトの名無しさん
07/09/04 16:16:38
いや、そう主張するならそれでもいいけど
精度はやっぱり下がるしさ
SSEの4並列を使うのは、コンパイラの最適化程度では期待できないでしょ

というわけで、自分でアセンブリ書かない人はdoubleでいいお

自分でアセンブリ書いて完璧にSSEで最適化できて精度いらん人はfloatでいいじゃん

155:デフォルトの名無しさん
07/09/04 16:35:36
>>154
iccでもgccでも最適化でベクタ化できるけど?

156:デフォルトの名無しさん
07/09/04 17:07:26
>>155
ちゃんとコード全体をうまく並び替えてコンパイラが4列使い切っているかってことだろ

で、結局、人間がちゃんと4列使い切るような書き方をしてやらんと効率悪いってことだろ

157:デフォルトの名無しさん
07/09/04 17:08:36
まあ、普通はdoubleで何も問題ない
floatでも特に問題はない

で、精度が高いのはdouble

158:デフォルトの名無しさん
07/09/04 17:08:44
>>154
基本的に精度が何ビット必要かという視点の方が大事だと思うよ
16bit入力のFIRフィルタなら　doubleはあきらかに無駄でしょ

159:デフォルトの名無しさん
07/09/04 17:12:58
>>158
んなことねーよ
作業中の演算精度が高くて少なくとも時間以外の損は無い

160:デフォルトの名無しさん
07/09/04 17:14:44
まあ、0から255までの結果しかいらないやつで
わざわざintを使わず演算するやつもいないしな

161:デフォルトの名無しさん
07/09/04 17:15:24
結論

・それぞれ好きにやれ

162:デフォルトの名無しさん
07/09/04 17:54:50
>>159
メモリサイズも当然違ってくるだろ。
あと、パソコン以外の環境にも移動させ易いのは大きなメリットだよ

163:デフォルトの名無しさん
07/09/04 17:57:37
逆に言えば、PC環境では全く問題ないってことだろそれ

164:デフォルトの名無しさん
07/09/04 17:59:30
もう、>>161が結論でいいよもう

165:デフォルトの名無しさん
07/09/04 18:34:04
確かに
FADD命令　レイテンシ3、スループット1/サイクル
FMUL命令　レイテンシ5、スループット1/2サイクル1,2
FDIV命令　レイテンシ-単精度17サイクル、倍精度36サイクル、拡張精度56サイクル

割算以外では単精度にしても早くならないね。

166:デフォルトの名無しさん
07/09/05 08:01:46
>153
お前の使ってるコンパイラが世の全てだと思ってるなら大間違い。

>157,>161でFAだな。

167:デフォルトの名無しさん
07/09/05 08:32:08
>>165
今がそうだとしても、過去そうでなかったし、
将来　単精度ならレイテンシが短くなるかもしれないし、
使ってるコンパイラが将来SSE命令をサポートするかもしれない。

何でも倍精度は楽かもしれないが、不必要に使うのはどうかと思う。
IIRならともかく、16bit入力16bit出力のFIRで倍精度にするメリットはまったくないのだから

168:デフォルトの名無しさん
07/09/05 10:08:36
>>167
将来doubleならレイテンシが短くなるかもしれない可能性もあるし、
将来も入出力が整数型16bitであり続ける保証も無いんだが？
今現在だって入出力形式でfloatはありうる。

未来の仮定の話をしたいのか、現状の話をしたいのかターゲットくらい絞れ。

169:デフォルトの名無しさん
07/09/05 10:48:55
単精度だ倍精度だと騒げるのが羨ましいよ。ホント贅沢な悩みだと思うよ
MP3あたりだと16ビット、高級なもので24bit　DSPの世界はまだそんなもの

170:デフォルトの名無しさん
07/09/05 11:05:00
FA

>>161

171:デフォルトの名無しさん
07/09/06 14:40:54
なんかよう分からんけど、これ関係してる？
URLﾘﾝｸ(www.pro.or.jp)

172:デフォルトの名無しさん
07/09/06 15:59:25
>>171
＞ほとんどのＣでは、float型よりdouble型で計算した方が数倍高速になります
といいながら　基準にしてるのは SPARCだけ

SPARCは倍精度どころか128bit幅の浮動小数点演算器を持っているわけで
それを基準にするというのもどうかと思うよ。

ゲーム機や組込用のCPUのコンパイラの殆どは当然のように単精度が早い。

173:デフォルトの名無しさん
07/09/06 19:56:17
>ゲーム機や組込用のCPUのコンパイラの殆どは当然のように単精度が早い。
そもそも浮動小数点演算装置がなかったり(全部ソフト）倍精度はソフトとかそんなのばっかりだからね
倍精度がハードウェア実装されている今時のCPUだとメモリアクセスが律速になることはあるかもしれないけど
double,floatどちらもそれほど速度に違いはでないよ。（int,double,floatの間を行ったり来たりするような型変換する方が単純な演算より遅いし）

結論としちゃ、自分が使いたいターゲットで使い易い型を使うってことでいいんじゃないの？

174:デフォルトの名無しさん
07/09/06 20:54:08
それでも IIRフィルタの遅延器は単精度では厳しいからなあ
計算方法を工夫すればある程度カバー出来るけど

175:（ ´∀｀）
07/09/06 21:05:28
( ´∀｀)ノ
先生！
IIRフィルタの遅延器って、なんで高い精度必要なんですか？
精度低いとどうなるのですか？

176:デフォルトの名無しさん
07/09/06 21:08:27
無限インパルス応答だから

177:デフォルトの名無しさん
07/09/06 23:58:36
フィードバック＝計算誤差が累積
でもま普通は（要求がシビアでなけりゃ）単精度でも十分じゃない？

178:デフォルトの名無しさん
07/09/07 00:09:54
なんでもいいよ
場合によっては固定小数点数でも可

179:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/07 16:35:54
>171
この人こんな記事書いてたのか、ターゲット絞れないバカの典型だな。
用途や環境にあわせられない奴は最適化語るなよ・・・

181:最早厭われてはいるが
07/09/07 22:19:07
>>180
あの本を書いた時点で既に、自称翁だ。バカだなんてとんでもない。年寄りは労われ。

182:デフォルトの名無しさん
07/09/08 03:05:32
多少配慮足らずでも、誰かの参考にはなる記事をネット上で公開してるんだし
それをバカの典型と言い切れるやつよりは敬われる権利あるよ。

183:デフォルトの名無しさん
07/09/08 06:29:03
90年台に「floatよりdoubleの方が速い」とか嘘かかれても、参考にならないと思いまーすｗ
ましてや「敬われる」とかありえませーんｗｗｗ

184:デフォルトの名無しさん
07/09/08 06:41:17
floatよりdoubleの方が速いって言うのは、昔のプロセッサはfloatを内部で動的にdoubleに変換してたからだろ。
今はそういうのが無いからどう考えてもfloatの方が速いし、データが短い分キャッシュにも残りやすいから最適化も効き易い。

185:デフォルトの名無しさん
07/09/08 07:25:16
どうでもいい。結局処理系による。
つか180の食いつきかた見ry

186:デフォルトの名無しさん
07/09/08 07:33:02
うちのMacBook Pro (CoreDuo 2.0GHz) で試してみたけど、
floatよりdoubleのほうが速いぉ。

187:デフォルトの名無しさん
07/09/08 07:34:34
Mac（笑）

188:デフォルトの名無しさん
07/09/08 07:41:17
>>184
専用機はしらないけど、96年当時主流だったインテルもモトローラも内部80bitだよ。
内部で動的にdoubleに変換してる石って何？

189:デフォルトの名無しさん
07/09/08 07:42:30
>>179 2次でノイズが出るのは　リミットサイクルって現象だろ？

なんかリミットサイクルの出ないフィルタとか論文があるけど、理解出来ないんだよな

190:デフォルトの名無しさん
07/09/08 08:09:02
>>188
内部80bitの場合も、floatよりdoubleの方がしばしば速い。
で、翁が想定しているのはSparcとx86だろ。

191:デフォルトの名無しさん
07/09/08 10:37:39
処理速度が問題になるほどのタップ数の多い FIRフィルタならキャッシュに収まるかどうかの方が
速度を決めてしまうと思うけどな　命令サイクルがギガに対してメモリは1桁下なんだから

192:（ ´∀｀）
07/09/08 13:21:01
( ´∀｀)ノ
>>175-179 先生、有難うございました。
無限インパルス応答だからの回答に超感動しました。
精度が低いと、無限の過去の影響を細かく現代に反映できない。反映できないものは誤差として累積され、
現代を惑わす魍魎を生み出すことになる。怖いですね。

193:デフォルトの名無しさん
07/09/08 14:48:57
double が速いのはC言語の math.h が double に対してしか定義されていなかったり、
自動昇格が多数発生するためでしょ

x87 の FPU は内部で 80bit に昇格するのがデフォだけど、それにしたって内部精度は命令を
発行して設定できるわけで、慎重に書かれたソースなら当時から float の方が速かったよ

194:デフォルトの名無しさん
07/09/08 15:11:02
今ならc99のお蔭でhypotf()なんかが使えるからねぇ。

195:デフォルトの名無しさん
07/09/08 15:30:39
今がどうだとか昔はどうだとかこのCPUではとかいつまでやってんだ？馬鹿馬鹿しい

196:デフォルトの名無しさん
07/09/08 17:58:56
>>161

197:デフォルトの名無しさん
07/09/08 18:14:47
>>195 じゃネタだしてよ。　>>189の話を膨らませるとかさ

198:デフォルトの名無しさん
07/09/08 18:21:01
>>197
じゃあ>>189の話を膨らませろ馬鹿

199:デフォルトの名無しさん
07/09/08 20:23:28
ようし、じゃグーグルさん使ってふくらませるぞ。

リミットサイクル＋フィルタ　でポチっとな
URLﾘﾝｸ(www38.tok2.com)
＞ＩＩＲなんかでフィルタ等の信号処理をすると３８４ｋＦｓだと係数語調は３２ビットでは
＞低域でリミットサイクルによる発振現象の影響が出てきますので不足で４８ビットもしくは６４ビット必要になりますな。
なるほどな。　

お！これだ
URLﾘﾝｸ(www.mk.ecei.tohoku.ac.jp)
＞リミットサイクルのない感度最小形ディジタルフィルタの合成

えと？　状態空間ディジタルフィルタ？　って何？　もいちどグーグルさんお願い。ポチっとな

カルマンフィルタ？　いや応用カルマンフィルタって本は持ってるんだが・・・・こりゃ退散だ

200:（ ´∀｀）
07/09/12 21:38:18
( ´∀｀)ノ、先生
WindowsメッセージMM_WIM_DATA（録音バッファの録音完了）を受けての処理手順について何ですけど
下記の1,2のどちらが正しいですか？　

1.waveInUnprepareHeader,waveInPrepareHeaderを用いる
// 録音バッファの登録解除
waveInUnprepareHeader

録音データ、lpDataを処理する

// 録音バッファの再登録
waveInPrepareHeader
waveInAddBuffer

2.waveInUnprepareHeader,waveInPrepareHeaderを用いない
録音データ、lpDataを処理する

// 録音バッファの再登録
waveInAddBuffer

201:デフォルトの名無しさん
07/09/13 07:32:05
>>200 さあ？　どっちが正しいかはしらないけど　２でやってて不具合にあたった事はないな

202:（ ´∀｀）
07/09/16 12:46:06
( ´∀｀)ノ
>>201、先生、ども、ども、有難うございました。そっそうなんですか...
なんか、waveInもwaveOut処理同様に>>200の1.のようにするのが正しいのかなと思たですけど

203:デフォルトの名無しさん
07/09/16 13:16:46
URLﾘﾝｸ(up2.viploader.net)

204:デフォルトの名無しさん
07/09/16 13:42:54
>>203
毎年見れば無問題

205:デフォルトの名無しさん
07/09/16 13:50:12
それなんて3年峠？

206:デフォルトの名無しさん
07/09/16 14:35:02
どうして周波数が低いと大きな音を出すのに、高周波と比べて指数的に高いエネルギーが必要なの？
蝸牛が低音を捕らえようとするとどうしても指数的に音量が小さくなってしまうからなの？
だったら低音は凄く耳に悪いね。難聴の原因だ。

207:デフォルトの名無しさん
07/09/16 15:58:19
動かす媒質の量

208:デフォルトの名無しさん
07/09/16 16:34:37
同じエネルギーを出すのに低いほどストロークが必要という事じゃないて
同じエネルギーを与えても、小さく感じるという事ならその通り
URLﾘﾝｸ(www.yacmo.co.jp)

209:デフォルトの名無しさん
07/09/17 00:58:06
１００人飛べる大縄跳びで二重飛びしようとするとものすごく大変なのと一緒・・・ではないな

210:デフォルトの名無しさん
07/09/17 01:52:12
>>207
マジレスありがとう。
1Hzで動く量と100Hzで動く量が違うのは当たり前ですね。

211:デフォルトの名無しさん
07/09/18 06:37:18
>206
真面目に低音は耳に悪いので注意。
スピーカー飛ばす原因も低音の出力が高すぎるってのが多いし。

212:デフォルトの名無しさん
07/09/18 07:12:34
スピーカーが飛ぶのは２つの現象

電力は電流*電圧だけど、ボイスコイルは、コイルと名前が付くようにL成分を持ってるから
同じ電圧振幅でも電流は低周波程流れてしまう。　発熱は電流の２乗に比例するので、低音程　焼損し易い

また、コントロールして同じV*Aを与えたとしても、ボイスコイルには質量があるから
同じV*Aを与えても振幅は低周波程大きくなる。　結果、大振幅で可動域を外れ物理的に変形してしまう。

213:デフォルトの名無しさん
07/10/05 21:15:13
waveOutOpenの引数にコールバックを指定した場合、waveOutProcはスレッドセーフっぽくないんですが。
なんか現在のスレッドの処理に割り込んで呼び出されませんか？
WM_DONEで再びWaveOutWriteしようとするとかなりの割合でスタックが破壊されています。

214:デフォルトの名無しさん
07/10/06 10:20:53
手順が間違ってる

215:デフォルトの名無しさん
07/10/06 13:40:55
>>213
そういうもんだよ。
waveOutProcはスレッドセーフじゃないと、しっかり覚えておくといいんじゃない。

216:デフォルトの名無しさん
07/10/07 01:54:40
どこにもスレッドに関わることが書かれてなかったような気がするんですが、スレッドセーフではないんですね
サウンド関連の生APIはむずかしいです

217:デフォルトの名無しさん
07/10/07 05:24:12
でもそんなの関係ねぇ

218:デフォルトの名無しさん
07/10/07 14:00:21
>>216
サウンド関連の生APIはむずかしいです
じゃなく
APIでプログラム作るのはとてもむずかしいです
が正しい。

219:デフォルトの名無しさん
07/10/08 20:27:23
極めてどうでもいい揚げ足取りだな

220:デフォルトの名無しさん
07/10/08 22:02:30
>>212
ブラウン管モニタを壊すにはデバイスドライバレベルでの制御が必要だけど
ひょっとすると、スピーカーはユーザープログラムで壊せてしまう可能性がある?
超低周波を出すとか、DCオフセットをかけ続けるとか。

221:デフォルトの名無しさん
07/10/08 22:09:13
ドライバレベルで保護してないかな。してなきゃまずいね。

222:デフォルトの名無しさん
07/10/08 22:26:59
ユーザープログラムも何も
曲作ってるときうっかり変な音を鳴らしてスピーカ飛ばすって時々あるもんじゃないの？

223:デフォルトの名無しさん
07/10/08 22:51:08
ない

224:デフォルトの名無しさん
07/10/08 23:03:21
俺もそんなに詳しいわけじゃないが、もちっとだけアナログの勉強をしてもいいと思うんだ。

スピーカーが飛ぶのは>212にあるようにスピーカーが想定以上の入力を受けた時。
なので出力波形だけでなく、アンプのパワーやボリュームによる所が大きい。

225:デフォルトの名無しさん
07/10/08 23:16:44
>>220
直流を通すオーディオアンプなんてほとんど存在しないだろ。
アンプにデジタルで直結したとしても、
普通はスピーカ出力の直前にコンデンサが入ってたりしてHPF特性がかかるから、
スピーカに超低周波や直流がかかることはない。

226:デフォルトの名無しさん
07/10/08 23:22:58
ああ、でも、直流そのものは通さないとしても、
ステップ関数とかガンと入れられたら階段部分はスピーカ的に結構きついかもな。

次ページ