ok, just found the answers for this one. This is apparently expected behaviour of ALL the MP3 encoders and decoders out there from what I've just read. It also explains some of the timing differences between Mike's and my mp3 tests (older versions of LAME added more padding).
It's a bit technical, but check it all out here:
http://lame.sourceforge.net/tech-FAQ.txtSadly I don't think there would be any sort of easy fix to any of this. This extra space is needed for several reasons (explained in that faq). Also with different versions of LAME, and with different encoders/decoders the appended and prepended samples can't be properly predicted, so there's no real way of "fixing" something like this. Also with different bitrates and encoding options the amount of padding required can change as well.
Now after all these explanations, it really makes me wonder if WMA doesn't also pad both ends of a file... it almost seems like for a compressed format it would be required.
Anyone wanna test this?
I can't really encode wma on OSX properly.
Mark