Greetings!

I know that adding an ID3v2 tag to an MP3 file with variable bitrate might cause the decoder not to find the VBRI/Xing header. Also, if it does find it, the position entries in the TOC won't match anymore.
Anyway, I was wondering about two things:

1. LAME has an option to add an ID3v2 tag during encoding. Does that mean that the entries in the TOC will be correct then?
2. Aren't decoders smart enough to add the ID3v2 size (which is also stored inside the tag) to the position identifiers? Let us say the TOC stores byte 1000 for second 10. If I add an ID3v2 tag, which is 500 bytes long, the decoder should know that second 10 is now at byte offset 1000 + 500.

TOC is an expression usually used when talking about cds. I'm not sure what you mean by TOC in an mp3 file.
I don't think there's a vbr+id3v2 specific problem either. At least not with a decent decoder.
Any decent decoder will skip the id3v2 so it shouldn't be a problem.

The gap problem with mp3 files is caused by format shortcommings (will add silence to end with a complete frame) and seeking info in xing/vbri headers not being sample-accurate.

The VBRI and Xing headers can also contain a TOC. This TOC (Table Of Contents) stores a combination of frames and byte offsets. This helps the decoder to navigate more faster and accurate. MP3 files with constant bitrate don't need such a TOC because the position of a frame inside the MP3 file can be calculated directly using a formula.

Well, that is what I thought first, but I have seen lots of posts here telling us not to use ID3v2 tags because they are evil.

I know about that one. A MPEG 1 Layer 3 frame must have 1152 bytes. If only 1000 bytes contain audio data, the rest (152 bytes) are filled with silence.

I think you're refering to the LAME tag.
If the decoder actually uses the LAME tag info it can playback the file without gaps, but AFAIK only foobar2000 does this ATM.

edit: without the lame tag there's no info stored useable to playback gaplessly.

IMHO a good decoder should simply add ID3V2-Tag's size to each byte offset contained in the VBR header. This wouldn't be a problem if VBR byte offsets would be seen relative to VBR header's offset (and that's what I always expect from all decoders, but I really never tested it).

Funny thing I that I have over 4000 songs with ID3v2 tags and have never had problems with them losing their VBR tags...hell, I've even MP3Gained them all...

Same's for me. The WinAMP version I use (2.90?) never got problems with ID3V2 before VBR. Unfortunately it doesn't make use of VBRI (FhG) headers, but that's a missing feature and not due to existing ID3V2 Tags.

What's still unclear is if the VBR tags' TOC is used properly. But nevermind: The average case would be a 4KB ID3V2 Tag in combination with lots of 32kbps frames in the file. Therefore generally the seeking position discrepancy would be a maximum of (tagsize/4kb) seconds, so in standard cases (normal ID3V2 tag without binary data like cover image etc.) the maximum discrepancy would be exactly one second.

Same with me, more than 150 GB with VBR MP3's, equipped with ID3v2 - played mainly on RioVolt 100, NAPA DAV 3.26, WinAmp and BPM Studio Profi. No problems whatsoever, at all.

I never understood what's the problem with the ID3v2 tag.