今回は、解説が長いのでサクサク進めよう
ちなみに、1.6.5のリリースをBlogに書いていないのはいいネタが無く面倒になったので。
フリーソフトの制作なんて根を詰めるようなもんじゃないし。
今回の変更点は以下
・通知設定の配信者名が未入力であった場合の動作修正
・お知らせ音のボリューム調整追加
・ゆっくりボイスが驚きの高サンプリングレート化
・ネットで見かけた、xmlの設定ファイルのサイズが0バイトになって起動できなくなる問題の暫定対処。
・ログファイルをメモ帳なんかで開いている時に、ログの追記が実行されると例外を吐く事象の対処。
・「配信取得間隔」のコントロールを変更。最小値は変わらず。
で、今回困ったり時間がかかったりしたこと。
1、設定値のxmlファイルのサイズが0バイトになって起動でコケる事象の対処
恐らく、終了時になんかのタイミングで、オブジェクトが存在しないのを書きこもうとしてると思うのだけれど、
コード上は.NetFrameworkから終了メッセージを貰った後、書き込みをしている。
少なくとも、メッセージを処理し終わるまではオブジェクトが存在しているはずなのだけれど。
また、自分の環境だと問題が出ていないので今ひとつ原因がつかめない。
そういう意味では、昔、対策を諦めたウィンドウ位置の保存に失敗する事例と似てる。
結局、こっちは原因が掴めないので逃げのコードを書くことに。
2、音声ボリュームの追加
ぶっちゃけ、Windows7やVistaではアプリケーション毎に音声ボリュームを設定できるので、
今更らいつべバルーンで設定項目を作る必要はないと思って今まで特に手を入れていなかったのだけれど、
そんなに難しくもない筈なので、作っておくかと思ったのが間違いだった。
今まで使っていた、.NetのSoundPlayerクラスにボリューム変更位あるだろうと余裕こいてたら
あっさりとそんなプロパティは存在しない事が判明する。
なら、別のコントールがあるだろうと、適当に見繕って試してみるも、
「有効ではないスレッド間の操作: コントロールが作成されたスレッド以外のスレッドからコントロール ‘hoge’ がアクセスされました。」
とか、言われる。
どうやらバックグラウンドのスレッドで回すのはダメらしい。
では、どうするか。
と考えた挙句、C++/CLIで記述しているので、C++時代のソースを取り込めることに気がついた。
型変換さえきちんとしてやれば、普通にwinmm.hの低レベルAPIを叩ける。
で、手元には昔にゲームでも作ろうかと思って作っていたwavファイル再生クラスのソース。
条件は揃った。
という訳で、音声再生部分については自前のクラスを使うようにした。
が、今度は再生される音声がなんだか微妙に感じる。
どうも、クラス内でWavを44.1khzの16Bitステレオに変換しているのがダメらしい。
変換しただけで、平均化をかけていないので、妙に角張った音が聞こえてしまう。
しかし、変換しないと音声ボリュームの変更ができないので変換しないわけにもいかない。
結局、ゆっくりボイスをアップサンプリングして無駄に高音質にしてしまうことにした。
ここまでやった後で、デリゲートなる機能があることを知る。
が、機能の実装までやってしまって、簡単にテストした後なので今更そっちを
利用するってのも無いよなぁ……
ちなみに、
『ひまわりストリームのRSSに暫定対応コードをいれる』
というのもあるのだけれど、ひまわりストリームは配信数が増えると1回のリクエストで
全部の配信リストを取れなかったり、RSSに配信者名が入ってなかったりで、
途中でめんどくさくなったのでGUIから無効にするだけで放置することにした。
そんな訳で、難産した割には殆ど変わってないらいつべバルーン1.6.6のリリース。
不具合っぽい症状がでたので報告を
新バージョンになってから(1)アラート音の最初にバグったような音が入る(2)終わりにプツっというノイズが入る、1はたまにで2は必ず入ります。Win7の64bitでアラート音は自分で用意した音源を使ってます。 旧バージョンでも同じ物を使ってましたがこのようなことはなかったです。
このバージョンから、音声を内部的に一度44.1khzの16Bitに変換してから再生するようになってます。
これは、ボリューム音の変更をするために入れています。
この処理はOS標準の物を使っているのですが、ノーマライズしてくれません。
音声の不具合はそのOS側のAPIによるものだと思います。
なので、用意するアラート音を44.1khzの16bitステレオにしてください。
改めて WavePCM signed 16bit, 44100Hz, 1400kbps, stereo の無音の音源で試したところ(2)の症状がでました。 (1)は再現性なく試せていません、一時的なものだったのかもしれません。
OSのAPIやプログラムに精通しておりませんので、報告しかできず的外れでしたらすみません
1400kbpsはタイプミスで1411kbpsでした
問題が再現するということで、改めて調査しました。
その結果、(1)の方の問題が確実に再現する状況がつかめました。
Wavファイルを再生する時に、ヘッダ情報を正しく処理出来ないパターンがあり、
余分なヘッダ情報を音声データだと誤認して再生していたために、
バグった様な音が出ます。
APIに渡すデータが間違っており、私のWavファイルの仕様認識漏れです。
ですが、(2)の方が再現しない感じです。
ひとまず、配布ファイルは(1)の修整版に変えたので、このファイルで(2)が再現するか
見てもらってよいでしょうか?
お疲れ様です。 調査していただけたということで私なりに(2)の原因について調べました。
(1)の解決報告を見て最初のノイズがヘッダーならば終わりのは…とエディタで音源を見たところ(2)が出る音源には音声データの末尾に作曲者などのタグ情報が埋めこまれていたことが確認できました。
もしかしてこれかな?と思いつつも、私には専門知識はないのでとりあえずの報告でした
情報有難うございます。
恐らく、それでビンゴだと思います。
再生データを渡す処理として、ファイルを読み込んでバッファに追加していくのですが、
現行のプログラム側の作りは、ファイルの末尾までデータとして扱っており、
音声データの後に拡張情報がある作りを想定していません。
対処としては、ヘッダの音声データサイズを見てから、
バッファに追加するデータを読む時には、データサイズを元に拡張情報を見ない処理に
切り替える必要があります。
対処自体はそんなに難しいものでは無いので、2~3日中に直してバージョンを上げようと思います。