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

[Peter Schuller]

> > 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 at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at 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