[vorbis-dev] Vorbis bitstream specification...

[Segher Boessenkool]

> > Don't forget about -100.132 and things like that.
> 
> that's bits and binary point, not values .
> (eg, 8.24 is xxxx xxxx.xxxx xxxx xxxx xxxx xxxx xxxx)

and -16.48 is

 . ssss ssss ssss ssss xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

(with s the (virtual) sign extend).

> The result will be correct, but I'm not sure I trust every compiler to
> be sane about it.  Have you actually checked MSVC and GCC on a bunch
> of platforms?  I'll go check it on ARM now.

ARM works.  PowerPC works.  Both on multiple compilers.  Integer multiply
on x86 is a lost cause, so I never bothered to check.

If you're very worried, you can always define it to be an assembler define
like this (for ARM):

#define himul(x, y, xyhi) do { \
        int32 dum; \
        __asm__ ("smull %0,%1,%2,%3" \
                : "=r"(xyhi), "=r"(dum) : "r"(x), "r"(y) \
        ); \
while (0)

<p>> > Also, signed a.b * signed c.d ==> signed (a+c-1).(b+d) (effective range).
> > You can do tricks with unsigned muls to prevent that -1.
> 
> range is not an issue in this case (rather, the range of this MDCT is
> well understood).  I understand you're being complete, but there's no
> reason to worry about it here.

Well, I mean, if you don't do shifting, you lose one bit of range per
multiply.  The libvorbis mdct is 10 (or is it 20?) stages, so you need to
be careful not to lose too many bits.

> > > If you're on ARM (for example) and have SMULL, use 2.30 for the
> > > lookups, only save the RdHi register and you'll have very good S/N.
> >
> > Roundoff errors?  You can do it like this, but be careful about signs.
> > (Truncating in two's complement always rounds towards -inf; make sure
> > these errors don't accumulate).
> 
> I'm suggesting a n.m * 1.31 (or 2.30 if you don't want to fudge
> cos(0)) multiplication.  There's no reason to worry about the roundoff
> at that depth.  We'll still have >20 bits of S/N on the other side.

You always have to worry about roundoff, range and scale.  If in this case
the result of careful analysis is that the "naive" implementation performs
just fine, you're lucky.  But you always need to do the analysis.

> > > There's nothing tricky in an integerization;
> >
> > ...but there are a lot of tricks in integerization :)
> 
> You only have to worry about ones that actually matter.

This is for portable players, so don't you want to run at as low a clock
as possible? ;-)

<p>Segher

<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 'vorbis-dev-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.