こんにちわ。
オリジナルファイルと破損ファイルの両方をお送りいただき、ありがとうございました。調査した結果をご報告します。
結論としては、ファイルを破損させたのはTuneBrowserではなさそうです。
破損ファイルは、たしかにID3v2につづくMPEGデータの冒頭部分が破損しており、正常なMPEGデータが見つかるまでは、ゴミデータとして処理されています。そのため冒頭しばらくは再生されないということが起こります。
そしてオリジナルファイルのほうには、特異な部分があり、ID3v2のブロックが2つ含まれていました。MP3形式では、ID3v2ブロックはファイルの冒頭に置くとされていたと思いますので、これは厳密にいえばすでに破損した状態です。
ただし、TuneBrowser (というか内部で使用させていただいているmp3infp) は2番目以降のID3v2ブロックは単純に無視して処理しており、大きな画像を埋め込んで更新しても問題は起こりませんでした。ファイルの冒頭に画像ファイル分だけ大きなID3v2ブロックが書き込まれて、そのあとにもともとついていた2番目のID3v2ブロックとMPEGデータが書き込まれます。再生時は有効なMPEGヘッダが見つかるまで検索をつづけますので、ファイル編集前と同様に、2番目のID3v2ブロック後のMPEGデータから再生されます。このあたりの動作については、念のためソースコードを1行1行ステップ実行して動作を確認をしましたが、問題は見つかりませんでした。
先日のコメントで、勝手に大量(?)の画像データを生成しているのは、別のソフト (Windows Media Player) ではないかと書きました。これはわたし自身は確証は得ていないのですが、似たようなケースとしてWindows Media Playerが勝手にMP3ファイルを書き換えてしまうという噂もあるようです。Googleなど検索エンジンで「Windows Media Player MP3 勝手に」で検索してみてください。事例が見つかります。
その際に、これも想像ですが、ID3v2ブロックが複数あるような特異な構造になっていると、Windows Media Playerはこれをうまく処理できず、ファイルを破損させてしまうことがあるのかもしれません。
TuneBrowserは、特長のひとつとして謳っている通り、ユーザーの操作のない状態で勝手にファイルを書き換えることはしません。「いつのまにか」とか「勝手に」といった感じでファイルの更新が発生しているようであれば、まずはWindows Media Playerの利用を止めてみてはいかがでしょうか。
なお、ついでながら、次のリリースでは複数のID3v2ブロックが見つかった場合、その両方を読み込んでマージする動作に変更しようと思います。書き込む際には、ひとつのID3v2ブロックに統合するようにします (それで新しい不具合が出たらどうするねん、という話はありますが、せっかく新しい事例を知ることができましたので、改善したいと思います)。
よろしくお願いします。