Vorbis - Jun 2001 - RE: [advanced] Response to Ogg Vorbis comments

> From: Jack Moffitt [mailto:jack@icecast.org]
> 
> So in the very near future, I don't think that there will be any
> non-vorbis capable players.  And for the most part, I think Vorbis
will
> be included in most players, though I have little hope that Microsoft
> will allow Vorbis to stand side-by-side with WMA.
There is a big difference between having a codec available for some
player and having the same "included" with it.  I will let Real and
Apple speak for themselves but I would be very surprised if either one
will ship your code.  If this is wrong, please give us some specifics.
 
> Amir Majidimehr:
> > Vorbis is a variable rate codec so if by "pulling it in" you
mean
> > streaming, this is not going to work (or work well) for a while. You
> > need a constant bit rate codec for this.
> 
> Bullshit, Amir.  You're just spreading fiction.  Icecast 2.0 already
> supports Vorbis and there are several Vorbis streams up and running if
> you want to listen.  One of the biggest broadcasters of trance
(Digital
> Imported) is testing early releases right now.
 
Over dial-up modems with fixed data rate? I can't imagine you are doing
this with a VBR codec.  But if you are doing it, I am sure I and the
rest of the list like to understand how it works.  If by streaming you
mean that you need a channel that is faster than the stream, then I
suggest that it is not streaming in the sense that the rest of industry
understands it.  When we stay streaming, it means that the data is
metered and is transmitted at a precise rate so that it can be received
on fixed-rate channels (e.g. modems).  
> It does work, and it does work well.
> 
> You are also encouraged (as is everyone else) to send us test samples
> that don't sound good.  We'll fix the bugs and make new encoders
> available.  Constrast this to development cycle of MP3, AAC, or WMA :)
I will send you samples as soon as you start doing the same with WMA
:-).  

I am not sure what the comment means regarding WMA.  We are on forth
generation WMA encoder and have made every version available on the web.
I agree AAC and MP3 cost money and the former is hard to get but such is
not the case with WMA.
> There's a common misconception that a format's quality is set in
stone.
> You've only to listen to a beta1 encoded track next to a beta4 encoded
> track to know that that is not the case.  The RC1 encoder will again
> drastically improve quality.
We have no misconception here.  But I hope you understand that we can
only test and evaluate what you have today.  Comparing your tomorrow's
version against today's version of everyone else doesn't make sense now,
does it?
> The Xiph.org Vorbis code is all VBR, but it's not totally
free-reigning
> VBR.  If you try to encode some samples at 128k, it might throw you
down
> to 32k if it can't reasonable do so (try sox'ing a .wav down to
11025Hz
> and then encoding to see what I mean).  I doubt any of the encoders
> currently out there are really producing CBR-like files.  The Vorbis
> encoder will be capable of doing so, but it's not our first priority.
You don't have to have any doubts about the other codecs.  Just encode
different content with them and you will see that they will create
identical length files regardless of input signal.

Maintaining quality under all signal conditions with a CBR (or
"CBR-like") codec is astonishingly hard.  Just look at how bad the
Xing
MP3 encoder sounded like compared to FHG reference encoder.  This stuff
is not easy to do even when someone gives you the blueprints of a codec
as is the case with MP3.

I manage the group that develops WMA so I know the pain we go through to
maintain consistent quality with constant bit rate.  It is as hard to do
as developing the codec core itself, if not harder.

I am sure you guys are smart enough to tackle the above problem but I
for one, will not believe that your quality will stay the same.  It will
not.  It is a fact of nature.
>  I
> originally thought it was going to be much more important for
streaming,
> but apparently this isn't so.  Vorbis in it's current VBR-like form
> works wonderfully.
Again, what you call streaming and what we call streaming are two
different things.  Just because a server can send the bits and have the
receiver play it as it receives it is not enough.  The trick is to meet
the bandwidth constraints of the link.  Without this, it is not the real
thing.
 
> boss wrote:
> > possibly from design, Vorbis optimized its encoder for
'standard'
> > 128k; which could explain they always get a *file size* even lower
> > than a 128k fixed rate will produce ; then from witnessing the tight
> 
> It's true that we've concentrated our efforts on the 80kbps -
160kbps
> range up until now, simply because that's where most music is being
> encoded.  
I am not sure why it would be important to consider what most music is
encoded at.  People want the best quality at the lowest bit rate and get
stuck with MP3 at 128kbps since it doesn't sound good at lower rates.  

I am sure you have tried to use your codec at lower rates and found the
quality much less than optimal.  The job gets much harder at lower
rates.  Trust me when I say this.  Getting WMA to do stereo at 48kbps
while retaining 44Khz sampling rate was no easy matter.  You have your
work cut out for you if ever go down to this space :-).
> Channel coupling will take this same quality and drop it in
> bitrate quite a bit, and at the same time we're now starting to
> concentrate on lower bitrate modes.  At the end of the proverbial day,
> we should be kicking ass up and down the bitrate spectrum, from 16kbps
> to 350kbps.
This reminds me of a story :-).  A guy goes to the butcher and asks how
much steaks are per pound.  The butcher replies $10.  The guy says that
the butcher across the street has stakes for $5.  Butcher asks him why
he doesn't go and buy it there.  The guy responds that the other butcher
doesn't have any!

I guess the morale of the story is that only fair game is to compare
what you have *today*, against what others have *today*.  By the time
you reach your goal of having good quality down to 16kbps, other people
may have their next version too.
> Amir wrote:
> > Also, since the VBR fluctuations will be content dependant, there is
> > really no way to be sure that it will stay within the bounds that
you
> > saw.
> 
> Sure there is. The current tools just don't implement it yet.  It was
> always the goal to be able to specify constraints.
Are you asking us to evaluate your technology based on your "goals"
rather than what you have already developed?  I wish people would let me
do that :-).
> Amir wrote:
> > The net is that a rate control and/or buffering is needed to smooth
> > out these fluctuations and such a logic *will* reduce quality by 30%
> > or more in my experience.
> 
> I'm not the best person to address this technically, but I do think
you
> should qualify your statements.  This statement also applies to your
own
> codecs as well as others.
 
This statement does NOT apply to WMA codec since WMA only supports CBR
encoding (we provide VBR for *video* only).  Take *any* signal and feed
it into WMA and you will see that it creates the same output file size.
Try forcing your codec to do this and you will see a noticeable drop in
quality with any non-trivial content.  We and others have done numerous
studies in this area.  This is not just conjecture.  VBR gives
tremendous advantage to a codec, be it video or audio.  You can not
marginalize the advantage of VBR (better quality) or its disadvantage
(can not stream on fixed-rate channels or control the output file size).
> boss wrote:
> > - ho yes one of my acoustic guitars which is fitted with some
> > Electret mics inside ; it gives such wild transients and rich
> > harmonicc content that ALL codecs I have tested nearly collapse ;
> > even at 128k
> 
> We'd love to get any good test samples you have and add them to our
> tuning and QA process.  Please contact me if you are interested.
Be sure to test Yannick's clip when you implement CBR.  I will assure
you that your codec will fall apart with the rest of them :-).
> Amir, I'm glad to see that your being a lot more neutral in your
> discussions than you were a year ago.  I guess that means we must have
> made some minor impact :)
Me, neutral?  Nah...  you are going to get me fired this way :-).
 
> jack.
Amir

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> > We'd love to get any good test samples you have and add them to
our
> > tuning and QA process.  Please contact me if you are interested.
> 
> Be sure to test Yannick's clip when you implement CBR.  I will assure
> you that your codec will fall apart with the rest of them :-).
Let's have Yannick send the clip, and set the parameters of a wager in
text, hm?  I'm sporting if you are! ;-)

Monty

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, 22 Jun 2001, Amir Majidimehr wrote:
> I am not sure what the comment means regarding WMA.  We are on forth
> generation WMA encoder and have made every version available on the web.
> I agree AAC and MP3 cost money and the former is hard to get but such is
> not the case with WMA.
I'm not responding to Amir directly, because I hope he doesn't see my
reply. I dont want to give m$ ideas that would make WMA better.

Anyway, I sincerely hope m$ *doesnt* port WMA to linux/bsd/etc, and I
sincerely hope m$ keeps WMA closed source. By doing so they will *ensure*
the failure of WMA on anything but the narrow tunnel vision field of view
of platforms that m$ "supports".

The precise reason why mp3 succeeded where aac/etc has utterly failed is
because mp3 is widely available on *all* platforms. Vorbis has the
potential to kick m$' sorry ass all over the playing field.

-Dan

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> > Bullshit, Amir.  You're just spreading fiction.  Icecast 2.0
already
> > supports Vorbis and there are several Vorbis streams up and running if
> > you want to listen.  One of the biggest broadcasters of trance
> (Digital
> > Imported) is testing early releases right now.
>  
> Over dial-up modems with fixed data rate? I can't imagine you are doing
> this with a VBR codec.  But if you are doing it, I am sure I and the
> rest of the list like to understand how it works.  If by streaming you
> mean that you need a channel that is faster than the stream, then I
> suggest that it is not streaming in the sense that the rest of industry
> understands it.  When we stay streaming, it means that the data is
> metered and is transmitted at a precise rate so that it can be received
> on fixed-rate channels (e.g. modems).  
This is the first time I (as a user) has every heard this definition of
streaming. If it gets sent, decoded and played in realtime over a network -
it's streaming. And if a Vorbis VBR stream doesn't quite use 100% of my
available bandwidth, so what? If the quality beats the MP3 version which
*does* consume 100% of my bandwidth, I'd be an idiot to choose the MP3 one.

You seem to take the stand, "use all the bandwidth available for maximum
quality". To me, that's backwards. Since we're talking streaming,
we want to
*conserve* bandwidth. In other words, "use enough bandwidth to get adequate
quality, but don't *waste* bandwidth". ("Wasting" bandwidth
being things
like using 128 kbit to transfer 10 seconds worth of silence...).

A VBR stream at 100 kbit average bitrate might yield better quality than a
128 kbit stream using the same encoding/decoding algorithms. The former
conserves bits when they're not needed, and is able to punch up the rate
when it *is* (taking into account of course, the limitation of the target
bandwidth and buffering). 

And even if that's not the case (it becomes problematic because if you allow
peaks above the maximum bandwidth of the stream, you need a way to ensure
that it doesn't get clogged), I'll happily use some extra availalbe
bandwidth taht VBR gives me.
> We have no misconception here.  But I hope you understand that we can
> only test and evaluate what you have today.  Comparing your tomorrow's
> version against today's version of everyone else doesn't make sense
now,
> does it?
It does to me. I, as a user, am interested in what Vorbis will be like when
it's done. *Any* codec sucks in its infancy. *Any* codec will gradually get
better as development progresses. So yes, it makes *perfect* sense to me to
compare, say, Vorbis 1.0final to MP3pro of WMA. Especially when comparing to
mature codecs. If we're comparing two projects in similar situation, I might
be interested in knowing that the currnet version of X is better than Y,
because it may mean X is progressing faster / has a better chance of
eventuelly yielding the best results. This isn't the case here.
> I guess the morale of the story is that only fair game is to compare
> what you have *today*, against what others have *today*.  By the time
> you reach your goal of having good quality down to 16kbps, other people
> may have their next version too.
And fusion in its current state may not be a viable energy source, but that
doesn't stop it from potentially solve much of the worlds environmental
problems in the future - and one certainly doesn't abandon it.


-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller
<peter.schuller@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis/attachments/20010623/39558857/part-0001.obj

If I say something incorrect, I don't know what I'm talking about
anyway.
> > From: Jack Moffitt [mailto:jack@icecast.org]
> >
> > So in the very near future, I don't think that there will be any
> > non-vorbis capable players.  And for the most part, I think Vorbis
> will
> > be included in most players, though I have little hope that Microsoft
> > will allow Vorbis to stand side-by-side with WMA.
>
> There is a big difference between having a codec available for some
> player and having the same "included" with it.  I will let Real
and
> Apple speak for themselves but I would be very surprised if either one
> will ship your code.  If this is wrong, please give us some specifics.
As pointed out before, if someone has a song they want to listen to, they
will download the plug-in.  And once Vorbis is popular, it will be included
with the various players.
> > Amir Majidimehr:
> > > Vorbis is a variable rate codec so if by "pulling it
in" you mean
> > > streaming, this is not going to work (or work well) for a while.
You
> > > need a constant bit rate codec for this.
> >
> > Bullshit, Amir.  You're just spreading fiction.  Icecast 2.0
already
> > supports Vorbis and there are several Vorbis streams up and running if
> > you want to listen.  One of the biggest broadcasters of trance
> (Digital
> > Imported) is testing early releases right now.
>
> Over dial-up modems with fixed data rate? I can't imagine you are doing
> this with a VBR codec.  But if you are doing it, I am sure I and the
> rest of the list like to understand how it works.  If by streaming you
> mean that you need a channel that is faster than the stream, then I
> suggest that it is not streaming in the sense that the rest of industry
> understands it.  When we stay streaming, it means that the data is
> metered and is transmitted at a precise rate so that it can be received
> on fixed-rate channels (e.g. modems).
I can't believe you're actually trying to argue this.  First, all
internet
connections are variable, meaning you can't play a 56k file on a 56k
connection.  You always play a stream slower than the channel (or you need
"a channel that is faster than the stream", as you put it).  Second,
streams
are buffered, so VBR will fill and empty the buffer accordingly.  VBR is
actually superior in this sense, since the encoder can reduce the bitrate
drastically (such as the beginning/end of the file and other periods of
silence) while CBR must waste unnecessary data.
> > It does work, and it does work well.
> >
> > You are also encouraged (as is everyone else) to send us test samples
> > that don't sound good.  We'll fix the bugs and make new
encoders
> > available.  Contrast this to development cycle of MP3, AAC, or WMA :)
>
> I will send you samples as soon as you start doing the same with WMA
> :-).
I'll send the Vorbis code when you send the WMA code :-).  (or at least the
decoding specification)
> I am not sure what the comment means regarding WMA.  We are on fourth
> generation WMA encoder and have made every version available on the web.
> I agree AAC and MP3 cost money and the former is hard to get but such is
> not the case with WMA.
Whoa, cowboy.  WMA may not cost money but it is incredibly restrictive.  I
downloaded a WMA song once, and WMP required that I be logged onto the
Internet to listen to the song.  WTF?  How is that free, when I have to pay
for a phone line and an Internet connection to listen to the song?  Maybe it
is possible to encode WMA without this restriction, but how long until MS
releases a new version (which encodes files incompatible to the old version)
which requires "authentication".
> > There's a common misconception that a format's quality is set
in
> stone.
> > You've only to listen to a beta1 encoded track next to a beta4
encoded
> > track to know that that is not the case.  The RC1 encoder will again
> > drastically improve quality.
>
> We have no misconception here.  But I hope you understand that we can
> only test and evaluate what you have today.  Comparing your tomorrow's
> version against today's version of everyone else doesn't make sense
now,
> does it?
A Microsoft employee criticizing the announcement of future developments?
Vorbis must really be corrupting you :).  I never thought I would hear this
from Microsoft:  "Comparing your tomorrow's version against today's
version
of everyone else doesn't make sense now, does it?"
> > The Xiph.org Vorbis code is all VBR, but it's not totally
> free-reigning
> > VBR.  If you try to encode some samples at 128k, it might throw you
> down
> > to 32k if it can't reasonable do so (try sox'ing a .wav down
to
> 11025Hz
> > and then encoding to see what I mean).  I doubt any of the encoders
> > currently out there are really producing CBR-like files.  The Vorbis
> > encoder will be capable of doing so, but it's not our first
priority.
>
> You don't have to have any doubts about the other codecs.  Just encode
> different content with them and you will see that they will create
> identical length files regardless of input signal.
>
> Maintaining quality under all signal conditions with a CBR (or
> "CBR-like") codec is astonishingly hard.  Just look at how bad
the Xing
> MP3 encoder sounded like compared to FHG reference encoder.  This stuff
> is not easy to do even when someone gives you the blueprints of a codec
> as is the case with MP3.
>
> I manage the group that develops WMA so I know the pain we go through to
> maintain consistent quality with constant bit rate.  It is as hard to do
> as developing the codec core itself, if not harder.
>
> I am sure you guys are smart enough to tackle the above problem but I
> for one, will not believe that your quality will stay the same.  It will
> not.  It is a fact of nature.
As has been pointed out by the Vorbis developers, VBR has proven superior to
CBR.  Kudos to WMA's CBR ability, but sorry, not needed.
> >  I originally thought it was going to be much more important for
> streaming, but apparently this isn't so.  Vorbis in it's current
VBR-like
form
> > works wonderfully.
>
> Again, what you call streaming and what we call streaming are two
> different things.  Just because a server can send the bits and have the
> receiver play it as it receives it is not enough.  The trick is to meet
> the bandwidth constraints of the link.  Without this, it is not the real
> thing.
So VBR using fewer bits than CBR is bad?  What???
> > boss wrote:
> > > possibly from design, Vorbis optimized its encoder for
'standard'
> > > 128k; which could explain they always get a *file size* even
lower
> > > than a 128k fixed rate will produce ; then from witnessing the
tight
> >
> > It's true that we've concentrated our efforts on the 80kbps -
160kbps
> > range up until now, simply because that's where most music is
being
> > encoded.
>
> I am not sure why it would be important to consider what most music is
> encoded at.  People want the best quality at the lowest bit rate and get
> stuck with MP3 at 128kbps since it doesn't sound good at lower rates.
>
> I am sure you have tried to use your codec at lower rates and found the
> quality much less than optimal.  The job gets much harder at lower
> rates.  Trust me when I say this.  Getting WMA to do stereo at 48kbps
> while retaining 44Khz sampling rate was no easy matter.  You have your
> work cut out for you if ever go down to this space :-).
People want their music to sound as good as possible.  I have switched from
encoding at 128k to 192k (even though the encoders are now better at lower
bitrates) since Internet speeds are faster (modem -> DSL/cable), music is
more plentiful (gnutella, etc.), and hard drives are increasing in size (10
GB -> 40/60 GB).  Of course, Vorbis bitrate peeling will be awesome for
devices with storage limits.
> > Channel coupling will take this same quality and drop it in
> > bitrate quite a bit, and at the same time we're now starting to
> > concentrate on lower bitrate modes.  At the end of the proverbial day,
> > we should be kicking ass up and down the bitrate spectrum, from 16kbps
> > to 350kbps.
>
> This reminds me of a story :-).  A guy goes to the butcher and asks how
> much steaks are per pound.  The butcher replies $10.  The guy says that
> the butcher across the street has stakes for $5.  Butcher asks him why
> he doesn't go and buy it there.  The guy responds that the other
butcher
> doesn't have any!
>
> I guess the morale of the story is that only fair game is to compare
> what you have *today*, against what others have *today*.  By the time
> you reach your goal of having good quality down to 16kbps, other people
> may have their next version too.
Once again, why is it wrong to tell the mailing list of future developments?
> > Amir wrote:
> > > Also, since the VBR fluctuations will be content dependant, there
is
> > > really no way to be sure that it will stay within the bounds that
you
saw.
> >
> > Sure there is. The current tools just don't implement it yet.  It
was
> > always the goal to be able to specify constraints.
>
> Are you asking us to evaluate your technology based on your
"goals"
> rather than what you have already developed?  I wish people would let me
> do that :-).
Why the personal attacks?  Who doesn't set goals?  Except certain companies
which wait for others to develop the technology, then copy ....
> > Amir wrote:
> > > The net is that a rate control and/or buffering is needed to
smooth
> > > out these fluctuations and such a logic *will* reduce quality by
30%
> > > or more in my experience.
> >
> > I'm not the best person to address this technically, but I do
think you
> > should qualify your statements.  This statement also applies to your
own
> > codecs as well as others.
>
> This statement does NOT apply to WMA codec since WMA only supports CBR
> encoding (we provide VBR for *video* only).  Take *any* signal and feed
> it into WMA and you will see that it creates the same output file size.
> Try forcing your codec to do this and you will see a noticeable drop in
> quality with any non-trivial content.  We and others have done numerous
> studies in this area.  This is not just conjecture.  VBR gives
> tremendous advantage to a codec, be it video or audio.  You can not
> marginalize the advantage of VBR (better quality) or its disadvantage
> (can not stream on fixed-rate channels or control the output file size).
VBR is better, so we only do CBR.  Did you learn this at Microsoft, or
before?
> > Amir, I'm glad to see that your being a lot more neutral in your
> > discussions than you were a year ago.  I guess that means we must have
> > made some minor impact :)
>
> Me, neutral?  Nah...  you are going to get me fired this way :-).
>
> > jack.
>
> Amir
Vorbis really is a cancer/virus, look what they've done to Amir :)

Greg

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Fri, Jun 22, 2001 at 11:37:01PM -0700, Amir Majidimehr wrote:
[snip]
> >  I
> > originally thought it was going to be much more important for
> streaming,
> > but apparently this isn't so.  Vorbis in it's current VBR-like
form
> > works wonderfully.
> 
> Again, what you call streaming and what we call streaming are two
> different things.  Just because a server can send the bits and have the
> receiver play it as it receives it is not enough.  The trick is to meet
> the bandwidth constraints of the link.  Without this, it is not the real
> thing.
If you are streaming over any best effort network (like the Internet), you
*MUST* have buffering. Why? Because the bandwidth is variable, and can have
bursts of latency. 

VBR streaming is totally possible as long as you bound the stream to a
maximum bitrate within the buffering window. 

No transform based codec can be a pure CBR codec: In a truly CBR codec,
each input sample is represented with a definite number of bits. In a
'CBR'
transform codec, a non-time-domain 'block' is represented in a certain
number
of bits. From a time domain prospective, the bitrate value of bits within
the block are clustered around 'interesting events: The bitrate varies but
remains constant within the block.

Some codecs (MP3, probably WMA) allow a small amount of block to block
variance by using a bit reservoir technique, even in a CBR mode.  This is
just an assumption of a small buffering size in the player codec into the
format, and can improve quality somewhat and simplify some of the bit
allocation issues (mostly, achieving a constant bitrate after performing
lossless entropy coding).

You seem to have a big problem separating the format (Vorbis) from it's
implementation (libvorbis). Today the released libvorbis does not support
much bitrate control (a stereo 2channel 44.1k file encoded with beta4 @128kbit
can be from 2kbit/sec-306kbit/sec), nor a few other things like channel
coupling..  BUT THE FORMAT (and the decoder) already do, I can give you
files that are bitrate shaped, and channel coupled if you like to test them
on the decoder.  The current encoder may be immature, but that doesn't
reflect on the superiority of the *format*.

You make the claim that VBR is much easier then CBR, and from a bit
allocation perspective, it can be. But in most other ways, it's a lot
harder: For example, your perceptual model has to be smarter. For a CBR
stream, the overall quality to the listener (which is determined by the worst
audible distortion) could be achieved by a much lower bitrate as you are
only under pressure a small amount of the time, the rest of your frames are
easy, the perceptual model functions to tell you where to put your bits, not
how many you need. The extra bits on the majority of frames makes it easy to
cover flaws in your psymodel.

If VBR were so easy, why don't you perform 'maximum bitrate
encoding'?
Right now, you faithfully encode a block of digital silence into many bits.
Although having a maximum bitrate over a time window is useful, there is *NO*
advantage to wasting bits, if you had some kind of strange physical
transport that needed to be stuffed full, you could pad your frames
(hopefully with non-realtime data useful to other activities, but otherwise,
zeros).  The reason that you don't is that your poor psymodel and inflexible
bit allocation scheme will lie to you and cause you to make suboptimal
quality sounding files in such a way.

The vorbis *format* offers a much better solution: Encode in such a way as
to achieve a consistent high level of quality, then shape the output to
meet the listener requirements (via bitrate peeling), in realtime and on
demand. No extraneous bits are wasted (such bits could be used to reduce the
bitrate reduction required to fit a video codec into the same fixed pipe, or
just left untransmitted to be a better netizen).

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

#if Amir Majidimehr
> This statement does NOT apply to WMA codec since WMA only supports CBR
> encoding (we provide VBR for *video* only).  Take *any* signal and feed
> it into WMA and you will see that it creates the same output file size.
> Try forcing your codec to do this and you will see a noticeable drop in
> quality with any non-trivial content.  We and others have done numerous
> studies in this area.  This is not just conjecture.  VBR gives
> You can not marginalize the advantage of VBR (better quality) or
> its disadvantage (can not stream on fixed-rate channels or control 
> the output file size).
Er, _can_ stream on fixed-rate channels. You just use less of the 
bandwidth when you don't need it all.

Why would you want to control the output file size, except to know the 
maximum size that it would be ? Ok, you might want to have an extremely 
accurate progress meter for the user downloading a file which is being 
produced on-the-fly, but I think they'll live with a couple of percent 
either way, no ?

Rik

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> understands it.  When we stay streaming, it means that the data is
> metered and is transmitted at a precise rate so that it can be received
> on fixed-rate channels (e.g. modems).
[snip]
> This statement does NOT apply to WMA codec since WMA only supports CBR
> encoding (we provide VBR for *video* only).  Take *any* signal and feed
> it into WMA and you will see that it creates the same output file size.
[snip]
> tremendous advantage to a codec, be it video or audio.  You can not
> marginalize the advantage of VBR (better quality) or its disadvantage
> (can not stream on fixed-rate channels or control the output file size).
This would mean that streaming video, as you understand it, would either not 
be possible at all, or mean a huge waste of bits, and (as you use VBR for 
video) that Microsoft chose the first option. Right ?

Go Tarkin! =)


-- 
Trick

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.