[vorbis] Graceful degradation of signal

[Johan Ovlinger]

Hello all. 

In the shower the other day (where most of this sort of musing gets
done, eh?) I was thinking about graceful degradation of audio signals.
Let me apologise in advance if these are elementary concepts or if I
demonstrate a complete lack of insight -- I don't rate even a dabbler
status in the area of audio codecs.

Anyway:

If we have a 128kbs signal coming down a *udp* channel with close to
25% packet loss, it would be really nice if it sounded like a 96kbs
signal, not a choppy 128kbs.

Short question: is this possible and feasible?

Extended question/scenario: 

It is of course easy to achieve if we are unconcerned about the
absolute quality. Just define a 128kbs stream to be a 2-redundant
64kbs stream, and voila, we have graceful degradation. 
That's none to nice tho. That's still an all-or-nothing affair. 

Instead, we'd like to have the property of the codec that it be
possible to separate the encoded signal into "quality shells" (to
invent a term). A necessary property of such a shell is that they be
additive onto the next lower rung. (sorry for no doubt misusing
terminology) Ie:

a 128kbs shell is equiv. to the 64kbs shell + 64kbs extra information

Now we can acheive graceful degradation by sending the various shells
with varying degrees of redundancy. For example, 
the 0->32kbs shell might  be sent 3/2 (ie 1 parity bit for 2 data) and 
the 32->64kbs shell might be sent 5/4 and 
the 64kbs->128kbs shell      sent 9/8.

that adds up to sending 17/14 which is something like 155kbs instead
of the 128kbs data stream. However, we are now able to accept a 11%
drop rate before noticing any degradation, up to 20% with slight
degradation, and a 33% rate for extreme degradation.

*However, the sound will still be continuous, although with decreasing
quality* 

Users accept drops in quality rather than glitches (source: pulled out
of a hat).
 
So now that I've demostrated my ignorance, I invite ya'll to tear the
idea to shreds. I imagine that the feasability of producing a codec
with the quality shells will be the most glaring flaw.

This is of course only one approach. If any others (or indeed this
one) have been investigated, please point me in the right direction.

Johan

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