uri: http://www.geocities.jp/aoyoume/aotuv/

Here're OggEnc and Win32-DLL binaries:
aoTuV Beta3 OggEnc MSVC7.1 Win32 build and aoTuV Beta3 OggEnc MSVC7.1 Win32-DLL build

Hmm.. I'll give it a few listens.

If anyone is interested, I've added a standard P3/AMD compile of oggdropXPd using aoTuVb3 at Rarewares. This is an ICL 8.1 compile. I'll add the other versions if it's deemed appropriate.

Nice, thx

Would be nice to see it compared against 1.1, i tried ABXing it without much success

Also, isnt this big enough news to have made the "validated news" thread?

Hi all,

I have built a rpm set for aotuv beta3.
They are built on a suse 9.1, but the binaries should work on any glibc 2.3 distro (i suposse)
They are available from
http://users.servicios.retecal.es/maacruz
Look for the libvorbis_aotuv-* files.
This is a temporary location because my ISP only gives me 20 MB of web space, so it would be nice if someone could find them a better location

Best regards.

It seems it increases the bitrate by 10 %
oggenc castanets2.wav -> 97247 bytes
oggenc_aotuv castanets2.wav -> 107636 bytes
oggenc -q5 castanets2.wav -> 153707 bytes
oggenc_aotuv -q5 castanets2.wav -> 139948 bytes

That new -q-2 mode is incredible. Size of the files is like 2/3 of the ones encoded with previous -q-2, while quality is not much worse.

Interested?? Are you kidding Downloading now.

Pretty please with sugar on top?

It would appear the bitrate has decreased for q 5 here.

It's always comforting to see more Vorbis development

You should test bitrates over a broader selection of samples to obtain realistic numbers.

aoyumi's own compile aoenc.exe doesn't work with EAC external compression; might be something wrong with the pass through code.

nyaochi's compile oggenc.exe does work.

not abx'ed yet, but it sounds pretty sweet at q7 with lots of headroom even played softly hehe, it's heaven-sent, I was getting clipping errors with mpc 1.15 on reggae/ska and was using b2. Dammit I hope I don't have to reencode the good stuff... Should probably use flac for archival anyway, oh well once I get $$$.

That's because Aoyumi's binary is actually a modified version of encoder_example, which doesn't have the features of oggenc.

MPC watch out! where is guru?

Where is someone to take the role of public listening test conducer? :B

rjamorim

Here? ^

But seriously, I'd like to see aoTuV Beta3 at -q-2 vs HE/LC-AAC vs MP3pro at similar bitrates listening test.

good proposal

i also would like to know

OK, later today.

hehehe Unfortunately we dont live in the right parallel universe where he still is



LC-AAC would be struggling at those ultra-low bitrates

Really nice new! I'll test it as soon as I can

I'm sorry
Just typed the wrong way.
It is actually
oggenc_aotuv -q5 castanets2.wav -> 153707 bytes
oggenc -q5 castanets2.wav -> 139948 bytes

OK, Generic and P4 compiles added to Rarewares.

john33

can you plz update CDex compiles? I would really appreciate this, I'm in the process of encoding all my collection for portable usage...

Right, I've added what I believe to be a full set of dlls and executables. OK?

I get a 404 with the ogg vorbis dlls using aoTuVb3

http://www.rarewares.org/files/ogg/oggvorbis-dllsaoTuVb3.zip

my pc's cpu is Pentium 4 3.0GHz (Northwood). but Oggenc2.3 using aoTuVb3 (pentium 4 only) dose not work. Standard does work.

i think from experience, it's the bug of ICL 8.1

the bug may have come out also oggdropXPd V.1.7.11 using aoTuVb3. plz check.

Ooops!! Sorry, I missed uploading that one. It's done now.

I have the exact same problem with oggenc2.3 (P4 build) as well, on my P4 2.4 GHz (Northwood).

Seems OK here. The P4 oggdropXPd is also OK here.

Northwood 2.8c M0, 2 x 512kb KingMAX PC4000, WinXPSP2.

Anyone else have this? If so, I'll revert to ICL7.1.

Hmmm, I wonder whether the 8.1 runtime dlls are required? I'll make those available as I'd like to resolve this rather than simply go back to 7.1, if pos.

OK, I've uploaded the ICL 8.1 libmmd.dll to Rarewares. Could someone kindly check whether this resolves the problem? TIA.

Works now

Excellent, thanks!!

Hi,
the P3/AMD compile of OggDropXP I downloaded also needed the libmmd.dll file in order to function on my AMD Win2k system. Do all ICL 8.1 compiles need this file? BTW, how much faster are ICL 8.1 compiles in general than, say, 7.1 ones?

Greetings,
sTisTi

I suspect most, if not all, will need the 8.1 dll. I don't see any speed difference between them, TBH, I am assuming that the later version is more bug free!!

does work, me too

many thx john33 and QuantumKnot

The link is wrong.
Please check.
Thank you.

Sorry about that!! It's fixed now.

I agree. The -q-2 mode is quite remarkable. Amazing work!
Although I can ABX a -q-2 file from a lossless file quite easily, but the -q-2 doesn't sound significantly worse to me.

Thanks maacruz

Here's a mirror of the libvorbis_aotuv-* files.

http://www.selune.net/files/suse/

Anyone tried these on SUSE 9.2?

binaries also at the Rarewares Debian Repository

later

I cant get this to work with EAC.

Userdefined encode. .ogg as extension.

P3/AMD 8.1 compile oggenc2.exe in the EAC dir is selected.

-q 6 in the commmandline option.


Tools>Compress .wavs in EAC. After I select the .wav file the cmd window opens and then closes in flash and nothing gets compressed. the libmmd.dll file was added to the EAC dir aswell.


I did the testogg thing with the .dll, the .exe and a .wav in a lone folder like john33 did and the encode worked, but not in EAC.

A quick test with castanets at Q7 is disapointing.

Aotuvbeta2 (260kbit/s) - 3/8 : Transparent
Aotuvbeta3 (245kbit/s) - 14/16 : Easy

One sample should not be enough to make conclusive statements about the encoder. I think thanks should be required for the input, but more tests, on more samples, will be preferable.

I will try testing tomorrow when I am less drunk.

-Tyler

Off topic: It seems that you're drunk very frequently, me too!
As we (me & my friends) say: Chlast forever! It means: Booze navždy!

PS: The words you don't understand are from Czech language...

It's worth noting that some further tests with the same sample at Q5 are more pleasing. Where beta3 actually uses a higher bitrate (185kbit/s) than beta2 (169kbit/s) and sounds less annoying. Why at Q7 the two encoders seem to swap sides I can't fathom.

I will do some more tests with more pre-echo samples later today.

This time I tested hihat.wav from the Lame samples page here.

Aotuvbeta2@Q4 (116kbit/s) - 8/8 : Incredibly easy
Aotuvbeta3@Q4 (118kbit/s) - 3/8 : Transparent

Aotuvbeta2@Q5 (145kbit/s) - 8/8 : Still fairly easy. Slight more concentration needed.
Aotuvbeta3@Q5 (149kbit/s) - 8/8 : Easier than Q4 Maybe the practice has helped.

Aotuvbeta2@Q6 (177kbit/s) - 8/8 : Getting tough. Pre-echo on the edge of my perception.
Aotuvbeta3@Q6 (178kbit/s) - 4/8 : Transparent.

Aotuvbeta2@Q7 (202kbit/s) - 5/8 : Bah transparent. Even with some serious concentration.

Bitrates for rest of Q levels:
Beta2 Q7: 202
Beta3 Q7: 202
Beta2 Q8: 237
Beta3 Q8: 231
Beta2 Q9: 300
Beta3 Q9: 295
Beta2 Q10: 466
Beta3 Q10: 454

On this sample Aotuv beta3 has made improvement. I am still confused as to again why upping the Q levels starts to make beta2 use more bits than beta3. Maybe this phenomenom has nothing to do with pre-echo.

What about Aotuvbeta3@Q7 for hihat.wav?

So, you're saying that Aotuvbeta3 is transparent at Q4, but easy to ABX at Q5 on this sample? I would think that would be a bug, if true.