HydrogenAudio

Lossy Audio Compression => Ogg Vorbis => Ogg Vorbis - General => Topic started by: john33 on 2005-04-02 22:30:13

Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-02 22:30:13
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.
Title: oggenc2.42 and oggenc2.5 released
Post by: Sebastian Mares on 2005-04-02 22:35:55
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
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-02 23:48:13
Quote
......, or is it OK if I use -q5 -m96 -M224
[a href="index.php?act=findpost&pid=287865"][{POST_SNAPBACK}][/a]

Yep, that's it.
Title: oggenc2.42 and oggenc2.5 released
Post by: Hyperion on 2005-04-03 01:27:22
oggenc2.42  seems preferable.
Title: oggenc2.42 and oggenc2.5 released
Post by: Sebastian Mares on 2005-04-03 10:59:42
Quote
Quote
......, or is it OK if I use -q5 -m96 -M224
[a href="index.php?act=findpost&pid=287865"][{POST_SNAPBACK}][/a]

Yep, that's it.
[a href="index.php?act=findpost&pid=287877"][{POST_SNAPBACK}][/a]


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.
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-03 11:18:42
Well, the only comment I can make is that it is supposed to work, according to this comment extract from oggenc/encode.c:
Code: [Select]
            /* libvorbis 1.1 (and current svn) doesn't actually fill this in,
              which looks like a bug. It'll then reject it when we call the
              SET version below. So, fill it in with the values that libvorbis
              would have used to fill in this structure if we were using the
              bitrate-oriented setup functions. Unfortunately, some of those
              values are dependent on the bitrate, and libvorbis has no way to
              get a nominal bitrate from a quality value. Well, except by doing
              a full setup... So, we do that.
              Also, note that this won't work correctly unless you have a very
              recent (2005/03/04 or later) version of libvorbis from svn).
            */

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.
Title: oggenc2.42 and oggenc2.5 released
Post by: ErikS on 2005-04-03 11:35:40
Quote
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.
[a href="index.php?act=findpost&pid=287954"][{POST_SNAPBACK}][/a]


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...
Title: oggenc2.42 and oggenc2.5 released
Post by: guruboolez on 2005-04-03 11:51:17
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 (http://ftp://ftp2.foobar2000.net/foobar/Short_Block_Test_2.exe) (wavpack sfx format).
Title: oggenc2.42 and oggenc2.5 released
Post by: Aoyumi on 2005-04-03 13:46:43
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
Title: oggenc2.42 and oggenc2.5 released
Post by: Sebastian Mares on 2005-04-03 14:21:07
Quote
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
[a href="index.php?act=findpost&pid=287987"][{POST_SNAPBACK}][/a]


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.
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-03 14:28:27
Quote
            ai.bitrate_limit_reservoir_bits = bitrate * 2;

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...
[a href="index.php?act=findpost&pid=287961"][{POST_SNAPBACK}][/a]

Yes, 2 seconds is the default.
Title: oggenc2.42 and oggenc2.5 released
Post by: kurtnoise on 2005-04-03 14:34:29
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 (http://kurtnoise.free.fr/oggspot.zip) and upper/higher bitrate values are correctly in the header.
Title: oggenc2.42 and oggenc2.5 released
Post by: Sebastian Mares on 2005-04-03 15:40:46
Quote
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 (http://kurtnoise.free.fr/oggspot.zip) and upper/higher bitrate values are correctly in the header.
[a href="index.php?act=findpost&pid=288008"][{POST_SNAPBACK}][/a]


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.
Title: oggenc2.42 and oggenc2.5 released
Post by: kurtnoise on 2005-04-03 16:33:10
erff, yes...You are completely right. Sorry...
Title: oggenc2.42 and oggenc2.5 released
Post by: ErikS on 2005-04-03 16:59:58
Quote
Yes, 2 seconds is the default.
[a href="index.php?act=findpost&pid=288007"][{POST_SNAPBACK}][/a]


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?
Title: oggenc2.42 and oggenc2.5 released
Post by: Sebastian Mares on 2005-04-03 17:06:50
Quote
Sebastian: How long are those frames in foobar?
[a href="index.php?act=findpost&pid=288038"][{POST_SNAPBACK}][/a]


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.
Title: oggenc2.42 and oggenc2.5 released
Post by: guruboolez on 2005-04-03 17:11:13
You can change the 'frame' size in the preference/input/standard input. 128 frames seems to be the maximum.
Title: oggenc2.42 and oggenc2.5 released
Post by: ErikS on 2005-04-03 17:17:15
Quote
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.
[a href="index.php?act=findpost&pid=287965"][{POST_SNAPBACK}][/a]


Are you sure you used 2.5? It doesn't work with aoyumi's code (yet  )...
Title: oggenc2.42 and oggenc2.5 released
Post by: guruboolez on 2005-04-04 09:06:48
Yes, oggenc 2.5
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-04 09:12:36
Just to let you know, I've emailed Mike Smith asking for his comments. I'll report back what he has to say.
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-04 10:28:50
OK, I've heard back from Mike, as follows:
* 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.
Title: oggenc2.42 and oggenc2.5 released
Post by: ErikS on 2005-04-04 23:52:23
Quote
Yes, oggenc 2.5
[a href="index.php?act=findpost&pid=288185"][{POST_SNAPBACK}][/a]


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
Title: oggenc2.42 and oggenc2.5 released
Post by: guruboolez on 2005-04-05 07:22:51
Quote
>oggenc2 -q4 Short_Block_Test_2.wav
at quality 4,00
        Average bitrate: 125,6 kb/s

[a href="index.php?act=findpost&pid=288317"][{POST_SNAPBACK}][/a]

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.
Title: oggenc2.42 and oggenc2.5 released
Post by: PatchWorKs on 2005-04-05 08:09:30
Just a question: is possible to integrate a DC offset correction algorithm that filters the soundwave before the encoding ?
Title: oggenc2.42 and oggenc2.5 released
Post by: john33 on 2005-04-05 18:01:39
Quote
Just a question: is possible to integrate a DC offset correction algorithm that filters the soundwave before the encoding ?
[a href="index.php?act=findpost&pid=288378"][{POST_SNAPBACK}][/a]

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.
Title: oggenc2.42 and oggenc2.5 released
Post by: PatchWorKs on 2005-04-08 12:37:29
Quote
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.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=288488")


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

Here are some links:

[a href="http://service.real.com/help/content/audiohints.html#dc_offset]RealNetworks' Signal Processing[/url]
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 1 (http://www.streamingmedia.com/r/printerfriendly.asp?id=8205)
Sure-Fire Tips for Encoding High-Quality, Low-Bandwidth Audio, Part 2 (http://www.streamingmedia.com/r/printerfriendly.asp?id=8208)

HaPpY CoDiNg !!!
Title: oggenc2.42 and oggenc2.5 released
Post by: Anakunda on 2011-04-29 21:37:49
Hi!

I have problem compiling oggenc2.87 sources.
In oggenc.c  I have call to unresolved function utf8_validate
I have searched for this function everywhere and no luck finding, even google can't find the library which does export this function.
Any help?
Title: oggenc2.42 and oggenc2.5 released
Post by: lvqcl on 2011-04-29 21:49:53
Holy thread resurrection...

You can find this function in vorbis-tools-1.4.0 ( http://xiph.org/downloads/ (http://xiph.org/downloads/) ).
Title: oggenc2.42 and oggenc2.5 released
Post by: alter4 on 2011-04-30 08:41:49
Hi!

I have problem compiling oggenc2.87 sources.
In oggenc.c  I have call to unresolved function utf8_validate
I have searched for this function everywhere and no luck finding, even google can't find the library which does export this function.
Any help?


If you compile oggenc using aotuv, please dont forget to share it with HA folks.   

Title: oggenc2.42 and oggenc2.5 released
Post by: lvqcl on 2011-04-30 10:26:44
http://rghost.ru/5398357 (http://rghost.ru/5398357)

* tested, but not thoroughly
* don't have built-in resampler
* don't have built-in FLAC reader
Title: oggenc2.42 and oggenc2.5 released
Post by: Steve Forte Rio on 2011-04-30 14:54:09
http://rghost.ru/5398357 (http://rghost.ru/5398357)

* tested, but not thoroughly
* don't have built-in resampler
* don't have built-in FLAC reader


Thanks! Works fine, as for me

More then 2x speedup for x64 SSE3 in compare to reference venc:

Code: [Select]
CLI encoder: D:\oggenc2\Win64\SSE3\oggenc2.exe
Destination file: D:\??? ??????\Mozart\Eine Kleine Nachtmusik\01_WAM_Eine_Kleine_Nachtmusik_1_Allegro.ogg
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "D:\oggenc2\Win64\SSE3\oggenc2.exe" -s 727225542 -Q -q1 - -o "01_WAM_Eine_Kleine_Nachtmusik_1_Allegro.ogg"
Working folder: D:\??? ??????\Mozart\Eine Kleine Nachtmusik\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Ogg: rewriting stream
Track converted successfully.
Total encoding time: 0:08.221, 61.06x realtime

CLI encoder: D:\aoTuV_b6.03\venc.exe
Destination file: D:\??? ??????\Mozart\Eine Kleine Nachtmusik\01_WAM_Eine_Kleine_Nachtmusik_1_Allegro1.ogg
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "D:\aoTuV_b6.03\venc.exe" -q1 - "01_WAM_Eine_Kleine_Nachtmusik_1_Allegro1.ogg"
Working folder: D:\??? ??????\Mozart\Eine Kleine Nachtmusik\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Ogg: rewriting stream
Track converted successfully.
Total encoding time: 0:18.688, 26.86x realtime


(Intel Core i3 530)

Also, I've got the same peak value for your encoder on this track.
Title: oggenc2.42 and oggenc2.5 released
Post by: lvqcl on 2011-04-30 14:58:31
I use SoX to compare two encoders:

Code: [Select]
sox -D -m -v 1 test1.ogg -v -1 test2.ogg --null spectrogram -o diff.png
Title: oggenc2.42 and oggenc2.5 released
Post by: Steve Forte Rio on 2011-04-30 15:26:52
As I understand, it generates a spectrogram of the difference signal, right?
Title: oggenc2.42 and oggenc2.5 released
Post by: lvqcl on 2011-04-30 15:42:25
Yes, exactly.
Title: oggenc2.42 and oggenc2.5 released
Post by: Steve Forte Rio on 2011-04-30 16:41:24
Thanks! Of course, it's better way than peak analysis or bitcomparing
Title: oggenc2.42 and oggenc2.5 released
Post by: alter4 on 2011-05-01 07:51:49
Thx IgorC!

I was learning minGW installation guide when I saw your post.
I am starting encoding  some CDs and post here notices if any problems.
Title: oggenc2.42 and oggenc2.5 released
Post by: lvqcl on 2011-05-01 08:24:14
Do you mean that you encode DTS-CD to Vorbis?
Title: oggenc2.42 and oggenc2.5 released
Post by: Anakunda on 2011-05-01 17:19:04
Holy thread resurrection...

You can find this function in vorbis-tools-1.4.0 ( http://xiph.org/downloads/ (http://xiph.org/downloads/) ).


thanks!
Title: oggenc2.42 and oggenc2.5 released
Post by: alter4 on 2011-05-02 20:21:41
Do you mean that you encode DTS-CD to Vorbis?

I convert some concerts with 6ch lossless sounds to WebM + 6ch vorbis. The purpose is escape from proprietary codecs, let me omit the details why I need it.