[vorbis] Bit pealing and streaming

[Keith Wright]

> From: Geoff Shang <gshang at uq.net.au>
> 
> Since I'm not a programmer and just want to get stuff worked out properly
> in my head, I'm posting this here.

I'm not a Vorbis wizard, but I think somebody should at least
make some answer, and I haven't seen another one, so I will
spout off a bit.  The wizards will no doubt correct my egregious
errors.

> The way I understand things is that vorbis is meant to be able to do
> 44.1khz audio at bit rates as low as 16 kbps per channel, at least
> in theory (see vorbis.com & vorbis.org).  However, I am led to
> understand that encoding streams below a certain data rate at
> 44.1khz will involve incoding at a higher rate and then pealing off
> bits in order to obtain the desired data size.  Is this correct?

Not quite.  There's a lot more to audio encoding than throwing away
bits.  The raw sound data consists of samples at 44 kHz, i.e. one sample
every 1/44 ms = 23 microseconds.  Each sample is a 16 bit integer giving
the instantaneous amplitude of the waveform at that instant.  That works
out to 705 kbits/sec of raw data.  If you were to compress this by
simply throwing away 9 out of 10 samples it would sound horrible
(painful speaker-damage horrible).

Fortunately sound waves are not random, but are fairly smooth and
repetitious.  The coded form does not contain samples at all.  It
contains (very roughly speaking) data about the pitch, duration, and
loudness of the notes that make up the sound.  The decoder uses that
information to rebuild the sound by regenerating the notes and adding
them together.  (Macho math supressed).  Vorbis uses a variable bit
rate encoder, which means that a minute of a simple sound, like say
the hum of a refrigerator, may be coded into many fewer bits than a
minute of, say, Frank Zappa's "Zombie Woof".  (Just as the musical
score by FZ takes more pages than "low G whole note and repeat 60
times".)

> If so, is this size point yet known or will
> this have to be determined as development proceeds?

I don't understand the question.  What "size point" are you
asking about?

> OK, now suppose you run a server like icecast 2.0, for example.
> Will it be possible for the server to receive a suitably encoded
> vorbis stream at a high rate, say 128kbps, and then serve up streams
> at the right rate for various connections?

If somebody writes the code.  I don't know what icecast 2.0 does
at this time, presumably not that.  Does it do that for sound
encoded in some other format, or are we starting from scratch?

> (e.g. pass the full stream on to people using high bandwidth
> connections, strip it down for ISDN and strip it down still further
> for modem users, all on the one server?)  If this were possible,
> this would make life much easier for content providers, being able
> to make one version of the content and letting the server slice and
> dice it to suit the listener.  This would mean the need for some
> smarts in the server and client to determine the optimal data rate.

I see no reason why that would not be possible in priciple.  At
worst you decode the Vorbis stream to get back the original
waveform, and then re-encode at the lower rate.
 
> This of course raises the issue of the processing power needed to do the
> pealing.  Is this very resource intensive?

Compared to what?  (I don't know.)  Don't try it on a TRS-80!

> Note that a person wanting to stream to a server via modem would
> have to be able to cope with the need to encode at a higher bit rate
> *and* peal the data, both in realtime, before uploading it to the
> server.  Is this asking too much?

Yes.  Re-coding at a lower bit rate is possible, but there is no
going back.  Once you have thrown away information it is gone.
If you don't ask for real-time, then it is possible.  You can
spend all day uploading the megabyte file that contains your
three minute hit single through a 2400baud modem, somebody else
could spend half a second downloading it through a T1 line.
Either way it takes three minutes to play it.

> Another question.  Seeing you can peal down 44.1khz, can you do the same
> to, say, 22.05khz and get, say, 8kbps per channel?  I kinda like the idea
> of being able to broadcast at 22.05khz in 16kbps stereo, so I'd like to
> know if I should stop dreaming now before I get too set on the idea.

This sounds like you are confusing the sampling rate of the raw sound
with the bit-rate of the encoded data.

> I am involved with a project called ACB radio
> (http://www.acbradio.org), and particularly the ACB radio
> interactive channel.

Involved how?

> If vorbis will be able to do all that I think it can (above), this
> would overcome pretty much all that MP3 does not let us do.

As Scotty says: you can't change the laws of physics.

Who programs the server?  You might reasonably lobby the Vorbis
wizards to put calls in libvorbis that would allow for re-coding
at a lower average bit rate, but that still leaves a lot of
work to make the server pick the rates and send the proper
bit stream in the proper direction.  Are the icecast programmers
interested in doing that?  I'm not sure what Icecast is.
Is it free (Open Source, GPL) software?

    -- Keith

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