[vorbis] RE: [advanced] Response to Ogg Vorbis comments

[Amir Majidimehr]

> From: Jack Moffitt [mailto:jack at 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 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.