there was some talk of replacing the garf tuned version with aoTuV as the new recommended encoder for ogg vorbis.
now that Roberto's test is over and aoTuV did realy well, and considering that in the pretests discussion (for the vorbis part) the few results where more in favour of the new version IIRC...
how about chosing aoTuV beta2 as the recommended encoder for at least lower bitrates (untill q4)?

any thought's on this?

cheers,
Digga

Yes, I think it is safe to recommend aoTuV for q 4 and below which would completely discard 1.0.1 and we're back to the two-tier situation Ideally, it would be nice for aoTuV to be recommended for all bitrates.

Anyway, I'll update the recommended build very soon. Hopefully John33 can prepare an OggDrop using aoTuV

QuantumKnot is (mostly) maintaining the Recommended Version/Settings thread and I'd consider him the resedential Vorbis expert, so I'd leave it up to him.
Seems like a good decicion to me, though.

New libraries would be nice too.

yes, it would be nice to have _one_ recommended encoder, but I gues in order to do so one needs a few representive testsresults for higher bitrates, and that's always a difficult task.

I bet it's in during the next two hours after John reads this, as usual

Is there any reason to recommend John33's build instead of the original AoTuV one?

The "internal" test shows very clearly that 1.01 can't be considered as a reference (if by reference we mean the best implementation).
aoTuV is for me a very strong encoder. Better than 1.01 with pre-echo tweakings. Difference is maybe more impressive at lower bitrate (I've tested -q2) than 128 kbps.
There's also the solution of aoTuV+QK ; I've encoded some samples with this encoding, and the only difference I've heard in quality were in favour of aoTuV+QK (sharper sound). Nevertheless, I didn't encode that much samples, and I can't be sure that this encoding is totally safe compared to original aoTuV code.

Probably not, though he is the maintainer of OggDropXPd. And we all love watching that fish spin.

Maybe a merged version of "aoTuV beta 2 combined with the pre-echo tunings from QKTune beta 3.2" for the lower bitrates combined with GT3b2 for settings >= -q 5 would be a terrific recommended version.

I personally prefer aoTuV b2 to GT3b2 because of its boost/noise improvement with the exception of some serious pre-echo cases(castanets, etc).

I guess it's easier for newbies who don't mess/care/know about commandlines.
that beeing said, there's abselutly no reason to not mention them both IMHO (IF John kindly builds the 'AoTuV-drop').

intersting!

edit: typo

BTW, aoTuVdrop by 3rd party is already there.
http://demupe.hp.infoseek.co.jp/

I'll very happily put some compiles together, but, can someone please point me to the correct library source to be using? TIA.

I would guess it's this at the homepage?

Apart from q 5, are there noise/HF boost problems in GT3b2 at say q 6, 7, 8,... that are fixed or reduced in aoTuV?

I had a test to compare those encoders at -q 6 for noise issue on Brahms3 sample. Brahms3 test

Thanks!!

you're welcome (et v44 )

btw, hurry uo, you only got 1 3/4 hours left

For those who prefer the safety of vanilla MSVC compiles, I've uploaded an aoTuV beta 2 binary and DLLs, compiled with VC7 and nothing else.

http://www.rarewares.org/quantumknot/oggenc-aotuv.zip
http://www.rarewares.org/quantumknot/aoTuV-dlls.zip

Most of the aoTuV b2 compiles are now available at Rarewares. Any outstanding will be added soon.

what? am i missing something?

wasn't aotuv the recommended vorbis compile < q5 since the vorbis format tests?

...anyways, i think it would be nice to have an all-in-one build, so testing higher bitrates would be a good idea

something like aotuv vs aotuv+qk vs gt3b1(2)


later

What I believe has to be compared is aoTuv b2 @ Q6 against GT3b2 @ Q5... The "Q" is just a symbol. It represents the average bitrate. So if you compare two codecs it has to fair. In the case of aoTuv q6 and GT3b2 q5 their average bitrates will both be equal to 180 kbps.

Do you gentlemen agree?

Edit: John33, if you compile an aoTuvb2 oggdropXPd, please also compile the aoTuvb2 filter for Adobe Audition. Thank you in advance.

or maybe
gt3b2 vs aotuv vs aotuv+qk+gt3b2

iirc aotuv+qk and gt3+qk already exist

however something like aotuv+qk+gt3b2 would be really kick ass

with vorbis topping the 128kbps test and vorbis2 on its way (hopefully ) and with something like aotuv+gt3b2+qk; vorbis will rule all

bye bye mpc
bye bye he-aac


am i just too optimistic or what !!!

Braak, can't ye see yer killin' me, human? I've been encoding all my music with gt3b2 at -q 6 over the past few weeks for my new Karma assuming the noise issues weren't a problem at that level...

Can we get linux compiles of a standalone oggenc with aoTuVb2? Or maybe compilation instructions even...

*keeping fingers crossed for the appearance of the ONE TRUE VERSION of vorbis that solves HF noise and preecho simultaneously...*

Will do.

I encoded a wav with oggenc compile from Rarewares and another oggenc compile from aoTuV site, and the resulting ogg files differ. Then I decoded them back to wav and both wavs differ too. Differences are not only in headers, but in audio data too. Should I care or is it fine (due to different compilers)?

rarewares debian rep has:
libvorbis-aotuv
oggenc-aotuv (dynamic, essentially vorbis-tools w/libvorbis-aotuv & oggenc broken out...)


later

Assuming the "official" compile is from the same source, then the differences must be due to compilers. BTW, in what way do the headers differ?

Here is the screenshot with highlighted differences at the beggining of files...

EDIT: I removed link to the screenshot.

The only variable in the headers I can think of is probably the serial number.

It is not surprising to find the audio data to differ since different compilers use different optimizations. The Intel compilers obviously have their own special optimizations to give their code the speed advantage, hence there will be small and subtle differences. As to whether Intel-compiled oggenc's sound any different to the human ear than MSVC-compiled or gcc-compiled oggenc's, then I doubt anyone has verified it.

Now if only we could get the dll's compiled that will work with CDex...

The ones I linked earlier will work with CDex

http://www.rarewares.org/quantumknot/aoTuV-dlls.zip

EDIT: And I noticed John33's compiled them too

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

I've also made a (static) oggenc for linux using aoTuV beta 2. No need for libraries. Just run and have fun.

http://www.rarewares.org/quantumknot/oggenc-aotuv.gz

I've updated the recommended encoder page with the new win32 and linux builds of aoTuV beta 2. I've also added a new section explaining the different builds (MSVC, ICL, gcc, etc.) so that people can make their own choice which build to use.

I'm still uncomfortable with having this two-tier encoder setup since it causes confusion. I'm wondering what everyone's opinion is. My hope is to have aoTuV beta 2 replace GT3b2 at higher bitrates. Obviously I can't just decide this. I need feedback from our expert listeners here whether aoTuV is (in general) a better encoder than GT3b2 at these high bitrates.

I would think the first thing to do is to create a bitrate correspondence table. What q setting of AoTuVb2 corresponds to, say q 6 of GT3b2?

Then you could start listening tests.

ff123

@rutra80: Thanks for the screenshots, I think QuantumKnot has provided as much in the way of an answer as I could.

One thing I noticed was that aoTuVb2 is based on Release 1.0.1. It would be good to have this updated against the Post 1.0.1 CVS (or SVC, if you prefer!! ).

Isn't it time to rename the encoder to something understandable and sense making? A blend of upper- and lower case letters - aoTuV beta 2 and the other one - QKTune. And even gt3b2.

So when/if they will be merged together to a recommended version, maybe a new name will be appropriate? I reckon the people responsible for the tunings should be the ones doing that I frankly have trouble telling them apart just by their no sense names!

That's just my humble opinion

I can't realy see a problem concerning the names of the forks/tunings...
one can easily differenciate btw them IMO. I also see no need for upper or lower case letters only, why would there be one?

as for an explenation what the lables stand for (AFAIK):
gt(...) --> Garf tuned
QKTune --> QuantumKnot Tune(d)
aoTuV --> named after it's creator, Aoyumi...

it's the personal choise of the creators how they name their tunings, I think everyone should respect that (of course there's nothing wrong with politly suggesting something else).

In the low bit rate, aoTuV should obtain a quite good result (setting to 32/44.1/48kHz).
And probably, the difference of aoTuV and 1.0.1 will be so large that the bit rate is low.
In the high bit rate, although it is dependent on a sample, I like aoTuV generally.

Tuning of aoTuV was performed in the environment of mingw(gcc 3.2). Therefore, I recommend gcc to compile of aoTuV.

Are there any pre-echo tunings at all in the aoTuV version? I have observed that the bitrate does not fluctuate as wildly as it does with GT3B2.

Do you find configuring and compiling in mingw to be very slow? It seems much slower than in linux. I guess the win32 port of rxvt wasn't very optimal.

Yes, that's right. An actual problem is that a part of program contained in mingw consumes a system resource excessively rather than compile being slow. Therefore, in a standard setup of OS, it becomes unstable.

Since assignment of a system resource is increased now, it is proper.

I'd like to add my vote for a common encoder. It's extremely confusing with multiples out there.

(relating to the b2 Windows encoder from Aoyumi's site)
Congrats to Aoyumi! I hope somebody is working on an AoyumiDrop utility.
(BTW, the encoder from a DOS prompt produces files named filename.wav.ogg ...)
Like many, I just encoded my first Aoyumi file, a 'Round Midnight at q7.5. Average bitrate was reported by foobar at 161 kbps and I spotted peaks at above 440 kbps on saxophone passages.
Roberto has told me previously that reported bit rates may not be accurate, but is it truly likely that the bit rates on my file went to 2.75 times the average? Was Aoyumi's tweaking focused on increasing awareness of complexity so as to allow far-above-normal bitrates?

Check RareWares out for oggdropXPd.
You can use oggenc available at Aoyumi's site or RW instead.

I don't think it's strange for a VBR codec like Vorbis. You need to use -M option if the maximum bitrate matters like for streaming purpose. Aoyumi seems to be strongly against this kind of bitrate management with his encoder though.

OK, one simple question.

I want a nominal bitrate of 192 Kbps (-q6 on aoTuV)

What vorbis version should I use to get the best quality on that bitrate: GT3b2 or aoTuV or QKTune?

http://www.hydrogenaudio.org/forums/index....ndpost&p=131596

I don't think the answer to that question is known yet, and it's even possible that there isn't a clear winner. GT3b2 specifically targets preecho (for -q > 4), which for me is easily audible on some problem samples with stock vorbis at -q 6, but is lessened with gt3b2. QKTune also targets preecho, but at -q <= 5 or so. On the other hand, there are other sound quality issues addressed with aoTuV (which does not target preecho). Probably right now, you can find some samples that sound better with any one of them at a given -q level. There's also the aqk2 version that combines QKTune with aoTuV.

I'm sticking with gt3b2 right now at -q 6 because it's 'old reliable' and also because I'm particularly sensetive to preecho. But, listening tests must be done to determine what's really the best, and it may depend strongly on the listener.

I've done a test to compare GT3b2, aoTuVb2, and aqk2 at -q6. None of them is transparent to the original on fantasy sample.
Fantasy_Vorbis_q6_test