Option to fix it. In post-processing for example, just an idea.
You don't know how the input was encoded, but you know how you are going to decode it (to wav) and encode it again. So there's room to make things nice in LameXP scope. I'm not sure, I just got to know about this bug (I consider it a bug) but I think the delay is a
constant value so with a few tests you can get to know. But it's up to you to decide if this is LameXP scope, right now I think I can't use it anymore for my videos audio. Now it's only useful for music audio, and individual tracks of course, if you encode a session composed of tracks LameXP won't be suited either...
Fortunately I now know about it, and can use workarounds, many people will still encode delayed audio without knowing aka doing the wrong thing.
In video processing we also add some padding for some filters to comply the mod 16 requirement, or just to protect borders. But the padding is always cropped back after filtering.
I think you call them Tools.
https://github.com/lordmulder/LameXP...ster/res/tools
You have some kind of a list more towards suppported formats rather than used tools for input/output formats
http://gitorious.org/lamexp/lamexp/b...AQ.html#line39
That can make the cut if I were to test for delay issues and flag options.