マイクで録音の話があったときに作ったものを少し手直し。 概出ですがヘルプの文書が少し怪しいサウンド関連、配列のサイズによっては自動でアップ・ダウンサンプリングが発生するような? ただ、知っているどのプログラム環境よりも音が扱いやすいのでいじっていて楽しいです。

O2 B1で再生したほうが正しいかもしれないです。 O3 C1で再生すると巻きかえりが出てくるので。 いちど周波数を調べたいところですが　もにょもにょ。

8180Hzというサンプリング周波数から考えてみます。 8180Hzでかっちり表現できる周波数は409Hzの倍数。 409Hzというのはmidi noteの67(391.9954Hz) G と68(415.3046) A#の中間です。 プチコンか3DSが内部でいい感じに波形を変換しているのだとは思いますが、以前だした加算合成のプログラムでも波形がきれいにかみ合わないためにギャップが生じていました。 409Hzで作ればぴったりではあります。ちなみにサンプリングレート3180Hzで409Hzを作る際の配列数は10になります。 まだ何をどうすればいいかわかりませんがプチコンでの音関係はちょっとだけ癖があるのかもしれないですね。

MIC機能で2秒取り込むと確かに8180*2秒分のデータが出来上がるのですが、それをそのままきれいに元通りの速度で再生する手段がないのかもしれません。

440Hzを表現できる8180に一番近いレートは7920Hz 7920*2=15840 7920/8180=0.96821516 8180*2*0.96821516 = 15840.0000176 おおよそ1.9秒の録音をすれば綺麗にできるはず…とWAITを1.9秒に調整したもののMIC機能はある一定の配列数をまとめて確保するようでWAITを変えても8180*2の配列を確保されてしまいました。　なかなか手ごわい…。 一旦レコーディング後に配列の長さをいじってやればもしかしたら周波数を合わせることは可能かもしれないという点からもう少しいじってみることにします。

画像のプログラムではマイクのデータを配列Dに確保しています。 録音後8180*2の長さになります。 これを新たに配列D2などを作り長さを0～15839まで配列Dからコピーしてやります。 WAVESETAでこの新しい配列D2から波形をつくり、 BGMPLAY "@224 O3 T120 C1" これで再生すると。タイミングぴったりでした。 なんでオクターブ3のCになっちゃうのかは謎ですが録音したままの速度で再生するというのはなんとなくこれで達成出来るような気もします。 調査続行します。

しかし配列をいじり2秒→1.9秒くらいにカットすると都合が悪いこともあるかもしれないので、じゃあ再生のほうを何とかしようと思います。 MMLのコマンドにデチューンというものがありますのでこれを使います。 録音したもともとの波形データを使うと微妙に再生速度が速いために巻きかえるので少し遅くしてやればいいわけです。 BGMPLAY "@224 T120 O3 @D-30 C1" これでどうでしょうか。 大雑把にしかデチューンをいじっていませんので微調整が必要かもしれませんが。配列をいじるよりも手軽ではないでしょうかね。

しばらく考えていました。 元通りの速度で再生出来ないことでわたしは何も困っていないのでこの件ここまでにしておこうと思います。 一つだけ。 元通りの速度で再生したい理由は2つ思いつきます。 音色として綺麗にループさせるため。 もうひとつは何か既存の楽曲をまるまる録音して使おうという場合です。 はっきり言っちゃいますが後者をやりたいならやめたほうが良い。というかやらないでください。みんなの迷惑になります。 迷惑ものになりたくないでしょ？ だからやめてください。