Recommended Encoder Versions and Settings Options

[phong]

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.

[DreamTactix291]

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

This post has been edited by DreamTactix291: Mar 17 2005, 02:21

[john33]

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.

[kjoonlee]

I just built an AMD64 system and was updating my software. I tried both of the ICL compiles (P3/AMD & P4) and found that the P4 version was consistently around 2x faster. (*Not double speed)

CODE

P4 ICL Compile
Done encoding file "M:\My Music\Track03.ogg"

       File length:  2m 39.0s
       Elapsed time: 0m 08.0s
       Rate:         19.9717
       Average bitrate: 167.0 kb/s

P3/AMD
Done encoding file "M:\My Music\Track03.ogg"

       File length:  2m 39.0s
       Elapsed time: 0m 09.0s
       Rate:         17.7526
       Average bitrate: 167.0 kb/s

So should you use the P4 compile if you have AMD64 or should you still use the P3 version?

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.

[Jebus]

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.

This post has been edited by Jebus: May 26 2005, 07:47

[HbG]

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?

[Garf]

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.

[CoRoNe]

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

[HbG]

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.

This post has been edited by HbG: May 31 2005, 18:32

[moozooh]

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

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.

This post has been edited by Mo0zOoH: Jun 1 2005, 02:00

[HbG]

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?

[CoRoNe]

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

[Digisurfer]

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

[moozooh]

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

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

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

Oops, I meant <128 kbps.

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

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.

[beto]

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

This post has been edited by beto: Jun 1 2005, 02:08

[saratoga]

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

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

[kjoonlee]

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

[HbG]

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?

[moozooh]

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.

This post has been edited by Mo0zOoH: Jul 12 2005, 15:31

[alter4]

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

Consider making 1.1.1b4 version the recommended one.

This post has been edited by alter4: Jul 18 2005, 10:14

[Saoshyant]

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?

[guruboolez]

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?

This post has been edited by guruboolez: Jul 26 2005, 23:38

[QuantumKnot]

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.

[QuantumKnot]

Updated the settings page with aoTuV beta 4 and Lancer 20050709

This post has been edited by QuantumKnot: Aug 7 2005, 03:38

[rjamorim]

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

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.