Wav データの波形表示について
Masayoshi Katou
早速ですが、
WindowsのWin32APIで、Wavデータの波形を表示するプログラムを
作成しているのですが、それらしきAPIも見つからず、
ANSI Cの範囲でバイナリファイルを読みこんで作ろうと
思っているのですが、
そのまま、全て表示させていったらとてつもなく重くなるし
とばし、とばし、読んでいったら極端にレベルが違う所は、
とばされてしまうと.....設計段階から悩んでます。
それで、一般的にどのようにしたら、ストレスもなく
きれいな波形になるのでしょうか。
その辺のことを教えていただけないでしょうか？
＃最初、全てバッファに代入するとか考えたのですが、
やっぱりそれはナンセンス？（素人ですいません...）
＃参考になる本でもかまいません。
＃よろしくお願いします。
m-k...@ma3.justnet.ne.jp
KATO Kenji
in message news:8refgs$6e6$1...@news.justnet.ne.jp...
> ども、いつもこのNGにお世話になってるかとうと申します。
おなじく加藤というものです。
> WindowsのWin32APIで、Wavデータの波形を表示するプログラムを
> 作成しているのですが、それらしきAPIも見つからず、
> ANSI Cの範囲でバイナリファイルを読みこんで作ろうと
> 思っているのですが、
Wavファイルの読み込みに関してはmmio系のAPIが使えますね。
(mmioOpen, mmioDescend, mmioRead, etc.)
これらを使うと、ヘッダ部分と実データ部分の切りわけが
比較的楽に出来ます。
> そのまま、全て表示させていったらとてつもなく重くなるし
> とばし、とばし、読んでいったら極端にレベルが違う所は、
> とばされてしまうと.....設計段階から悩んでます。
>
> それで、一般的にどのようにしたら、ストレスもなく
> きれいな波形になるのでしょうか。
オーディオデータの処理というのはもともと重いものなので...
WAVファイル全体の表示と、正確な表示は多分両立しません。
# たとえば、CD音質だと44100サンプル/秒なので、
# 1600*1280の画面で1サンプル1ピクセルで表示しても
# 0.036秒分(計算合ってる？）しか表示できないことになります。
多分一般的な波形編集ソフトでは、表示の倍率(?)を変更できる
ようになっていて、全体を見渡したいときは間を飛ばしながら
表示、詳しく表示したい部分を拡大していくと読み飛ばす間隔を
少なくしていく、という方法を取っていると思います。
# たとえば私が使っているアプリでは、全体を表示した場合
# など、やはり部分的にレベルが高いところや低いところは
# つぶれてしまいます。
> ＃最初、全てバッファに代入するとか考えたのですが、
> やっぱりそれはナンセンス？（素人ですいません...）
...？ ごめんなさい、ちょっと意味がわかりません。
--
========================================
KATO Kenji (ken...@cij.co.jp)
========================================
Shiroh Sado
佐渡です。
こんにちは。
スレッド「Re: Wav データの波形表示について」での
ken...@cij.co.jp氏の発言 <y5AC5.4$Tk3...@nnrp.gol.com> より引用
>> # たとえば、CD音質だと44100サンプル/秒なので、
>> # 1600*1280の画面で1サンプル1ピクセルで表示しても
>> # 0.036秒分(計算合ってる？）しか表示できないことになります。
計算あってます。
(馬鹿正直には横44100ドット)
# (馬鹿正直には縦65536ドットx2ch)
>> 多分一般的な波形編集ソフトでは、表示の倍率(?)を変更できる
>> ようになっていて、全体を見渡したいときは間を飛ばしながら
>> 表示、詳しく表示したい部分を拡大していくと読み飛ばす間隔を
>> 少なくしていく、という方法を取っていると思います。
8kHz / 8bit サンプリング相当(もっとサンプリングレートが
低くても構わない)のデータをメモリに持っておき、表示には
それを使う、という方法を取るのが良いはずです。
# 「平均値」をつかう必要は無く「間引き」で十分です。
# 当然、折り返しノイズ(4kHzより高い周波数が、一見、低い
# 周波数として現れること)が出て来ますが、無視して、折り
# 返しノイズをふくんだまま表示すればいいでしょう。
必要に応じて、処理をかける部分、詳しく見たい部分などを
読み込み直せばOKではないでしょうか。
>> > ＃最初、全てバッファに代入するとか考えたのですが、
>> > やっぱりそれはナンセンス？（素人ですいません...）
そんなにはナンセンスではないと思いますが。
最近のPCは数百MBぐらい平気でメモリ積んでいるんですから。
---
佐渡詩郎 (さど しろう) / e-mail : sa...@smlab.tutkie.tut.ac.jp
Masayoshi Katou
フォローありがとうございます。
>Wavファイルの読み込みに関してはmmio系のAPIが使えますね。
>(mmioOpen, mmioDescend, mmioRead, etc.)
>これらを使うと、ヘッダ部分と実データ部分の切りわけが
>比較的楽に出来ます。
このmmio*って関数は、RIFF形式専用のファイルアクセス関数って
考えていいのでしょうか？（すいません勉強不足で....）
調べてみたら、ANSI Cで言うところのfopenとかfseekとかの
機能しか持ってないようだったので....だからmmio(multi media i/o)?
ということだったので、再生する時はWaveOut*()で再生して
波形表示の部分はmmioでもってきた値で線を描けば、
スタンダード(?)、初心者でも短時間で制作できる
Wave編集ソフトが作れるのかしら？
KATO,Kenji
in message news:8ribur$ntg$1...@news.justnet.ne.jp...
> このmmio*って関数は、RIFF形式専用のファイルアクセス関数って
> 考えていいのでしょうか？（すいません勉強不足で....）
そのとおりです。
> 調べてみたら、ANSI Cで言うところのfopenとかfseekとかの
> 機能しか持ってないようだったので....だからmmio(multi media i/o)?
ただ、RIFFチャンク、サブチャンクの先頭をシークしたり、
入出力のバッファリングを指定できるなど、マルチメディア
ファイルの操作がやりやすいようになってます。
# 少なくとも私個人は便利だと思って使っています。
> ということだったので、再生する時はWaveOut*()で再生して
> 波形表示の部分はmmioでもってきた値で線を描けば、
> スタンダード(?)、初心者でも短時間で制作できる
> Wave編集ソフトが作れるのかしら？
多分。
というか、私もオーディオファイル関係の
プログラミングは比較的最近始めたので、
あまりえらそうなことは言えないのです。
mmio系のAPIに関しても、ちょうど自分で調べたのが
記憶に新しかったので...
--
========================================
KATO, Kenji (ken...@cij.co.jp)
========================================