hiroさん、こんばんわ。Chartreuxさん、いつもありがとうございます。
ご指摘の動作は、Change Logに書いた、以下の動作の変更に起因しています。
関連して、TuneBrowserでタグを編集した場合に, ファイルへの書込み完了後、再度ファイルを読み直すようにしました (OSのキャッシュが効くので速度劣化はあまりありません). これにより、タグ名のゆらぎやタグ形式特有の表記変換 (ID3v2のジャンル番号など) について、ファイルとデータベース間の齟齬の発生を抑制します.
MP4/M4A系は、トラック番号をバイナリ値で格納するという稀有な形式で、テキスト形式では保存していません。そのため、”2″も”02″も、数値の2として書き込まれます。これまでは、ファイルに書いたあと、そのままデータベースにも書いていましたので、”02″がデータベースに書かれることになっていました。今回からは、ファイルに書いた2を改めて読み出して、その2がデータベースに書かれます。結果として冒頭のゼロパディングは消えてしまいます。
4.6.1でも、当該曲の右クリックで「データの更新」を行うと、ゼロパディングは消えてしまうのではないかと思います。
また、Chartreuxさんも書かれていますが、わたしのところでもWavPack形式ではこの事象は発生しませんでした。
どうするか、なのですが、いまはちょっと方針を決め切れていません。これまで何度か、ファイルに書いた値とデータベースの値が異なるというご指摘をいただいていて、それはそれで不信感を生んできました。その対策として今回の動作にしたわけですが、結局、ファイルに忠実が良いのか、良くないのか、ということになってきます。
「そういう話ではないんだけど」と言われそうな解決策として、表示上トラック番号を2桁固定で表示させるという手があります。詳細は省きますが、%TRACKNUMBER%としてトラック番号を表示しているクエリに、2INTという引数をつけます。
%TRACKNUMBER,2INT%
そうすると、表示上ゼロパディング付きの2桁で表示されるようになります。これでなにか改善にはなりませんか?