Pretty much the same deal as with the latest oggdropXPd compiles.

2.42 = aoTuVb3 compile, SRC libsamplerate resampler replaces standard Xiph resampler.
2.5 = Post 1.1.0 SVN compile, incorporating new resampler and including the Hard Min and Max bitrate limits options that now work!!

Both now at Rarewares.

How exactly do I use -q5 and a min bitrate of 96 kbps and a max bitrate of 224 kbps? Do I have to use --managed, or is it OK if I use -q5 -m96 -M224

Yep, that's it.

oggenc2.42 seems preferable.

Doesn't seem to work. I tried setting a maximum bitrate of 172 kbps and a minimum bitrate of 96 kbps with both oggdropxpd and oggenc2, but the resulting file still had frames with bitrates of 188 kbps and higher according to foobar2000.

Well, the only comment I can make is that it is supposed to work, according to this comment extract from oggenc/encode.c:

If this continues to be a problem for people, I can only suggest raising it on the vorbis/vorbis-dev mailing lists. The guy responsible for the oggenc code is Michael Smith. He is currently travelling, so any response may be subject to a slight delay.

Maybe the averaging window used to calculate the average bitrate has different sizes in oggenc and foobar.

ai.bitrate_average_kbps = bitrate/1000;
ai.bitrate_average_damping = 1.5;
ai.bitrate_limit_reservoir_bits = bitrate * 2;
ai.bitrate_limit_reservoir_bias = .1;

The size of the reservoir seems to indicate that a 2 second window is used in oggenc. In foobar I can choose between every frame and every 2^n:th frame. Don't know how long each frame is though...

I've tried with an extreme (artificial) sample, known as short_blocks_2 (15 sec long):
-q4 -m96 -M192
-q4 -m96 -M160
-q4 -m96 -M150

=> all encodings generate the same output bitrate (161 kbps). I can see frames > 200 kbps with foobar2000, and as you can see, an average bitrate of 161 kbps for encoding that shouldn't exceed 150 and 160 kbps reveals that the function is still not working properly.



EDIT: file is available here (wavpack sfx format).

It seems that "-b" must be specified in order to use full bit rate management engine correctly by oggenc.

[example]
oggenc -b128 -m96 -M224 filename.wav

Well, as far as I understood the concept, it should be possible to use the quality mode and limit the bitrate with the -m and -M switches.

Edit: Anyways, still doesn't work.

Yes, 2 seconds is the default.

Hi,

I've tried with many samples at -q4 -m96 -M160 & -q6 -m96 -M192 and all seems to work fine here.

I've checked my encoded samples with oggspot and upper/higher bitrate values are correctly in the header.

Well, in the header, yes, but when looking at the dynamic bitrate display of fb2k, some frames have bitrates greater than the maximum value specified.

erff, yes...You are completely right. Sorry...

Ok. So then it means over a window of 2 seconds it must not use more than 256 kbit if I specify -M 128, right? But if a frame (the "frame" other people here talk about) is shorter than 2 seconds, then it may go over that as long as the average stays under the limit...?

Sebastian: How long are those frames in foobar?

Dunno. I only know that foobar updates the dynamic info every 16 frames, but I am not sure if that applies to MP3 only or Vorbis, too.

You can change the 'frame' size in the preference/input/standard input. 128 frames seems to be the maximum.

Are you sure you used 2.5? It doesn't work with aoyumi's code (yet )...

Yes, oggenc 2.5

Just to let you know, I've emailed Mike Smith asking for his comments. I'll report back what he has to say.

OK, I've heard back from Mike, as follows:

1. As I suspected, the method of applying hard min/max limits to the quality setting is simply another way of setting up ABR with limits. So, if ABR doesn't work for you, this won't either.
2. Quote from Mike:
   QUOTE
   All the bitrate controls operate over a sliding window (I think it defaults to 2 seconds?), so yes - the bitrate can drop below this* within that period.
   (Yes, it is 2 seconds) Whether there is any mileage in trying to play with the Advanced Encoder Options relating to reservoir bias and reservoir bits, I don't know. I've played with both a little, but it seems to make little difference.

* This was in relation to a bitrate min/max limit of 96-224kbps.

For reference, Reservoir Size: The size of the minimum/maximum bitrate tracking reservoir, set in bits. The reservoir is used as a 'bit bank' to average out localized surges and dips in bitrate while providing predictable, guaranteed buffering behavior for streams to be used in situations with constrained transport bandwidth. The default setting is two seconds of average bitrate.

When a single frame is larger than the maximum allowed overall bitrate, the bits are 'borrowed' from the bitrate reservoir; if the reservoir contains insufficient bits to cover the defecit, the encoder must find some way to reduce the frame size.

When a frame is under the minimum limit, the surplus bits are placed into the reservoir, banking them for future use. If the reservoir is already full of banked bits, the encoder is forced to find some way to make the frame larger.

If the frame size is between the minimum and maximum rates (thus implying the minimum and maximum allowed rates are different), the reservoir gravitates toward a fill point configured by the reservoir bias setting described next. If the reservoir is fuller than the fill point (a 'surplus of surplus'), the encoder will consume a number bits from the reservoir equal to the number of the bits by which the frame exceeds minimum size. If the reservoir is emptier than the fillpoint (a 'surplus of defecit'), bits are returned to the reservoir equaling the current frame's number of bits under the maximum frame size. The idea of the fill point is to buffer against both underruns and overruns, by trying to hold the reservoir to a middle course.

And, Reservoir Bias: Reservoir bias is a setting between 0.0 and 1.0 that biases bitrate management toward smoothing bitrate spikes (0.0) or bitrate peaks (1.0); the default setting is 0.1.

Using settings toward 0.0 causes the bitrate manager to hoard bits in the bit reservoir such that there is a large pool of banked surplus to draw upon during short spikes in bitrate. As a result, the encoder will react less aggressively and less drastically to curtail framesize during brief surges in bitrate.

Using settings toward 1.0 causes the bitrate manager to empty the bit reservoir such that there is a large buffer available to store surplus bits during sudden drops in bitrate. As a result, the encoder will react less aggressively and less drastically to support minimum frame sizes during drops in bitrate and will tend not to store any extra bits in the reservoir for future bitrate spikes.

I don't get such high bitrates at all with my oggenc 2.5 unless I force it up with -m (which works here btw...)

>oggenc2
OggEnc v2.5 (libvorbis Post 1.1.0 SVN)


>oggenc2 -q4 -M160 Short_Block_Test_2.wav
at quality level 4,00 using constrained VBR (no min, max 160 kbps)
Average bitrate: 125,6 kb/s


>oggenc2 -q4 Short_Block_Test_2.wav
at quality 4,00
Average bitrate: 125,6 kb/s


>oggenc2 -q4 -m128 Short_Block_Test_2.wav
at quality level 4,00 using constrained VBR (min 128 kbps, no max)
Average bitrate: 145,8 kb/s

I fear that you did something wrong. short_block_2 sample triggers a lot of short blocks and lead to amazing high bitrate with all VBR encoding. -q4 with vorbis can't be 125 kbps with this sample.


EDIT: I've tried, and you're right That's weird!

EDIT2: try another time on my side with oggenc 2.5 -q4 -m96 -M150, and I obtained too 125 kbps as average bitrate. I'll see what I did last time when I'll return at home. Thanks for this correction.

Just a question: is possible to integrate a DC offset correction algorithm that filters the soundwave before the encoding ?

Yes, it is. I added a little code to my current test version of WaveGain and the wave files that showed offsets in EAC prior to processing, showed zero offsets after processing. So, yes it could be added as an option if it's felt to be generally useful.

Oh, well, expecially for low bitrates seems to be necessary (even if not all music have these problems).

Here are some links:

RealNetworks' Signal Processing
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 1
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 2

HaPpY CoDiNg !!!