peeling as I understand it (was Re: [vorbis] When will quality increase be unnoticable?)

[Ed Sweetman]

On Mon, 2002-06-24 at 01:28, Alan MacDonald wrote:
> 
> 
> > -----Original Message-----
> > From: owner-vorbis at xiph.org [mailto:owner-vorbis at xiph.org]On Behalf Of
> > Graham Mitchell
> > Subject: peeling as I understand it (was Re: [vorbis] When will quality
> > increase be unnoticable?)
> 
> > That is, if a file is encoded at (for example) q9, and subsequently
> "peeled" to q6, it may not sound quite as good as the same file originally
> encoded at q6.
> So they'll peel, and the bitrate (and filesize) will be right
> where you want it, but the quality may be sub-optimal.  But this depends
> probably on how "smart" the peeler is.
> 
> 
> 
> 
> Well I wish someone would give a clearer explaination of what is meant by
> peeling, because there are at least two ways, that I can see, to effectively
> reduce the bit-rate of a vorbis file with out completely decoding then
> re-encoding.  The simplest way is to drop some of the residue codes, which
> would give you a sub-optimal result, as Graham mentioned.  The second is to
> decode the data to right after the codebook stage and then use a new set of
> codebooks (ones for a lower quality level, and re-encode) which should be,
> in theory, quite effective at reproducing what a file encoded at the lower
> quality rate would produce, I think...

that's not peeling, that's just re-encoding 

> Although this would be a little more CPU intensive, it is still much less
> intensive than encoding on-the-fly because you never leave the frequency
> domain.  But, I think what we are talking about is the first scenario, where
> coarser values are used for the residue, because of the layered nature of
> the residue quantization.  Does anyone know?
> 
> Thanks,
> Alan

<p>that first method, taking less bits per "frame" from the file instead of
reading them all is what peeling is supposed to be in vorbis. the
algorithm for deciding which bits to read i suppose is the real
question.

if say a "frame" of an ogg file is encoding from most significant bits
to least significant (low quality to high quality bits) 
128kbit
|################| 

then reading up to half will give you what encoding to 64bit (assuming
you used the same flags) gives you.  The remaining bits would be bits
only existing there for higher bits.   I guess that way would be
thinking of oggencoding as multi-pass encoding, layering data from
beginning to end of the frame.   Heh, if that's not the case then
clueless I am and that's probably the case.    but if you have to read
the entire frame then it kind of defeats the functionality of peeling
(ie. you're not peeling at all but just decoding and re-encoding )

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