On 13-Oct-99 Patrick De Smet wrote:
> (Mike,) You may send me the linked list code if you want to.
it's a bit embarrassing :)
On the weekend, i may post a "snapshot" 

> + : try avoid loading same coefficients over and over again from 
>     memory, ((doing similar pointer operations, etc ...))
> - : needs more complex program
> So indeed if you filter more then 32 new samples in one go; you can
> "recycle" the filter coefficients by using appropriate samples:
>  ie win1 [0..512]  = PCMsample[i] * filtercoef[i]
>     win2 [32..554] = PCMsample[i+32] * filtercoef[i]
This is what Kumar & Zubairs method basically does.

> However, things are more complex in current lame3.34: win's are not
> restored to memory but summed into 64's zi's; see below;
> This is not a problem (?), only makes things more complex I guess/hope.
K&Zs should work in both layerII and layerIII.
However, K&Z performs 12 windowsubbands at a time for layer2. I'd suggest 18 at
a time for layer3 due to the different granule/frame config.

> Somebody should investigate if the same "mem bandw reduc"  thing can be
> done for fft's cos/sin coefficients and other stuff; ie. calc two or more
> fft's in one go, or is this not possible ?
It is possible.
Lame currently does one real FFT for the left channel, and one real FFT for the
right channel.  It is possible to do one complex FFT which computes the FFT for
both channels at the one time.  I've never tried tracking down an
implementation of this. 

> lame3.34 filtering is nice but the "+off[k] & (512-1)" and pointers are
> a pain; (I fixed this for lame3.11, the off[k] & 511  I mean)
I couldn't see a good way of getting rid of these without doing an exhaustive
refilling and reordering of the array. What was your solution?

> Also, and I haven't seen this anywhere (did not really look ?) the
> enwindow is "almost symmetrical"   !  
optimize/change this if you can.  windowing is still a bottleneck in lame.

> The 64 zi-calculation stuff complicates things; I am investigating;
> or is this a waste of time, has it all been done before ??
I'm not sure what you want to investigate here.

> Also, for high speed fft's : the pre-ftt PCM windowing (Hann-window I
> believe) is this window not symmetrical too ? If so then why not recycle
> those coeff too.
could be done.  it'd save memory, not sure if it'd save time though.
 
> these (single win) things; if it works it would really appreciate it if my
> own code would go into future lame; 
so would we :)
later
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to