??? three point thr *edit* ................ oh
3 minutes 34 seconds right?
*temporary dumbness on my part*
*2nd edit, but only the one post*
is it just me, but am i......... er, no, sorry... but is the board playing up tonight? think something's stressing the server as there's timeouts and the like going down, which is unusual (wouldn't have noticed, if it were old-timey porka, when it wasnt yet club polo)
*3rd edit after another snafu and inexplicable double post

*
28mb over 3m34 = approximately 1076 or 1103kbit/sec for the whole stream (depending how you measure it - k=1000 or k=1024). Obviously this doesn't really sit well with any of the bitrates you used. Either there's something odd in the settings, or the encoder is bollocksed. As it's actually making your high bitrate file about 1/3 smaller than it should be, i doubt it's a "pad low bitrate frames to standard size" option...
dissecting that, if we assume there is no "program stream" overhead (it's usually about 1 or 2k, a max of maybe 10k), the encoder is using k=1000 (typically these things do... yes, its a pain, but whats more brainfoxing is that ONE of the major hobbyist ones uses k=1024...gahhh), and that's its a lot harder to bend the bandwidth of the audio than either the video or program streams....
1103 - 128k = 975k is your actual video (+prog) bitrate for 128k audio
1103 - 96k = 1007k, similar for the lower rate audio.
My diagnosis is chuck it and see if anything different is available. Possibly it's a shareware version that's locked down to 1000k video and 96k sound but doesn't tell you upfront?
I haven't been keeping up but I have strong hopes that my favoured MPG-1 (and MPG-2 capable) encoder, TMPGEnc (Tsunami MPG Encoder) has entered the MPG-4 game. Because it's easy to understand, capable of some powerful stuff, and produces some really quite sweet output (even if tis not quite the fastest...)