Maybe your Pentium D system lacks VC8 runtime DLLs? You may check this with a dependency walker tool.

That did occur to me, too, so I did copy some of them over to no avail, but it's certainly something I'll look at more closely. Thanks for the input.

It turns out that when I copied the dependent dll (only one) across, I forgot to copy the manifest file to go with it. Doh!! The VC8 compile works fine now, but I won't bother to upload again as the VC6 compile is perfectly adequate, I'll leave it until next time.

Lancer 20061103 is out! Based on AoTuV Beta 5

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

I personally think that -q0 sounds pretty decent now (actually rather impressive, considering that there's no SBR), though it still has some problems. I prefer HE-AAC at the moment, but who knows what the future might bring.
But wouldn't a raised lowpass reduce quality?

It's unbelievably fast, I can hardly believe my eyes

i just thought the same.. 62x encoding speed on my machine
i only hope the quality doesn't suffer with these compiles..

-andy-

Well, I've never read anyone's complaints about the Lancer builds' quality compared to Aoyumi's original ones. There are some differences due to floating-point rounding from 80-bit FP to 64-bit SSE, but in fact Lancer is still the aoTuV encoder, regardless of its speed.

I thought so, too until I tried it in Foobar. Although the bitrate does indeed go up very slightly from the nominal, the sound quality is noticeably (or is it "unnoticeably") better... Try Foobar's 'ABX' feature and you'll see (I failed on some songs with the --advanced-encode-option lowpass_frequency=16.5)...

Very, very weird. I'm going to retest (again).

I tried a 16khz lowpass after you mentioned it, and I have to say that it does sound better for a lot of songs. And it's rather strange that the bitrate only goes up 1-3 kbps, and that it doesn't sound -worse-.

I did some testing a couple of days ago and I came to the same conclusion. I think the default low-pass is a bit too aggressive, especially in the lower quality modes.

Perhaps we can suggest to aoyumi to tune the lowpass settings for lower quality modes.

Indeed. I'd suggest to tune for the whole range. These are the current low pass settings and as you can see there are some weird low pass settings of 48 and 999 kHz.

-q -2 13.1 kHz
-q -1 14.8 kHz
-q 0 15.1 kHz
-q 1 15.8 kHz
-q 2 16.5 kHz
-q 3 17.2 kHz
-q 4 18.3 kHz
-q 5 20.1 kHz
-q 6 48.0 kHz
-q 7 999.0 kHz
-q 8 999.0 kHz
-q 9 999.0 kHz
-q 10 999.0 kHz

Now, I think it would be best to do some testing and find out where the "sweet spot" for each of the quality settings. Maybe it would be a good idea to limit at 20 kHz even in the higher quality modes to avoid aliasing problems etc?

People who don't understand the source code shouldn't complain about the lowpass filter range and it shouldn't be touched. The 999 KHz means that no lowpass filter is applied. It makes sense to the the very concerned listener that can't tolerate any sacrafice or loss of quality.



the lowpass filter is correlated to Noise Normalization level. It's very complicated, but that's the basic jist of it.

Where did I complain? It was merely a suggestion and I still think it's a valid question. Of course I know that 999kHz means that low pass is disabled. My point is, even if you can hear frequencies > 20kHz you would most likely not be able to distinguish between 20kHz low passed music and non-low passed music so why waste the bits that could be better used elsewhere?

http://wiki.hydrogenaudio.org/index.php?title=Lowpass

Not you personally I am just saying complaints in general. We can't make claims about suggesting that bits be used elsewhere without not understanding how the source code specifically works. Vorbis is specifically tuned to suite a lifestyle of specific people and that's why it should be left up to the developers to best determine, while your suggestion is helpful I don't see where it would best be helpful. I need to finishing writing that lowpass filter page, however from a purely engineering standpoint my knowledge is limited to how one goes about designing a lowpass filter from each of those designs.

For the moment, I am not going to set up lowpass filter more highly. 2~3kbps in the low bitrate is precious. In order to justify it, sufficient test result is needed.


In the high bitrate, I think that there is almost no meaning which restricts frequency with a fixed value.

I could possibly do a test for this. How many samples would you want? And I guess you'd also want a bitrate table.

There is not necessarily a required number about a sample.
Wanting me is sufficient proof. The test in a lot of people and the many samples in an ABC/HR formula is desirable.
If the result of those tests and the rise of the bitrate balance, I will consider it carefully.

Does it compile with gcc4 under Linux when I patch the libvorbis code with the patch provided?

I don't pay attention for a while and look what happens

I'll certainly have fun testing this in the very low bitrate regions (28kbps).

edit:
I was using vorbis.dll with oddcast3 and it has crashed every time with this version (both from rarewares and my own compiles). The problem seems to only effect the samplerate range of 26000-39999hz (40+khz, and below 25999hz seem to work perfectly fine). Either the crash occurs when I first try to connect the encoder, or when the song changes. Windows reports vorbis.dll as the cause. Using vorbis.dll based on aotuv r1 does not crash at all. My thinking is that something got changed for the 32khz psymodel setup that is causing this problem. It is entirely possible that the combination of oddcast3 and aotuv b5 is causing the crash. Is anyone else experiencing any crashes with vorbis.dll?

A 32kHz model is not special at all. It is almost the same as 44.1kHz.
It seemed that 32kHz operated normally in "aoTuV dlls" of my page, and the combination of "oddcast v2" at least. (I do not know about the combination of oddcast v3 and vorbis.dll)

I think that it can probably compile. However, I am not checking.

I compiled it in Arch Linux, using libvorbis 1.1.2 + aotuv b5 patch, with gcc 4.1.2, without a hitch

Yep, works. At least I think so
Ubuntu 6.10, gcc 4.1.2


PS: WOW, THAT sounds great. Even at -q 0. Nice work, I'm impressed
I'm looking forward to get a i.Beat organix, I read some tests and it seems that this is a quite good player :>

What is in fact the reason, that these patches are not being integrated in official libvorbis? Would not it be possible to ask xiph an SVN account and work immediately upstream, so that all users (who do not know about this patch) automatically benefit from the improvements in AOTuV? The reason I'm asking, is that I proposed to included this patch in Mandriva Linux' default libvorbis packages, but the maintainer did not want this, as he considers AOTuV an experimental fork, and it should be integrated first in official libvorbis.

You can see the whole discussion here: http://qa.mandriva.com/show_bug.cgi?id=26982 (server down at the moment I write his).

They actually are. From http://www.misticriver.net/showthread.php?t=12302:



Of course this is an older update. But the most current aoTuV b5 update's gonna be implemented into official libvorbis soon too: http://www.hydrogenaudio.org/forums/index....=49940&st=0

Hence, you can tell the maintainer he may safely include aoTuV in Mandriva Linux' default libvorbis packages. It is far from being an experimental fork, but rather the de facto official one.

Edit: Besides, did you propose including plain aoTuV or/and the optimized Lancer builds into the default packages? One major drawback of Vorbis is its slow encoding speed, which is satisfyingly accelerated by Blacksword's SSE implementations. Would make sense to think about making Lancer the default encoder, in addition with plain aoTuV as an alternative for old computers which still don't feature an SSE processor.

vorbis.dll off of your website works perfectly fine with both oddcast2 and oddcast3. But both rareware's and my own compiles experience the crash at 32khz One thing I noticed is that all three are different sizes.

I compile with MSVC6.0, first by loading 'vcvars32' then running 'build_vorbis_dynamic.bat'. It shows a bunch of loss of precision warnings but it compiles just fine.

@Aoyumi:
Are you doing anything different when compiling vorbis.dll?

I usually use gcc. The dlls are similarly compiled by gcc.

Like MSVC, gcc does generate crappier code behind them than ICL, around the level of VC 6. But it's still faster than C, at least. It has to be at least gcc 4.3 if you want any multithreading, however, as that's the first version with openmp support.

Gameplaya, have you tried building a debug version and following the crash with a debugger? Of course, both you and john33 use VC6, so maybe it's just (yet another) bug. You could always try the free VC8 compiler or a demo of ICL 9.1.

Don't expect to see Lancer merged into mainstream Vorbis anytime soon unless Blacksword removes the Win32-specific API calls from his code. I spent hours trying to get Lancer to compile under ICC and Linux.

If ANYONE knows of a POSIX substitute for the _aligned_realloc() C function, please let me know. He's also calling the sleep() function declared in windows.h, but that should be easy to fix under POSIX.

Some of my more recent compiles have been based on VC8/ICL9.1 and that's the direction I'm trying to move in. However, some projects don't painlessly convert and for those I revert to VC6/ICL9.1 until I have the time to resolve the issues (if I'm able!! ).

I take it you found posix_memalign and friends then. While I'm not aware of any substitute for _aligned_realloc (I haven't really looked though ), re-writing them should be fairly easy. A first prototype for _aligned_malloc could look something like this (without any error checking):


Note that the above hasn't even been through a compiler, so there could be issues with it. However, the idea is that you do a normal alloc for a bit more memory than requested (for the alignment and some extra), do the alignment yourself, and save something so you can get the original pointer. In _aligned_free and _aligned_realloc (which otherwise would be similar to the above), you pick up the stored information, and use that to get the real pointer to use in the calls to free and realloc.

ABX results please. More tests need to be done to make sure that there really is noticeable difference between lowpasses, if there is any. I can't hear it myself... Beta 5 needs more testing anyways so that it can became Release 2.

Aoyumi, are you going to tune pre-echo handling further on next version? If yes, when we can expect new release?

Thank you for your work, Aoyumi-sensei. Your extraordinary work is very much admired and appreciated.

L'arc~en~ciel - Spirit Dreams Inside. A had a 16KHz lowpass, B was using default (which is around 15).



Above & Beyond - Alone Tonight. A was 16Khz lowpass, B was default.

Bitrate difference in both cases was 1kbps.
I can test more songs if you want.
What I'd really like to do is use ABC/HR to rank them though, and see if the slightly increased lowpass actually sounds more pleasant in general. It's certainly not as good as HE-AAC, though. But, I'm not particularly sure how to setup a test with ABC/HR.

Firon, which quality setting were you testing?

-q0. I've done no tests with -q1, and I don't plan on doing any.

Okay, so you still find HE-AAC superior to the latest AoTuV tunings at -q0. I was just curious on that matter having not done any extensive testing there myself. -q1 with the AoTuV tunings works wonders for my portable needs. I'm wondering how *that* setting compares to HE-AAC at ~64 kbps.

Funny, in my ears q0 vorbis (aoTuV b5) sounds much closer to the original than the HE-AAC equivalent. There's a little bit of distortion in the higher frequencies, but the HE-AAC just looses a lot of clarity and for me it is much easier to abx.

I tested with default settings. Nero AAC quality 0.25 and ogg vorbis (b5) -q0. The AAC track ended up 65kbps and vorbis was 69kbps.

foo_abx 1.3.1 report
foobar2000 v0.9.4.2
2007/01/20 11:47:21

File A: D:\FLAC\test.wav
File B: D:\FLAC\test.mp4

11:47:21 : Test started.
11:48:05 : 01/01 50.0%
11:48:11 : 02/02 25.0%
11:48:19 : 03/03 12.5%
11:48:26 : 04/04 6.3%
11:48:31 : 05/05 3.1%
11:48:39 : 06/06 1.6%
11:48:44 : 07/07 0.8%
11:48:50 : 08/08 0.4%
11:48:54 : 09/09 0.2%
11:48:59 : 10/10 0.1%
11:49:13 : 11/11 0.0%
11:49:18 : 12/12 0.0%
11:49:23 : 13/13 0.0%
11:49:28 : 14/14 0.0%
11:49:35 : 15/15 0.0%
11:49:45 : Test finished.

----------
Total: 15/15 (0.0%)

As you can see, very easy to abx. I did have a little more trouble with ogg vorbis though and even though I can abx q0 quite easily on most tracks, this particular song, Paul Van Dyk - For An Angel (PvD's E-Werk Club Mix) gave me a little bit of trouble.

foo_abx 1.3.1 report
foobar2000 v0.9.4.2
2007/01/20 12:09:05

File A: D:\FLAC\test.wav
File B: D:\FLAC\test.ogg

12:09:05 : Test started.
12:12:27 : 01/01 50.0%
12:12:36 : 01/02 75.0%
12:12:47 : Trial reset.
12:14:17 : 01/01 50.0%
12:14:32 : 02/02 25.0%
12:14:44 : 03/03 12.5%
12:15:01 : 03/04 31.3%
12:15:08 : Trial reset.
12:15:45 : 01/01 50.0%
12:15:55 : 02/02 25.0%
12:16:09 : 03/03 12.5%
12:16:25 : 04/04 6.3%
12:17:02 : 05/05 3.1%
12:17:14 : 06/06 1.6%
12:17:27 : 07/07 0.8%
12:17:56 : 08/08 0.4%
12:18:18 : 09/09 0.2%
12:18:44 : 10/10 0.1%
12:19:05 : 11/11 0.0%
12:19:21 : 12/12 0.0%
12:19:36 : 13/13 0.0%
12:19:49 : 14/14 0.0%
12:20:08 : 15/15 0.0%
12:20:10 : Test finished.

----------
Total: 19/21 (0.0%)

I have not opted for the still concrete thing about a next version. Therefore, I can't say clearly now...

I prefer -q1 over HE-AAC at 64kbps, and I can ABX the two.



I can ABX -q1 versus the original on this particular track, but it's a lot harder.



Anyway, here's -q0 vs HE-AAC at 64kbps.


Nero Digital using -q0.25 (came out to 71kbps), Vorbis at -q0 (61kbps), no tuning of lowpass. ND sounds significantly better, less warbling and more HF content.




I can ABX the original and HE-AAC as you can see, but it sounds much closer to the original than q0 does.





q0 sounds lousy, lack of HF and pretty strong warbling. Listening more closely, it seems like stereo is destroyed in the q0 file.

Okay. Vorbis seems to have problems with pre-echo and smearing on some cases, check posts #36 and #38. When you start planning next version, maybe you could take a look to it and see if it could be improved.

Personally, I'd like for -q-1, -q0 and -q1 to be improved some more. Vorbis handles pre-echo pretty well, in my opinion.

Thanks for your findings, Firon. I think they line up with my take on -q1 pretty well. They also reveal my suspicions as being true...that HE-AAC starts eclipsing Vorbis at 64 kbps and below.

following these instructions http://menzonius.files.wordpress.com/2007/04/vorbis.pdf

I could patch and compile the vorbis aotuvb5 libraries for Ubuntu Feisty (i386)

As it took me some of my time, I'd like to save some of yours

here

Great! A much better approach than mine (I am the pjssilva person cited in the end of the pdf file). Would you consider making these libs available using Ubuntu Personal Packages Archives? It is a very nice way to make your packages available for everyone. If you don't want to bother, just let me know. I can do it myself.

http://www.geocities.jp/aoyoume/aotuv/test.html

oggdropXPd V.1.8.9 using aoTuVb5 2007-09-01 doesn't work on my computer (lpac_codec_api.dll missing)

You need the LPAC dlls from here: http://www.rarewares.org/ogg-oggdropxpd.php

Extract them into the OggdropXPd directory and it should work.

thanks