I added to a topic that I just realized wasn't in the FB2K forum. I'll ask that question again here.

Using autonumber on the properties window, I cannot get fb2k to write %totaltracks% to anything other than a TXXX frame. Is there a setting to force fb2k to use the TRCK frame? Also, is there anyway to force leading zeros with the autonumber? Foobar, of course, is smart enough to zero-pad when displaying, but most other programs are not.

Also, using the TRCK frame typically results in %tracknumber%/%totaltracks% being stored, which foobar still interprets correctly, I just can't get it to write this.

you may want to consider using Mp3Tag to do the autonumbering.

interesting read in the Mp3tag forum here:
http://www.anytag.de/forums/index.php?showtopic=4027

someone else may be able to provide a foobar2000 method, but since no one else replied, i thought i'd pass along the alternative idea.

you could also try checking/unchecking the option in Pref -> Advanced -> Tagging -> MP3 -> ID3v2 writer compatibility mode

I'm sorry but I fail to see how you got totaltracks stored in a TXXX frame. I get NN/NN in TRCK instead. Did you try writing totaltracks with tracknumber not set or something like that?

agreed. i finally got back to my foobar install and tried it myself. both with writer compatibility mode on and off. using properties -> auto track number i was definitely unable produce TXXX fields. the only way i could get TXXX fields for totatracks was to write that field with nothing in the tracknumber field (as Peter suggested above).
in fact, after writing totaltracks by itself, using auto track number after would actually remove the TXXX frame and put everything back into the TRCK frame.

maybe i'm doing something wrong but when i used auto track number it did remove leading zeros. it appears in the 9.5.3b1 DUI layout as NN/NN, but the raw tags appear to be in N/N format (viewed in Mp3Tag & Hex Editor).

I don't think I'm doing anything crazy. Often I download an album that will have only track numbers, so I select the album and do auto track number to fill in total tracks. In that case, it seems a TXXX frame is written. Once I have the TXXX frame, if I auto track number again, it sticks around. If I remove just the totaltracks tag (via foobar) and renumber, TXXX shows up again. If I remove all tracknumber tags (again in foobar), though, and renumber... TRCK only with X/Y. That's even if the TXXX frame is present... it gets removed.

Autonumbering when track numbers are present may not be a normal usage scenario, but hey, I'm too lazy to count the tracks.

For the record, I happened to notice this with the beta of Beyond Compare 3, so that is how I am viewing the frames used. I am using Columns UI, but I imagine that shouldn't matter. Also, I guess I didn't update to 0.9.5.2 at work... it's 0.9.5.1. I did reproduce this several times, but if no one else can, maybe I'm just doing something really funky or starting with weird data. Thanks for the input!

OK, makes sense now: adding totaltracks when tracknumber is already present may result in a TXXX because we're trying to reuse existing ID3v2 frames when possible and a TRCK frame with just tracknumber already exists. I'll get this behavior changed, thanks for the report.

Thanks for looking into it. The leading zero bit is still an (incredibly minor) annoyance to me. If that's something you would consider, great, otherwise not a problem. I appreciate your help.

Matt

Leading zeros are probably something that is best handled at the display level, not the actual tag level.

e.g.
$num(%tracknumber%,2)

Leading zeros are probably something that is best handled at the display level, not the actual tag level. e.g.
$num(%tracknumber%,2)

The %tracknumber% field automatically zero-pads. If that behaviour is not desired (and I don't know about you guys, but I usually desire it), $num(%tracknumber%,1) will get you a non-padded version.

not in the tag though, right?

that is what I see after autonumbering, it strips the padded zero's off if they preexisted in the TRCK frame.

shakey_snake: No, not in the tag. The field simply pre-processes the data, much like the way %album artist% and %track artist% do.

Fix included in 0.9.5.3 beta 2.