[vorbis] Conformance (was Re: Why is Vorbis development slow?)

[John Ripley]

> -----Original Message-----
> From: Ralph Giles [mailto:giles at xiph.org]
> Sent: 30 September 2003 12:36
> To: vorbis at xiph.org
> Subject: Re: [vorbis] Why is Vorbis development slow?
> 
> On Tue, Sep 30, 2003 at 04:15:45AM -0700, John Ripley wrote:
> 
> > I'm now quite tempted to properly finish off my decoder and 
> use it instead
> > of Tremor in the portables I work on, if I could only work 
> out the rights
> > nightmare that would ensue...
> 
> I hope you don't mean us. The whole point of Vorbis is an open 
> specification anyone is free to implement. We think independent 
> implementations are wonderful and important for the health of the 
> standard as well.

No, I mean the rights issue between the company I work for and me. It's one
of those silly rights assignment contracts where by default anything you do
is the company's "property", and not yours. Ironically, that probably means
they get less out of me in the long term. But we all know the arguments here
:)

> While we certainly appreciate it when people contribute back to the 
> reference implementations, they're MIT licensed so that 
> borrowing code 
> and inclusion in closed software is explicitly permitted. We want to 
> place no impediments to adoption of Vorbis as long as the 
> implementations are conforming.
> 
> So please do use your own decoder if it does a better job.

Conformance is a good point. Aside from floor-0, mine very blatantly doesn't
conform in one other place: I assume all vector codebooks are restricted to
16 bit integer values. This works for anything oggenc 1.0 generates, and it
allows for huge savings in decoder memory and processing requirements.

Tremor appears to have the same conformance issue, because it uses fixed
point 24:8 (I recall) for vector values. The floating point Vorbis
implementation also has the same conformance issue because a 32 bit IEEE
single precision float can't hold the range of values that the vector
codebooks can. So, I feel quite justified in my less than arbitrary choice
of 16 bit integers :)

Personally I think residue vectors should have a restriction in the spec to
integer values anyway. That way you can treat the floor curve as a list of
exponents, and the residue vector as a list of mantissa values.

There's still the question of how much decoder workspace you need to be
conforming (e.g is a 256MB codebook valid). I suspect you'll have something
to say about that for version 1.1?

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