Vorbis Listening Test, Find the best for the multiformat test Options

[harashin]

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

[QuantumKnot]

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

This post has been edited by QuantumKnot: Apr 11 2004, 23:57

[QuantumKnot]

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]

This post has been edited by QuantumKnot: Apr 11 2004, 23:57

[harashin]

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.

[QuantumKnot]

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:

CODE

//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.

This post has been edited by QuantumKnot: Apr 11 2004, 02:26

[guruboolez]

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...

[Aoyumi]

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.

[bond]

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

great! can we use this one for the listening test?

[Garf]

I'd guess that would need at least retesting the bitrate and doing the listening test all over :-/

[bond]

I'd guess that would need at least retesting the bitrate and doing the listening test all over :-/

why? could this hurt quality?

[Garf]

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...

[Latexxx]

Isn't it enough to compare this new thing to original version and check which one is better?

[Garf]

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.

This post has been edited by Garf: Apr 11 2004, 11:03

[Aoyumi]

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).

[guruboolez]

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)

[maikmerten]

It will be interesting to compare the bitrate with metal or rock discs, mith more percussive instruments.

CODE

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.

[guruboolez]

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

CODE

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).

This post has been edited by guruboolez: Apr 11 2004, 14:06

[guruboolez]

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

This post has been edited by guruboolez: Apr 11 2004, 14:19

[Latexxx]

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 .

[guruboolez]

I don't see a second uploaded version of AoTuV+QK. Am I wrong?

[Big_Berny]

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 post has been edited by Big_Berny: Apr 11 2004, 20:29

[guruboolez]

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 !!!).

[Big_Berny]

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

This post has been edited by Big_Berny: Apr 11 2004, 20:33

[p0l1m0rph1c]

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.

This post has been edited by p0l1m0rph1c: Apr 11 2004, 20:40

[Big_Berny]

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

This post has been edited by Big_Berny: Apr 11 2004, 20:50