[vorbis] Ogg too good?

[Wilson]

Hey there, Angsty McFistShaker.
If you read my message, you'll notice that I was commenting that I thought
RC3's encoder seemed slower than RC2's.
You'll also note that I put a disclaimer there: I might be wrong.
Further, NB that I didn't call for any actual ACTION based on my
observation. You didn't see me shout "OMG! If this doesn't speed up, I'm
going to stop giving you all that money you're not asking for in the first
place!"

By the way.. I'm scrolling through the archives, looking for a post from you
that isn't written like an asshole. I'm not finding one. Maybe you can come
up with a better search algorithm for me, Mr. Open-source Ereet Coder?

To the rest of the list: I'm sorry if mentioning my processor speed
irritated anyone. I wasn't bragging. Also, I apologize for making you read
my reply to Ed Sweetman.

----- Original Message -----
From: "Ed Sweetman" <ed.sweetman at wmich.edu>
To: <vorbis at xiph.org>
Sent: Thursday, March 07, 2002 4:59 AM
Subject: Re: [vorbis] Ogg too good?

<p>> Why cant people wait until it's really released before questioning why a
> prerelease isn't as fast as lame or some other encoder.  So, oh my the
> encoder is slower than flac and lame can run circles around it.  When
> it's released and people still aren't happy with it being so slow, the
> whole big kicker with this open source thing is that you can read it,
> then go and change it and put out your own copy.  See, you can turn that
> energy of wanting change to actually making change.  oggenc is an
> example encoder.  It uses libraries implementing the ogg codec in a way
> that allows it to be used on the most amount of systems.  That's xiph's
> purpose in creating an open source codec like this. I'm glad they're not
> wasting their time pushing cycles out of an algorithm written in x86 asm
> with special instructions from the latest cpu spec sheets because it
> shouldn't be their place to and it doesn't serve them any better to do
> so.
>
> After the codec hits the big 1.0 all the x86 asm bufs can go optimize
> the hell out of the codec and encoder, fork off their tree and maintain
> it just like mp3s are done now. Fragmentation didn't kill off mp3, but
> fragmentation makes codec evolution extremely difficult if not
> impossible. So at least wait until the codec is complete before calling
> on the hand tuning cpu specific optimization of it.
>
> Now that we're sufficiently off of the topic of the original post.  I'd
> like to point out that you can specify an abr for the files you want
> sufficiently crappy sounding. Nobody is forcing you to use -q  but the
> lowest level of -q shouldn't have to sound bad if it doesn't need to
> be.  You're sacrificing an easy to understand argument system for a full
> range scale and most people wont go for it.  But once again, open source
> allows the magical property of being able to be reprogrammed by anyone
> so you can rewrite oggenc to do what you want.  Nobody is forcing you to
> use oggenc.  Think of the whole xiph package for vorbis and ogg as the
> ISO, it doesn't have to be the only implementation of vorbis and ogg.
> The specs to the codec are openly documented.   Now lets stop bitching
> about one person's oggenc when the source is right there; make your own
> version and release it as whatever you'd like.
>
>

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