Premise (since somebody may ask about the background): I am the author of the spectral modules for SynthEdit, a modular framework for realtime STFT audio processing, currently struggling since months to write a stable and robust spectral envelope estimator, for usage in voice modification, pitch shifting with formant preservation, vocoding, inverse filtering and so on.
After having invented (and tried) every possible algorithm for spectral envelope estimation, but disappointed by their inadequate robustness and time stability, I decided that the so called True Envelope has the potential of offering all the needed advantages I am searching for.
The algorithm, in short, keeps smoothing a target magnitude spectrum and then updates it iteratively with the maximum of itself and of the original magnitude spectrum until a smooth envelope slowly grows, and once some stopping criterion is satisfied the algorithm stops. After actual experimentation, it turns out that from 15 to 30 iterations are needed depending on the F0 in the original spectrum.
The proposed algorithm uses cepstral smoothing to smooth the target spectrum at every iteration, i.e an actual brickwall (sinc) LP filter by zeroing cepstral coefficients over an arbitrary order (50 is a good choice - unlike similar algorithms, given its iterative nature, the result seems no longer so sensible to the cepstral order chosen, which would naturally be linked to the knowledge of FO otherwise, which is in turn another ill-conditioned problem)
However this translates to computing 40 FFTs for 20 iterations, which even if feasable on modern cpus is surely a huge wastage of resources!
I tried a smarter approach: filtering the magnitude spectrum without going to cepstral domain i.e by simply using a bi-directional 1 pole LP filter. The speed improvement is huge but the result definitely inferior to the cepstral method, because the brickwall cepstral filtering has a different response which cannot be easily simulated with a quick IIR filter unless using a FIR with sinc convolution (but that would make things even worse as for performance)
In this paper and this some tricks are suggested to improve performance and to speed up convergence. I am not talking so much of the downsampling of the original spectrum (which is something I already do to some extent) but of the trick to control the step size of the iterative algorithm.
Unfortunately both papers,despite verbose, are explained very badly and despite all my efforts I failed to properly understand and implement the suggested trick.
My question is therefore if somebody can offer a pseudocode allowing me to understand how to speed up convergence the way the authors of the papers above suggest. Or alternatively any other elaboration or suggestions or ideas on how I could reduce the computational complexity of the True Envelope algorithm because having to compute tens of FFTs for every spectral frame just to compute an envelope is really an overkill.
Thanks in advance
Update: I am not 100% sure this will be the solution yet but chances are I discovered a simple but genial trick. After just one iteration, the resulting cepstrum can be compared with the cepstrum of the original spectrum, and the "future" of the cepstral coefficients meant to be kept (i.e inside the rectangular window used for liftering) can be EXTRAPOLATED linearly. For every coefficient after one iteration it is enough to compute the difference w.r.t the corresponding coefficient in the starting cepstrum and sum this difference multiplied by a factor which simulates the result of further iterations. The result is promising and looks like Columbus' egg... it is very strange that the authors of the papers above never thought of such a simple and elegant solution... in case linear extrapolation resulted not accurate enough one can use one more iteration and quadratic extrapolation but I would say it is not even needed...
UPDATE 2: In the end I even managed to "decypher" the original paper and implement the suggested speed up trick to increase the iterative step. With this trick the algorithm converges in 4 / 5 iterations. That is stil 8 to 10 FFTs for every frame though. Oh well... case closed however. I realize this was a too specialistic topic btw.