Andrzej Salm
It doesn't take a genius to figure out that some sort of simple algorithm could be developed to compensate for the delay since it's constant across two ranges of bit rates...
I would imagine that the delay would be different when using a different encoder.
I've paid for the encoder. I've bought Sonar too. Since the encoder is being sold by Cakewalk I expect it to work properly with Sonar.
As has already been said, your complaint should be aimed at the mp3 file format specification, not Sonar.
All mp3 encoders leave a small silence at the beginning of the file. It's called pre-delay. Mp3 encoding is done in fixed-size blocks of data and therefore if the data doesn't entirely and exactly fill a round number of blocks it gets padded out with zeros - that is, silence - so that it does.
Encoders tend to put the silence at the beginning of the file so the file ends on a full block, or as near full a block as possible.
Some encoders, such as Lame, can add to the file the length of the pre-delay, but not all decoders can read or use that data.
Pre-delay also varies, as you have discovered. Not just with bit rate but between different encoders as well.
Sonar, being designed for professional use, places the mp3 where ever you put it and rather than second-guess things just decodes and plays the file. If it's necessary to correct playback for pre-delay then just nudge the data so the noise starts when it should. We're only talking of a small fraction of a second usually anyway. Or convert the mp3 back to a wave then trim and nudge as required.
There's plenty of information on the web about the mp3 file format and encoding if you want to dig deeper into this.
https://en.wikipedia.org/wiki/MP3#File_structurePersonally I don't use Sonar to convert audio to mp3, simply because I'm lazy and since I've exported a wave file anyway I usually just let iTunes do the conversion. After all, it's free. As is LAME for that matter.