After much discussion (http://www.hydrogenaudio.org/show.php/showtopic/19213) and misunderstanding (mostly on my part), I think it is about time we start testing the Vorbis encoders and eventually choose the best one to participate in Roberto's 128 kbps multiformat test, which will start on April 14. We should come to a decision by April 10 which gives us about 7 days, starting from now.
Due to a lack of time, we can't make this listening test as formal as the other ones, so it will be a self-prepared test, where each listener will prepare the coded test set and ABC/HR tests themselves. Ultimately that means it is possible to fudge the results but I have full confidence that it's not going to happen since there is barely any zealotry within the Vorbis community itself.
The Encoders
The Vorbis encoders and respective quality values, to be tested are:
1. Vorbis 1.0.1 CVS at q 4.25: http://www.rarewares.org/files/ogg/oggenc2.3CVSMinGW.zip (http://www.rarewares.org/files/ogg/oggenc2.3CVSMinGW.zip)
2. aoTuV 20040402 at q 4: http://www.geocities.jp/aoyoume/aotuv/test.html (http://www.geocities.jp/aoyoume/aotuv/test.html)
3. Modest Tuning beta 3 at q 4: http://homepage3.nifty.com/nyaochi/soft/dist/oggencmtb3.zip (http://homepage3.nifty.com/nyaochi/soft/dist/oggencmtb3.zip)
4. QKTune beta 3.2 at q 4.25: http://www.rarewares.org/quantumknot/oggencqk32.exe (http://www.rarewares.org/quantumknot/oggencqk32.exe)
Optional: GT3b2 with HF reduction at q 4.25: http://www.rarewares.org/quantumknot/oggenchfr.exe (http://www.rarewares.org/quantumknot/oggenchfr.exe) (late addition to the list)
The above quality values have been determined (http://www.foobar2000.net/divers/vorbis/playlist160_MZ.htm) by guruboolez to give approximately 128 kbps on normal music. Given the time constraints (and given how we only got these to go by for now), they will do for now.
The Test Samples
The test samples that will be used are from ff123's 64 kbps listening test. There are 12 samples which can be downloaded from http://ff123.net/samples.html (http://ff123.net/samples.html) (right at the bottom of the page).
Test Results
As for the results, tabular format, such as this one (http://membres.lycos.fr/guruboolez/vorbisoldnew.png) would be nice and you can upload or post it in this thread. Otherwise, you can e-mail your ABC/HR results to: s dot so at griffith dot edu dot au
If you e-mail your result, please write a small post here to let me know so that I can confirm the submission was successful.
The test will end on April 10. Hopefully I can inform Roberto of the result the next day.
If there is anything I've missed or forgot to mention, please tell me ASAP and I'll make the changes/additions here. I apologise for the lack of co-ordination or notice since things have come upon me suddenly. We should manage to get some decent results.
Many thanks,
QK
EDIT: Edited aoTuV link
EDIT 2: Changed to mingw32 compile of 1.0.1 CVS
EDIT 3: Added GT3b2 with hfr. If you are already well into the test before I made this addition and don't feel like redoing everything again, continue with the original 4.
EDIT 4: I messed up the GT3b2/hfr link which pointed to a QK3.2 and GT3b2 combo....replaced with proper GT3b2/hfr binary
aoTuV 20040402 A link place is different.
It is as follows correctly.
http://www.geocities.jp/aoyoume/aotuv/aotu...nt_20040402.zip (http://www.geocities.jp/aoyoume/aotuv/aotuv_experiment_20040402.zip)
However, since you may not be able to carry out direct download, please choose "aoTuV experiment [20040402]" from the following pages.
aoTuV test page (http://www.geocities.jp/aoyoume/aotuv/test.html)
Thanks
A small step-by-step
HOWTO do the test, to make things easier:
1) download all 5 Encoders listed in QuantumKnot's Post and place/unpack them in the same folder
2) download FLAC (http://www.rarewares.org/files/lossless/flac-1.1.0.zip) and OGGDEC (http://www.vorbis.com/files/1.0.1/windows/vorbis-tools-1.0.1-win32.zip) and extract flac.exe and oggdec.exe to the same folder
3) download the samples you want to test from ff123's 64 kbit/s listening test samples (http://ff123.net/samples.html) (right at the bottom of the page)
4) copy paste the following code to a *.txt file:
flac -d -o sample.wav Layla.flac
oggenc23 -q4,25 sample.wav -o sample_101.ogg
encoder -q4 sample.wav
oggencmtb3 -q4 sample.wav -o sample_mtb3.ogg
oggencqk32 -q4,25 sample.wav -o sample_qk32.ogg
oggenchfr.exe -q4,25 sample.wav -o sample_gt3b2hfr.ogg
oggdec sample_101.ogg
oggdec sample.wav.ogg -o sample_aotuv.wav
oggdec sample_mtb3.ogg
oggdec sample_qk32.ogg
oggdec sample_gt3b2hfr.ogg
del sample_101.ogg
del sample.wav.ogg
del sample_mtb3.ogg
del sample_qk32.ogg
del sample_gt3b2hfr.ogg
5) VERY IMPORTANT: if you live in the us or japan replace the "-q4,25" with "-q4.25", if you live in europe (dunno about britain) leave it as is, otherwise you will only encode with "-q4", which wouldnt be good
6) replace "layla.flac" with the actual name of the file you want to test
7) rename your *.txt to *.bat and execute it (now the listening samples will get prepared for testing)
8) download the ABC-HR (http://ff123.net/abchr/abchrBinary0.9b.zip) listening test tool
9) open it and go to "file -> setup test", under "orig wav" open the sample.wav you have on your disc now, under "wav" the other .wav files (dont care about offset)
10) enjoy your listening test
1. Vorbis 1.0.1 CVS at q 4.25: http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip (http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip)
4. QKTune beta 3.2 at q 4.25: http://www.rarewares.org/quantumknot/oggencqk32.exe (http://www.rarewares.org/quantumknot/oggencqk32.exe)
note that with these encoders -q 4.25 will not use 4.25 but 4!
you have to use -q 4,25 if you are in europe!
edit: added a small how to
1. Vorbis 1.0.1 CVS at q 4.25: http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip (http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip)
4. QKTune beta 3.2 at q 4.25: http://www.rarewares.org/quantumknot/oggencqk32.exe (http://www.rarewares.org/quantumknot/oggencqk32.exe)
note that with these encoders -q 4.25 will not use 4.25 but 4!
you have to use -q 4,25!
hmm....could be a Windows localisation problem.
On mine:
E:\vsamples>oggencqk32 -q 4 violin.wav
NOTE: This version of QKTune beta 3.2 is an experimental release and is not suitable for archiving. Use for testing
only!
Opening with wav module: WAV file reader
Encoding "violin.wav" to
"violin.ogg"
at quality 4.00
[ 69.1%] [ 0m00s remaining] /
Done encoding file "violin.ogg"
File length: 0m 02.0s
Elapsed time: 0m 01.0s
Rate: 2.7237
Average bitrate: 133.0 kb/s
E:\vsamples>oggencqk32 -q 4.25 violin.wav
NOTE: This version of QKTune beta 3.2 is an experimental release and is not suitable for archiving. Use for testing
only!
Opening with wav module: WAV file reader
Encoding "violin.wav" to
"violin.ogg"
at quality 4.25
[ 69.1%] [ 0m00s remaining] /
Done encoding file "violin.ogg"
File length: 0m 02.0s
Elapsed time: 0m 01.0s
Rate: 2.7237
Average bitrate: 138.6 kb/s
E:\vsamples>oggencqk32 -q 4,25 violin.wav
NOTE: This version of QKTune beta 3.2 is an experimental release and is not suitable for archiving. Use for testing
only!
Opening with wav module: WAV file reader
Encoding "violin.wav" to
"violin.ogg"
at quality 4.00
[ 69.1%] [ 0m00s remaining] /
Done encoding file "violin.ogg"
File length: 0m 02.0s
Elapsed time: 0m 01.0s
Rate: 2.7237
Average bitrate: 133.0 kb/s
Regarding the aoTuV encoder, to encode at q 4:
encoder -q4 test.wav
Note there is no space between q and the value, which contrasts to the other oggenc encoders.
note that with these encoders -q 4.25 will not use 4.25 but 4!
you have to use -q 4,25!
It's -q 4
.25 here, too. IIRC comma is used in the EU while period is used in the United States and Japan. (I don't know other region.)
1. Vorbis 1.0.1 CVS at q 4.25: http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip (http://www.rarewares.org/files/ogg/oggenc2.3CVS.zip)
4. QKTune beta 3.2 at q 4.25: http://www.rarewares.org/quantumknot/oggencqk32.exe (http://www.rarewares.org/quantumknot/oggencqk32.exe)
note that with these encoders -q 4.25 will not use 4.25 but 4!
you have to use -q 4,25!
The same problem occurred with past Roberto's multiformat test. I hope your reminder will be considered with the following tests. The option of providing an "accepts only dots" version is another solution.
Garf suggested I add GT3b2 with HF reduction at q 4.25 to the list so I'll make it an optional encoder:
http://www.rarewares.org/quantumknot/oggenchfr.exe (http://www.rarewares.org/quantumknot/oggenchfr.exe)
If you're already well into the test and don't want to redo everything again, just continue with the original 4 encoders.
EDIT: I messed up The binary I originally had here (OggDropXPd) was a combo of QKTune b3.2 and GT3b2. I've updated the URL to the point to the proper GT3b2 with hfr binary. I apologise for this. It's 2.30 am here so my brain stopped a long time ago.
ok just a first small finding:
the tunings are significantly better than 1.0.1 here (on the layla sample, but still)!
so it definitely makes sense to join the test and help finding which tuning suits best!!!
,Apr 3 2004, 12:30 PM] The option of providing an "accepts only dots" version is another solution.
That's what was done in the former 128kbps test. Case provided a compile that accepted only dots.
i added a small howto to my first post to make things easier for everyone
note that with these encoders -q 4.25 will not use 4.25 but 4!
you have to use -q 4,25!
It's -q 4.25 here, too. IIRC comma is used in the EU while period is used in the United States and Japan. (I don't know other region.)
I can't comment on the specifics but in the UK the decimal point is "." not ",".
How this effects vorbis I know not.
Fairy
I can't comment on the specifics but in the UK the decimal point is "." not ",".
That was my wrong. Thanks for correction.
OK guys, I've finished. Raw results are also available here (http://cyberquebec.ca/harashin/harashin_results.zip).
(http://cyberquebec.ca/harashin/Vorbis.png)
OK guys, I've finished. Raw results are also available here (http://cyberquebec.ca/harashin/harashin_results.zip).
qktune aotuv mtb3 101cvs
gt3b2 0.261 0.061 0.000* 0.000*
qktune 0.439 0.000* 0.000*
aotuv 0.002* 0.000*
mtb3 0.628
-----------------------------------------------------------------------
gt3b2 is better than mtb3, 101cvs
qktune is better than mtb3, 101cvs
aotuv is better than mtb3, 101cvs
for harashin
gt3b2+hfr and qktune are clear winners
mtb3 and 101cvs are clear losers
Harashin: Thank you for the results. And thanks for taking the trouble to tabulate them as well
ff123: Was that analysis done using the tool you describe here (http://ff123.net/friedman/stats.html)? It looks perfect for choosing which encoder. So after we receive say 10 results from 10 different people, do we run this on each listener's results or on the whole group?
ff123: Was that analysis done using the tool you describe here (http://ff123.net/friedman/stats.html)?
Yes. That's the only analytical tool for listening test results I know of that is publicly available.
It looks perfect for choosing which encoder. So after we receive say 10 results from 10 different people, do we run this on each listener's results or on the whole group?
You must first create result tables for each sample. One column for each encoder tested, and one line for each listener.
So, you'll end up with 12 tables. Run each one of these tables through Friedman, and you'll get something similar to this:
friedman.exe -a results05.txt
FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/
Blocked ANOVA analysis
Number of listeners: 20
Critical significance: 0.05
Significance of data: 2.70E-002 (significant)
---------------------------------------------------------------
ANOVA Table for Randomized Block Designs Using Ratings
Source of Degrees Sum of Mean
variation of Freedom squares Square F p
Total 99 67.80
Testers (blocks) 19 40.26
Codecs eval'd 4 3.65 0.91 2.91 2.70E-002
Error 76 23.89 0.31
---------------------------------------------------------------
Fisher's protected LSD for ANOVA: 0.353
Means:
Compaact Real Faac iTunes Nero
4.68 4.37 4.32 4.21 4.11 <====
---------------------------- p-value Matrix ---------------------------
Real Faac iTunes Nero
Compaact 0.080 0.049* 0.011* 0.002*
Real 0.822 0.400 0.163
Faac 0.537 0.240
iTunes 0.574
-----------------------------------------------------------------------
Compaact is better than Faac, iTunes, Nero
(from the latest aac test)
Now, notice the line I put a <==== above. Take that same line from each sample result, and create a final table. Run this table through Friedman, and you'll get your final ranking.
Thanks Roberto.
Forgot to mention: You can use Phong's wonderful Chunky (http://www.phong.org/chunky/) to parse the abc/hr result files into tables that can be fed to friedman. It reduces 2 hours of work to 5 seconds :B
ok i now finished all 12 samples too
i will not post my results till april 10 to avoid that anyone gets biased, but only that much:
1.0.1 is definitely last, lying 1.19 points behind the first one (funny its the same for harashin )
1.0.1 is definitely last
Nice. That definitely agrees well with the other listening tests.
Because I don't have too much time, I tested Waiting only. It's 12:03 after midnight as well... I'm not sure if the results below are valid or not, because I didn't test all the files, but since I took the time to do the test, I will post them anyway. Below, you can see that I'm not too sensitive or picky about Vorbis artifacts.
-------------------------------------------------------------------
ABC/HR Version 0.9b, 30 August 2002
Testname: Waiting - ogg
1R = C:\My Music\test_samples\waiting\QK32.wav
2L = C:\My Music\test_samples\waiting\1.0.1CVS.wav
3R = C:\My Music\test_samples\waiting\GT3b2hfr.wav
4L = C:\My Music\test_samples\waiting\MTb3.wav
5L = C:\My Music\test_samples\waiting\aoTuV20040402.wav
---------------------------------------
General Comments:
all abxable, but they are all not really annoying.
---------------------------------------
1R File: C:\My Music\test_samples\waiting\QK32.wav
1R Rating: 3.9
1R Comment:
---------------------------------------
2L File: C:\My Music\test_samples\waiting\1.0.1CVS.wav
2L Rating: 4.5
2L Comment:
---------------------------------------
3R File: C:\My Music\test_samples\waiting\GT3b2hfr.wav
3R Rating: 3.9
3R Comment:
---------------------------------------
4L File: C:\My Music\test_samples\waiting\MTb3.wav
4L Rating: 3.9
4L Comment:
---------------------------------------
5L File: C:\My Music\test_samples\waiting\aoTuV20040402.wav
5L Rating: 4.5
5L Comment:
---------------------------------------
ABX Results:
Original vs C:\My Music\test_samples\waiting\QK32.wav
7 out of 7, pval = 0.008
Original vs C:\My Music\test_samples\waiting\1.0.1CVS.wav
7 out of 7, pval = 0.008
Original vs C:\My Music\test_samples\waiting\GT3b2hfr.wav
7 out of 7, pval = 0.008
Original vs C:\My Music\test_samples\waiting\MTb3.wav
7 out of 7, pval = 0.008
Original vs C:\My Music\test_samples\waiting\aoTuV20040402.wav
7 out of 7, pval = 0.008
Thanks for the result. I'm not too sure whether it is statistically ok to include the result for just one sample. Can someone offer some advice here?
Thanks for the result. I'm not too sure whether it is statistically ok to include the result for just one sample. Can someone offer some advice here?
Of course it is. Just put it together with the other results you receive.
I get one-sample participants all the time
Finished too... My results are very different from harashin's. I'm the first surprised by my results. I could publish them, but it's maybe better to wait the end of the test.
To help anyone wanting to join the fray instantly, here's a little help.
I made two small scripts for this on Windows. Place them together with the samples, the encoders, flac.exe and oggdec.exe in a directory.
Call up Notepad, and copy/paste the first block. Save as blah.bat .
call listentest1.bat ATrain
call listentest1.bat BachS1007
call listentest1.bat BeautySlept
call listentest1.bat Blackwater
call listentest1.bat FloorEssence
call listentest1.bat Layla
call listentest1.bat LifeShatters
call listentest1.bat LisztBMinor
call listentest1.bat MidnightVoyage
call listentest1.bat thear1
call listentest1.bat TheSource
call listentest1.bat Waiting
Save the following as listentest1.bat :
flac -d -o %1.wav %1.flac
oggenc23 -q4,25 %1.wav -o %1_101.ogg
encoder -q4 %1.wav
oggencmtb3 -q4 %1.wav -o %1_mtb3.ogg
oggencqk32 -q4,25 %1.wav -o %1_qk32.ogg
oggenchfr.exe -q4,25 %1.wav -o %1_gt3b2hfr.ogg
oggdec %1_101.ogg
oggdec %1.wav.ogg -o %1_aotuv.wav
oggdec %1_mtb3.ogg
oggdec %1_qk32.ogg
oggdec %1_gt3b2hfr.ogg
del %1_101.ogg
del %1.wav.ogg
del %1_mtb3.ogg
del %1_qk32.ogg
del %1_gt3b2hfr.ogg
the version of listentest1.bat for the american folks :
flac -d -o %1.wav %1.flac
oggenc23 -q4.25 %1.wav -o %1_101.ogg
encoder -q4 %1.wav
oggencmtb3 -q4 %1.wav -o %1_mtb3.ogg
oggencqk32 -q4.25 %1.wav -o %1_qk32.ogg
oggenchfr.exe -q4.25 %1.wav -o %1_gt3b2hfr.ogg
oggdec %1_101.ogg
oggdec %1.wav.ogg -o %1_aotuv.wav
oggdec %1_mtb3.ogg
oggdec %1_qk32.ogg
oggdec %1_gt3b2hfr.ogg
del %1_101.ogg
del %1.wav.ogg
del %1_mtb3.ogg
del %1_qk32.ogg
del %1_gt3b2hfr.ogg
1. Vorbis 1.0.1 CVS at q 4.25: http://www.rarewares.org/files/ogg/oggenc2.3CVSMinGW.zip (http://www.rarewares.org/files/ogg/oggenc2.3CVSMinGW.zip)
This encoder crashs here. Most likely a problem related to SSE not supported by my processor (Athlon 1.3GHz - not AthlonXP); ICL compile from rarewares works though.
John33...?!
ok time for my results
(http://8ung.at/bond/ergebnis_bond.gif)
note that the confidence intervals are surely not correct (i simply copy/pasted my results in an old table from rjamorim)
(http://8ung.at/bond/vorbis_bond.gif)
and the result files can be found here (http://8ung.at/bond/bond_results.zip)
note that the confidence intervals are surely not correct (i simply copy/pasted my results in an old table from rjamorim)
The bars are pretty close to what they should be (each one in your particular case should be 0.535 long, or plus/minus 0.2675 from the average)
The Fisher's LSD is the length of each error bar.
ff123
note that the confidence intervals are surely not correct (i simply copy/pasted my results in an old table from rjamorim)
The bars are pretty close to what they should be (each one in your particular case should be 0.535 long, or plus/minus 0.2675 from the average)
ok thanks
so basically my vote would go to aotuv, qkt or gt3b2+hfr
dunno which one is the most interesting one technical-wise?
OK, time for mine (more negative against Quantum Knot tuning):
(http://membres.lycos.fr/guruboolez/AUDIO/vorbis128/vorbis128.png)
GREEN= best encodings
ORANGE= worse encoding
log files are available here:
http://membres.lycos.fr/guruboolez/AUDIO/vorbis128/ (http://membres.lycos.fr/guruboolez/AUDIO/vorbis128/)
QK tuning are suffering from the opposite effect of CVS: low-energy/powerless/hollow sound. And sometimes there's noise and powerless issues at the same time.
If you average the scores across the 3 listeners who submitted full results, the table looks like this:
101CVS AoTuV Mtb3 QKTune GT3_HFR
Atrain 3.0 4.2 3.3 3.6 3.7
BachS1007 3.4 4.3 3.4 3.3 3.3
BeautySlept 3.8 4.8 4.0 4.9 4.8
Blackwater 2.0 3.0 2.2 3.1 4.0
FloorEssence 2.7 4.3 3.0 4.1 4.7
Layla 2.5 3.5 3.3 3.7 3.6
LifeShatters 2.4 4.2 2.8 3.4 3.5
LisztBMinro 3.6 3.4 3.5 4.2 3.6
MidnightVoyage 2.4 3.7 2.5 3.5 3.5
Thear1 2.4 3.6 3.0 3.3 3.4
TheSource 3.2 3.1 3.6 3.2 3.2
Waiting 2.7 3.0 2.9 2.9 3.0
2.84 3.76 3.12 3.60 3.69
Which would yield:
AoTuV GT3_HFR QKTune Mtb3 101CVS
3.76 3.69 3.60 3.12 2.84
---------------------------- p-value Matrix ---------------------------
GT3_HFR QKTune Mtb3 101CVS
AoTuV 0.669 0.312 0.000* 0.000*
GT3_HFR 0.556 0.001* 0.000*
QKTune 0.004* 0.000*
Mtb3 0.074
-----------------------------------------------------------------------
AoTuV is better than Mtb3, 101CVS
GT3_HFR is better than Mtb3, 101CVS
QKTune is better than Mtb3, 101CVS
ff123
Edit: fixed average table
Edit2: Addition of LoFiYo's results for "waiting" don't significantly affect the outcome
Edit3: Addition of Mac's results for "waiting" don't significantly affect the outcome
I only have one sample to contribute to your test, the others all ended up with each codec getting 5/5.. I'll try again if you have another Vorbis pre-test before proposed dialup test
)[/span] - they all had a slight echo on the words that wasn't in the originals. QK was worse because one of the actual words sounded.. almost as though it had an incredibly mild distortion effect applied to it. This was the only sample I managed to spot any codecs on
Hope this helps a little, and thanks to everyone for working on these encoders
Many thanks to ff123 for analysing the results and also to those submitting.
It looks like there is a tie between aoTuV, GT3b2+hfr, and QKTune beta 3.2. aoTuV got the highest rating (3.76) out of the three so that means it was judged the best Vorbis encoder. Therefore, I suggest we submit aoTuV to the 128 kbps multiformat test.
Aoyumi: I suggest you make an oggenc.exe of aoTuV to make it easier for people to encode.
i have nothing against aotuv
No matter what encoder is chosen: Please provide me a compile that ignores user's local settings, and always uses either , or . for decimal separation.
I've PM'd aoyumi about providing an oggenc compile.
Is pre-echo code tuning (easily) pluggable for AoTuV? I've just read the short comments I've wrote during my tests, and it seems that AoTuV was more affected by pre-echo than other files (it's not a strong conclusion, and this supposition need specific tests for confirmation).
Anyway, it's sad to see that only three full sets of results were posted /
Is pre-echo code tuning (easily) pluggable for AoTuV? I've just read the short comments I've wrote during my tests, and it seems that AoTuV was more affected by pre-echo than other files (it's not a strong conclusion, and this supposition need specific tests for confirmation).
Anyway, it's sad to see that only three full sets of results were posted /
Yes, it should be quite easy to add pre-echo tunings to aoTuV though it is not going to be able to make the multiformat test. Aoyumi made a merge with Garf's tunings with a previous version of aoTuV so I'm sure he'll consider doing the same in the near future.
With regards to the results, it exceeded my expectations in a way since:
1. The test was organised and announced with very short notice
2. Vorbis has lost a lot of interest and attention, compared with codecs like AAC which enjoy active development and publicity.
nyaochi did PM me saying he would have his results in soon, though I assume he has been quite busy lately.
Thanks for the answer.
Vorbis has lost a lot of interest and attention, compared with codecs like AAC which enjoy active development and publicity
hmmm, not so sure. Lot of vorbis users are open-source supporters. The AAC agitation shouldn't really affect them. And by reading other generalist forums, I could easily conclude that vorbis is still more popular than AAC. But aac is certainly the new HA heartthrob; and if HA just precede (and make?) the public opinion, yes, I suppose that vorbis would lose popularity and interest in the next time.
Wait and see...
Anyway, it's sad to see that only three full sets of results were posted :o/
Welcome to the world of listening test conduction...
This is as a result of my test.
Please look at here. Listening Test (http://www.geocities.jp/aoyoume/lt/)
I suggest you make an oggenc.exe of aoTuV to make it easier for people to encode.
Since it was the test version, it did not plan to have released oggenc.exe etc. Since it seems that the so so result is obtained, I think that a plan will be changed. Please wait a little.
Is pre-echo code tuning (easily) pluggable for AoTuV?
Yes, it is easy if it is pre-echo tuning like GT3 b1 and QKTune3.2. However, since there is a case which the bit rate increases superfluously, about this problem, it is deferment.
and it seems that AoTuV was more affected by pre-echo than other files.
The portion which is likely to be concerned with pre-echo will not change with the present place 1.0.1.
and it seems that AoTuV was more affected by pre-echo than other files.
The portion which is likely to be concerned with pre-echo will not change with the present place 1.0.1.
I'd probably worried about pre-echo with AoTuV because other problems audible with CVS encoder were removed or lowered. Good new, and thanks for this clarification (and of course, for all your job)
OggEnc and the source code were uploaded to the test page.
In use, Please don't encode by the sampling frequency 30kHz or less. problem remain.
aoTuV test page (http://www.geocities.jp/aoyoume/aotuv/test)
Good new, and thanks for this clarification.
Aoyumi, your oggenc doesnt recognize the , / . separation rjamorim asked for
No matter what encoder is chosen: Please provide me a compile that ignores user's local settings, and always uses either , or . for decimal separation.
I don't think it's necessary, because -q4 should be OK with this AoTuV encoder (but more bitrate tests are needed to be sure)
(but more bitrate tests are needed to be sure)
Yes, I would be grateful if people could run bitrate tests. I am on my parents' Pentium 166, so encoding large batches of files is not really an option (specially considering they have a 2Gb HDD, and less than 200Mb are free)
No matter what encoder is chosen: Please provide me a compile that ignores user's local settings, and always uses either , or . for decimal separation.
your oggenc doesnt recognize the , / . separation rjamorim asked for
I am sorry, an understanding was lacking.
By the way, is there any easy method of solving this?
Would you let me know, if some people know simple good solution?
Yes, I would be grateful if people could run bitrate tests.
Artist: Dream Theater
Album: Images And Words
Year: 1992
Genre: Progressive Metal
1.0.1 -q 4,25 | aoTuV -q 4
129,6 128,1
134,1 132,9
130,4 128,4
128,2 127,1
132,9 130,6
131,7 129,3
120,6 119,6
132,7 130,6
-------------------------
Artist: Iron Maiden
Album: Brave New World
Year: 2000
Genre: Heavy Metal
1.0.1 -q 4,25 | aoTuV -q 4
129,2 126,5
128,3 126,2
130,3 127,8
132,3 129,8
130,9 129,1
129,0 127,2
128,9 126,4
130,7 129,4
131,3 129,0
131,1 128,6
-------------------------
Artist: Judas Priest
Album: Rocka Rolla
Year: 1974
Genre: (early) Heavy Metal
1.0.1 -q 4,25 | aoTuV -q 4
128,2 125,8
131,6 129,2
126,7 123,8
128,7 127,0
122,4 119,8
130,4 127,3
125,5 123,1
127,5 125,1
128,0 125,5
123,1 120,2
121,3 120,6
Bitrate of aoTuV -q 4 definately isn´t too high on my samples... looks OK IMO.
I've also tested on some classical tracks: average is inferior to 128 kbps, which is common with vorbis and classical music (at least with all CVS version, from 1.00 to 1.02). I suppose that with other musical genres (especially louder music), bitrate should be really close to 128 kbps.
I made bitrate tables from my own several albums include various styles of music. -q4 should be fair to the 128kbps test.
aotuv_tables.htm (http://cyberquebec.ca/harashin/aotuv_tables.htm)
I've modified the oggenc source to use only a '.' (dot, fullstop) in the quality levels, should we decide to use fractional quality values.
[Link removed]
Test to see if it gives the same output as aoyumi's binary. I ran into a few errors when compiling his source and made a few rectifications to fix this.
EDIT: Found a bug in the quality parsing...
EDIT 2: Fixed the quality parsing bug
For those who want better pre-echo handling in aoTuV, I've merged only the pre-echo tunings (q 2 to 5) from QKTune beta 3.2 with aoTuV.
[Link removed]
Test to see if it gives the same output as aoyumi's binary. I ran into a few errors when compiling his source and made a few rectifications to fix this.
They seem to produce different files here. I'm not sure if the difference is audible though.
(http://cyberquebec.ca/harashin/aotuv.png)
Test to see if it gives the same output as aoyumi's binary. I ran into a few errors when compiling his source and made a few rectifications to fix this.
They seem to produce different files here. I'm not sure if the difference is audible though.
Oh no I used VC7 to compile.
The changes I made to Aoyumi's original code are:
In mapping0.c, mapping0_forward() function:
//int nc_db[n/2];
int *nc_db = (int *)calloc(n/2, sizeof(int));
Since n is not constant, static declaration of that array won't work, so I did a dynamic allocation.
Also, there was a variable declaration in the middle of a block which VC7 complained about, so I moved it to the beginning of the block.
EDIT: I've emailed Aoyumi my patched oggenc.c file so that he can do the compile himself.
Using different compilers isn't sufficient to obtain encoders that produces different output files? IIRC, there were always OBJECTIVE difference between lame release (Mitiok vs Dibrom vs John33), though this difference was never audible. Am I wrong? I've no experience at all on software compiling...
Locale fix binary upload was built and carried out using "oggenc.c" which QuantumKnot corrected. A binary can be downloaded from test page.
Moreover, the difference of a binary is a difference of a compiler. I am using GCC. And an optimization option is also a standard range (default).
Furthermore, since it was a thing that it cannot compile well by VC, correction was added and re-uploaded to the source code. someone check whether this moves normally? (I do not have VC) The binary which builds this source code and is obtained brings the same encoding result as a front thing.
For those who want better pre-echo handling in aoTuV, I've merged only the pre-echo tunings (q 2 to 5) from QKTune beta 3.2 with aoTuV.
http://www.rarewares.org/quantumknot/oggencaqk.exe (http://www.rarewares.org/quantumknot/oggencaqk.exe)
great! can we use this one for the listening test?
I'd guess that would need at least retesting the bitrate and doing the listening test all over :-/
I'd guess that would need at least retesting the bitrate and doing the listening test all over :-/
why? could this hurt quality?
I'd guess that would need at least retesting the bitrate and doing the listening test all over :-/
why? could this hurt quality?
Any tuning brings the risk of an unexpected sideeffect...
Isn't it enough to compare this new thing to original version and check which one is better?
Isn't it enough to compare this new thing to original version and check which one is better?
Yes, a listening test in other words. You also need to check whether it doesnt change the average bitrate (and possibly use new setting to encode with), which is exactly what I already said in my first post.
I am Sorry, There was a serious mistake for locale fix version and source code.
Now, it is substituted for the normal thing.
If some people already downloaded, I will ask you to eliminate the older one.
why? could this hurt quality?
Bad influence will come out of hack of the stereo contained in QKTune depending on the case. It is clear at the low bit rate.
If it is the transplant of only pre-echo and tuning, it should succeed in general (however, it cannot be guaranteed).
I've few lossless albums on my computers. I've compared the bitrate on two different ones:
- cello concertos from Joseph Haydn: highly tonal, fews attacks. Conclusion: both encoders produces exactly the same bitrate (according to foobar2000).
- works for mandolins from Antonio Vivaldi: more sharp attacks. Conclusion: bitrate of AoTuV+QK is clearly higher, up to 11 kbps on two track. Difference on album: +4-5 kbps.
It will be interesting to compare the bitrate with metal or rock discs, mith more percussive instruments.
(P.S. I didn't look for quality)
It will be interesting to compare the bitrate with metal or rock discs, mith more percussive instruments.
Artist: Dream Theater
Album: Images And Words
Year: 1992
Genre: Progressive Metal
1.0.1 -q 4,25 | aoTuV -q 4 | aQK -q 4
129,6 128,1 137,7
134,1 132,9 141,2
130,4 128,4 140,8
128,2 127,1 134,8
132,9 130,6 145,1
131,7 129,3 142,7
120,6 119,6 122,9
132,7 130,6 144,5
Artist: Iron Maiden
Album: Brave New World
Year: 2000
Genre: Heavy Metal
1.0.1 -q 4,25 | aoTuV -q 4 | aQK -q 4
129,2 126,5 141,1
128,3 126,2 138,5
130,3 127,8 140,8
132,3 129,8 143,7
130,9 129,1 141,2
129,0 127,2 139,0
128,9 126,4 140,0
130,7 129,4 139,8
131,3 129,0 141,9
131,1 128,6 140,8
Artist: Judas Priest
Album: Rocka Rolla
Year: 1974
Genre: (early) Heavy Metal
1.0.1 -q 4,25 | aoTuV -q 4 | aQK -q 4
128,2 125,8 135,1
131,6 129,2 143,5
126,7 123,8 129,2
128,7 127,0 135,0
122,4 119,8 121,7
130,4 127,3 140,0
125,5 123,1 129,5
127,5 125,1 134,8
128,0 125,5 135,0
123,1 120,2 133,4
121,3 120,6 129,0
aQK = aoTuV + QK
Bitrate is a bit too high for a ~128 kbps test IMO.
maikmerten> thanks a lot. This is confirming my suspicions.
The "problem" with Garf/QK tuning, it's the gap existing between tonal music and percussive music. There's usually a small difference in bitrate between classical and other kind of music (~8...10 kbps, something like that on average). With QK tuning, the difference is much higher for the same quality setting. It's not a problem in real life, but for this test, it's a serious one. If we lower the setting in order to match 128 kbps, it will lower for sure the quality for tonal samples, like BachS1007 for exemple (because Garf/QK tuning have no quality effect with this kind of music). In other word, with AoTuV+QK we will probably gain quality on some (percussive) samples, but we will also lose (audibly?) quality on other. Really problematic.
A solution would be to keep -q4, and accept the bitrate difference. But...
...I'm really far from sharing the opinion of people asking for bitrate exact match on the tested samples, but I know that the discussion always appears after the test. Here is the bitrate table of both encoders, on the 12 samples used for the AAC test
AoTQK AoTuV
162 136
147 127
134 117
137 126
121 118
131 126
123 119
135 129
152 137
170 138
165 138
143 135
AVR AVR
143.33 128.83
There is virtually no discussion possible for vorbis AoTuV (really close to 128 kbps). I fear that some people will complain about methodology if AoTuV+QK will be the vorbis competitor.
EDIT: clarifications (I hope so).
Other thing: my version of AoTuV+QK oggenc is broken. I've encoded samples with -q3,5 and -q3,7, and bitrate was terribly low (100 kbps on average). Quality is simply awful. -q4 is working perfectly, but at lower bitrate, there's a big problem.
EXEMPLE (extreme): velvet.wav
-q4 = 165 kbps
-q3,99 = 84 kbps
Other thing: my version of AoTuV+QK oggenc is broken. I've encoded samples with -q3,5 and -q3,7, and bitrate was terribly low (100 kbps on average). Quality is simply awful. -q4 is working perfectly, but at lower bitrate, there's a big problem.
EXEMPLE (extreme): velvet.wav
-q4 = 165 kbps
-q3,99 = 84 kbps
Did you test using the ./, hacked version? If you did, try -q3.99 .
I don't see a second uploaded version of AoTuV+QK. Am I wrong?
Hi,
I saw the bitratebug too:
Die Ärzte - Unrockbar (Aotuv-QK):
-q4 ---> bitrate: 134.4kbps (Encoder shows quality 4.000000)
-3.99 ---> bitrate: 116.4kbps (Encoder shows quality 3.990000)
-3,99 ---> bitrate: 96.1kbps (Encoder shows quality 3.000000)
This shows that the encoder doesn't support "," but it's normal that the difference between 4 and 3.99 is so high? Does q4 uses other optimations than q3.99?
EDIT: OUPSSSS, I think I did something wrong. Wait some minutes...
EDIT2: No! My results were true and I just saw, that the q3.99 sounds very crazy! I think there is a bug in the encoder!
Big_Berny
This shows that the encoder doesn't support "," but it's normal that the difference between 4 and 3.99 is so high? Does q4 uses other optimations than q3.99?
It's clearly a bug. Whatever the bitrate value is (100 or 130 kbps), the quality of 3.99/3,99 is horrible (lowpass is alterning between 18 Khz and 2 Khz !!!).
Also the oggenc-aotuv is broken!
q4 ---> bitrate: 126 (sounds ok)
q3.99 ---> bitrate: 117 (sounds very strange!)
No I did no ABX! But this bug is very audible also for my bad ears!
Big_Berny
Here, it doesn't make any difference (the . or , ).
Carlos Paredes - Movimento Perpétuo
q4 -> bitrate: 174 kbps
q3.99 -> bitrate: 110.8 kbps
q3,99 -> bitrate: 110.8 kbps
Still, there's clearly an issue with q3.99
EDIT: and what an issue! It's a serious problem, very, very audible.
I tested aoyoume's reference-encoder! Fortunatly there is no bug! (Only that the "," doesn't work here...)
But q3.99 is a little bit bigger than q4 (128kbits vs. 126kbits)...
I would say that roberto should use the reference-encoder with q4...
Big_Berny
Oh, my...
Oh, my...
I seriously hope you won´t have a nervous breakdown
finally: My 100th post.
Oh, my...
Don't worry. It's probably a small mistake, easy-to-fix.
Anyway, there's no evidence that AoTuV+QK should be use. We must test it before, and find the ideal bitrate setting (of course, if you prefer take the responsability of using an untested version of vorbis, you could do it).
In my opinion, AoTuV beta 2 is a wise choice. For two reasons:
- -q4 could be use without problem. 128 kbps seems to be reached an average, for daily use as well for the short samples selected for the next test. The QK modified version is more problematic (opting for a quality setting inferior to -q4/128 would probably be questionned by some people, as weel as big 128 kbps overrun).
- AoTuV beta 2 was tested, and approved by four persons. It's not a strong collective approbation, but it's better than nothing. AoTuV+QK didn't compete. Bugs are always possible. It's the work of two indepedant developers. An hybrid encoder. Epistemologicaly speaking, it's very problematic to use something like that, even if the output quality is possibly better than AoTuV. If we found a bug after the test, the whole seriousness of the listening test might be ruined.
On the other side, both AoTuV beta2 and AoTuV+QK have a very short life expectancy. In few weeks, something like AoTuV beta 3 will be released. Vorbis 1.1 (major update) too... therefore, the conclusions of the next multiformat test about vorbis will quickly be invalidate. Whatever the choice of the codec for the test.
Gosh, I think I've created a stir.
Firstly, can I say that the aoTuV + QKTune was just an experimental encoder and wasn't meant to be included in the multiformat test. I guess I should have stated that but I did mention it in my earlier reply to guruboolez' questions about including pre-echo tunings into aoTuV and how it wouldn't be able to make the multiformat test.
Quoting myself:
Yes, it should be quite easy to add pre-echo tunings to aoTuV though it is not going to be able to make the multiformat test.
I thought I'd give it a try for those interested but it's still too early to use it. Also, it only includes changes to values that affect pre-echo. There have been no point stereo changes.
Secondly, Aoyumi found the bug in my "rectified" source which is causing the problem, I think. Therefore I suggest that people
use the binaries on his test page rather than the ones I made.
Just for clarification, please use the binaries at
http://www.geocities.jp/aoyoume/aotuv/test (http://www.geocities.jp/aoyoume/aotuv/test)
Aoyumi included the locale fix I emailed him so this version only uses a '.' (dot, fullstop). Again, please make sure through testing of his binary (not mine) that the locale fix is not giving any strange bugs
Sorry for the confusion.
Furthermore, since it was a thing that it cannot compile well by VC, correction was added and re-uploaded to the source code. someone check whether this moves normally? (I do not have VC)
Just to confirm, the source code from your test page now compiles flawlessly in VC
I'm very sorry I could not contribute to this listening test because I had been busy recently. I read aoTuV 20040402 was chosen for the upcoming multi-codecs listening test. I'm in favor of the decision too. Although I had finished half of the test, I threw it away and began again another test, including oggencaqk -q4.
Here's my listening result:
(http://homepage3.nifty.com/nyaochi/temp/comparison_vorbis_tunings.gif)
In few weeks, something like AoTuV beta 3 will be released. Vorbis 1.1 (major update) too... therefore, the conclusions of the next multiformat test about vorbis will quickly be invalidate.
Unless it's "Vorbis weeks' and 'Vorbis quick'
Aoyumi is nevertheless faster, and he updates his encoder more often.
Unless it's "Vorbis weeks' and 'Vorbis quick'
"God - give me patience. NOW!"
Oh, my, what a mess.
I'm about to start doing bitrate deviation tests and encoding. As I understand it, I am supposed to be using this binary:
http://www.geocities.jp/aoyoume/aotuv/ogge...x_20040402m.zip (http://www.geocities.jp/aoyoume/aotuv/oggenc_aotuv_ex_20040402m.zip)
If I'm wrong, please shout ASAP. And God help us all...
I'm about to start doing bitrate deviation tests and encoding. As I understand it, I am supposed to be using this binary:
http://www.geocities.jp/aoyoume/aotuv/ogge...x_20040402m.zip (http://www.geocities.jp/aoyoume/aotuv/oggenc_aotuv_ex_20040402m.zip)
so guys thats important now! we want vorbis to behave at the best possible way, right?
so everyone following this discussion closely get your nuts together, forget all the unnecessary discussions and tell rjamorim if he uses the right binary now!!!
rjamorim,
the version you linked to handles the ./, problem correctly
-q4,25 output 129kbps
-q4 output 123kbps on a small test here
Yes.
Aoyumi is nevertheless faster, and he updates his encoder more often.
Plus we should leave open the possibility that aoTuV may still sound better than the upcoming Vorbis "1.1". I've had a quick scan over Aoyumi's modifications and they are quite interesting.
Nyaochi:
Don't worry. This test did come up very suddenly. And thanks for the results too. Another thumbs down for 1.0.1
Roberto:
Yes, that is the binary that uses a . (dot) only. And since it's a compile by anyone except me, it's gonna work fine.
And since it's a compile by anyone except me, it's gonna work fine.
Although I don't use Vorbis myself, I really appreciate what you've done in the past months so please don't say those things!.
What you're doing here is unvaluable and don't forget you're human, cheer up and keep providing us your good Vorbis work.
edit: though I have to admit that was funny .
Plus we should leave open the possibility that aoTuV may still sound better than the upcoming Vorbis "1.1". I've had a quick scan over Aoyumi's modifications and they are quite interesting.
I still don't quite understand the argument that the official Xiph vorbis implementation is supposed to be a "reference" encoder and that's why it may not fold in improvements.
Doesn't it hurt Vorbis overall to be fractioned into competing implementations? So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate? Doesn't seem optimal to me.
ff123
hm now that rjamorim postponed the test we can maybe test and prepare a merged version
maybe a merged version, using the best parts from all tunings, would give the best results...
what do you guys think?
Doesn't it hurt Vorbis overall to be fractioned into competing implementations? So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate? Doesn't seem optimal to me.
I can see your point.
Vorbis 1.0.2 is in CVS - just needs to be released AFAIK. Vorbis 1.1 will certainly take some time. There is probably enough time for Vorbis 1.0.3 - perhaps someone being in contact with xiph.org could ask if this may be a "community powered" version using some 3rd-party tuning.
This tuning has to meet some requirements:
- It should sound better (of course)
- it should not inflate bitrates
Benefits for xiph.org:
- new version "for free"
- prove Vorbis is open
- pressure for Vorbis 1.1 is lowered
Just my 2 cents...
Doesn't it hurt Vorbis overall to be fractioned into competing implementations? So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate? Doesn't seem optimal to me.
ff123
I guess without competition, there can be no progress.
I already pointed to the possibility of a forking of Vorbis in a previous thread but the point is that the various Vorbis tunings still produce compatible files. They can be played on any standard Vorbis decoder. The only things we have changed are constants affecting various things that determine quality (that are there to be modified). Incompatibility between the various versions is detrimental but we are not seeing that with Vorbis.
The only concern one has is that everyone is free to modify the Vorbis source code however they feel like and are not obliged to release it as open-source. Hence it is possible for Vorbis-variants or forks to appear which are incompatible with Xiph Vorbis, yet still carry the "built on Vorbis" tag, and perhaps include patented and proprietary modifications. Very hypothetical at this stage but forking is still a possibility.
Forking the format or forking the encoder?
I don't think forking the format would be beneficial to anybody.
hm now that rjamorim postponed the test we can maybe test and prepare a merged version
maybe a merged version, using the best parts from all tunings, would give the best results...
what do you guys think?
I think aoTuV is as good as it gets. Nyaochi's results on aoTuV+QKTune don't indicate any sizable improvements which dispels the hope that the pre-echo issues that guruboolez raised could be solved by a simple merging.
About pre-echo: I compared AoTuV against 1.01 CVS on some samples (like mandolin), and AoTuV souned sharper. Can't say if it's really pre-echo improvements, but the noise reduction seems to affect in a positive way the sharpness feeling (at least, on some samples).
Anyway, improvements are really nice. At mid/low bitrate (~96 kbps), vorbis AoTuV is probably the best encoding solution I ever heard (better for my taste than he-aac, at least -again- on some samples).
Nice work
Excellent. I'm gonna re-rip my copy of Vivaldi's Four Seasons using aoTuV.
And since I use CDex, I made these DLLs from aoTuV which can be downloaded from:
http://www.rarewares.org/quantumknot/aoTuV-dlls.zip (http://www.rarewares.org/quantumknot/aoTuV-dlls.zip)
in case anyone is interested in using it.
I have build a complete set of aoTuV RPMs for RedHat 9... please let me know if anybody is interested.
Forking the format or forking the encoder?
I don't think forking the format would be beneficial to anybody.
Forking the encoder. There would be no benefit from changing the bitstream format IMO (it´s already flexible enough).
Excellent. I'm gonna re-rip my copy of Vivaldi's Four Seasons using aoTuV
Sorry, but I am a little confused...
At the risk of jumping the gun, what 'q' settings should be used for aoTuV vs GT3b2? (like q0-q4 = aoTuv; > q4 = GT3b2)
Also, is a merger between these two encoders being proposed???
Sorry, but I am a little confused...
At the risk of jumping the gun, what 'q' settings should be used for aoTuV vs GT3b2? (like q0-q4 = aoTuv; > q4 = GT3b2)
Also, is a merger between these two encoders being proposed???
At q 4 and below, aoTuV is definitely the better encoder (since GT3b2 at q < 5 is similar to 1.0.1 which has been shown in the listening tests here to be the worst). Above q 4, things are a bit confusing. GT3b2 addresses pre-echo problems but has no effect on HF boost/hiss at q 5. I'm not too familiar with aoTuV (perhaps Aoyumi can answer this) but I think the HF problems are addressed at q > 4 and pre-echo handling has been tweaked with respect to 1.0.1
A merger appears the likely solution though after I merged my pre-echo tunings in QKTune beta 3.2 with aoTuV, results weren't as I had expected.
If no-one is working on a aoTuV+GT3b2 merger at the moment, I'm willing to do that.
EDIT: After having a peek at the source, looks like aoTuV does include changes that affect pre-echo (possibly at q 6, 7, 8, 9). So a merge with GT3b2 will cause conflict. I suggest someone test aoTuV at these higher q's to see how it performs
After having a peek at the source, looks like aoTuV does include changes that affect pre-echo (possibly at q 6, 7, 8, 9).
The changed part of aoTuV influences in all the bit rates.
And it will make it hard to be audible in quantization noise (include pre-echo).
Although the pre-echo tuning by the high bit rate may be effective, balance may be broken down conversely.
However, it may have worth of a challenge.
By the way, the present aoTuV is the experiment version and is still due to change.
[Postscript]
I'm sorry, it had mistaken. The measure against pre-echo was slightly made after q6 of aoTuV. I forgot this.
However, original post is a fact again.
I have build a complete set of aoTuV RPMs for RedHat 9... please let me know if anybody is interested.
There are also Debian packages available at RareWares.
Of course, people will only be able to reach it once the host goes back online
If no-one is working on a aoTuV+GT3b2 merger at the moment, I'm willing to do that.
Why don't you, Aoyumi, Nyaochi and whoever else is interested start a Sourceforge project where you can work together? Then, it won't be needed to later come up with hackish merges of each branch's best tunings.
Why don't you, Aoyumi, Nyaochi and whoever else is interested start a Sourceforge project where you can work together? Then, it won't be needed to later come up with hackish merges of each branch's best tunings.
It seems QuantumKnot is (was?) interested:
http://www.hydrogenaudio.org/forums/index....howtopic=19131& (http://www.hydrogenaudio.org/forums/index.php?showtopic=19131&)
Hi !
Could someone provide ogg librairies (ogg.dll, vorbis.dll, vorbisenc.dll, vorbisfile.dll) from aoTuV, Modest Tuning beta 3, QKTb3.2, and GT3b2-HF reduction encoders ??
10x
Hi !
Could someone provide ogg librairies (ogg.dll, vorbis.dll, vorbisenc.dll, vorbisfile.dll) from aoTuV, Modest Tuning beta 3, QKTb3.2, and GT3b2-HF reduction encoders ??
10x
QKTune beta 3.2: http://www.rarewares.org/quantumknot/vorbisqk32-dlls.zip (http://www.rarewares.org/quantumknot/vorbisqk32-dlls.zip)
aoTuV: http://www.rarewares.org/quantumknot/aoTuV-dlls.zip (http://www.rarewares.org/quantumknot/aoTuV-dlls.zip)
I'll compile the other two later when I have time
Ok...Thank you very much QK
The fact of changing dll improve the quality we listen musics or theses dll impoves just the quality at the encoding ?
For example, if we want to listen a file with winamp and the music is encoded by aoTuv or QKTune, the sound will be better if we update dll ?
Or even if I keept always the same dll, musics encoded by ogg vorbis (futurs versions) will be always compatible ?
An other example , in games likes UT2003 if I replace currents dll by theses news dll, the sound will be better ?
The fact of changing dll improve the quality we listen musics or theses dll impoves just the quality at the encoding ?
These dlls don't improve the quality of decoding. It is only encoding.
aoTuV beta2 was released.
Some problems should have improved.
This beta2 believes that I am better than an experiment version.
aoTuV page (http://www.geocities.jp/aoyoume/aotuv/)
aoTuV beta2 was released.
Good news. Thanks alot for your work!
Wonderful ! Have you already make test to compare with the previous version of aoTuv and the other encoders ?
The bitrate of the files encoded by this version seems perfect !
This encoder will may chose for the multiformat test ?
This encoder will may chose for the multiformat test ?
It would be good for some people to do some listening tests first. The idea of including a 3rd party Vorbis tuning into the multiformat listening test is still up for debate.
This encoder will may chose for the multiformat test ?
It would be good for some people to do some listening tests first. The idea of including a 3rd party Vorbis tuning into the multiformat listening test is still up for debate.
I thought it was already decided that the previous aoTuV encoder would be used in the listening test? The decision was based on the Vorbis listening test result, wasn't it?
Roberto should have the appropriate encoder now:
http://www.hydrogenaudio.org/forums/index....ndpost&p=202430 (http://www.hydrogenaudio.org/forums/index.php?showtopic=20389&view=findpost&p=202430)
Frankly I don't understand why this is
still being debated. As you already hinted, if we want to use another encoder we should first conduct a new listening test. I don't think there's time for that now.
Why don't we stop discussing this and just stick to the encoder that won the Vorbis listening test?
Why don't we stop discussing this and just stick to the encoder that won the Vorbis listening test?
because we want vorbis to behave as good as possible
someone could also critize that we didnt test the first alpha version of aotuv, people often simply assume that new versions are better (of course it can be questioned if this is correct always)
still i dont really have time to run such a test atm
did rjamorim already announce when the test will start? or does he already prepare the samples?
did rjamorim already announce when the test will start?
Next wednesday - hopefully
Why don't we stop discussing this and just stick to the encoder that won the Vorbis listening test?
because we want vorbis to behave as good as possible
That's exactly why we shouldn't rush to get the newest encoder included. It first needs to be tested. There is always a risk that flaws got introduced.
someone could also critize that we didnt test the first alpha version of aotuv, people often simply assume that new versions are better (of course it can be questioned if this is correct always)
That has nothing to do with my argument. Because of the importance of the encoder choice, the decision was made to perform a Vorbis listening test. The test is finished, the winning codec was chosen, everybody agreed.
End of story.If we discard this choice for a newly released encoder, then why perform the listening test in the first place? And since Roberto wants to start the test next week we don't have time to organize a new test.
Therefor, my recommendation is not to take any chances and stick with the winner of the listening test.
Have you already make test to compare with the previous version of aoTuv and the other encoders ?
The all-inclusive comparison test with other encoders is omitted.
However, it tunes up so that it may become an original sound more with my ear closely.
An important thing is how you feel by testing this.
This encoder will may chose for the multiformat test ?
Since a new version regards me as better, I want to recommend this.
However, the opinion of other people is important.
Aoyumi's personal results correlate almost perfectly with the average results for the group (harashin, bond, guru, aoyumi, and nyaochi, with extra results on Waiting.wav for LoFiYo and Mac). Here are the averages for the group:
101CVS 3.02
AoTuV 3.87
Mtb3 3.26
QKTune 3.74
GT3_HFR 3.75
And here are Aoyumi's personal averages:
101CVS 3.3
AoTuV 4.2
Mtb3 3.5
QKTune 4.0
GT3_HFR 4.0
Correlation is 0.997, which is the highest of any individual who participated in the listening test. The other correlations were:
bond: 0.98
guru: 0.36
nyaochi: 0.94
So, if Aoyumi personally tested all 12 samples with the beta 2 version against the older version to form his opinion, then it is very likely that the group would agree with his opinion.
ff123
Is there something wrong with my results?
So, if Aoyumi personally tested all 12 samples with the beta 2 version against the older version to form his opinion, then it is very likely that the group would agree with his opinion.
I agree with that.
But it's not clear that Aoyumi tested all 12 samples to form his opinion.
ff123
Edit: Oops, Harashin had scrolled off my Excel screen. His correlation was 0.91 with the group (his numbers had been included in the group averages in my first post, so I didn't actually leave him out).
Edit: pretty much anybody who tested all 12 samples except guru, is likely to produce results which the group can agree with. Such a test can be shorter, since only beta2 needs to be compared against the older version, but it should include all 12 samples.
So, what's the deal? Which codec should I use? It's not very clear from this theme. The freedom of choice is not, what I need. I wanna know, which codec showed best results. Is there such page ready? And is GTune 3 beta 2 + QKTune beta 3.2 EXPERIMENTAL going to be tested?
aoTuV beta2 was released.
updated RareWares Debian Packages available now, too
(html updates to come later, as always unfortunately...)
later
So, what's the deal? Which codec should I use? It's not very clear from this theme. The freedom of choice is not, what I need. I wanna know, which codec showed best results. Is there such page ready? And is GTune 3 beta 2 + QKTune beta 3.2 EXPERIMENTAL going to be tested?
Based on the Vorbis listening test, aoTuV won at q 4, so at this nominal bitrate, it is expected to give you the best quality that the Vorbis codec has to offer.
The quality of the new aoTuV (beta 2) is not so definite. Or perhaps I should say, not as definite as the previous aoTuV that was tested by at least 4 people.
With regards to the situation, I personally would love to see the new aoTuV be used in the multiformat test, if it can be reliably verified that it performs better than the previous aoTuV we tested. There is a risk that there is some regression and the last thing we want is for this to appear in the multiformat test.
However, on the other side of the coin, I did accept the point made by Roberto earlier that we shouldn't go about tuning Vorbis continually in order to improve its chances in the listening test up to the last minute. That would be unfair. Therefore I took the initiative and froze my version of QKTune beta 3.2 on that day and Nyaochi also did so for MTb2 the next day. So I already departed from that rule slightly when I agreed to include the experimental version of aoTuV just before the test and I'm not sure if its proper that I bend the rule again after the Vorbis listening test had completed and we'd all agreed to that version of aoTuV.
Not to place the ball in his court deliberately, but it is ultimately for Roberto to decide whether he will accept this new version of aoTuV (if after preliminary testing, it gets the nod from listeners), to be included in his test or continue to use the one we agreed on in this thread.
With regards to the situation, I personally would love to see the new aoTuV be used in the multiformat test, if it can be reliably verified that it performs better than the previous aoTuV we tested. There is a risk that there is some regression and the last thing we want is for this to appear in the multiformat test.
However, on the other side of the coin, I did accept the point made by Roberto earlier that we shouldn't go about tuning Vorbis continually in order to improve its chances in the listening test up to the last minute. That would be unfair. Therefore I took the initiative and froze my version of QKTune beta 3.2 on that day and Nyaochi also did so for MTb2 the next day. So I already departed from that rule slightly when I agreed to include the experimental version of aoTuV just before the test and I'm not sure if its proper that I bend the rule again after the Vorbis listening test had completed and we'd all agreed to that version of aoTuV.
Not to place the ball in his court deliberately, but it is ultimately for Roberto to decide whether he will accept this new version of aoTuV (if after preliminary testing, it gets the nod from listeners), to be included in his test or continue to use the one we agreed on in this thread.
If the older version of AoTuV is to be used, it should be made available on Aoyumi's page. Right now, only the beta2 release is available.
ff123
With regards to the situation, I personally would love to see the new aoTuV be used in the multiformat test, if it can be reliably verified that it performs better than the previous aoTuV we tested. There is a risk that there is some regression and the last thing we want is for this to appear in the multiformat test.
However, on the other side of the coin, I did accept the point made by Roberto earlier that we shouldn't go about tuning Vorbis continually in order to improve its chances in the listening test up to the last minute. That would be unfair. Therefore I took the initiative and froze my version of QKTune beta 3.2 on that day and Nyaochi also did so for MTb2 the next day. So I already departed from that rule slightly when I agreed to include the experimental version of aoTuV just before the test and I'm not sure if its proper that I bend the rule again after the Vorbis listening test had completed and we'd all agreed to that version of aoTuV.
Not to place the ball in his court deliberately, but it is ultimately for Roberto to decide whether he will accept this new version of aoTuV (if after preliminary testing, it gets the nod from listeners), to be included in his test or continue to use the one we agreed on in this thread.
If the older version of AoTuV is to be used, it should be made available on Aoyumi's page. Right now, only the beta2 release is available.
ff123
I still have my own compile:
http://www.rarewares.org/quantumknot/oggenc-aotuv.exe (http://www.rarewares.org/quantumknot/oggenc-aotuv.exe)
Hopefully it is bug free
If anyone has some spare time, by all means, do a test comparing this new aoTuV with the old one. Irrelevant to whether it does or doesn't make it to the multiformat test, we would still like to know whether it is the best. I'm already contemplating using this to rip my audio collection
Not to place the ball in his court deliberately, but it is ultimately for Roberto to decide whether he will accept this new version of aoTuV (if after preliminary testing, it gets the nod from listeners), to be included in his test or continue to use the one we agreed on in this thread.
I won't accept anything without some valid backing up. Otherwise, I'll be making a criticism target out of myself. I only accepted featuring auTuV because there was a listening test behind it I could point critics to.
It seems that aoTuVb2 is superior to its previous version on the same samples.
aotuv_results.zip (http://cyberquebec.ca/harashin/aotuv_results.zip)
(http://cyberquebec.ca/harashin/aotuvb2.png)
It seems that aoTuVb2 is superior to its previous version on the same samples.
It's probably a pretty safe bet that the other 4 people who listened to all 12 samples will also find beta2 to be better on this sample set (except maybe guru whose correlation with the group wasn't very high).
What is the bitrate penalty for this improvement?
ff123
Surprisingly, seems the b2 tends to produce smaller files.(at least with the 12 samples) Therefore, IMO including the b2 shouldn't be unfair to the 128kbps features tests.
(http://cyberquebec.ca/harashin/aotuv_bitrate.png)
Excellent. Thank you, harashin and ff123 (and of course Aoyumi).
Sorry if I looked overly paranoid, but I just wanted to remind everybody not to submit the latest and greatest version of a codec without testing. But then again, Roberto would never accept this anyway.
With all this progress on Ogg Vorbis, it's hard to believe that, only a few months ago, we had the infamous "Is Vorbis dead"-thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=18098&).
Well, if someone else can come with results that corroborate b2 is better than b1, I will include it in my test.
Anyone up to the challenge? I would need these results by monday the latest.
Edit: Thank-you for testing, harashin.
My listening result: aoTuV beta2 seems to be better than the previous version. Particularly, preecho problem in Blackwater and FloorEssence samples, background noise problem in MidnightVoyage sample and crash cymbal sound in thear1 sample are improved. IMHO, it's OK to use atb2 for 128kbps instead of at20040402 if someone else does not notice severe regression.
Here's the result (http://homepage3.nifty.com/nyaochi/temp/result-atb2.zip).
(http://homepage3.nifty.com/nyaochi/temp/atb2.gif)
is aoTuV beta2 available as oggenc yet?
is aoTuV beta2 available as oggenc yet?
Check his site (http://www.geocities.jp/aoyoume/aotuv/test.html) out.
thanx harashin
OK. Considering harashin's and nyaochi's results, I would reckon aoTuV b2 should be used instead of b1.
Everyone agree with me? Can we get things rolling?
OK. Considering harashin's and nyaochi's results, I would reckon aoTuV b2 should be used instead of b1.
Everyone agree with me? Can we get things rolling?
I think so, yes. Just gotta make sure that version of oggenc doesn't have the localisation difference with the decimal. If so, I can provide a binary.
I think so, yes. Just gotta make sure that version of oggenc doesn't have the localisation difference with the decimal. If so, I can provide a binary.
I think I will go with 4 anyway. So, no worries.
But, of course, a version with . or , hard coded would be welcome
I think I will go with 4 anyway. So, no worries.
But, of course, a version with . or , hard coded would be welcome
Oh yeah, q 4. Silly me
Well, here is my hard coded version, for anyone interested. It uses a . (dot)
http://www.rarewares.org/quantumknot/oggenc-aotuvb2.exe (http://www.rarewares.org/quantumknot/oggenc-aotuvb2.exe)
Thank you for carrying out harashin, nyaochi, and a comparison test.
Locale fix oggenc (.version) of beta2 can be used from a test page.
This outputs the same data as a reference binary.
aoTuV test page (http://www.geocities.jp/aoyoume/aotuv/test.html)
Moreover, on the page of aoTuV, oggenc and dll of the usual version (for win32) by offer of nyaochi are also prepared.
Now that we have some sort of scientific proof that aoTuV is the best Vorbis tuning out of the bunch, do you think it is time to make it the recommended encoder or do we need more rigorous testing before we retire GT3b2?
do we need more rigorous testing before we retire GT3b2?
I think so. We, however, can recommend aoTuVb2 at -q4 and below at the moment.
So let's test aoTuV b2 at 180 kbps nominal bitrate (Q6), so we could compare it with Q5 of GTb2!
So let's test aoTuV b2 at 180 kbps nominal bitrate (Q6), so we could compare it with Q5 of GTb2!
Comparing two codecs at such high bitrates is pretty difficult.
But in this specific case, it's maybe easier. I explain.
There are two known problems with vorbis at this bitrate. By "known", I mean generic problems, occuring with a lot of samples :
- noise issue (very small I admit after -q6): present with GT3b2, maybe removed with aoTuV
- pre-echo issues (very high with CVS code): excellent correction with GT3b (but maybe excessive bitrate inflation), aoTuV need to be tested.
By focusing the tests on these two problems (using percussive samples for pre-echo, and quiet samples for the noise problem), I suppose that we could build a serious opinion about respective quality of these two vorbis encoders.
I was far from internet these two weeks, and my latest aoTuV encoder was the prebeta2 release. I've played a bit with this one, mainly at 96-128 kbps. I've also encoded some samples at -q6, and noticed sometimes additionnal noise, not very hard to ABX. IIRC [I don't have access now on my main computer], on one sample the noise was audible up to -q7. Obviously, the prebeta2 didn't solve the (or maybe "a") noise issue at high bitrate settings.
Testing is possible, and it's worth to try.
on one sample the noise was audible up to -q7. Obviously, the prebeta2 didn't solve the (or maybe "a") noise issue at high bitrate settings.
Doesn't the noise problem occur in GT3? If GT3 is better, it has the possibility of the problem of pre-echo (or block switching).
Simultaneously, I am interested in the sample.
I didn't compared it with GT3 (or even with CVS encoder - only with mpc ).
I'll probably investigate further, with the latest encoder (I used the pre-beta2).
For uploading, it's possible, but not before the next week. Sorry... (I must also find again this sample, or similar ones).
I've done some testings on the samples cause typical Vorbis' artifacts as guruboolez already mentioned.
Brahms3 (http://cyberquebec.ca/harashin/Brahms3_Vorbis_test.htm): I prefer aoTuVb2.
Castanets (http://cyberquebec.ca/harashin/castanets_Vorbis_GT3_aoTuV_test.htm): I prefer GT3b2.
OK, somebody please point me to the EXACT encoder I should be using for my test, so that we avoid last-minute mistakes.
Thank-you.
For uploading, it's possible, but not before the next week.
Thanks.
Brahms3: I prefer aoTuVb2.
Castanets: I prefer GT3b2.
I am also the same opinion as you.
somebody please point me to the EXACT encoder I should be using for my test, so that we avoid last-minute mistakes.
Please use "aoTuV beta2 Win32 OggEnc-locale fix" of aoTuV test page (http://www.geocities.jp/aoyoume/aotuv/test). This is an equivalent for a reference binary.
Please use "aoTuV beta2 Win32 OggEnc-locale fix" of aoTuV test page (http://www.geocities.jp/aoyoume/aotuv/test). This is an equivalent for a reference binary.
Thank-you very much.
I've found my noisy sample, and uploaded here:
http://www.hydrogenaudio.org/forums/index....ndpost&p=208504 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=208504)
@guruboolez
I checked the sample by which you were uploaded.
In order to correct this difference, it is likely to take time considerably. Probably, many experiments are needed, also considering balance with other samples.
If an experiment succeeds, it may be improved by the future version.
Encoding files now, using precisely this version:
http://www.geocities.jp/aoyoume/aotuv/test...c_aotuv_b2m.zip (http://www.geocities.jp/aoyoume/aotuv/test_version/oggenc_aotuv_b2m.zip)
If it's wrong, scream now before it is too late :B
If it's wrong, scream now before it is too late :B
No problem.
Guys, how about compiling an aoTuvb2 plugin for Adobe Audition (Cool Edit Pro)?