- 初版：2005-03-30
- 改訂：2006-02-09
現下、MUSIC PC さんとのいくつかの実験・情報交換などを経て、この問題が Timescale code に起因するものであることが確認されています。詳細な問題・事情を知るためにはこの記事よりも後の記事を確認する必要があります。
この問題を回避する最も最適な方法としてこのサイトが推奨する方法は MKA 変換機のファイルチェックモードを使用することです。詳細は「mka を簡単に作れる「MKA変換機」」（2005-10-16）を参照してください。
久しぶりに試してみたところ、input.tta と output.tta が同一になって「わーすごい。直ったのかなー」と思ったのもつかの間、今度は merge した後に出来た mka の再生時間が延びているという。むー…。やはり複雑すぎて問題がどこにあるのかがよく見えてきません。
44100Hz の場合におかしくなった wav を 44100Hz と 48000Hz の2種類用意しましたので、ちょっと試してみてください（サンプル数は 44100Hz.wav/48000Hz.wav ともに 240001 として作ってあります）。
44100Hz(tta+wav).mka を Splitter → True Audio Decorder の順で DSF 経由再生してみたところ、44100Hz.wav とは再生時間が異なります。しかし、そのうえで 44100Hz(tta+wav).mka を extract するとサンプル数が減少するので 44100Hz.wav と同一になるという。
やはり自分がなにか間違えて妄言を吐いている説が最有力。ですが、もしかしたら特定のビットレート＆サンプル数のときに matroska のビット規格に合わせるためにサンプル総数を変更しているのかな、などとも考えています。初期の実験に使用した際には問題がなかった 48000Hz ですが、別の場合にはサンプル数が変動することも掴みつつありますので、現状 44100Hz の限定的問題という適当な仮説も崩壊確定。むしろ逆に、44100Hz でもサンプル数が減少する場合と一定の場合、そしてサンプル数が増加する場合があるようです（ただし、断続的に行う実験の最中にサンプル数を計測し間違えた可能性があるので、この測定結果を信用していません）。入れて出したら曲が長くなっているというよくわからないことまで起こっているので、やはり問題を掴みにくい。
さまざまなライブラリを併用して、どのような場合に問題が発生するかを特定できるよう暇を見つけては実験を続けていますが、今のところどのような場合に問題が発生するかについて明確な再現性がありません。この問題に非常に興味はあるのですが、なにぶん Level.10 のマリーに賢者の石と鉄屑から金を製出させているザールブルグの錬金術師状態なので、他の方の支援に継続して期待しています。
真剣に、知識のある方に試していただいて模範解答を出してほしいところです…。現在までに情報提供をして下さった方には総じて感謝しています。発生しないという方のご意見も、大変参考になります。
