I use ogg when I need to encode something at really low bitrate, so I wasn't using GT3 compiles. Lately I've read that the newest (GT3b2) compile of oggdropXPd uses LibVorbis v1.0.1 on low quality settings, and GT3 tweaks on the higher ones, so I downloaded it thinking that it gives both good things. Then I performed a simple test - I encoded the same wav twice, first with the LibVorbis v1.0.1 compile, and then with the GT3b2 compile, the result surprised me because the 2 wavs were quite a lot different in size. I was encoding in ABR mode (with bitrates set to Min. 0, Nom. 45, Max. 45) to get the smallest files possible, so I thought that both will be encoded using LibVorbis v1.0.1 code without GT3 tweaks, and will be exactly the same. Why they aren't? Does GT3b2 compile use LibVorbis v1.0.1 without GT3 tweaks only when encoding in Quality Management Mode (on low quality settings), and when encoding in the other modes it always uses GT3 tweaks (even when low bitrates are chosen)?

Can you post the size differences please. Were you using 1.0.1 and GT3b2 as oggdropXPd variants?

I deleted both files so I reencoded them again:
1.0.1: 806823 bytes
GT3b2: 811614 bytes

Hmm, I'm pretty sure that on first encoding the GT3b2 file was smaller (something like 789xxx bytes), but I may be wrong... of course I didn't change any settings and I encoded the same wav.
Well, assuming that I didn't screw anything, sizes don't seem to be "quite a lot different" now (4791 bytes), but can you tell me why there's a difference at all?

The variants I used are from Rarewares (GT3b2 I downloaded today, 1.0.1 a couple of days ago):
1.0.1: oggdropXPd V.1.7.5 using LibVorbis v1.0.1 2003-12-11, ICL7.1 compile, 1.0.1 (313Kb)
GT3b2: oggdropXPd V.1.7.5 using GT3b2 based on LibVorbis v1.0.1 2003-12-11, ICL7.1 compile, GT3b2 (312Kb)

Thanks, I'll look into this before making any comment.

Well, there is a small difference between the two versions when using the ABR setting you mention, but the comparison I found was:

1.0.1 - 1,321,882bytes
BT3b2 - 1,310,393bytes

However, and I think this was what you were referring to, in the course of looking at this, I found and fixed a small bug that related to ABR only. I have, therefore, uploaded oggdropXPdv1.7.6 in all incarnations.

Not only ABR.
I still have not 1.7.6 to test it.

1.0.1 q2__________104'042
GT3b2 q2_________103'752
fatboy.wav was used
so the difference is abot 0,3%
1.7.5 were used

I just checked both 1.7.6 variants of oggdropXPd, and there still are differences:

1.0.1: 806823 bytes
GT3b2: 811614 bytes

...so they're the same as in v1.7.5. Is it ok?
I still wonder, why both files aren't of the same size?

Yeah, they sure are different, I just ran the same test, then decoded each back to WAV, and they are indeed different. This also throws out the idea that this is some sort of header difference. Might some of the floggy code still be in there interfering, or would that even affect q2? Regardless, this is weird.

I've made some progress on this, but I'd like to do a little more testing. It certainly seems from the testing I've done so far that there is some interaction between Garf's tuning and 1.0.1 that yields slightly different results as compared with both GT3b1 and 1.0.1. However, I've made a couple of small changes that bring things closer together. Before I do anything with this I want to test it a little more. I'll get back on this during the course of tomorrow.

I have resolved the issue of the lower bitrate settings whether using bitrate management, or quality settings. The GT3b2 encoded files are now larger than the 1.0.1 files by the size of the vendor string size increase. However, I still have a small issue regarding the higher bitrate settings which I am in communication with Garf about. I'll report back once this is resolved.

OK, I've now had a helpful response from Garf, as a consequence of which I shall be uploading all new GT3b2 compiles later this evening. I'll post when they're available with some information about the situation.