[vorbis-dev] Vorbis bitstream specification...

[Monty]

On Mon, Feb 11, 2002 at 08:35:13PM +0100, Segher Boessenkool wrote:
> > Codebooks are general and may need to be anywhere from 1.31 to 24.8.
> 
> 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)

Anyway, Vorbis I will not exceed 24 bits of residue integer (that is,
by the current spec, no more could possibly be used by implication of
the floor vector being a max of -140 to 0 dB). technically speaking,
the residue fraction could be up to 24 bits (if a future encoder
nailed the floor to 0dB, unlikely but possible), so I'm going to
outlaw that in the formal spec.

The LSP coder could conceivably use values that are all fraction, but
it won't exceed 1.31.

> 
> > 3) the MDCT on mainline has a stable dynamic range and is easy to
> > integerize.  The mainline integer version assumes a 14 bit fraction on
> > the trig lookups, which frankly is far too little.  This is done only
> > because C doesn't have a 32x32->64 bit two result register multiply.
> 
> #ifndef BIGENDIAN
> union magic {
> 	struct {
> 		int32 lo;
> 		int32 hi;
> 	} halves;
> 	int64 whole;
> };
> #else
> ...
> #endif
> 
> static inline int32 himul(int32 x, int32 y) {
> 	union magic magic;
> 	magic.whole = (int64)x * y;
> 	return magic.halves.hi;
> }
> 
> and with optimization turned on, everything will work Just Fine(tm).

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.

> 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.

> > 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.

> > 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.

Monty

--- >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.