[opus] Potential transient pre-echo reduction filter
    Aikku 
    aik at aol.com.au
       
    Sat Feb 16 11:56:42 UTC 2019
    
    
  
Hey everyone.
I've been designing my own audio codec with extremely strict 
decode-performance constraints (including a fixed block size), which led 
me to attempting a number of unorthodox things to squeeze as much 
quality as possible.
One surprising thing I discovered just earlier today was an extremely 
cheap method of reducing pre-echo during transients, without using short 
blocks (and still using a 50% overlap MDCT). Since I figured this might 
be pretty important even /with/ them (due to better frequency 
resolution), I decided to send a message here.
The basic idea is: Transients generally add a sinusoidal shape to the 
frequency-domain coefficients, which is what makes them so hard to code 
at low bitrates, and why some codecs even implement frequency-domain 
linear prediction. But since that would impact performance a fair bit 
for my codec, I instead decided to take a lesson from wavelets and used 
a simple sum/difference on every pair of coefficients (sort-of emulating 
a Haar wavelet). ie. (excluding normalization factors)
a = X[i*2], b = X[i*2+1]
X[i*2] = a + b
X[i*2+1] = a - b
I tested with a very long block size to really emphasize the transient 
error diffusion, and the pre-echo seems to be cut down by half with no 
other effort at all. Adding another layer of this transform (ie. 
X[i*4]+/-X[i*4+2]) doesn't seem to improve things much, though. Perhaps 
a more frequency-selective wavelet (eg. LeGall5/3 or CDF9/7) would 
improve things a bit more, but in honesty I don't really have the 
motivation to test any further than this.
I've included some examples of this modification in action (please 
excuse the particular taste in music; I just find it very useful for 
this kind of testing). It's coded at 32kbps stereo @ 44.1kHz, though 
quality is heavily degraded from using a larger block size than what 
I've optimized it for (and degrades further with the 2x filter, due to 
even worse separation between the non-zero and zero bands making the 
run-length coding perform very badly).
I'm not sure how useful this will be, given the CELT layer's band 
folding, but I hope it's useful for the community at large anyway.
-- Ruben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32kbps_2xFilter.flac
Type: audio/flac
Size: 1190399 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/opus/attachments/20190216/418f0775/attachment-0003.flac>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32kbps_NoFilter.flac
Type: audio/flac
Size: 1181118 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/opus/attachments/20190216/418f0775/attachment-0004.flac>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32kbps_1xFilter.flac
Type: audio/flac
Size: 1177537 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/opus/attachments/20190216/418f0775/attachment-0005.flac>
    
    
More information about the opus
mailing list