[vorbis] Response to Ogg Vorbis comments

[Jack Moffitt]

Todd Day wrote:
> How many players (players that can pull an MP3 stream) are using
> Vorbis? I have used it a couple of times for testing and was
> impressed by the results. Does Winamp have Vorbis decode built-in?

Winamp just put the finishing touches on their own vorbis plugin, and we
expect it to ship in the next version.  Sonique has already had Vorbis
for some time (millions of installed sonique players are vorbis
capable).

On the Mac platform, Audio, Unsanity Echo, and Macast are all vorbis
capable.

On linux, pretty much everything is already Vorbis capable.

That really leaves Quicktime, RealPlayer, and Windows Media Player (and
iTunes, although I'm not sure if the quicktime support will fix this. or
that C&G said they'd support it at 1.0).

Quicktime plugins are already in development, and I believe the encoding
one is already finished and usable.  The RealPlayer plugin is functional
(lacks seeking) and will probably be feature complete after one more
pass.  The Windows Media Player plugins (a set of DirectShow filters)
are soon to be released.  I believe they already work, though I haven't
tested them.

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.

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.

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 :)

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.

boss wrote:
> my first impressions ( tests) were all made using fixed rate encoding          
> in Vorbis ; I also did not mention in my former post that I had to go
> VBR with any other mp3 encoder engine to get close to Vorbis in fixed
> bit rate ! so I fully disagree here with your 'golden ear' assumption

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

boss wrote:
> now it IS true that selecting a lower bit rate , for instance 64k
> stereo, would produce some 100k or so stream ; which here looks like
> possible VBR ; 15 point each....

The current vorbis tools don't do downsampling or downmixing, so you'll
have to do that as a preprocess step (this will change in the next
version I believe, and the encoder tools will do these kinds of
preprocessing for you like the other tools do).  If you preprocess your
file, you'll get lower bitrates.  But really, we haven't started tuning
the modes for < 80kbps.  That will come in the RC1 encoder, so asking
for 64kbps will get you 64kbps :)

Amir wrote:
> But it will not guarantee that the bit rate stays constant
> throughout the clip, ruling it out for general streaming use.

I disagree, and there's publically available code to prove it.

Amir wrote:
> From your comments around stereo seperation, it
> sounds like Voribs may also be staying away from it (although this
> could also be due to VBR mode). Unfortunately, this also means that
> the codec has to try a lot harder to squeeze the bits as there is
> twice as much high frequency information that has to be coded. But we
> believe if someone created stereo content, they intend for it to stay
> that way rather than be converted to "half mono".

Currently channel coupling (a generalized method of combining channels,
as opposed to Join Stereo or Intensity Stereo which are specific on
numbers of channels) is only implemented in the decode side of Vorbis,
for the RC1 decoder which we just released.  Test encodes of coupled
content are encoding at about 40kbps below what they encode at
uncoupled.  A while it still needs tweaking, everyone on the lists has
been very impressed.

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

boss wrote:
> now Vorbis is no
> new marvel since it can't keep these features with lower bit rates
> (ie 64k stereo) ; too bad

Preprocess the file as mentioned above and see if that works. From all
reports, it still sounds pretty good, and we haven't done tuning for
those rates yet.  You can be assured that when 1.0 hits the streets,
you'll be able to make awesome sounding 64kbps encodings.

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.

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.

boss wrote:
> well after this good surprise and since you also assume Microsoft has
> no interest to settle for standards (ISO Mpeg4), I am looking after
> Tarkin, the video conterpart of Vorbis ; if it's again that good ,
> that could be interesting ....

Tarkin has a long road ahead of it, although we do have high hopes.
Video compression, while in some ways easier, is also somewhat harder,
because there's not a century of research to build from.

Right now there are 3 implementations under the Tarkin moniker.  One on
 3D wavelets, another with 3D wavelets, and one with 2D wavelets plus
some motion compensation.  So far with the limited effort we've
expended, we've gotten some good results.  If anyone is interested in
partcipating in design, discussion, etc, I encourage you to venture over
to www.xiph.org.  The tarkin-dev list isn't very high traffic, but the
discussions are very good.

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.

boss wrote:
> PS : I will try to take all this to Vorbis if ...they feel interested
> ! they are busy after the Tarkin video codec ; another soon coming
> nail (?)

I think everyone should join the vorbis discussion list or the vorbis
developer list who is interested in this.  You'll have a chance to
scream at us when the codec doesn't sound to your liking, and lots of
questions will be answered :)  You can find all the subscription
information and archives at www.xiph.org.

boss wrote:
> PS2: may be we should end this thread as Amir suggests ; unless
> interesting revelations

I will have Monty join the list, and he can go head to head with
everyone in technical detail.

I'm glad to see discussions like this taking place in other places,
although it does make it hard for me to find and participate.  Thanks to
Kevin (who is a participater on the vorbis discussions lists) for
pointing me in this direction and giving me the old messages to peruse.

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 :)

jack.

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