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

[Greg Hogan]

If I say something incorrect, I don't know what I'm talking about anyway.

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

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