This is my own attempt at tuning Vorbis, targetting mainly the pre-echo handling only and nothing else. The tunings are done for q 2, 3, 4, and 5.
I've uploaded a win32 binary (wasn't that hard to make, thank goodness with VS.NET) but it is a bit slow.
The vendor tag is: Xiph.Org libVorbis I 20030909 (QKTune beta 1) EXPERIMENTAL
Again, I stress this is experimental only and I'm not sure of the quality. I didnt change much from the other code so hopefully no breaks in quality.
The uploaded binary is at http://www.hydrogenaudio.org/forums/index....ndpost&p=176752 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=176752)
Test it on music at qualities q 3 and 4 (which I focused a lot of time on improving) but q 2 and 5 are also tuned to an acceptable state. So far, castanets sounds quite nice at q 4. The bitrate of q 5 is generally smaller than GT3b1 at q 5 but the quality isn't too much poorer (I hope). Compare q 5 with GT3b1 too.
This is my first attempt at tuning so don't crucify me if I break something. I'm learning too.
Feedback is most welcome.
I did a quick test on castanets.
QKTune beta 1 (-q5) 15/15: better than 1.0.1(-q5) and aoTuVa2(-q5).
Worse than GT3b1(-q5), but difference is not obvious.
Worse than GT3b1(-q5), but difference is not obvious.
Yes, that is what I expected. It is something I'll try and improve, if only my ears were better.
Try q 3 and 4. That is the quality that I am much less pessimistic about
Try q 3 and 4. That is the quality that I am much less pessimistic about
OK, I compared QKTune(-q4) vs 1.01(-q4).
13/15:QKtune has less pre-echo.
Also, QKtune is slightly better than 1.0.1 at -q3.
I've uploaded beta 2 at http://www.hydrogenaudio.org/forums/index....ndpost&p=177141 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=177141)
The pre-echo should be even less now for q 2, 3, 4, and 5 (and hopefully q 5 is approaching GT3b1 ). Castanets at q 2 and above sounds more crisper than 1.0.1 which is a good sign.
Stereo should be better in q 2 and 3 as I've slided the stereo modes down. q 4 => q 3 and q 3 => q 2. I did this because I heard some flanging on the castanets sample at q 2. It shouldn't hurt quality but may bump the bitrate up a few kbps. *shrugs*
The main quality value I'm targetting most on is q 4 as this is the 128 kbps nominal range. Hopefully QKTune beta 2 is stable enough to use in this medium quality range so we can do some nice ripping at ~128 kbps.....yay!!
Try it and tell me how it goes.
Nice to see, that there are already guys improving Vorbis
Keep it on, QK !
Encoding speed is improved in comparison with QKtuned1, a quick sound test was well.
I think, I'll take your encoder at q3 for my littlle Iriver
WOW,
great to see how developement is going on.
I made a small test between -q 4 (1.01) vs. -q 3 (1.01 qktune 2) with my own produced samples.
The qktune 2 encoded file sounds great. Really close to the original.
Bitrate: 128kbps
The 1.01 sounds bad. Much preecho and smearing, especially the snares!
(but encoding was a bit faster)
Bitrate: 121kbps
Great work!
thanks
Cool, that's good news. The files produced will be bigger than 1.0.1 as QKTune will use up more bits on those hard=to-encode places. On the castanets sample, the average bitrate is about 170 kbps at q 4. If your music has very isolated transients, then the final bitrate won't be very much higher. On classical music where things are a bit smoother, QKTune will perform exactly like 1.0.1.
Oh yeah, this oggenc is slower since I'm not using the Intel C++ compiler and no optimisation switches were used. Just a straight-out-the-box compile from Visual Studio.NET.
Try some ABXing too, though it will be easily ABXable as pre-echo isn't the only problem with Vorbis. At q 2, 3, 4, I easily ABXed it by listening to the high frequency boost. That, I have no solution for at the moment. The tunings in QKTune are only focused on reducing pre-echo.
More listening tests are welcome, esp. from our 'golden eared' members Anyone tried testing q 2?
QuantumKnot, first of all I would like to thank you for your effort.
The case. I don't know if this can be useful:
I encoded spahm.wav sample (the only one I had on my PC) with 1.0.1CVS and QKb2.
Here are results, but first I would like to say I KNOW that Ogg Vorbis is VBR, not ABR codec.
1.0.1CVS
q2.00=182.6
QKb2
q2.00=326.2
Anybody can predict that QKb2 was better at this bitrate difference. And despite Ogg Vorbis is VBR codec, IMHO it is not good to produce such big bitrates at q2. Then I encoded the same sample with QKb1 at different -q (not at ABR mode) to get comparable bitrate:
q0.00=119,3
q1.00=156.7
q1.13=179.8
q1,14=181.6
q1.15=183.4
q1.20=192.4
Then I took 1.0.1 CVS q2 encoding and QKb1 q1.15 encoding and began ABXing on first 4-5 seconds of the file. I ABXed it 45 from 50 times and despite they were ABXable it was quite difficult to say what sample is better. But IMHO I chose sample 1 as winner and that was 1.0.1 CVS encoding. :-( Can anybody do a test at given -q meanings?
P.S. I chose 1.0.1 CVS version because it was less hmmm.... I would say coughing and I can't determine the cause of it. May be it is of preecho or may be postecho.
Thanks for the tests.
I didn't modify the tunings of q 0 and 1 in QKTune b1 or b2 so it won't show any tangible improvement.
Secondly, I am aware this coder will exhibit highly inflated bitrates on difficult samples. At a nominal rate of 96 kbps, even the 1.0.1 coder requires nearly twice as many bits. GT3b1 also suffers from this problem of runaway bitrates. The challenge is to fine tune this down to save as many bits as possible without compromising on quality. Clearly this is something I need to work on and I tried way too hard to get the pre-echo at q 2 down, when in fact, it may not be possible at such a low rate. I'll down-tune q 2 and 3 a bit to rectify this.
But generally speaking, most of the music we encode won't contain so many difficult parts as to affect the final average bitrates by so much. So a slight jump to 200 or 300 kbps on a few frames due to sharp transients are few and far between.
I don't even want to think about the bitrates produced when encoding that artificial impulse train sample
Damn, that is one nasty sample. Just tried to encode spahm.wav using Nero AAC using VBR Internet preset (90 - 100 kbps) (LC profile). Average bitrate came out at 149 kbps and it sounds watery. GT3b1 at q 5 averages at 490 kbps. It's interesting to note that the bitrate shoots back down to nominal from 24 seconds onwards with all the Vorbis encoders and AAC.
I didn't modify the tunings of q 0 and 1 in QKTune b1 or b2 so it won't show any tangible improvement.
1. As I understand the way Ogg Vorbis q values work - any fractional value is a result of interference of whole meanings. So if you tuned q2,3,4,5 - q>1.00 (I used 1.14) is also affected. Am I wrong?
2. Did you tried to encode some different (I mean genre) albums? What is average bitrate?
1. As I understand the way Ogg Vorbis q values work - any fractional value is a result of interference of whole meanings. So if you tuned q2,3,4,5 - q>1.00 (I used 1.14) is also affected. Am I wrong?
2. Did you tried to encode some different (I mean genre) albums? What is average bitrate?
1. That I'm not too sure about. There may be some intermixing at the fractional values. But in terms of actual tuning, I only modified the variables at quality 2 and above. Quality 1 remains the same as 1.0.1. Also to note is that Garf modified the pre-echo trigger thresholds so perhaps that explains why q4.5 had different bitrates. I didn't touch the pre-echo thresholds.
2. Yes, I did a few just to see how it went. I encoded some classical and the bitrate was about the same as 1.0.1 so that's nothing surprising. I encoded some pop and the bitrates were usually slightly higher (+10 kbps). And the most increases came from encoding techno where the bitrates were about 20 kbps kbps higher. Note that I encoded entire songs rather than 30 second samples so generally, it averages out. Unless you are listening to a 3 minute song of just impulse trains
EDIT: While I'm at it, I might try adding lossless stereo coupling to a low q and see if the high frequency boost is there. I just noticed this (http://www.xiph.org/archives/vorbis/200302/0099.html)
I've released a binary of QKTune beta 3. The only changes from the previous beta are at q 4.
http://www.hydrogenaudio.org/forums/index....ndpost&p=185473 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=185473)
I've done some more tweaks to address pre-echo and also experimented with other noise bias values, esp. those affecting transitional blocks (short->long, long->short).
However one particular characteristic at q 4 is a slight reduction in the HF boost. I used nyaochi's 8823.flac (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360) sample, and focused on the range of 7.1 to 9.1 seconds. While not perfect (abxable with original), I was able to ABX the difference between beta 3 and beta 2
WinABX v0.23 test report
02/18/2004 00:03:50
A file: E:\vsamples\qk3.wav
B file: E:\vsamples\qk2.wav
00:04:55 1/1 p=50.0%
00:05:02 2/2 p=25.0%
00:05:24 3/3 p=12.5%
00:05:40 4/4 p= 6.2%
00:06:29 5/5 p= 3.1%
00:06:36 6/6 p= 1.6%
00:06:47 7/7 p= 0.8%
00:06:54 8/8 p= 0.4%
00:07:12 9/9 p= 0.2%
00:07:22 10/10 p< 0.1%
00:07:25 test finished
My impression was the HF boost was a bit lower, though it could be related to pre-echo....
So I need someone to verify this HF boost for me.
Please note this is more experimental than beta 2 and the bitrate has jumped
quite a bit since then. It gives me no comfort that this has happened and I'll address it ASAP....but the apparent HF boost reduction has got me excited for now
I did a test on 41_30sec.
The QKTune b3 didn't bother me with pre-echo, though the HF-boost is still found there.
Also, the bitrate at 191kbps is far bigger than 1.0.1 q4(138kbps).
WinABX v0.42 test report
02/17/2004 23:44:40
A file: I:\test\41_30sec\41_30sec.wav
B file: I:\test\41_30sec\qk3q4.wav
Start position 00:12.6, end position 00:13.4
23:47:01 1/1 p=50.0%
23:47:11 2/2 p=25.0%
23:47:15 3/3 p=12.5%
23:47:26 4/4 p=6.2%
23:47:38 5/5 p=3.1%
23:47:46 6/6 p=1.6%
23:48:10 6/7 p=6.2%
23:48:21 6/8 p=14.5%
23:48:31 7/9 p=9.0%
23:48:53 8/10 p=5.5%
23:49:19 9/11 p=3.3%
23:49:30 10/12 p=1.9%
23:49:52 11/13 p=1.1%
23:49:59 12/14 p=0.6%
23:50:16 13/15 p=0.4%
23:50:25 14/16 p=0.2%
23:50:32 15/17 p=0.1%
23:50:43 16/18 p< 0.1%
23:51:19 test finished
Yeah, it is still there but do you feel the HF boost is more/less/same than that in 1.0.1?
With the ridiculous bitrate increase, I guess this beta is a no-goer.
Yeah, it is still there but do you feel the HF boost is more/less/same than that in 1.0.1?
With the ridiculous bitrate increase, I guess this beta is a no-goer.
On 41_30sec, I think QKTune's HF boost is less than 1.0.1(both q4 and q5) and GT3b1(q5), indeed.
My ABC/HR result. (http://cyberquebec.ca/harashin/41_30sec_Vorbis_test.html)
Thanks for the listening tests. Looks like Modest Tuning is doing the best out of all the encoders.
And where is the Beta3 ?
I realy want to testing it
And where is the Beta3 ?
I realy want to testing it
http://www.hydrogenaudio.org/forums/index....howtopic=17949& (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&)
And where is the Beta3 ?
I realy want to testing it
I removed the binary for beta 3 since it wasn't really worth further testing. I only want to release encoders which I think are not only worth testing, but safe enough to put in the public. The last thing I want is broken quality ogg vorbis files lying around.
If you are still interested in testing it, I can e-mail you the binary. Just PM me your e-mail address.
OK, I've uploaded beta 3.1 which is my second attempt at reducing HF boost/hiss. It is a complete departure from what I did in beta 3 (which admittedly, produced too high bitrates).
Download the binary here:
http://www.hydrogenaudio.org/forums/index....ndpost&p=187306 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=187306)
I've made a certain change to the point stereo mechanism which will try to compensate (in an arbitrary way) the energy increase in high frequencies. This is quite a radical change to the code and is not just a simple tuning. So it may very well break quality in other areas. Use for testing only.
It includes all the pre-echo tunings from beta 2.
Let me know if the HF boost/hiss is higher, lower, or the same with other versions (eg. 1.0.1). And also, please report any other problems like loss of naturalness, loss of tonality, metallic sounds, flanging, watery sounds etc.
Thanks
Well, I did some tests on samples from an album which I usually listen to. (Kyohei Tsutsumi Ultra Best Tracks Soul & Disco)
drdragon_Vorbis_test (http://cyberquebec.ca/harashin/drdragon_Vorbis_test.htm)
Hustle_Jet_Vorbis_test (http://cyberquebec.ca/harashin/Hustle_Jet_Vorbis_test.htm)
Stranger_Vorbis_test (http://cyberquebec.ca/harashin/Stranger_Vorbis_test.htm)
Each sample is hard to encode imo. But, then, I think "Hustle Jet" specially is a new killer sample for the HF boost issue(and pre-echo). The samples are found here.
http://www.hydrogenaudio.org/forums/index....ndpost&p=187351 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187351)
Thanks for the tests and samples. These Vorbis killer samples are invaluable for tuning.
Well, beta 3.1 is doing at least better than its predecessors. *wipes forehead*
One thing I should mention is that the compensated point stereo is sort of quality-independent so it should apply (for better or for worse) to all q values below 6. Since it was based on beta 2, the sweet spots should be from q 2 to 5.
[span style='font-size:8pt;line-height:100%']EDIT: Point stereo isn't used at q>=6 so edited the statement[/span]
I've uploaded an electronic sample which sounds very metallic after encoding with QK3.1.
I can hear a difference up to -q 5 without any ABXing.
But difference is much smaller than with Oggenc 1.01
http://www.hydrogenaudio.org/forums/index....ndpost&p=187389 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187389)
I've uploaded an electronic sample which sounds very metallic after encoding with QK3.1.
I can hear a difference up to -q 5 without any ABXing.
But difference is much smaller than with Oggenc 1.01
http://www.hydrogenaudio.org/forums/index....ndpost&p=187389 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187389)
hmm...Each time I try to download that sample, I get a 0 kB flac file Can you try and upload it again?
Sorry,
but uploads not seem to be working properly in my network.
I've uploaded it again from my server (Mandrake 9.2) and it works.
http://www.hydrogenaudio.org/forums/index....ndpost&p=187398 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187398)
Sorry,
but uploads not seem to be working properly in my network.
I've uploaded it again from my server (Mandrake 9.2) and it works.
http://www.hydrogenaudio.org/forums/index....ndpost&p=187398 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187398)
Yup, I managed to get it now. Thanks.
So is this metallic sound you speak of also present in 1.0.1?
Here's my quick test of QK b3.1. I felt strange stereo impression with QK b3.1 on these two samples, but I could not find a killer sample. I think QKb3.1 improves HF boost. On 8823 sample, it turned the hi-hat sound down much.
ABC/HR Version 0.9b, 30 August 2002
Testname: 8823
1R = C:\test\test\8823\8823-q4mtb2.wav
2R = C:\test\test\8823\8823-q4qk31.wav
3L = C:\test\test\8823\8823-q4atb1.wav
4R = C:\test\test\8823\8823-q4.wav
---------------------------------------
General Comments:
Hard to rank sample 3 and 4.
---------------------------------------
1R File: C:\test\test\8823\8823-q4mtb2.wav
1R Rating: 4.0
1R Comment: I could abx this sample but it was acceptable.
---------------------------------------
2R File: C:\test\test\8823\8823-q4qk31.wav
2R Rating: 3.0
2R Comment: Strange to me. It lowers the volume of hi-hat shots more than the original. It also narrowens stereo image to center.
---------------------------------------
3L File: C:\test\test\8823\8823-q4atb1.wav
3L Rating: 2.5
3L Comment: Hiss of hi-hat shot.
---------------------------------------
4R File: C:\test\test\8823\8823-q4.wav
4R Rating: 2.0
4R Comment: Pre-echo of snare, tom and cymbal drum shots. Much background noise.
---------------------------------------
ABX Results:
Original vs C:\test\test\8823\8823-q4mtb2.wav
6 out of 6, pval = 0.016
Original vs C:\test\test\8823\8823-q4qk31.wav
6 out of 6, pval = 0.016
Original vs C:\test\test\8823\8823-q4atb1.wav
6 out of 6, pval = 0.016
Original vs C:\test\test\8823\8823-q4.wav
6 out of 6, pval = 0.016
ABC/HR Version 0.9b, 30 August 2002
Testname: HongKong GP
1L = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4mtb2.wav
2L = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4.wav
3L = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk31.wav
4R = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
---------------------------------------
General Comments:
Hard to rank sample 2 and 4. I failed to abx sample 1.
---------------------------------------
2L File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4.wav
2L Rating: 2.5
2L Comment: Tambourine's pre-echo.
---------------------------------------
3L File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk31.wav
3L Rating: 4.0
3L Comment: Centered stereo image?
---------------------------------------
4R File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
4R Rating: 2.0
4R Comment: Tambourine's pre-echo.
---------------------------------------
ABX Results:
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4mtb2.wav
4 out of 10, pval = 0.828
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4.wav
6 out of 6, pval = 0.016
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk31.wav
10 out of 12, pval = 0.019
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
6 out of 6, pval = 0.016
It's cool to hack the source code, QuantumKnot.
But difference is much smaller than with Oggenc 1.01
Yup, I managed to get it now. Thanks.
So is this metallic sound you speak of also present in 1.0.1?
1.01 is really worse.
QK3.1 -q 4 performs better than 1.01 -q 6 on this sample!
But the sound reminds me of wma and the stereo image seems to be widespread.
sorry for my bad english
Here's my quick test of QK b3.1. I felt strange stereo impression with QK b3.1 on these two samples, but I could not find a killer sample. I think QKb3.1 improves HF boost. On 8823 sample, it turned the hi-hat sound down much.
Ah, that is something that I feared. I also heard this during tuning (I used 8823 sample and 41_30sec to tune) The compensation I made is very arbitrary and I had to continually tweak it to ensure a balance....so that the hi-hat was not too high and not too low. Looks like it is too low.
The stereo imaging problems are not unusual for the type of change I made. Hopefully it is fixable
It's cool to hack the source code, QuantumKnot.
Yeah, I gave up fiddling with those psych_44.h values. Couldn't do much with them to verify my hypothesis about point stereo.
Yup, I managed to get it now. Thanks.
So is this metallic sound you speak of also present in 1.0.1?
1.01 is really worse.
QK3.1 -q 4 performs better than 1.01 -q 6 on this sample!
But the sound reminds me of wma and the stereo image seems to be widespread.
sorry for my bad english
Ah ok. I needed to check this in order to work out whether my hack was creating this new problem or whether it was always there in the beginning so I'm innocent. As is always the case, I end up breaking more than I can fix.
As is always the case, I end up breaking more than I can fix.
These results sound to me like you have fixed more than you have broken . I will do some testing on these Vorbis versions once I have finished the AAC test.
edit: typo
As is always the case, I end up breaking more than I can fix.
These results sound to me like you have fixed more than you have broken . I will do some testing on these Vorbis versions once I have finished the AAC test.
edit: typo
Many thanks.
I've got some new ideas on how to improve it, though it could mean an increase in the bitrate. In which case, I might have to downtune or remove my pre-echo tunings. We'll see.
I've tried to address the problems with stereo imaging and excessive suppression of the hi-hat that nyaochi reported in his listening tests in beta 3.2 which can be downloaded from:
http://www.hydrogenaudio.org/forums/index....ndpost&p=187669 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=187669)
These are mainly experimental changes which I've found through listening tests, to improve the problems with beta 3.1. It uses a less aggressive linear compensation to prevent excessive suppression of the hi-hat. Also, my suspicion is that this compensation has 'unmasked' the mono effect of point stereo, which explains why the stereo image is collapsing into the centre (which is an undesirable of point stereo). To counter this, I've implemented a 'partial point stereo' where I retain some angle information (diffuse sounds/reverberations) in the compensated frequencies. Now the hi-hat isn't so 'centered' anymore though perhaps it might be a bit too diffuse?
We'll see how it goes. The more I spend time doing this, the more I realise this is only a band-aid solution and doesn't fix the root of the problem, which I suspect has little to do with point stereo....
I also want to offer my sincere thanks to those who are willing to download these test binaries and spend time testing them. I sometimes feel guilty releasing test binaries so frequently as I realise listening tests are very time consuming. I can assure you I do my best in testing quality before releasing, but my ears are not so good. The feedback has been invaluable and I am learning heaps.
On my samples, I couldn't find any stereo imaging problems with my headphones(Sennheiser HD580). Nevertheless, I still did 2 tests to detect other artifacts, so I believe "better than nothing". The one is adopted as a killer sample,(2harps) and the other is cropped from my favourite song.
Golden Vorbis test (http://cyberquebec.ca/harashin/golden_Vorbis_test.htm)
2harps Vorbis test (http://cyberquebec.ca/harashin/2harps_Vorbis_test.htm)
The samples are found at usual place (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=187693).
Damn, you created a monster !
The sound is completely different (especially the hi-hats) to b3.1 and mostly transparent at -q 4.
But there is a big bug in -q 2
Oggenc QK 3.2 adds very strange tones to the material
Hope you'll fix that
bye
Awesome. Now merge that with GT3B1 and you have pre-echo improvements from Q2 all the way into the high quality settings
Just curious, if you can tune this codec, and Garf can tune this codec, why can't Xiph tune this codec? No interest in doing so I imagine, or else they would have incorporated Garf's tunings.
Thanks for your effort with this.
On my samples, I couldn't find any stereo imaging problems with my headphones(Sennheiser HD580). Nevertheless, I still did 2 tests to detect other artifacts, so I believe "better than nothing". The one is adopted as a killer sample,(2harps) and the other is cropped from my favourite song.
Golden Vorbis test (http://cyberquebec.ca/harashin/golden_Vorbis_test.htm)
2harps Vorbis test (http://cyberquebec.ca/harashin/2harps_Vorbis_test.htm)
Luckily pre-echo is something that can be fixed without too much trouble. But how beta 3.2 performs on classical samples is an uncertainly as my ears aren't that good with this genre though last night, I tried it on guruboolez's violin sample and it seems to sound the same (ie. noisy) as 1.0.1 I suspect that noise is different to the HF boost which some of us are hearing on hi-hats and cymbals. *shrugs*
I'll do some pre-echo tuning based on the 2harps sample. Many thanks.
But there is a big bug in -q 2
Oggenc QK 3.2 adds very strange tones to the material
Hope you'll fix that
I'll address the other quality levels soon. At present, I've only been focusing on -q 4 => the 128 kbps range has great symbolic importance.
EDIT: After I listened to q 2 and 3, it does sound pretty nasty. I'll be right on it.
Awesome. Now merge that with GT3B1 and you have pre-echo improvements from Q2 all the way into the high quality settings
Not only will there be pre-echo improvement....it should theoretically remove HF boost in GT3b1 as well.
Just curious, if you can tune this codec, and Garf can tune this codec, why can't Xiph tune this codec? No interest in doing so I imagine, or else they would have incorporated Garf's tunings.
The only person at Xiph who can make major improvements to Vorbis is Monty. However, there are a bunch of other projects that he has to do, so Vorbis sits in his To-Do tray along with other things...kinda like round-robin scheduling. Thankfully Monty is available on IRC sometimes and he very kindly answered a few questions I had about lossless stereo and most importantly, point stereo.
UPDATE: The original beta 3.2 binary has a serious bug which causes spurious tones to appear at q < 4. This is not a bug in the tuning but rather a build problem caused by Visual Studio.NET.
I've replaced the buggy binary with another one (compiled using Visual C++ 6) which does not have this problem. From preliminary listening tests, HF boost seems lower in q 0,1,2,3 as well so things look good for now.
Please replace your previous 3.2 binary with the corrected one. Just go and download oggencqk32.exe again at:
http://www.hydrogenaudio.org/forums/index....ndpost&p=187669 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=187669)
Thanks.
This is not a bug in the tuning but rather a build problem caused by Visual Studio.NET.
Interesting. Any more details on that? I have to say that I always VC6 rather than 7 simply because 7 has never shown itself to have any advantage for my purposes. And, of course, 6 is much more mature!!
It's kind of strange that certain people around here seem to have a reverence for VC6 as providing an essentially 'bug free' environment, certainly when compared with the Intel compilers. The reason I say this is odd is that one thing you can certainly say about M$ is that they certainly can't be accused of having a reputation for 'bug free' software releases. Anyone remember the release of Word 6? It had well over 1,000 known and documented bugs at the date of release!!
This is not a bug in the tuning but rather a build problem caused by Visual Studio.NET.
Interesting. Any more details on that?
I found the problem. I noticed beta 3.1 wasn't exhibiting this sort of behaviour which was surprising since it was compiled using Visual Studio.NET as well. Eventually I traced it down to stupidity of mine. In one of my 'if' statements, I was multiplying an int with a float (1.0) and assigning it back to an int. I didn't even realise this before but somehow beta 3.1 was doing the same thing, but multiplying the int with 1.6. As to why 1.6 was acceptable but not 1.0 is unknown to me.
But since I'm multiplying by unity, I got rid of it and the .NET compile works perfectly now.
Excelent!! The problems (hi-hat and strange stereo impression) with b3.1 were disappeared.
My favorite samples: QK32 won against MTb2 on 8823 and white noise samples, which were used for MTb2 tuning.
ABC/HR Version 0.9b, 30 August 2002
Testname: 8823
1R = C:\test\8823\8823-q4mtb2.wav
2L = C:\test\8823\8823-q4atb1.wav
3R = C:\test\8823\8823-q4qk32.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: C:\test\8823\8823-q4mtb2.wav
1R Rating: 3.2
1R Comment: hi-hat.
---------------------------------------
2L File: C:\test\8823\8823-q4atb1.wav
2L Rating: 2.1
2L Comment: hi-hat and pre-echo.
---------------------------------------
3R File: C:\test\8823\8823-q4qk32.wav
3R Rating: 4.0
3R Comment: Best of all.
---------------------------------------
ABX Results:
Original vs C:\test\8823\8823-q4mtb2.wav
6 out of 6, pval = 0.016
Original vs C:\test\8823\8823-q4atb1.wav
10 out of 11, pval = 0.006
Original vs C:\test\8823\8823-q4qk32.wav
9 out of 13, pval = 0.133
ABC/HR Version 0.9b, 30 August 2002
Testname: HongKong GP
1R = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk32.wav
2L = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
3L = C:\test\hongkong-gp-intro\hongkong-gp-intro-q4mtb2.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk32.wav
1R Rating: 3.0
1R Comment: Spreading Chinese gong to the right channel.
---------------------------------------
2L File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
2L Rating: 2.5
2L Comment: Spreading Chinese gong to the right channel. Pre-echo of tambourine.
---------------------------------------
3L File: C:\test\hongkong-gp-intro\hongkong-gp-intro-q4mtb2.wav
3L Rating: 4.0
3L Comment: Chinese gong is perfect. Pre-echo of tambourine.
---------------------------------------
ABX Results:
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4qk32.wav
6 out of 6, pval = 0.016
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4atb1.wav
7 out of 8, pval = 0.035
Original vs C:\test\hongkong-gp-intro\hongkong-gp-intro-q4mtb2.wav
6 out of 6, pval = 0.016
ABC/HR Version 0.9b, 30 August 2002
Testname: White noise
1L = C:\test\white-noise-12db\white-noise-12db-q4atb1.wav
2L = C:\test\white-noise-12db\white-noise-12db-q4qk32.wav
3R = C:\test\white-noise-12db\white-noise-12db-q4mtb2.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: C:\test\white-noise-12db\white-noise-12db-q4atb1.wav
1L Rating: 2.0
1L Comment:
---------------------------------------
2L File: C:\test\white-noise-12db\white-noise-12db-q4qk32.wav
2L Rating: 3.5
2L Comment:
---------------------------------------
3R File: C:\test\white-noise-12db\white-noise-12db-q4mtb2.wav
3R Rating: 3.0
3R Comment:
---------------------------------------
ABX Results:
Original vs C:\test\white-noise-12db\white-noise-12db-q4atb1.wav
8 out of 9, pval = 0.020
Original vs C:\test\white-noise-12db\white-noise-12db-q4qk32.wav
8 out of 9, pval = 0.020
Original vs C:\test\white-noise-12db\white-noise-12db-q4mtb2.wav
8 out of 9, pval = 0.020
some of guruboolez's samples:
ABC/HR Version 0.9b, 30 August 2002
Testname: Harpsichord(yates)
1R = C:\test\harpsichord(yates)\harpsichord(yates)-q4mtb2.wav
2L = C:\test\harpsichord(yates)\harpsichord(yates)-q4qk32.wav
3L = C:\test\harpsichord(yates)\harpsichord(yates)-q4atb1.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: C:\test\harpsichord(yates)\harpsichord(yates)-q4mtb2.wav
1R Rating: 2.8
1R Comment:
---------------------------------------
2L File: C:\test\harpsichord(yates)\harpsichord(yates)-q4qk32.wav
2L Rating: 2.0
2L Comment:
---------------------------------------
3L File: C:\test\harpsichord(yates)\harpsichord(yates)-q4atb1.wav
3L Rating: 3.5
3L Comment:
---------------------------------------
ABX Results:
Original vs C:\test\harpsichord(yates)\harpsichord(yates)-q4mtb2.wav
6 out of 6, pval = 0.016
Original vs C:\test\harpsichord(yates)\harpsichord(yates)-q4qk32.wav
6 out of 6, pval = 0.016
Original vs C:\test\harpsichord(yates)\harpsichord(yates)-q4atb1.wav
10 out of 14, pval = 0.090
ABC/HR Version 0.9b, 30 August 2002
Testname: Mars
1L = C:\test\mars\Mars-q4mtb2.wav
2L = C:\test\mars\mars-q4qk32.wav
3R = C:\test\mars\Mars-q4atb1.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: C:\test\mars\Mars-q4mtb2.wav
1L Rating: 2.2
1L Comment:
---------------------------------------
2L File: C:\test\mars\mars-q4qk32.wav
2L Rating: 3.0
2L Comment:
---------------------------------------
3R File: C:\test\mars\Mars-q4atb1.wav
3R Rating: 2.6
3R Comment:
---------------------------------------
ABX Results:
Original vs C:\test\mars\Mars-q4mtb2.wav
6 out of 6, pval = 0.016
Original vs C:\test\mars\mars-q4qk32.wav
6 out of 6, pval = 0.016
Original vs C:\test\mars\Mars-q4atb1.wav
6 out of 6, pval = 0.016
I am under the impression that QK32 is now ahead of the tuning race, but I'd like to see more listening results.
I'd like to test all these new encoders, but for the moment, I've internet but not the soundcard and the headphone
Beta 3.2 was felt very impressive. The HF Boost problem has improved remarkably. So conversely that it becomes the low bit rate rather, a high frequency region can be heard so that it may tend to decrease rather than original.
Nice work!
Thanks for the tests, nyaochi. On the harpsichord sample, was the pre-echo in QKb3.2 a problem? My guess is that the stereo compensation is reversing my earlier pre-echo tunings.
The spreading of the chinese gong to the right is something I'll examine. Do you know where I can download this sample?
Beta 3.2 isn't doing so well with the classical genre. If only I had better ears.
Thanks for the tests, nyaochi. On the harpsichord sample, was the pre-echo in QKb3.2 a problem? My guess is that the stereo compensation is reversing my earlier pre-echo tunings.
Yes. Pre-echo around the beginning of the sample.
I uploaded Hong-kong grand prix sample (http://www.geocities.com/nyaochi2000/sample/hongkong-gp-intro.flac.zip) (open the url directly with your browser and rename *.flac.zip to *.flac after your download). I can abx this sample by Chinese gong at the beginning and tambourine.
Thanks. I just downloaded the sample and had a listen. These effects with the gong are very subtle, I must say. But I think I can hear it so I'll see how it goes when I get time for further tuning.
I've uploaded the partial source code of QKTune beta 3.2 so people can see what I've done and hopefully improve on it. It includes only the files that need to be replaced which are psy.c, info.c, and psych_44.h.
http://steve8988.homestead.com/files/vorbis/qkt32.tar.gz (http://steve8988.homestead.com/files/vorbis/qkt32.tar.gz)
Thanks Steve.
I've merged this with GT3b2 and you can d/l a version of oggdropXPd compiled from this merged code at: http://homepage.ntlworld.com/jfe1205/OggVo...9GT3b2QKT32.zip (http://homepage.ntlworld.com/jfe1205/OggVorbis/oggdropXPdV1.7.9GT3b2QKT32.zip). Please remember that this is experimental code only, at this time. The Vendor String is somewhat lengthy and includes the word 'EXPERIMENTAL'!!
Thanks Steve.
I've merged this with GT3b2 and you can d/l a version of oggdropXPd compiled from this merged code at: http://homepage.ntlworld.com/jfe1205/OggVo...9GT3b2QKT32.zip (http://homepage.ntlworld.com/jfe1205/OggVorbis/oggdropXPdV1.7.9GT3b2QKT32.zip). Please remember that this is experimental code only, at this time. The Vendor String is somewhat lengthy and includes the word 'EXPERIMENTAL'!!
Awesome. Less typing for moi. But just a minor point. Time to update the about box too
Just to make sure I understand. This version has:
Garfs GT3B2 tuning
QuantumKnot's HF tuning
It does not have:
QuantumKnot's low bitrate pre-echo tuning
Is that correct?
Just to make sure I understand. This version has:
Garfs GT3B2 tuning
QuantumKnot's HF tuning
It does not have:
QuantumKnot's low bitrate pre-echo tuning
Is that correct?
From my understanding, it has everything! pre-echo improvement from 2 to 10. HF tuning for all q's
Awesome
Please remember that this is experimental code only, at this time. The Vendor String is somewhat lengthy and includes the word 'EXPERIMENTAL'!!
So what needs to happen next so that the experimental tag is no longer needed? More testing, or just more time to see if there are any bad reports from the field?
Just curious. I know it's still early in the process
More testing, or just more time to see if there are any bad reports from the field?
I guess both. I've already encoded a few albums using this encoder and haven't been struck with spurious tones (like in the first version of beta 3.2 ) so it should be safe in terms of detrimental breakage.
The oggdropXPdV1.7.9GT3b2QKT32 seems to produce different files from QuantumKnot's oggenchfr.exe. Does the difference of compiler settings cause this behaviour? And is this nothing worth worrying about?
gt3b2qk32.png (http://cyberquebec.ca/harashin/gt3b2qk32.png)
Thank you guys for your work anyway.
The oggdropXPdV1.7.9GT3b2QKT32 seems to produce different files from QuantumKnot's oggenchfr.exe. Does the difference of compiler settings cause this behaviour? And is this nothing worth worrying about?
gt3b2qk32.png (http://cyberquebec.ca/harashin/gt3b2qk32.png)
Thank you guys for your work anyway.
I'm not sure what compiler John used. I used VC.NET while he probably used VC6 with the Intel compiler. If that is the case, then it is not unusual for the files produced to be different. Or you could try ABXing the files.
I'm not sure what compiler John used. I used VC.NET while he probably used VC6 with the Intel compiler. If that is the case, then it is not unusual for the files produced to be different. Or you could try ABXing the files.
Thanks for the clarification.
For those who are comparing q 3 and 4 with my oggencqk32.exe binary, the files will be different, mainly because I did some more pre-echo tuning before I uploaded the source code. I used castanets to get the perfect clack at q 4.
I just encoded my entire collection for testing with the experimental build of OggDropXPd, and interestingly enough, it became smaller by about 3 percent. I saved about 300 megabytes on a 10 GB collection encoded with gt3b2. Interesting that your tunings would have a positive gain of lower average bitrates as well as hypothetically better sound.
I just encoded my entire collection for testing with the experimental build of OggDropXPd, and interestingly enough, it became smaller by about 3 percent. I saved about 300 megabytes on a 10 GB collection encoded with gt3b2. Interesting that your tunings would have a positive gain of lower average bitrates as well as hypothetically better sound.
Yes, the HF reduction does produce smaller files since I'm applying a limiter to cut out the high frequency boost, hence there is some loss of information, and thus smaller size. Of course, we hope that we lose the undesirable information only which is why some more testing on everyday music is as much needed as listening tests based on small, special case samples.
Awesome. Less typing for moi. But just a minor point. Time to update the about box too
You're right. I did change the heading in the 'About' box, but not the narrative about the tuning. Let's get some feedback and then, assuming all is well, we can release with a full narrative rewrite, where necessary.
Should I publish the merged libs? I guess, yes. Give me an hour, or two, and I'll upload.
Uploaded the 3 files as QuantumKnot did. 'psy.c' is unchanged from Steve's upload, 'info.c' and 'psych_44.h' have changed.
Files are here: http://homepage.ntlworld.com/jfe1205/OggVo...gt3b2_qkt32.zip (http://homepage.ntlworld.com/jfe1205/OggVorbis/gt3b2_qkt32.zip)
Hello,
I´ve merged Vorbis CVS and qkt32.tar.gz for a private linux-compile. I found a piece of "normal" music sounding strange. (However, vorbis 1.0.1 doesn´t seem better to me on this sample but I may have to check this again...)
http://www.hydrogenaudio.org/forums/index....ndpost&p=188853 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=188853)
Maik
Well, this knocked (-) ions down from 375 to 364 kbps . Now I'll have to see if I can ABX them. It doesn't seem like one would be able to ABX between that high of bitrates, but who knows.
What type of music should we be listening to to find problems here? Aphex Twin type stuff, some of which has the highest average bitrates, or for instance, The White Stripes album De Stijl, which has some of the lowest average bitrates in my collection, where losing bits might affect the sound more? In other words, should we be looking at the extremes here, or is there no particular pattern to look for?
Hi,
I was testing QK HF tuning of Vorbis, and may I say that it is without a doubt absolutely super work Well done Quantum Knot !!!
Okay, so I tested low bitrate performance with a music track that has a classical Indian instrument called the 'Tabla' in the beginning. I also tested other codecs at 64 kbps CBR and ~64 kbps VBR. The codecs were AAC HE and LC (Nero), and mp3PRO (Nero). For the vorbis encodes I used oggdropXPd encoder at q = 0.
The bitrates of various encoded files are as follows:
Ogg Vorbis
==========
V 1.0.1 67
QKTune beta 3.2 63
AAC
==========
AAC HE (VBR) 61
AAC HE (CBR) 64
AAC LC (CBR) 64
mp3PRO
==========
VBR 51
CBR 64
It comes as no surprise that all the codecs are easily ABXable, but it is surprising that both the SBR based codecs (AAC HE and PRO) perform badly. The encodes sound the worst from the lot. The AAC LC encode sounds better than HE for the tabla part, but when electronic music starts it looses out heavily.
On the other hand Vorbis 1.0.1 suffers from high freq noise but does reproduce the tabla better than SBR based codecs. QK Tune 3.2 does so much better than 1.0.1 and produces smaller files as well.
The ranking based on my testing:
Vorbis QK3.2 > Vorbis1.0.1 > AAC LC > AAC HE > mp3PRO
I want to upload this sample file. How do I go about that? I would appreciate it if some of you could do a little testing on this file and confirm the same.
EDIT: Uploaded the file (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=189097)
EDIT: The bitrates indicated here are for the complete file not for the 30 sec sample
It comes as no surprise that all the codecs are easily ABXable, but it is surprising that both the SBR based codecs (AAC HE and PRO) perform badly. The encodes sound the worst from the lot. The AAC LC encode sounds better than HE for the tabla part, but when electronic music starts it looses out heavily.
You didn't decode with FAAD2, did you?
Hi,
I was testing QK HF tuning of Vorbis, and may I say that it is without a doubt absolutely super work Well done Quantum Knot !!!
Okay, so I tested low bitrate performance with a music track that has a classical Indian instrument called the 'Tabla' in the beginning. I also tested other codecs at 64 kbps CBR and ~64 kbps VBR. The codecs were AAC HE and LC (Nero), and mp3PRO (Nero). For the vorbis encodes I used oggdropXPd encoder at q = 0.
The bitrates of various encoded files are as follows:
Ogg Vorbis
==========
V 1.0.1 67
QKTune beta 3.2 63
AAC
==========
AAC HE (VBR) 61
AAC HE (CBR) 64
AAC LC (CBR) 64
mp3PRO
==========
VBR 51
CBR 64
It comes as no surprise that all the codecs are easily ABXable, but it is surprising that both the SBR based codecs (AAC HE and PRO) perform badly. The encodes sound the worst from the lot. The AAC LC encode sounds better than HE for the tabla part, but when electronic music starts it looses out heavily.
On the other hand Vorbis 1.0.1 suffers from high freq noise but does reproduce the tabla better than SBR based codecs. QK Tune 3.2 does so much better than 1.0.1 and produces smaller files as well.
The ranking based on my testing:
Vorbis QK3.2 > Vorbis1.0.1 > AAC LC > AAC HE > mp3PRO
I want to upload this sample file. How do I go about that? I would appreciate it if some of you could do a little testing on this file and confirm the same.
hmmm....It beat HE-AAC? That is most unusual since Vorbis is very mediocre at such low bitrate while SBR is absolute magic!! Definitely need some verification here. You can upload the sound file in the uploads section, in the thread called 'Vorbis samples'.
http://www.hydrogenaudio.org/forums/index....ndpost&p=180700 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=180700)
HE-AAC (current encoder) isn't perfect. Some samples have problems with the Nero encoder, and sometimes, other solutions are better.
Maybe the sample could help Ivan, but in my opinion, this situation is not something exceptionnal.
hmmm....It beat HE-AAC? That is most unusual since Vorbis is very mediocre at such low bitrate while SBR is absolute magic!! Definitely need some verification here. You can upload the sound file in the uploads section, in the thread called 'Vorbis samples'.
IMO it's no surprise that Vorbis can beat HE-AAC on a single sample. If you have a look at rjamorim's last 64kbps multiformat test (http://www.rjamorim.com/test/64test/results.html), you'll see that there were some samples where (at least a big part of the) listeners prefered vorbis over HE-AAC or mp3pro.
Oh ok, I don't have much experience with AAC I guess, but from the few times I've tried HE-AAC and mp3pro, they just blew me away.
What type of music should we be listening to to find problems here? Aphex Twin type stuff, some of which has the highest average bitrates, or for instance, The White Stripes album De Stijl, which has some of the lowest average bitrates in my collection, where losing bits might affect the sound more? In other words, should we be looking at the extremes here, or is there no particular pattern to look for?
Hard to say. I guess the first thing is to test music which 1.0.1 has a tendency to boost sounds like cymbals and hi-hats.
Second problem that might surface with this hack is stereo imaging problems. Try to listen for stereo flipping, stereo collapse, or anything unusual about the stereo.
Pre-echo is not top priority since you can only get so much with q 4 and most people are annoyed by hiss/noise more than anything else.
Hello,
I´ve merged Vorbis CVS and qkt32.tar.gz for a private linux-compile. I found a piece of "normal" music sounding strange. (However, vorbis 1.0.1 doesn´t seem better to me on this sample but I may have to check this again...)
http://www.hydrogenaudio.org/forums/index....ndpost&p=188853 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=188853)
Maik
Oh I should have posted my linux binary too. I do all my Vorbis development in Linux.
I've taken a test on guruboolez' Hosokawa___Atem_lied sample.
This one is a very good sample for pre-echo, ringing(I couldn't detect in the test though.), HF boost, etc.
result (http://cyberquebec.ca/harashin/Hosokawa___Atem_lied_Vorbis_q5_test.htm)
I've taken a test on guruboolez' Hosokawa___Atem_lied sample.
This one is a very good sample for pre-echo, ringing(I couldn't detect in the test though.), HF boost, etc.
result (http://cyberquebec.ca/harashin/Hosokawa___Atem_lied_Vorbis_q5_test.htm)
QKTune beta 3.2 at q 5 got a higher rating than GT3b1+QKTune? That is strange, though I assume John replaced my pre-echo tuning for q 5 with Garf's....
QKTune beta 3.2 at q 5 got a higher rating than GT3b1+QKTune? That is strange, though I assume John replaced my pre-echo tuning for q 5 with Garf's....
I felt qk32q5 is smoother(=less pre-echo) than gt3b2qkt32q5. Then I ranked it higher, though the difference is seldom apparent.
I used foobar for aac-he decoding and winamp with mp3pro plugin for mp3pro playback. actually i used winamp diskwriter to convert mp3pro -> wav and then listened to all the encodes in foobar
EDIT: Uploaded the file here (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=189097)
It makes me wonder whether we can get the same quality as GT3b1 without the bitrate inflation.
I think my next series of tunings will focus on pre-echo at q 6, 7, 8, 9, and 10 with focus on managing bitrate.
QuantumKnot, could you please check my private e-mail? I have one question about angle calculation at precomputed_partial_couple_point() function in your source code.
It makes me wonder whether we can get the same quality as GT3b1 without the bitrate inflation.
The tunings you did so far already seem to have increased quality/bitrate ratio. If Garf's tunings kill problems by throwing with bits at them you're already on a road to a better solution.
Good luck
QuantumKnot, could you please check my private e-mail? I have one question about angle calculation at precomputed_partial_couple_point() function in your source code.
Oh sorry!! Mozilla Thunderbird marked your email as Junk Mail and moved it to the Junk Mail folder without my knowing.
I just replied to it but forgot to mention one thing. I assumed qA to be an angular value since the two quantities are named qM and qA, where M is mag and A is ang. So yes, you are right. The change I made was an experimental and arbitrary one. From what I understand, the angle value is essentially the difference between L and R (from a decoupling point of view), thus I understood it from that context. I didn't really view it as an actual 'angular' value but rather representing a 'diffuse' quantity.
On closer inspection, it appears the second channel would decouple to the first plus a fraction of the second. I do have the coupling code there but since it tended to make things worse at the time, I commented it out.
On closer inspection, it appears the second channel would decouple to the first plus a fraction of the second. I do have the coupling code there but since it tended to make things worse at the time, I commented it out.
I replied to your email. If we didn't notice any stereo image problem with QK3.2, I think we can set the angle value to zero and only use your linear compensation.
On closer inspection, it appears the second channel would decouple to the first plus a fraction of the second. I do have the coupling code there but since it tended to make things worse at the time, I commented it out.
I replied to your email. If we didn't notice any stereo image problem with QK3.2, I think we can set the angle value to zero and only use your linear compensation.
If we set the angle to zero, then the only difference between QK3.2 and QK3.1 becomes only the linear versus non-linear compensation. I don't quite understand why using a non-linear limiter would interfere with the stereo image.
Anyway, I've uploaded beta 3.3, which modifies the angle calculation so that it makes a bit more sense (I think). Now it resembles more of how qB is calculated in lossless coupling function
*ang=*ang * 0.3 * cfactor;
...
if (*ang > 0)
*ang = *mag - *ang;
I have a feeling though this won't be as good as beta 3.2.
Anyway, I've uploaded beta 3.3, which modifies the angle calculation so that it makes a bit more sense (I think). Now it resembles more of how qB is calculated in lossless coupling function
*ang=*ang * 0.3 * cfactor;
...
if (*ang > 0)
*ang = *mag - *ang;
I have a feeling though this won't be as good as beta 3.2.
If we calculate the angle exactly, it does not differ from lossless coupling (and concequently cannot save bits). If we have to save angle information to improve -q4, we should consider four or eight phase stereo.
I don't think the code you provided is correct
if (*ang > 0) *ang = *mag - *ang;
because we have to consider and compare residue values of channel A and B (i.e., which is larger or are they greater than 0?) My assumption is if we did not experience strange impression even when the calculation was incorrect, we can set the value to zero.
However, I think QF3.2 was successful to improve Vorbis. So I'd like to understand why your solution (liner compensation, ang calculation, etc.) improved Vorbis from theoretical view and now thinking.
Anyway, I've uploaded beta 3.3, which modifies the angle calculation so that it makes a bit more sense (I think). Now it resembles more of how qB is calculated in lossless coupling function
*ang=*ang * 0.3 * cfactor;
...
if (*ang > 0)
*ang = *mag - *ang;
I have a feeling though this won't be as good as beta 3.2.
If we calculate the angle exactly, it does not differ from lossless coupling (and concequently cannot save bits). If we have to save angle information to improve -q4, we should consider four or eight phase stereo.
I don't think the code you provided is correct
if (*ang > 0) *ang = *mag - *ang;
because we have to consider and compare residue values of channel A and B (i.e., which is larger or are they greater than 0?) My assumption is if we did not experience strange impression even when the calculation was incorrect, we can set the value to zero.
However, I think QF3.2 was successful to improve Vorbis. So I'd like to understand why your solution (liner compensation, ang calculation, etc.) improved Vorbis from theoretical view and now thinking.
Yeah, I know it's not correct since its only a half (or quarter) of the lossless coupling code. But when I uncomment the entire code there, I got a lot of shift to the left channel. Also, I still have the check in place where if ang is greater than mag, ang is set to 0, thus this if condition won't execute if that occurred.
In order to see the effect of having zero angle, I've uploaded beta 3.4 which is exactly the same as beta 3.2 (linear limiter) but sets the angle to zero. My suspicion is that we will get some sort of stereo problem (like in beta 3.1) but let us see how it goes.
Can I stress that both beta 3.3 and beta 3.4 are very experimental releases so for those who want to re-encode their 40 GB collection, consider sticking with beta 3.2 for now.
Beta 3.2 has been reloaded and can be downloaded from the usual location:
http://www.hydrogenaudio.org/forums/index....ndpost&p=187669 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=187669)
or at:
http://steve8988.homestead.com/files/vorbis/oggencqk32.zip (http://steve8988.homestead.com/files/vorbis/oggencqk32.zip)
Changes:
- Fixed major bug that caused Visual Studio.NET to produce a broken encoder at q < 4. Now we are back to .NET compiles
- Some minor pre-echo adjustments.
I know you submitted a finalized 3.2 for the Ogg Vorbis test, but have you come to any conclusions on or has anyone else worked with 3.3 or 3.4? From your choice to add 3.2 to the Vorbis test, my conclusion was that 3.3 and 3.4 did not come up with positive results. Is this true, or have they still just not been tested enough?
I know you submitted a finalized 3.2 for the Ogg Vorbis test, but have you come to any conclusions on or has anyone else worked with 3.3 or 3.4? From your choice to add 3.2 to the Vorbis test, my conclusion was that 3.3 and 3.4 did not come up with positive results. Is this true, or have they still just not been tested enough?
Haven't had any results for 3.3 or 3.4 yet, so I'm placing my bets on the verified one (3.2). But after some conversing with nyaochi, personally I don't hold any high hopes for 3.3 or 3.4 either.
Beta 3.2 is da best in the QKTune series ATM
Beta 3.2 has been reloaded and can be downloaded from the usual location:
http://www.hydrogenaudio.org/forums/index....ndpost&p=187669 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=187669)
or at:
http://steve8988.homestead.com/files/vorbis/oggencqk32.zip (http://steve8988.homestead.com/files/vorbis/oggencqk32.zip)
Changes:
- Fixed major bug that caused Visual Studio.NET to produce a broken encoder at q < 4. Now we are back to .NET compiles
- Some minor pre-echo adjustments.
Any chance of the source, Steve?
Edit: OK, ignore me, I just read the other thread. Seems I already have it!!
Hi,
that might be interesting for you (all developers):
http://www.xiph.org/archives/vorbis-dev/20...-0005/01-sq.pdf (http://www.xiph.org/archives/vorbis-dev/200403/att-0005/01-sq.pdf)
Found at: http://www.xiph.org/archives/vorbis-dev/200403/0005.html (http://www.xiph.org/archives/vorbis-dev/200403/0005.html)
You see, there are also people at xiph who work on the problem.
Let's hope that it can be fixed before the big listeningtest!
Big_Berny
PS: Look at my new avatar
Hi,
that might be interesting for you (all developers):
http://www.xiph.org/archives/vorbis-dev/20...-0005/01-sq.pdf (http://www.xiph.org/archives/vorbis-dev/200403/att-0005/01-sq.pdf)
Found at: http://www.xiph.org/archives/vorbis-dev/200403/0005.html (http://www.xiph.org/archives/vorbis-dev/200403/0005.html)
You see, there are also people at xiph who work on the problem.
Let's hope that it can be fixed before the big listeningtest!
Big_Berny
Yeah I know of that thread since I was the one who started that topic on stereo mode settings
PS: Look at my new avatar
And mine too.
Are you able to impement this fix? Or is this to difficult/complexe?
Big_Berny
PS: QK: A nice avatar, too.
Are you able to impement this fix? Or is this to difficult/complexe?
Not at the moment. I don't know much of the mechanisms in residue quantisation so I'll have to become familiar with that. Plus I don't have much time to work on Vorbis now which is why I decided to submit beta 3.2, despite the doubtul nature of the stereo hack I made..
Would QKTune 3.2 be wise to use for Q0-Q1 (64-80kbps) ?. I've got a Sony Ericsson P800 and a 128MB memory card, and i'm using OggPlay! (http://www.geocities.com/p800tools) to playback vorbis files on it. Or is QKTune only optimized for high bitrates?
I've done some tests that shows that files encoded in Q0-Q1 actually has lower bitrate (3-6kbps usually) than official 1.0.1 encoded files.
I haven't had time to do a ABX test though, hence i'm asking
EDIT:
Hmm, nope.. i'll stick to 1.0.1 official. Found some huge artifacts in some Q1 encodings of a few Pink Floyd tunes (especially Comfortably Numb from the Pulse CD, at around 2:20-2:40 (guitar)). official 1.0.1 doesn't have these artifacts/errors at all. The tunes was transcoded from APE, so it shouldn't be anything to do with that.
EDIT:
Hmm, nope.. i'll stick to 1.0.1 official. Found some huge artifacts in some Q1 encodings of a few Pink Floyd tunes (especially Comfortably Numb from the Pulse CD, at around 2:20-2:40 (guitar)). official 1.0.1 doesn't have these artifacts/errors at all. The tunes was transcoded from APE, so it shouldn't be anything to do with that.
Yes, that doesn't sound too unusual since there is a large amount of point stereo being used at q 0 and 1.
Try aoTuV. I think it was tuned for low bitrates.
I've finally found the time for testing those oggencqk3x encoders.
But I don't think of these results are truly useful for you.
Tristan_QKTune_test (http://cyberquebec.ca/harashin/Tristan_QKTune_test.htm)
Castanets_QKTune_test (http://cyberquebec.ca/harashin/castanets_QKTune_test.htm)
I've finally found the time for testing those oggencqk3x encoders.
But I don't think of these results are truly useful for you.
Tristan_QKTune_test (http://cyberquebec.ca/harashin/Tristan_QKTune_test.htm)
Castanets_QKTune_test (http://cyberquebec.ca/harashin/castanets_QKTune_test.htm)
Thanks.
Actually they are quite useful in showing that this stereo hack isn't as effective as I had hoped but is causing other problems.
Oh well, it's back to the drawing board.
Hello,
I´ve merged Vorbis CVS and qkt32.tar.gz for a private linux-compile. I found a piece of "normal" music sounding strange. (However, vorbis 1.0.1 doesn´t seem better to me on this sample but I may have to check this again...)
http://www.hydrogenaudio.org/forums/index....ndpost&p=188853 (http://www.hydrogenaudio.org/forums/index.php?showtopic=18360&view=findpost&p=188853)
Maik
I had a listen to your spacedyevest sample. With 1.0.1 and QKTune b3.2, there is a distinct HF hiss on the 'is' of 'This', though it seems stronger in 1.0.1. The hiss is also present in MTb3 and aoTuV, though I can't determine from my mortal ears which has smaller hiss.
I think this is another great sample for tuning HF hiss.
I think this is another great sample for tuning HF hiss.
Ah.. now I see:
That´s what HF hiss sounds like...
Since Vorbis is one of the weakest modern codecs for the classical music genre, I've tried my hand at fixing some of the noise complaints, specifically with grainy or coarse noise that is heard on certain classical instruments such as the violin at q 4.
My ears aren't that trained with classical music so it would be good to get some feedback from others. This tuning may not fix the noise problems at all but I'd like to know whether I'm going in the right direction.
QKTune beta 3.5 CE (Classical Edition)
http://www.hydrogenaudio.org/forums/index....ndpost&p=193377 (http://www.hydrogenaudio.org/forums/index.php?showtopic=17949&view=findpost&p=193377)
Bitrates are somewhat inflated but I'll fix that later, should these tunings prove successful.
Thank you.
Do you want this tested on non-classical music as well?
Do you want this tested on non-classical music as well?
Sure, though I doubt it will be any more better than the previous betas, other than inflated bitrates. But I'm very interested to hear how it sounds on non-classical music too.
I didn't have time for a real test. Nevertheless, it seems that -q4 produces excessive bitrate compared to other encoders at the same setting.
Here is a table of 160 different tracks of classical music.
http://www.foobar2000.net/divers/vorbis/playlist160_IE.htm (http://www.foobar2000.net/divers/vorbis/playlist160_IE.htm)
http://www.foobar2000.net/divers/vorbis/playlist160_MZ.htm (http://www.foobar2000.net/divers/vorbis/playlist160_MZ.htm)
Q4: 157,9 kbps
Q3.5: 132,3 kbps
Q3.4: 126,5 kbps
I didn't have time for a real test. Nevertheless, it seems that -q4 produces excessive bitrate compared to other encoders at the same setting.
Here is a table of 160 different tracks of classical music.
http://www.foobar2000.net/divers/vorbis/playlist160_IE.htm (http://www.foobar2000.net/divers/vorbis/playlist160_IE.htm)
http://www.foobar2000.net/divers/vorbis/playlist160_MZ.htm (http://www.foobar2000.net/divers/vorbis/playlist160_MZ.htm)
Q4: 157,9 kbps
Q3.5: 132,3 kbps
Q3.4: 126,5 kbps
Yes, the bitrate is very high which means I may have to remap the quality levels (q 4 => q 5). At the moment, I'm curious about whether this tuning has any positive effect. I'm tweaking the noise3 values for long blocks, which is usually the predominant blocksize in classical. Plus, I am contemplating on introducing 'profiles' to Vorbis, much like in MPC, where the bitrate is generally allowed to wander quite freely, rather than be constrained to a nominal rate.
I'll probably test vorbis CE at -q3,4. What challengers do you suggest?
- Vorbis CVS -q4 or -q4.3
- Vorbis uncoupled -q2.3
- Maybe Modest Tuning -q4
Is it OK ? Or do you prefer that a test including vorbis QK CE at -q4 first ?
Plus, I am contemplating on introducing 'profiles' to Vorbis, much like in MPC, where the bitrate is generally allowed to wander quite freely, rather than be constrained to a nominal rate.
Isn't that, uhm, how the current encoder already works? (Unless it's forced into CBR/ABR mode, which is never by default)
Plus, I am contemplating on introducing 'profiles' to Vorbis, much like in MPC, where the bitrate is generally allowed to wander quite freely, rather than be constrained to a nominal rate.
Isn't that, uhm, how the current encoder already works? (Unless it's forced into CBR/ABR mode, which is never by default)
Yes. What I had in mind is instead of specifying a quality as having one nominal/average rate, actually specify a nominal range instead.
Like in MPC:
Profile Options (Quality Presets):
--thumb low quality/internet, (typ. 58... 86 kbps)
--radio medium (MP3) quality, (typ. 112...152 kbps)
--standard high quality (dflt), (typ. 142...184 kbps)
--xtreme extreme high quality, (typ. 168...212 kbps)
So we can have sort of a standard profile for Vorbis with a typical nominal range. I think it would dispel the perception that "Hey, I asked for nominal bitrate of 128 kbps and I got 160!!"....
I'll probably test vorbis CE at -q3,4. What challengers do you suggest?
- Vorbis CVS -q4 or -q4.3
- Vorbis uncoupled -q2.3
- Maybe Modest Tuning -q4
Is it OK ? Or do you prefer that a test including vorbis QK CE at -q4 first ?
Hmm....for the challengers, is it methodically correct to include QK CE at -q4 alongside QK CE at -q3.4?
Although I'm not well trained with this kind of genre, I've had some tests on classical samples
Bartok_strings Vorbis test (http://cyberquebec.ca/harashin/Bartok_strings_Vorbis_test.htm)
Szene Vorbis test (http://cyberquebec.ca/harashin/Szene_Vorbis_test.htm)
Hmm....for the challengers, is it methodically correct to include QK CE at -q4 alongside QK CE at -q3.4?
at ~158 kbps it's in a different class! Anything but a clear victory should be a huge surprise.
- Vorbis CVS -q4 or -q4.3
Roberto used -q 4.25 in the 128 extension test (http://www.rjamorim.com/test/128extension/presentation.html).
Hmm....for the challengers, is it methodically correct to include QK CE at -q4 alongside QK CE at -q3.4?
at ~158 kbps it's in a different class! Anything but a clear victory should be a huge surprise.
True. Rub that out then.
I performed a small test this morning, after I woke up. I've only tested ~128 kbps bitrate (which mean -q3,4 with vorbis QK 3.5 Classical Edition). I've compared it to CVS encoder at -q4,3 and Nyaochi 1.01 "uncoupled" at -q2,3.
For this purpose, I used 10 samples, uploaded here (9 MB - flac):
http://www.foobar2000.net/divers/vorbis/vorbis10samples.zip (http://www.foobar2000.net/divers/vorbis/vorbis10samples.zip)
I'm not completely happy with this test. At least, I fear that my feeling on the first samples are not really accurate (I don't recommand ABX tests just after awakening). Therefore, at the end of the 10 samples, I performed again the test on the first sample, and results were completely different. I also fear that the results of the second tests are approximate too, but I didn't tested it another time. The third sample is surely OK, because noise issue with the "gorecki.wav" sample is very easy to detect.
I discard the result of the first sample in overall notation.
RESULTS
(http://www.foobar2000.net/divers/vorbis/vorbisCEresults.png)
CONCLUSION:
QK 3.5 is far from perfection. Noise is still audible with some samples, and distortions are introduced (cf. Gorecki, Rameau, Lassus, Penderecki, Guédron). Generally, distortions are something like an hollow sound, and electrical noise/signal. Hard to describe, but really disturbing, more than vorbis usual noise (cf. Gorecki sample). I also heard a tiny form of ringing with the La Spagna sample.
But there are significant improvements on noise. The good exemple is the Satie.wav sample: the recorded noise is not warmer or brighter anymore. I've also found QK 3.5 less noisy than the uncoupled encoder, with Lassus, Ysaye or Florentz (but I have to redo the test for this sample). This surprised me, because uncoupled encoder don't usually suffer from noise.
EDIT: ABC/HR logs (uninteresting) are here:
http://www.foobar2000.net/divers/vorbis/vo...20CE%20results/ (http://www.foobar2000.net/divers/vorbis/vorbis%20CE%20results/)
Many thanks to guruboolez and harashin.
I think I know why there were some extra distortions introduced and I'll try to address them using these samples. Fixing these noise problems in classical music can be quite a challenge.
I've uploaded the dlls of QKTune beta 3.2.
http://www.rarewares.org/quantumknot/vorbisqk32-dlls.zip (http://www.rarewares.org/quantumknot/vorbisqk32-dlls.zip)
I've been using these dlls in CDex for a while now and they work quite well.