Hi!

I just encoded a short track (11.88 seconds, 32KHz, 16bits, mono, 512kbps) for a video clip using oggenc1qk2. Trying to find the bitrate that fits the best I encoded in -q2, -q3 and -q4. That's when I saw that -q3 had a higher bitrate than -q4. Having a closer look to that bitrate range I found out, that the bitrate rises up to -q3.999 (56,9) and then suddenly falls of at -q3,999999 (54.1). Comparing it to 1.0.1 bitratewise, there isn't this step. but it occurs between -q1.999 and -q2. This phenomen is showed in the following graphs:


I had no time to test it on other samples. It might be interesting if someone with really golden ears could hear a difference between a -q3.999 and a -q4.0 test file.

This evening I found some time to test the aoTuV b2 + QK encoder on several quality settings on another track: Iron Maiden - Can I Play With Madness (ripped with EAC secure mode; CRC check ok) I checked each whole number quality setting and the setting 0.01 lower.

the result:
I could reproduce the decreasing bitrate between increasing quality settings. (marked red)



I discovered another problem: if I entered negative whole numbers the oggenc encoded it correctly with the desired nominal bitrate. But if the negative quality level wasn't a whole number it did not encode them correctly.

-q-0.01 becomes -q0.01
-q-0.99 becomes -q0.99
-q-1.01 becomes -q-0.99
-q-1.99 becomes -q-0.01

So.. the unconstant growing bitrate is not such a big bug, but the lower bitrates are more disturbing. Fixing this would be another succes after Roberto's great listening test. I'd apreciate some feedback.

hey vorbis tuners,
mind giving us an explanation on whats going on here
is this ok or is it a bug ?

thx for the support

I already mentioned it before the listening test. But I thought that I only found a special case/sample.

Big_Berny

The reason yould be that the codec uses different optimizations which become active above a certain quantizer. For example Aoutuv uses his anti-HF-boost-Algorithm only at <q5.

Big_Berny

@fragtal

About the first problem, it is not a bug.
It is the specification on account of an internal parameter. This may happen to all the present Vorbis encoders to some extent.
However, there may be a case which is conspicuous a little in aoTuV.

It seems to be the problem which arises this only by oggenc of locale fix version about the 2nd problem.
A problem does not arise in the usual oggenc.

Make sure the oggenc you downloaded wasn't the one with the locale fix. That one only uses a dot (.) for decimal, not a comma (,).

EDIT: And I may have used the locale fixed oggenc source to compile the combo encoder. My apologies Use a dot, not a comma.

I downloaded the version the 29th of April. I encoded with it at those bitrates always using a dot. A just performed test showed, that a comma also works. I don't quite understand what it is all about with the locale fix, as I didn't follow Vorbis developement all day, but if you wanna know more about what I did, simply ask!

About this locale fix prob, which version should I download?

@Aoyumi and Quantumknot
Thanks a lot for your great work on Vorbis!

The locale fix was a special version of oggenc I wrote to keep the decimals consistent so that encoding scripts for the 128 kbps multiformat test were consistent. In European countries, their version of Windows uses a , and in our side of the world, we use a . so if you said -q 4.35 in a French version of Windows, it would take it as -q 4 or if you said -q 4,35 in the US version of Windows, it would take it as -q 4 as well.

To grab the normal kind of oggenc (no locale fix), you can go the Recommended Encoder settings page. There is one compile by John33 and one by me. Also, on Aoyumi's webpage, there is a compile done by nyaochi that uses MSVC+ICL 6.