[vorbis] bitpeeler

[John Ripley]

> -----Original Message-----
> From: Sebastian Gesemann [mailto:sgeseman at uni-paderborn.de]
> Sent: 14 April 2003 16:05
> Subject: Re: [vorbis] bitpeeler
> 
> On Wed, 9 Apr 2003, Segher Boessenkool wrote:
> [...]
> > No, because you can *losslessly* reencode a Vorbis file to a
> > better-peelable (or easier-peelable) file, or even to a newer
> > version of the Vorbis format, as long as that new format still
> > uses the same MDCT (or something very much like it) and the same
> > floor curves.
> 
> ... and the same window function and this and that ...
> 
> I'm not sure if it is possible to reencode a vorbis file to
> a newer better-peelable vorbis-1 file. This implies redisign
> of the (currently one-stage?) quantizing mechanism to multi-stage
> VQ. - Yes, I'm aware that Vorbis supports multistage VQ. But
> i have absolutely no idea how this conversion should be done
> without introducing new quantizing errors. Do you ?

I've been puzzling over this a little recently. I think that having the bit
peeler make any decisions based on psychoacoustics entirely defeats the
point - it's no longer a trivial operation. So these decisions must be made
by the encoder and communicated to the peeler.

The way I've always imagined a bit peeler working is as you suggest - a
multistage VQ. This is probably just how everyone else has suggested, but
just to recap:

* One stage consisting of one or more passes of VQ is used for "peeled"
quality.
* A second stage (0+ residue passes) of VQ is used for "high" quality.
* (More stages are used for e.g a streaming server which has
32/64/128/192kbit rates)
* The encoder runs passes until it reaches "peeled" quality, and marks off
how many passes it took.
* The encoder then runs more passes until it gets to "high" quality.
* The bit peeler simply runs through the file and rewrites the residues
without the "high quality" passes.

The problem is I don't see anywhere in the spec where the encoder could
indicate how many passes are assigned to each stage on a per-frame basis. I
guess you could add another residue format type, but I think it's orthogonal
to the format type.

I'm tempted to play with this idea when I have spare time (which I might
have a lot of depending on what happens to SonicBlue tomorrow!) Does anyone
know if there's something blatantly wrong with this method that I should
know? :)

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