Ok, I've been looking at this to see whether anything could be done in the kernel to prevent the transients. I added a hijack menu option to enforce muting whenever the eq was applied. I had thought that this would slow down the manual EQ interface, hence not just enforcing it period. Strangely enough it doesn't and it removes the nastiness that is present when you try to change a bands frequency when a large gain/cut is already applied to it.

However, it does not fix the problem with Auto EQ. And I realised that Auto EQ adjusts in small steps whilst measuring, rather than measuring then applying one large step. This means that as long as you start from a flat EQ, this fix wouldn't do anything to help anyway and in fact may screw up the measurements. So that patch will probably hit the bit bucket - I don't remember anyone complaining about the manual EQ glitch before so it would seem strange to have a hijack option to fix something no one cared about.

Back to Auto EQ, I played the files in XMMS. Sure enough, the transients are present in the files. It sounds like the files were bandwidth limited first and then cut in the time domain, resulting in a square transient at the beginning of the file. I'm guessing that no effort was made to cut at zero crossing points...

Is anyone set up to re-generate the files from scratch?