I just noticed that I'm getting a vendor string of "Xiph.Org libVorbis I 20040629" for the impulse_trigger_profile version of oggenc, which is contrary to what is listed in the head post - I got the same from both the 1.1rc1 and 1.1 compiles (of both stock and itp versions.) These are linux binaries.

Also - quick question. Is there a statically linked linux binary of aotuvb3 anywhere? I made one myself, but it's optimized for my system. I can easily make a generic version if there is a need for it.

The 1.1 with ITP Windows binary from Rarewares is the only one with the Xiph.Org libVorbis I 20040920 Vendor string AFAIK.

I seem to recall that the date I put on the Rarewares offerings was the release date of 1.1, although the libs were unchanged from the RC1 release which was, I think, the earlier date. So, there is no difference between them.

The reason the two dates remain is that Xiph made their release with the earlier date in place and could not then sensibly change the date, and I too was reluctant to change the date on the Rarewares releases for the same reason.

So, sorry for the confusion, but they are one and the same thing.

I got similar results today. The P4 version is faster for me too.

According to Wikipedia, AMD64 supports SSE2, so I guess there's nothing wrong with using SSE2-optimized binaries.

Eh? What about SSE3, you say? I suspect the current compiles don't use SSE3.

Well SSE2 was a pretty significant thing - double precision floating point units basically completely replacing the x87 in functionality. SSE1 only gave single precision (AFAIK) so it was good for stuff like 3D, but the x87 had to be used for double. My understanding is that when SSE was originally designed it was more like SSE2 but Intel couldn't get it to work with the Pentium 3, so they had to cripple some of the pipelines. Then they got it right with their new P4 architecture. This is all very "I remember reading something 5 years ago", so i could be way off base.

Now because of that, the P4 got a piece of shit x87 unit, while the Athlon (which didn't have any SSE at first) had a really good one. So that's why Athlon binaries compiled with, say, --fpmath=sse (in GCC) don't run that much quicker anyhow. The P4 BADLY needs to be optimized for SSE/SSE2.

Athlon64 does support SSE2, so P4 binaries should by and large work fine on it.

SSE3 (again, AFAIK) is only a few extra instructions added to the SSE2 unit... I don't even know what they're good for.

The general concensus on the AcesHardware forum seems to be that SSE3 is somewhat of a misnomer, SSE2+ would be more accurate. That said, it does bring some artchitectural improvements that may benefit some SSE code.

The SSE2 is only there because ICL8 can vectorise code by itself, which is a nice feature, but it'd be much better (and faster still) if Vorbis supported it natively. There was a japanese guy who created Archer for this. I'd love to see that tested and integrated with the next Xiph release.

BTW, x87 floating point is 80 bit precision, SSE is 64 bits. Do 16 bits less really cause an unacceptable loss in encoding quality?

No, moreso because intermediate results in x87 code are usually only stored with 64 bit precision. C doesn't guarantee more than 64 bits precision to start with.

My first appearance on this forum, so perhaps a silly question, but anyway...
I was wondering if it whould be right to say that -q4 (nom. 128Kbps | aver. 117Kbps) gives the same (or better) quality as LAME 128Kbps CBR !?
It's just that I'm at the point of choising between Vorbis or MP3, and I've decided to go with Vorbis. I prefer low filesize, but with a sound quality that is at least equal (or better) to MP3 @ 128Kbps.
Thanks in advance

According to This multiformat 128kbps listening test Vorbis one the whole outperforms MP3 (and all other tested formats) at ~128kbps VBR. Vorbis has improved since, lame has not, at least, 3.96 is still the latest official version. In addition to that, the MP3 files used in that test were in VBR mode which generally gives quite an improvement over 128kbps CBR.

In short yes, i'd say you're better off with Vorbis, but of course the only way to be sure is to try both and compare the results.

Not quite right.
Alpha version of 3.97 performs quite well at -V4 and -V5 and, in rare cases, may even outperform Vorbis on the same bitrate! On the other hand, AAC is an even more dangerous competitor.
However, Vorbis aoTuV pre-beta 4 is still my favourite lossy codec for <128 kbps.

Edit: mistakes.

True, but it's alpha, my post was about stable versions. But yeah, aac is the most dangerous competitor. But it's quality encoders are not free

Wasn't aoTuV pb4 tuned to give improvement primarily at lower bitrates? <q4?

So, Vorbis @ q4 is quality-wise always better then MP3 @ 128Kbps CBR?
Or is Vorbis @ q3 even ≥ MP3 @ 128Kbps CBR?

It all depends on the individual, so you really have to do your own tests. For me OGG blows away everything 96k and up. That's from my own extensive ABX testing (using foobar2000), and is actually partly why I ended up with the portable player I have. Yeah I can hear artifacts, but I find their least annoying in the Vorbis format. With LAME I can ABX 320k encode pretty reliably fwiw, and this is why I stopped using MP3. Everyone is different in what they can and cannot hear, as well as what is and what is not acceptable to them. This might help you though:

http://www.rjamorim.com/test/multiformat128/results.html

AFAIK, you can install demo version, grab the dlls and use them with LoggerSoft's frontend without paying a cent.


Oops, I meant <128 kbps.


Generally, it depends on a huge load of factors including your own ability to spot specific artifacts. But, to avoid TOS #8 violation, I'd say: with latest versions, mostly, yes. Sometimes, no. Try for yourself.
As from my own experience, I managed to get awesome sounding samples @45 kbps with Vorbis pb4.

Bear in mind that vorbis is not as widely compatible as MP3, meaning that the widely deployed players do not support it out of the box.
If compatibility is an issue you are better off with MP3.
IMO wide compatibility is more important than the quality difference that is marginal favouring vorbis for my ears.

edit: typo

Until the demo runs out anyway. iTunes is pretty good, and VBR is right around the corner though.

... and how is this relevant with recommended Vorbis encoders and settings, again?

Yeah i've had good results with aoTuV pb4, i'm setting up a little free internet radio station and at q-2 mono it's officially 26kbit, but it tends to chronically overshoot to ~32, and it sounds pretty damn good.

Which brings me to something else, is there any way i can make oddcast tell the vorbis dll's to use --managed?

Time to update the post.
1. Oggenc is updated to 2.6.
2. Add aoTuV pb4, b4, merged 1.1.1+b4 and Archer/Lancer's version strings.
3. Consider making 1.1.1b4 version the recommended one.

I make some ABX test with problematic samples (not very strong, but results are trustworthy I hope) with aoTuV b4 merged 1.1.1 and 1.1.1 official at q4 and q6.
My personal conclusion: aobeta4 can't do any worse than Vorbis 1.1.1 [edit: at least with no depression) I agree with Mo0zOoH

Ok, this will sound lame at first sight, but please don't flame my intention. I love Ogg Vorbis ever since I tried it 3 years ago, yet with the ascension of lossless formats in popularity and their comparison with the lossy ones I have now my own doubts if I should keep my own backup CD collection as Vorbis or FLAC. I seriously would rather use Vorbis; FLAC is still huge, so I decided to post on this thread in case someone might have make comparison tests regarding FLAC and Vorbis, or how much does Vorbis approach FLAC at the higher bitrates.

See, I have made my own blind tests that so far show that aoTuV4 Vorbis q8 (average bitrate = 256kbps) with noise-tune = -5 and Replaygain tags sounds exactly like any FLAC file I tried comparing with. So, what I would like to know is the opinion of those that are more hardcore at this. How does my "LosslessVorbis" compares to real FLAC? Is there really any quality loss? If so, what do you people suggest me to reach this goal? Higher bitrate? Using other advanced options like Impulse Trigger? Or what exactly?

You're asking for the level of transparency of Vorbis at high bitrate. It's a recurrent question and the aswer depends on your hearing abilities, the listening conditions and the kind of signal. The level of transparency is therefore very subjective. But at -q8, it's very hard for most people to get any difference. Therefore, if you don't have enough storage to use lossless encoding, and if you failed on ABX comparisons with your lossy format and settings, go with lossy.


EDIT: changes were done for the recommendation. Thanks QuantumKnot. One regret: aoTuV beta 4. I tested it at 80 and 96 kbps, and in both case aoTuV was superior to 1.1.1. The current recommendation doesn't mention anywhere the existence of this encoder. Same thing for LANCER (better than 1.1.1 for speed and certainly for quality too). Is it possible to mention these encoders somewhere?

Sorry, I've been awfully busy lately and haven't visited for a week or so. I'll update it very soon.

Updated the settings page with aoTuV beta 4 and Lancer 20050709

Maybe you can consider moving the recommendation list to the Knowledge Base? That way, several people could contribute to keep it up-to-date. Also, people would keep a close look to make sure noone messes it up.

That's a good idea. I'll look into that then.

I think that might be a good idea also . Wiki is coming along pretty good I mean it could always use work, but I think things are coming along.

I was a big mpc fan but this newest guru`s listening test is making me to nswitch from mpc to vorbis as mpc wont progreess anumore.I was testing today the q5 and q6 aotuvb4 with vorbis1.1.1 and what is the status with lancer optimatization build.
Is it general ha concensus that is safe to use and that it gives same output as regular aotuvb4 enc???
If this has been mentioned i apologize as im total vorbis newbie

I guess the purpose of Lancer are to produce identical quality as the aoTuVb4-libVorbis1.1.1-merged encoder, just using SSE optimizations and such for higher speed. Tweaking done should only affect encoding speed. But if this goal are fully reached I would also like to know.....

Just a question regarding CDex.

I've downloaded ogg vorbis dlls using libVorbis v1.1.1 2005-06-29 from rarewares and replaced the old files that were in the CDex folder.

I'm just curious, how do I enable padding? Is it enabled if I just update the DLL's or do I need to use oggenc as an external encoder for this?

I tried both the P3 and P4 versions from the first page with the recommended settings for CDex, but I get a "Can't send data to encoder" error trying that.

Any help is appreciated.

Thanks

You'll need to use oggenc2 for padding, the option isn't available elsewhere. Otherwise, just set it up as any other external encoder in CDex.

As I said before:

I tried both the P3 and P4 versions from the first page with the recommended settings for CDex, but I get a "Can't send data to encoder" error trying that.

Thanks anyway

Does anyone know how to solve the problem, and getting padding to work in Cdex?

Cheers

I get the following error when clicking on the OggDropXPd download link in the first message:

Fixed the broken links.

hmm.... Did you type out the command line (with all the switches) exactly?

Just as a test, try this and see if it works

-q 5 - -o "%2"

If it does, then we can add the other switches one-by-one.

Updated the recommended encoder to aoTuV beta 4, following guruboolez' listening test.

the links in the first post for dloading the .exe seem to be dead (.404 error)

oggenc26.exe aoTuV beta 4 (ICL compile for P4/AMD Sempron, Athlon 64)

-

Thanks for the heads-up. Looks like the aoTuV beta 4 binaries are all gone on rarewares so I've had to put the newest aoTuV beta 4.51 on there. Not what I prefer since it hasn't been tested as extensively as aoTuV beta 4, but I got no choice. Hopefully they are very similar.

I'm having problems encoding. I'm using Foobar2000 0.8.3, downloaded the A64 compile of Aotuv4.51 with Clienc settings

-q2 - -o %d

Whenever I try to encode, the command prompt screen appears. looks to be running Oggenc2.exe, but there is only a cursor on the screen, and nothing happens.

I hope you did put a space between -q and 2.

The space is optional, as is usual with *nix programs.

I can use the command line with -q2 and it works just fine.
It still doesn't work in foobar, with or without the space.

Does the generic build work fine w/ foobar?

I downloaded the foobar 9 beta, and it's clienc worked without a single problem. Does it use different command line parameters for ogg files than 083?

It shouldn't be.
Probably something wrong when piping the decoded stream, either on foobar's end or oggenc2's end, but cmiiw...

The quotes around %d ? I.e. "%d" instead of %d ...

Most of the first posting has been placed into this wiki page. It seems to have acquire a life of its own so would someone please check up on that page?

Thanx.

One step at a time. I am going to go through and mercifully edit it (including spelling and grammar) . I like the fact that your taking the time to adapt the thread into the wiki, but I started working on the page and it's something I have had in mind for a few months and didn't get to finish. I understand a lot of the internals beneath the Vorbis too, because I have thoroughly inspected the code and I know how to code myself (even though I don't quite that often). You managed to add in junk that doesn't need to be in here

Just wanted to say thanks for this wiki. There is nothing else like it that I have found on the web and it is very concise.

IMO, vorbis is an amazing encoder in terms of size vs. quality. I've invested in an iaudio 5, and am already looking at a HD player for vorbis (anybody want to buy an ipod?). I hope that it is here to stay and that tremor keeps getting written and optimized for new chips.