Lancer's DLL's are pretty big too, 3 meg unpacked, 450kb zipped. Beats me why they're that inflated.

Current Lancer (Archer) version is stable release? Why changed name of this tune?

The change of the name form Archer to Lancer is because it uses the AoTuV pre-beta 4, the Archer versions uses Beta 3... thats why the change of the name, or at least I suppose that... it is pretty stable but it maybe have various bugs to be fixed... and in the other hand it uses a pre-beta which maybe have some others problems...

new version is out,
Lancer 20050621(Based on aotuv-b4_20050617)

Many thanks for the heads up. =)
Will test it out in a moment...

Almost a week has passed. Any test results?

I use it regularly without any problems (mostly q3 & q4), the speed is fantastic. Also I've noticed that it uses only about 90% CPU when running on my AMD 2700+ machine, as Archer spent full power.

Ooh. That probably implies that it's fast enough that it's actually sometimes blocking on IO. Impressive!

Well, compared to the Lancer that uses aoTuV pre-beta 4, no real noticeable difference.
U might wanna check that out a few posts (or pages?) back about previous Lancer's performance.
To the Archer, it's just like Josef said.

Anyway, the speed gain (from the auTuVb4 compiles found in Rarewares.org) on slower PIII systems is adequate.
(I tested it on a PIII 600MHz)
No numbers yet (since I kinda forgot...), but I think it was about 1.15x to 1.30x faster.
As always, cmiiw. =)

From http://www.tom.womack.net/x86FAQ/faq_features.html



This is also why P3's are notoriously poor on certain games such as UT2003/4.

New Lancer build based on the aoTuVb4 library merged with libvorbis 1.1.1. Previous was based on aoTuVb4 with libvorbis 1.1.0

http://homepage3.nifty.com/blacksword/index_e.htm as always

Just tried the latest version to replace the built in Foobar and it's well over twice as fast, especially when converting from FLAC. Amazing!

Just finished a test with besweet. Encoding time dropped from 1:54 to 1:13 (mins:secs).

FYI - New 'Lancer' builds of oggdropXPd v1.8.6 and libvorbis.dll

http://homepage3.nifty.com/blacksword/index_e.htm as always

I have a question. Will Lancer and P-III optimized (from rarewares.org) versions work and have any gain on Celeron 128kb cache (not Tualatin)?

Only if your Celeron support SSE.... try to use a program like cpuz to see if it have SSE instruction.

Got a question guys
I did some encodings with foobar0.8.3 and about 25 different songs,using built in vorbis which is 1.1 and using lancer which is merged 111 and aotuvb4 and im getting increase on all samples by 5-10% in size,actuaally 20 samples were 10% and rest was between5-10%.It was a classic rock songs,using p4 and xp-sp2.
It is a quite faster which is nice,but what confusing me is that on beginning of the thread all tests shows the same bitrate-i encoded at q5 everything was default from foobar

By 'built-in', did u mean the official vorbis libraries?
The difference is probably caused by the different tunings used.
The official one doesn't use AoTuV b4 tunings yet.
(is it still b2 or something...? I forgot...)

I meant the one which comes by default in foobar allready configured in diskwriter
mrq and foobar reports it as 1.1.
Both were encoded with default preferencies-q5 and no other parametars

The bitrate difference you're seeing is aotuv vs 1.1, lancer may change bitrates compared to the regular aotuv, but only by a tiny bit.

Exactly.
I don't think that version (1.1.0) already use AoTuV b4 tunings.
So if the resulting file size difference is quite big, it's probably 'cause of different tunings used.

Yes, CPUZ says my CPU has SSE, I tried 'Lancer oggenc' and it is realy faster than P-III compile.
However I also tried 'Lancer OggDropXPd' and it doesn't work.
When I drop wav's in it nothing happens. Does anybody know why?
My PC is Intel Celeron 1000 MHz (not Tualatin) with Windows 98SE. If anybody have Windows 98SE installed - please check - does 'Lancer OggDropXPd' work?
Thanks.

Try these updates...

Nice speed incrase here on AMD x2 4400+

aoTuVb4 - no enhancements (oggenc)
File length: 72m 28.0s
Elapsed time: 5m 07.0s
Rate: 14.1643
Average bitrate: 192.2 kb/s

aoTuVb4 - SEE version (oggenc2)
File length: 72m 28.0s
Elapsed time: 4m 16.0s
Rate: 16.9861
Average bitrate: 192.2 kb/s

aoTuVb4 - SEE2 version (oggenc2)
File length: 72m 28.0s
Elapsed time: 3m 30.0s
Rate: 20.7068
Average bitrate: 192.2 kb/s

lancer20050709 (oggenc2)
File length: 72m 28.00s
Elapsed time: 2m 3.66s
Rate: 35.1655
Average bitrate: 192.2 kb/s

Is this optimizing done via implementing SSE and SSE2 only, or also via assembling some parts of code?
Can such optimizing work be done with Ogg Vorbis decoder?

I recall reading vorbis was all x87 code, that is, floating point, but not accelerated.

What the ICC compiler does is a process called autovectorisation, it's a very clever piece of software that examines routines and attempts to implement them using the faster SSE(2) instructions. At least, that is how i understand it.

What lancer does is replace certain standard routines in vorbis with hand written SSE implementations. This is not assembly (i think), but it is vectorisation (making use of SSE) done by a human.

The SSE instruction set works at a lower precision than the regular x87 instructions, but i don't think that's ever reduced sound quality in a noticeable way.

I'm not an expert on this, but i hope this explanation is accurate enough to answer your questions.

There is also an accelerated vorbis decoder, look at the first post of this topic.

Babelfish translation
I'll see if i can get this to work and bench it.
EDIT: can't make much sense of the japanese even with babelfish, the .dll supplied at least doesn't work as a regular vorbisfile.dll or vorbis.dll.

@toot - very impressive speedup, imagine if it were multithreading!

Lancer 20051118 is out
http://homepage3.nifty.com/blacksword/

Basically nothing you said was correct.

1) autovectorisation is not the same as using SSE or SSE2 instructions
2) hand written SSE implementations are assembly or intrinsics
3) hand written (or automatically generated) SSE does *not* imply vectorisation
4) SSE or SSE2 does not automatically imply lower precision than floating point.

Fantastic! Thanks to all people involved!

Here is a small Ogg Vorbis CLI encoder speed comparison between John33 and Lancer builds:


Test environment:
Pentium4 2.4GHZ, Windows XP SP2, 512MB ddr266 sdram.
Test with 18.5 MB, 44.1khz, stereo, 1min 50sec audio file, and -q4 switch.

NOTE: result above might not accurate...

To explain:

3DNow, SSE, SSE2 are alternate instruction sets for floating point processing. These instruction sets have some major advantages over the old x87 mode:

1) They have register based access, instead of stack based
2) They have the *possibility* to operate on 2 or 4 values at the same time (vectorisation)

SSE and 3DNow have 32 bit accuracy, SSE2 has 64 bit accuracy. x87 has 32 or 64 bit accuracy and a possibility (that shouldn't be used and I'm pretty sure vorbis doesn't use it!) to do 80 bit accuracy arithmetic.

Using these instruction sets can be done in the following manner: code for them manually (in assembler or with instrinsics), use a compiler that can use the SSE(2) instructions for floating point instead of x87, or use a compiler than can *vectorize* computations for SSE/SSE2.

Currently (besides manually writing in assembly), ICC is the best at vectorization, and some very recent GCC's have the possibility too. MSVC2005 and older GCC's have the possibility to generate SSE(2) floating point instructions (without vectorisation).

For some reason on the site right now the links are crossed out and removed.

EDIT: I see why now. aoTuV b4.51 came out.

really ?

Ogg Vorbis acceleration project

they must've pulled it, maybe since 4.51 bugfix was released almost simultaneously.

It looks like it.. according to google's surprisingly legible translation..


November of 2005 19th

Release is discontinued to completion of the aoTu V beta4.51 base.

Thanks for the explanation, Garf. Reading mostly about the use of 3DNow/SSE with regard to 3D work i didn't realise vectorisation was only a possibility. Or that x87 had precisions other than 80 bit.

OK, lancer_20051121 patches against aotuv4.51 are out.

Can I batch the source under the Linux ?

What would be the exact command and what I need (besides aotuv source) ?

I have downloaded Lancer_20051121 and tested the OggEnc2.exe. Here's the log of what I have done (_j33 is John33's compiled, _lancer is Lancer version):



Wow! It's amazingly fast (I use my brother's AthlonXP 2400+). However, the next step I took made me pause:



Whoa! Significant difference? Can't be because of different comment, no? I go check with EditPlus, and I think the files mostly are identical. So I decode both to WAVs and got the same size:



Same as original. Not knowing what else to do, I try EAQUAL:



And it seems there are differences.

I tried listening to the results but to my ears they sound the same.

Anyone can shed a light as to why they differ?

EDIT: Changed CODE to CODEBOX that's all

Read this page with machine translation if you really want to know the reason (the first item in Frequently Asked Questions)
http://homepage3.nifty.com/blacksword/readme_j.htm

In short, SSE arithmetic has 32bit precision while FPU (i.e., without SSE optimization/compile) arithmetic has 80bit precision. The computational error in floating point arithmetic may make the difference but is so small that you probably cannot hear the difference. I bet you also get a difference between John33's compile and reference binary distributed by Aoyumi.

SSE2 has 64 bit accuracy, and the FPU is generally used with only 64 bit accuracy (using 80 bit mode is not possible in a portable way, and as I said, vorbis is not doing it).

Note that AMD64/EM64T use SSE/SSE2 exclusively instead of the FPU.

But yes, in this case the difference is likely just minor rounding error. Note that positive ODG means that there is no audible difference (actually: encoded sample is better than the original, but that's a limitation in the way EAQUAL works).

Whoa! Thanks for the clarification I was afraid that Lancer optimizations is buggy and will degrade the output, but this puts my fear to rest. I am very amazed at the encoding speed increase and will change over to Lancer (oggenc, oggdrop, and libvorbis.dll).

One question: How do I decode the result of EAQUAL? Any pointer will be appreciated. Thanks a lot.

ODG = Objective difference grade

From memory



Positive value = better than perfect

OK, managed to patch aotuv sources with lancer dif (don't know what went wrong last time), but now oggenc segfaults. Switching back to original aotuv helps.

Any comments ?

My box is amd64 Gentoo with gcc 3.4.4.

Try to compile by gcc 3.3.x.

For me gcc 3.4 can't compile sources, 4.0 compiles but oggenc display mystic error on start but 3.3 compiles and oggenc works after it.

I'm using Ubuntu 5.10 with gcc 3.3.6, 3.4.4 and 4.0.1 (acutally 4.0.2 pre) on Athlon XP 2200+. libvorbis 1.1.2 compiled by gcc 4 with default package options (--host=i486-linux-gnu) gives ~11x, with -march=athon-xp -mfpmath=sse about 14x, with lancer patches by gcc 3.3 with -march=athon-xp gives about 17x.

With the late November Lancer oggenc2 , I get MediaCoder encoding speeds from Flacs around 29x on my AMD 3300+ Win X64 system (q 6.16).
I know this thread is about speed, but I wonder if others disagree with my perception that quality now is comparable to MPC at rates around 200 kbps.

The quality at which -q setting...?

Say, in the range of nominal 200 kbps, which is q 6.16 to 6.24.
I recall that MPC was considered near as dammit to transparent at q 8. So, I'm getting at whether there's a sweet spot in the latest Japanese tweaked Ogg Vorbis encoders in that 6 to 8 range.
I'm pretty sure that that glitch on the 6.0 boundary for the official release that made those just north sound much better has been solved...

I know that I've ditched mpc "insane" for ogg q7. The poor seeking and limited hardware support for mpc and the improvements in Vorbis are what convinced me.

I don't think Guru has tested beyond the 170 to 180 range yet, which showed ogg to be on par with (and in some cases better than) mpc.

No, need to it's waste of time IMO. Most people with the exception of a few like GuruB can tell the difference, I can't. If it was low-bitrate test then sure why not