Hi,

i recognized a strange tracknumber behaviour of foobar (or maybe mp3tag?).

I normally rewrite my id3v2.4 tags to id3v2.3 with mp3tag bacause of my XBOX360 (Mediacenter). And because of Mediacenter can't read DISCNUMBER, i use a tracknumbering like:

Disc1: Track1: 101
Disc2: Track15: 215

But now i recognized that it doesn't work for Disc4. When i rewrite my tags to v2.3 and reread them in foobar i get this:

Disc4:Track1: -111
Disc4:Track2: -110
...
Disc4:Track12:-100

Then everything goes well with Track 413.

After reloading the files into mp3tag, the right numbers are shown. This is only for Disc4 all the other Tracknumbers 2xx, 3xx, 5xx work.

Picture

As you can see, foobar shows wrong, total commander (anytag-plugin) is right, mp3tag is right and file-prperties (explorers) are wrong.

I wrote about that too before, it's strange that it doesn't handle it.

This indicates that your tracknumbers are stored in ID3v1 tags, which use a byte instead of plain text and are thus unable to hold those large values.

412 mod 256 = 156, which is 1001 1100 in binary, which turns out to be the two's complement of -100.

Solution: Disable ID3v1 tag writing in your Mp3tag options.

No. 412 is congruent to 156 mod 256.

Why does 412 work but not 413? Because -100 is 4 characters ?! (Flawed logic if that's the case...)

Sorry about that small mistake.


Yes, this is indeed the proper explanation.

When deciding between multiple tags (ID3v1/v2, APEv2), foobar2000 prefers the longest value for each field.

Let's see how values are written by Mp3tag and how they are read by foobar2000:


"-100" is indeed longer than 412, and thus preferred.

How about just allow numbers? (Make foobar2000 ignore other chars).
Or, prefer ID3v2x/APE tags in tracknumber if present.

ID3v1 reading could be improved by reading the tracknumber byte as 0..255 instead of -128..127.

This would avoid incorrect ID3v1 values being preferred over ID3v2 ones.

Thanks... removing id3v1 tags solvedthe problem.