サウンドプログラミング6 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
落ちていたので立てました。
テンプレ等はお願いします。 エイリアスノイズってオーバーサンプリングしてLPF掛けるしかない?
それとも保管してからLPFかけても出来るの? ノイズの周波数が必要な周波数より低ければ取れると思うけど。
「エイリアスノイズ」の意味を取り違っているなんて事はないですよね。 てか>>26が何を言ってるのか分からないから誰もまともに返答できない
既にエイリアスノイズが乗ってる信号をどうにかしたいという話なら
ノイズが必要な帯域外にあることが分かってるならLPFやHPFやBPFでなんとか出来るかもしれないけど ものすごく初歩的で原始的な質問ですが、
2つのPCMデータ(A,B)をミックスして1つのPCMデータ(C)にするとき
上限下限を超えないように処理するには、平均を取ればいいのですか?
それだと、PCMデータ(C)を鳴らしたときに聞こえるPCMデータ(A)の音は
PCMデータ(A)を単体で鳴らしたときの半分の音量になってしまわないでしょうか?
PCMデータ(B)が仮にほぼ無音に近いものだったとしたら、ミックスすることで音量が半分になるのはおかしくないでしょうか? >>30
レスありがとうございます
実際のところ、一音毎にサンプリングされたピアノの音(88個)をシーケンス情報を元にミックスしてPCMデータ化したいと思っています。
一音一音の振幅の最大は70%くらいなので、数音混ぜるだけでかなり頻繁に飽和が発生し、時には100%張り付きの状態が発生し、とても聴くに堪えない音になりそうです。
二つあるいは複数の音を混ぜるという単純な処理でも、コンプレッションの概念が必要になってくるものなのでしょうか?
または、サンプリングの時点でレベルをかなり抑え目にしておいて、上限を超える頻度が常識的な演奏であれば少なくなるようにバランスを取ることで妥協するのでしょうか?
もっと何か根本的に間違っているのでしょうか? >>29
複数の音を混ぜるだけなら普通に加算と飽和処理でいいと思うよ。
ピアノのサンプルは大きい音で録音しておいて、ミックスするときに
1音あたりの音量を下げる。
1音あたりの振幅はもっとも大きい音(MIDIだとVelocityが127)でも
最大の8〜10%程度にしてみたらどうかな?
ピアノだったらもっとも音量の大きい弾いた瞬間が10音以上重なることはまずないから
飽和することはほとんどないと思う。 クリッピングでいいよ。
この場合はオーバーフローを起こさないように処理するだけ >>32
なるほど具体的な回答ありがとうございます。
最大10音重なる想定であれば一つあたりは10%程度にするものなんですね。
なんとなくリアルのピアノでの一音と同じ強さで弾いた10音が10倍の音量になっているようには聞こえないかなと思ったのと、
かと言って10音で弾いた内の1音が、単音の場合より小さく聞こえるわけでもない気がするので、
音が混ざるとはどういう現象なのかわからなくなった次第です。 そのへんは振幅と音量(音圧レベル)の関係あたりを調べるとわかってくると思う。 >>34
そうですか。
単なるクリッピング処理の事に飽和演算なんていう専門用語があったのが驚いた。 CPUで32倍以上のオーバーサンプリング処理するとむちゃくちゃ重いんですが、
CUDAでやったら劇的に軽くなったりしますか? 「CPUでオーバーサンプリング処理」が意味不明
アップサンプリングのことか? だから意味不明なんだが
どうやって「CPUで」オーバーサンプリングするんだよ? はあ?
「CPUでオーバーサンプリング」の具体的な意味を少しは言ってみろよ
キモイ顔文字野郎 はいはいオーバーサンプリングの意味すら知らないということは良く分かったよ
もったいぶることしかできないクズ野郎 答えもしないくせに他人のこと暴言吐くことしかしない変な奴w
しかも元の質問者そっちのけ 何言ってるんだこの糞ボケ
答えもしないで因縁だけ付けてるのはお前だよ
俺は「CPUでオーバーサンプリング」の意味を確かめてるだけだよ
それがはっきりしないと答えようもないからね 厳密な意味を求めるのもわかるけど、相手のレベルが分からない以上
質問の内容をある程度の推測も必要だと思う。
それはさておき…
音声処理に詳しくないから一般的なところだけど、
「むちゃくちゃ重い」の原因は何だろう?どんなアルゴリズムなんだろう?
って思った。 むちゃくちゃ重い、が何と比較して重いのかも全く分からない 本当に申し訳ないのですがそのままの意味です
GPGPU・FPGAの音声処理に詳しい方もいらっしゃらないようですので以後スルーでお願いします<m(__)m> あらあら
で結局アップサンプリングのことなんだろ?
マルチレートフィルタをちゃんと勉強しないと何でやろうがダメだろうな どうせフィルタの効率的な作り方なんて全く知らなくて
大きな係数のフィルタを古い教科書通りの時間領域の積和処理で作ってるとかだろ
この手の処理がFPGAで早くなるなんてことはないし、GPGPUでも一緒
殆どメモリアクセスがネックなんだから >>44
いやサンプリング済みのデータに対してCPUでオーバーサンプリングすることは可能だが
その場合の意味はアップサンプリングの前段処理に他ならない >>54
輪をかけて意味不明なこと言ってどうする?
「サンプリング済みのデータに対してCPUで」
それは「アップサンプリング」「補間」とかもっと一般的には「サンプリング周波数変換(N/M)」と呼ばれるものだから。
オーバーサンプリングというのはな、ADCやDACについて言われることで、
サンプリング周波数を、扱う信号の最高周波数×2より高くすることだ。
特別なことがない限りCPUで行うものではない。 アナログフィルターって無限まで周波数があるし
デジタルがいくらオーバーサンプリングしてもかてるわけないしな オッサン世代の俺は、ソフトシンセの進化の物凄さに、
卒倒する思いだわw CPUの処理速度が代わってないのに進化する訳ないじゃん。
逆に耳が慣れたんだと思うな。 いや。大昔、PCMからFM音源に移行した際、感動したくらいの
オッサン年齢だからね。 リアルタイムのシンセシスやウェーブシェーピングは10年前くらいと処理速度ほとんどかわんないね
ムーアの法則なにそれおいしいのって感じ なんちゃってリズムマシンをプログラミング中
割と楽しいっす サウンド処理によく使われるファンクションを詰め合わせたライブラリってありませんか?
グラフィック処理で言えばImageMagickやOpenCVみたいなものです
出来れば日本語の情報が充実していると助かります
単純な加減乗除ならともかくFFT変換やWavelet変換などの周波数分解/合成を伴う処理を
実用になるレベルでコーディングするのは自分には荷が重いです
というかAudacityのNyquistで実現できないかと調べていたのですが複数のトラックの情報を
元に処理して出力を得る方法が見つけられず、他のDAWアプリケーションにもそのような処理が
出来るような物はないようで、自分で作るしかなさそうです・・・ SuperCollider, Pure Data, Chuck, Csound の話題はスレ違い? アップサンプリングに関してですが
直線位相FIRのインターポーレーションフィルタをかける場合
適切なタップ長と窓関数が纏まっているページはありませんか?
もしくはもっと技巧を凝らさないと
元波形と完全に一致するレベルにはならない、とか、何かあります?
今のところ128倍とか、高いアップサンプリングは割と精度が出るんですが
むしろ、4倍とかそこいらの低めのアップサンプリングで精度が出なくて困っています 「適切な」とは何かわからないけど
とにかく理想的になればいいというのであれば、可能な限りタップ長を長くすればいい
ただしビット深度もそれなりに高くないと意味がなくなる
まずそれがうまくいってないなら、どこかに間違いがあるか、うまく計算できていない箇所がある
タップ長が限られるなら窓関数によって主に、フィルタの切れ味とストップバンドの低さのトレードオフになる
そもそも直線位相だからと言って波形が全く一致することになるわけではない
(完全に一致するということは、折り返し成分も再現されたようなもの、これもどの程度のことを言ってるのかわからないけど) 返信ありがとう
今のところ完璧といってよいぐらいの精度、(24bitの分解能以下の誤差)は出てるんですが
なぜか音は悪いです
テストの方法は、適当な波形を用意して、それを間引いて
(というか間引きたいところをゼロにして)
それにインターポーレーションをかけて得られた結果を
元の波形と比べてどれぐらい一致しているかを判断しています
このテストではかなりうまくいっているのに
実際の音楽をアップサンプリングするとあまり音がよくなくて困っています
タップ長は2倍のアップサンプリングでしたら33タップです
アップサンプリングの倍率*8*2+1、で計算しています
窓関数は160dBのカイザー窓です
いろいろ試したらこれが一番精度が良さげだったのでそうしています アップサンプリングで補間されたとこは元データに存在しないと思うけど、
誤差がほとんどないってのはそこを除いた部分に関してだよね?
そうなら、聞いた感じが違うのはあり得るんじゃない? >>69
まず33タップはオーディオ信号処理としては短いと思いますよ(遅延があると困る場合は仕方ないけど)
sinc関数のどこ(の振幅レベル)で切られることになるか確認してみましょう
それに-160dBまで押さえ込もうとしているんだとしたら相当緩いフィルタになってると思いますよ
出来上がった33タップの係数から周波数特性を確認してみましょう
かなりカットオフ周波数を下げないと折り返しが漏れまくりだと思います
(z関数の式で確認すればビット深度の影響を除外できます)
それに24bitは144dBしかDレンジないですよ(floatingだったとしても)
カイザーのβを欲張りすぎだと思います
窓関数の端の方がほとんど0になってませんか?(floatでもあまりに小さい値になってると積和する時に捨てられることになります) >>70
いえいえ、誤差がほとんどないというのは
適当な信号を間引いてダウンサンプリングして
もう一度アップサンプリングしたものと
もともとの波形を比べると、ほぼ差が出ないという意味です
>>71
計算自体はdoubleでやってまして
24bitの分解能以下の誤差、と言いましたのは
最終的なデバイスへの出力が24bitになるので
その分解能以下の誤差であれば問題なかろう、という意味でした >>72
ダウンサンプル前のデータに含まれる周波数は、
ダウンサンプリング後のナイキスト周波数以下のみだよね?
そうなら、
>>71の言うようにフィルタが甘くて、
アップサンプリング時のゼロ埋めで生じた高周波を適切にカットできてないぐらいしか思い付かないな。 質問者ですが、良い情報を見つけました
>http://ascii.jp/elem/000/001/130/1130242/
>「普通のDAC ICは100タップで、8倍か16倍のオーバーサンプリング」
ということらしいので、私がテストを繰り返して適当に求めた
「アップサンプリングの倍率*8*2+1」
という適当な数式は割と妥当みたいです
あとは160dBという窓関数がきつすぎるとか、そういうのはありそうです
でもテストすると、計算上は160dBが一番精度が良いんですよねぇ
なぜ音が悪くなるのかは結局謎でして
もうちょっといろいろ試してみたいと思います あと、あり得るとしたら
「アップサンプリングの倍率*8*2+1」で計算したタップ数は
一般的なDACが内部で行っているアップサンプリングとくらべて
ちょっとタップ数が多い、のかもしれませぬ
そのため、カイザー窓を深く(160dB)かけたときに精度が高まっているのかも
なのでタップ数を減らして窓関数を浅くする実験もしてみないとダメかもしれません
どうせ最終的な出力は24bitなので、必要以上の精度は要らないですし
タップ数が増えることでプリエコーも増えるので
この辺が音質に関係している可能性もあるかもです >>74
たぶんタップ数とフィルタの時間長を混同してらっしゃるかと・・・
それに今時は100でも少ない方かと・・・
DAC ICではさらにその後の処理もあります
精度の出し方が怪しいと思います・・・
カットオフ周波数の話が出てこないのも怪しいです・・・ >>75
>一般的なDACが内部で行っているアップサンプリングとくらべてちょっとタップ数が多い、のかもしれませぬ
逆です
>そのため、カイザー窓を深く(160dB)かけたときに精度が高まっているのかも
逆です
>どうせ最終的な出力は24bitなので、必要以上の精度は要らないですし
正論です
>タップ数が増えることでプリエコーも増えるので
あまり関係ないです
(でかい波は中央付近にいるので)
そのプリエコーでも特性が作られていることを忘れずに
気になるなら最小位相など他のタイプへ
(もっとタップ長が必要になるが) ノイズシェーピングについてどなたか教えて下さい。
以下は3次のノイズシェーピングを行っているつもりです。
ttp://ameblo.jp/etsuo-okuda/image-10477341542-10444025802.html
を参考にしました。
考え方は正しいでしょうか?出力結果は高域になるにつれて周波数成分が増えています。
また、これ以上に次数を増やしたいのですが、★の行をどのように変更すべきでしょうか?
Visual Basic 2015
Class Test
Private Diff(2) As Int64
Function To24_NoiseShaping(ByVal V As Int64) As Integer
Dim I24 As Integer
V += Diff(0) * 3 - Diff(1) * 3 + Diff(2) '★
I24 = V >> 40
Diff(2) = Diff(1)
Diff(1) = Diff(0)
Diff(0) = V - (CLng(I24) << 40)
Return I24
End Function
End Class >>80
の訂正です。
×以下は3次のノイズシェーピングを行っているつもりです。
○以下のコードは3次のノイズシェーピングを行っているつもりです。
「以下」がリンク先を表しているように読めてしまうので訂正いたします。 今日は朝からBraunのシェーバーのCMばかりでうざいと思ったら
9日でシリーズ9の販促特異日のようだ サンプリングレート変換に使える良いライブラリが無いかと探していたら
Secret Rabbit Codeと言うのがあるのを知り有難く使わせてもらうことにした
http://www.mega-nerd.com/SRC/index.html
昔はGPLと商用ライセンスだけだったが
2016年からは2条項BSDライセンスで使えるようになった模様 みんな自分の作ったプログラムの動作確認ってどういう風にしてる?
サウンドプログラミング興味あるんだけど、デスクトップ上で作ったプログラム
動かしてみたい
最終的にはマイコンに移植して使うからC++で書くことを前提としてる。
VSTiがいいかなと思ったけど、GUI作るのがめんどくさそうなんだよね 音の処理そのものに関することではなくメタデータに関する質問なのですが・・・
タイアップ曲があったとしてそのタグにOPとかEDとか挿入歌(1バイト文字表記でどのように書くのが適当なのか不明)などの
使用箇所を入れたいのですがこのフィールドのキーの名前として標準的な物はありますか?
いまのところVorbisCommentとAPEv2での使用を考えています ネタ投下。
http://ideone.com/j8JajR
https://en.wikipedia.org/wiki/Frequency_modulation_synthesis#Spectral_analysis
暇だったのでパルスジェネレータをガリガリ書いたのだけど、FMに興味が出たので書いたのだ。
んで、うまくできてるのかさっぱりわからんのでアドバイスクレクレ。
ほんと、自分が今何を操作してるのかさっぱりわからんのでたすけてくだしあ。
ちなみに数学はわからん・・・。Orz >>89
うまく行ったら革つけてシンセ作りたいとか言う妄想。
でも、能力なさ過ぎてマジで何やってるのかさっぱりわからん。 サンプルサイズ8bitってファミコン音のイメージしか無かったけど
実際16bitの音楽ファイルを8bitに落としてみたら以外に聴ける音だね
これで安心して8bitで出力するプログラムが書けるよ デサンプラーの性能とかあるからね。
ファミコンは、絵とかプログラムとかまるっと揃ってあの形だから音に割けるリソースは少ない。
時代も時代だから、品質も微妙だし。 ところでお前ら、>>88については意見をくれないのかね。
マジで何やってるのかわからないから開発止まってる。 それもそうだな。
自分でコーディングしといてあれだが、以下のパラメータの意味がよくわかってない。
A*Fun1(InitA*Time + B*Fun2(InitB*Time));
勝手に推論してそんなもんだろうと思ってるけど、あってる気がしない。
たすけて、プリーズ。 >>96
そうなんだけど、どのパラメータいじったらどういう効果かわかってないというか。
取り留めなくてすまない。 Yes!!Yes!!Yes!!Yes!!Yes!!Orz 間違ってこのスレ開いたら,>>88にコードがおいてあるじゃないか
雑談が多い板でそれなりのコードがおいてあるスレって珍しいな。
>>88
なにをやっているかわからないのにコードを書けるってすごいな
俺もコードは読めるが、何をしているんだ?って感じだが >>102
識者現る。
最初は、パルスジェネレータ書こうと思ってパルスジェネレータ書いて、
FMのDTM版開いたらなんかウィキペディアのリンク張ってあるからパクるつもりで書いた。
数式を推論でコードに落としただけだから。しかし、俺には高度すぎた。そもそも文系だしな。
違和感があるならぜひ教えてほしい。 コード書けるひとを見つけたとき
自分もそうなりたい ← がんがれ
どうやったらそうなれるの? ← 金払え
自分には無理 ← さっさとやめれば?
このパターンしかない プログラムコピペして、何これ意味わからん、一から教えれと言われてもムリですマル >>88だけど、叩きネタになってきたからもういいよ。
開発やめるわ。 FM変調なんて出る音は想像しにくいけどアルゴリズムは超シンプル
何がわからないのかわからないし
他人にタダでプログラム読ませてレビューさせようとする態度じゃ開発やめた方がいいよ 自分のメモも含めて
離散フーリエ変換(DFT/FFT)や離散ウェーブレット変換(DWT)を実装したいけどググっても
数式が列挙されているような記事ばかりで高卒の自分にはさっぱり判らん
出来れば時間情報を残したいので最終的にはDWTの実装が目標
数式がずらずらより抽象化された資料や最低限の実装例が欲しいけどなかなか見つからない
DFT/FFT
理論からのアプローチ
小学生に教えるフーリエ変換 - researchmap
ttp://researchmap.jp/jow16lae8-617/
見つけられた中では最も抽象化されている資料。ただし抽象的すぎるのか装に結びつけられん・・・
PIC AVR 工作室 FFTの計算と複素数の入門
ttp://picavr.uunyan.com/warehouse_fft.html
高校生相当に抽象化されているもよう。が、ベクトルの合成・分解は今までにやった記憶があるけど
ベクトルの内積とか複素数とか全く記憶にない・・・多分必須しか取っていないせいだな
でもこれを理解出来ればFFTを実装できそうな気はする。積分式?がずらずらよりは遙かに良い
実装からのアプローチ
FFTの扱い方 - ロジカルアーツ研究所
ttp://www.logical-arts.jp/?p=112
FFTライブラリの入出力について解説されている記事。これを読めば何となく使えそうな感じ
Ruby で FFT (高速フーリエ変換) を書いてみた - まめめも
ttp://d.hatena.ne.jp/ku-ma-me/20111124/p1
Ruby的な書き方をしている上に再帰呼び出しをしているとはいえ驚異的に短い。これ、あっているのか?
正しいなら理解を助ける一助になりそう(自分はRubyメインだし)
参考元のコードも比較的コンパクトに書かれている
DWT
めぼしい資料は未発見
窓関数
未着手 フーリエ変換後にやりたいことに合わせて処理を簡略化するんだよ
律儀にやる必要はない flacフォーマットの質問をしたいんだけど、スレチなら誘導してくれ。
https://xiph.org/flac/format.html
https://xiph.org/flac/api/index.html
ここらを見て構造を調べてるんだけど、いまいち分からん。
METADATA_BLOCK の APPLICATION と CUESHEET および PADDING は、
ひとつのflacファイルに複数あっても良いのだろうか、それとも、
あるなら1個のみだろうか。
というのも、他のブロックはドキュメントに明確に数が示されている。
・STREAMINFO 必ず1個
・SEEKTABLE 0個か1個
・VORBIS_COMMENT 0個か1個
・PICTURE 0個以上
しかし、先の3つのブロックについては明記されていない。
何となく CUESHEET は役割的にあるなら1個のみのような気がするが・・・
どうなんだろ? >>113
一般的な回答になっちゃうけどそれらの親はMETADATA_BLOCK_DATAだよね
METADATA_BLOCK_DATAの存在可能個数に依存するんじゃないかな
あと明記されていない以上どう扱うかは“実装による”と言うオチが付きそうな気がしなくもない
タグだって標準的ではない情報を入れようと思ったらそれっぽい名前のフィールドをでっち上げるしかないわけだし >>114
ありがと。
メタデータの個数は、ドキュメントには
STREAM
<32> マーカー
METADATA_BLOCK ストリームインフォのため
METADATA_BLOCK* その他のメタデータのため
FRAME+
としか書かれていないから、これに従えば上限は無い。
いくらでも加えられる事になる。
もしかして俺がドキュメントや API を見落としているかもと思ってたから、
実装によることが確かなら、それでいいんだ。
俺が作ったライターが書き出したflacファイルを他人が作ったリーダーで読み込んだ時、
たとえば PADDING が複数あっても、実装依存なら、それをリーダーにどう扱われようが、
少なくともエラーにはならない(解釈しないメタデータは無視するのが仕様)。
でもドキュメントや API から、それは「複数あってはダメ」なことが仕様だと読み取れるのなら、
厳密に正しく作られたリーダーにflacファイルではないと解釈されてしまう。
俺が作ったライターは仕様に則っていない糞プログラムといことになる。
それは避けたい(まぁ実際に PADDING を複数作ることは無いが、例として挙げた)。 何をしたいのかわからんけど
APPLICATION:サードパーティーアプリに対し付与される保証ID
CUESHEET:内部埋め込みキューシート
PADDING:余白
てあるから、必須ではないと思うけど >>116
仕様としては、それらが0個以上あることが許されているのか、
多くても1個までなのか、が知りたかった。
で、一般論としては、ドキュメントに明記されてなきゃ実装依存だろ、
とのアドバイスをもらったたころ。 >>115
結局何を優先したいのかが重要じゃないかな?仕様に忠実だからといって最大の互換性を得られるとは限らない
仕様上は問題ないけどイレギュラーな構造や値の入ったデータはそれだけで互換性の問題を起こしやすいよね
互換性最大だったら公式ツールが吐くデータに添うのが現実的では。一般的にそれらは1ファイルに付き1つだよな? >>118
何を優先したいかじゃなくて、まずは仕様を正しく知りたい。
正しく知った上で、じゃあ互換性を優先しようかどうかと考えるんだけど、
それは仕様を知ることとは別問題でしょ。
互換性を優先するのが目的ならば仕様を正しく知る必要はない、
なんてことは無いと思うんだよ。 仕様がないと困る人はRubyとか使えないんだろうなぁ。Rubyは仕様が存在しない言語だしな PCMデータから特定の音(倍音も含む)のみを抽出・抑制したいのでPCMデータとパラメータ(周波数とゲインのセットが多数)を
入力するとパターンに従ってPCMデータを加工してくれるEQライブラリ的なのってありませんかね?
パラメータは処理中に変化していくため既成のソフトウェアでは対応できそうにないので自作を考えています
パラメータの与え型は
ttp://alphamanual.audacityteam.org/man/Equalization
みたいな感じをイメージしています。倍音を抽出する場合は方形波状に沢山窓を並べることになると思います DFTで特定の周波数だけ計算してしまえばいい。
位相も一緒に計算しておいて逆位相を加えれば消えてくれる ■ このスレッドは過去ログ倉庫に格納されています