On Thu, 14 Oct 1999, Takehiro Tominaga wrote:
[...]
> P> Also, and I haven't seen this anywhere (did not really look ?)
> P> the enwindow is "almost symmetrical" ! ie c[0..256] = -
> P> c[512..256] + some special cases (@ 64*n-values) check the
> P> table you'll see.
>
> This is also done on my current version.
>
> see mdct.c/l3psy.c/musicin.c in my latest version. there's no buffering
> and copying. The window function calculation is also optimized.
> I will merge the patch to the current lame if I have a time....
>
> My snapshot is moved and is available at
> http://www.isoternet.org/~tominaga/lame-beta/
I will to try review your code to see if it has all ideas (I trust it
will).
In another follow up [EMAIL PROTECTED] wrote:
>> 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?
I can post code, but not it is not properly tested, and I would like to
compare with above mentioned first.
Another thing to consider layer II (III also if you pre-decide "cut
off", or is this already in there, again I did not check lame?); current
toolame filtering does not consider sblimit; I added this to my list too;
will not be spectacular for high qual (only sb 30, 31 get dropped, see
bitalloc tables), but for low qual, much more will be dropped.
best regards,
Patrick.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
