[tremor] Re: [PATCH] new mdct code, redundant tables eliminated

timmy brolin timmy at home.se
Fri Sep 13 15:17:47 PDT 2002



I had not received your last post when I wrote my last post.
Sorry I didn't see your little hack for the case when step=0.
I'd say this little hack for the second table will reduce the sound quality to something like the equvivalent of half the samplerate. Linear interpolation might give us a accaptable quality/textsize tradeoff.

As I said previosly, I was working on the exact same patch.
Here are two versions of mdct.c and mdct_lookup.h
Both have the last table removed (saves like 12kB) (second is table still there), and there is no negation fixes in either because I wanted to demonstrate that the code produces bit perfect output.

This version produces bit perfect output at the cost of some extra cycles, it's main purpose is to demonstrate that the code works:
http://194.47.15.142/~timmy/mdct3.zip

This version works exactly the same way as the one above, except it is more efficient, but some very minor integer rounding errors does occur like ten times in a tune:
http://194.47.15.142/~timmy/mdct4.zip

Just in case someone is intrested.

/
Timmy

-----Original Message-----
From: Nicolas Pitre <nico at cam.org>
To: timmy brolin <timmy at home.se>
Date: Fri, 13 Sep 2002 16:42:23 -0400 (EDT)
Subject: Re: Re: [tremor] Re: [PATCH] new mdct code, redundant tables eliminated

On Fri, 13 Sep 2002, timmy brolin wrote:

> I noticed the not-identical output from Nicolas last patch (the one that only took care about the negation).
> So I agree that that's likely the problem, but it must be examined more closeley.

That can be easily explained.

Suppose you have the following 64 bit values:	0xffffffffffffffff
Negating it would give you:			0x0000000000000001

Now if you truncate those values, preserving the top 32 bits, you obtain 
0xffffffff and 0x00000000 respectively.  Negating them at that again at that 
point will give you 0x00000001 and 0x00000000.  We are now up to a 
difference of 1.  Remember that we started with the same value but integer 
truncation combined with multiple negations produced this error.

Therefore, by removing extra value negations in the code, I might actually 
have improved the accuracy of the final output at some point.

> But, there is another problem with this latest patch... When the 8192 or
> 4096 tables are required it will probably fail.

It won't fail.  The output will just not be perfectly accurate.  See my 
previous post where I explained the whole issue.

<p>Nicolas

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'tremor-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'tremor-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Tremor mailing list