こんばんわ。
検証とご報告、ご意見、どうもありがとうございました。
コンパイラによって音が変わっているというご報告は、藤本健氏の言われているようなデジタルオーディオのオカルトネタがひとつ (やっかいなところで) 増えたという感じですね。念のために申し上げておくと、同氏は「オカルト」という言葉を使われていますが、決して否定的なものではなく、前回ご紹介した記事にもあるように、それをオーディオのネタのひとつとして楽しもうというスタンスに立たれていると理解しています。わたしも同感です。
同氏の記事のタイミングと同様に、まるで今回の議論に合わせたかのように、日本マイクロソフトのJapan Developer Support Core Teamから1月21日に以下のブログ記事が公開されていることに気がつきました。
この記事では、TuneBrowserが全面的に使用しているC++という言語については、同一のソースコード、同一のコンパイラを適用した場合、動作や機能は同一だとしても生成されるバイナリは同一とは保証されない、バイナリ内部のタイムスタンプや乱数的要素だけでなく、そもそも「決定論的ビルド」がサポートされていないと説明されています。
最近のC++コンパイラは、CPUのSIMD拡張と合わせて極めて高度な最適化を行いますので、決定論的ビルドが困難であることは理解できます。そして現在のTuneBrowserのソースコードは、コンパイラの進化に合わせてその最適化をできるだけ引き出せるように考慮した構造になっており、とくに性能に機微な部位はソースコードの変更のたびに生成されたアセンブラコードを確認するようにしています。
その経験から「ビルドのたびにバイナリコードが変わっている」という事象を目にしたことはほとんどなく (じつは数年前の数か月間その現象に悩まされた経験はあるのですがいまは解決しています)、生成されたバイナリコードはそれほど変動するものではないと思うのですが、わたしがアセンブラで確認できるのは本当にコアな処理の一部であり、その物量からとても全体を確認することはできません。つまり、ビルドのたびにバイナリコードが変動するリスクが発生します。
どうすべきでしょうか。ビルドしてリリースするたびに、「今回は音がいい」「残念、今回はもうひとつ」と一喜一憂していただけばいいのでしょうか (皆さんがそうではないと言われていることは重々承知しています。これは単に自問自答です)。
ASIOドライバが受けとったデータも含めた今回の検証で、こうした結果は、わたしの意思・技術力・開発行為とは別のところで発生していて、ケーブルの材料のように開発者の意思で選択できるようなものではないということはご理解いただけたのではないかと思います。そのような言い方をすると何となく責任逃れのような感じがして自分でも気持ちの良いものではありませんが…。
いっぽうで、今回の議論で、わたしの開発したソフトウェアがこのように高度な (=趣味性の高い) 領域での音質の議論ができる再生能力を持つに至ったことに、(へんかもしれませんが) 感慨も感じています。10年以上、良くなろうと念じながら自分の全力を投じて開発をつづけてきたわけですが、それは地道にデータの精度と処理に気を遣って改善する活動であって、決して「ここをこうして高域の質を上げてやろう」とか「低域を膨らまそう」とか、そういう音質選択的活動ではありませんでした。にもかかわらず、今回の議論ができるということは、ある意味その地道な開発の結果のひとつの現れなのかなあとも感じています。
コンパイラのバージョンは、上のマイクロソフトの説明から決定論的ビルドが保証されない以上、あまり強くこだわっても仕方がないのかとも思います。当面は4.17.4で使用したコンパイラを使用しますが、その結果として趨勢の進化から取り残されるようになるのも本意ではないので、必要があればバージョンは変更すると思います。