WavCheckerを実装する時に課題になったのが64bitWAVへの対応でした。
Python標準のwaveライブラリは64bitWAVに対応していません。
ハイレゾ云々のこの時代、ライブコンテンツで2時間を超えてくると使用頻度が高くなるのが64bitWAV。

開発も中盤に進んできたところでどうしたもんかなーと思っていたころ、
たまたまGithubで見かけたNRK（ノルウェー国立放送局）のオープンソースライブラリwave-bwf-rf64がドンピシャでRF64に対応していることに気づき、とても助かりました。

しかし、実戦に投入してみるとAVID Protoolsで吐き出したwavに何故かエラーになるやつがたまにあることが判明。

「たまにってどういうこっちゃ？」

EBUの仕様書を読みながらデータをダンプして眺めていたところ、
なんとも微妙なProtoolsのバグ（とも言い切れないんですが）であることがわかりました。

Pro Toolsは画像の部分の「tableLength」に0（何もエントリがない）としているのに、実際にはChunkSize64構造体を生成してくるのです。
これは規格違反とまでは言わないですが、意味がなく謎な挙動です。

で、ついでに言うとそれを読み込むwave-bwf-rf64の当該部分の実装も手抜きでイケてなかったのがわかりました。
仕様外のデータなんて来ないという楽観で作られていたのです。

なので、自分でwave-bwf-rf64を修正してプルリクエストを出しました。
https://github.com/nrkno/wave-bwf-rf64/pull/4

・変なデータを出すPro tools（たぶん一番悪い）
・変なデータなんてくるわけないと思っていたwave-bwf-rf64ライブラリ（そんなに悪いわけでもない）
・そもそも仕様がざっくりして、値のMUST説明がないEBUの仕様書
（そこそこ悪い気がする）

いろんな人のすれ違いでこうなっちゃったという、
WAVは魔境だなあというよもやま話でした。

余談：
nrknoは放送局システム全体をオープンソースにしているようで、
wave-bwf-rf64以外にも極めて興味深いプロジェクトがいっぱいあります。
興味ある方は色々眺めてみるといいと思います。

サワツ