Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:59:27Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/292ov_pcm_total(&file, -1) says there's one more sample than there actually is2017-04-08T10:59:27ZAdamDobsonov_pcm_total(&file, -1) says there's one more sample than there actually is```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytes...```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytesRead = ov_read(pFile, ((char *)pBuffer) + nTotalRead,
nBytesToRead, 0, 2, 1, ¤t_section);
if (nBytesRead > 0)
{
nTotalRead += nBytesRead;
nLength -= nBytesRead;
}
else if (nBytesRead == 0)
{
OutputDebugString("EOF reached\n");
return;
}
else
{
OutputDebugString("Error in stream detected\n");
}
}
// We never get here EOF is always reached first
OutputDebugString("It worked\n");
}
This was done using the 1.0 win32 sdk (using static linked release libs) and
the files were encoded with oggdropXPd v1.1 (Compiled 20020719).
To make it work as expected I needed to change the first line to read:
int nLength = (ov_pcm_total(pFile, -1) - 1) * 4;
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/290ftell() callback uses long instead ogg_int64_t2017-04-08T10:59:27Zpeterftell() callback uses long instead ogg_int64_t```
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
``````
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/288Syntax error in code prevents building2017-04-08T10:58:44ZandreaskSyntax error in code prevents building```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in li...```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in libvorbis/lib/lookup.c like this
return INVSQ2EXP_LOOKUP[a-INVSQ2EXP_LOOKUP_MIN];
Note the missing space between 'a-' and the macro.
On my HP/PA-RISC, with the native compiler this causes an syntax error.
The expansion of the code above is
a--32
This is at least ambiguous: 'a-- 32' vs 'a- -32', and the first interpreation
truly is a syntax error.
Best solution: Change the define to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The parentheses prevent any misinterpretation of the value.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/284libvorbis crash2017-04-08T10:58:44ZStephanlibvorbis crash```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compile...```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compiled
again using electric fence just to find out that it complains about mmap.
What exactly do you need to know in order to find a solution. This is the first
time I use bugzilla and I'm quite sure the above is not sufficient.
```titihttps://gitlab.xiph.org/xiph/vorbis/-/issues/279error in use of qsort2017-04-08T10:58:44ZThomas Gerekeerror in use of qsort```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler...```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler
(watcom 11.0a) the decoder hangs in qsort called in lib/sharedbook.c. if an
extra compare is added, all is fine.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/271ov_bitrate misbehaviour with gcc3 + optimizations2017-04-08T10:59:27Zflexoov_bitrate misbehaviour with gcc3 + optimizations```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable...```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable
file getting the nominal bitrate works fine) When compiled with ``make debug''
(and so optimizations disabled) it doesn't occur.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/266vorbisfile and vorbisenc don't build as shared libraries2017-04-08T10:59:08Zshattyvorbisfile and vorbisenc don't build as shared libraries```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform...```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform. It
may help other platforms to build these libraries as well. (cygwin?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/264local_book_besterror in res0.c2017-04-08T10:58:44Zmpxplaylocal_book_besterror in res0.c```
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
``````
source: res0.c
routine: local_book_besterror
line: 334 (?)
bug: "e++" have to be "e+=dim"
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/257OggEnc gives bad quality with synthetic speech2017-04-08T10:58:44ZtgirmannOggEnc gives bad quality with synthetic speech```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've...```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've tried other encoders too; at the same bit rates MP3 (LAME version 3.92 MMX)
suffers from similar problems but it sounds better (when using vbr) while
Musepack sounds almost perfectly.
(side note: when forcing LAME to 128 kbit/s the quality is really bad)
As I selected quality I want oggenc to allocate enough bits to achieve the
desired quality.
See attachment for reverence WAV and Ogg Vorbis examples.
(Yes I'm using OggEnc v1.0 (libvorbis 1.0))
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/256encoder_example (and libvorbis?) leaks memory in managed bitrate mode2017-04-08T10:58:44ZPatrick Bridgesencoder_example (and libvorbis?) leaks memory in managed bitrate mode```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is ...```
This is in libvorbis 1.0 final.
Change vorbis_encode_init_vbr(...., 0.5) to vorbis_encode_init(..., -1, 128000,
-1) in encoder_example.c (as described in the comments already in that file) and
memory usage grows steadily as data is encoded. Memory usage is constant if
_init_vbr() is used instead. Tested on RedHat Linux 7.3, with the gcc version 2.96.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/246Decoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over...2017-04-08T10:58:44ZgcDecoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over-read```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "noc...```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "nock.ogg"...
New logical stream (#1, serial: 62f352bc): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3)
Channels: 1
Rate: 11025
Nominal bitrate not set
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 721 bytes
Playback length: 0m:00s
Average bitrate: 49.798121 kbps
Logical stream 1 ended
-=-=---=-=---=-=---=-=--
which reports a "ov_pcm_total(vf, -1) * channels * 2" of 2554 bytes, when
getting read by ov_read, sends back to the caller 256 bytes, then 256, 256, 1152
and 2048, which makes a total of 3968 bytes - then tuxpuck crashes because
it malloc'ed only 2554 bytes in its buffer.
This bug seems confirmed by using "oggdec" which doesn't segfault but ends
reporting it was at 155.0% of the stream.
We're using the final 1.0 release of Ogg Vorbis (since Sun Jul 21 2002). I've
tried to query this bug database for a duplicate but didn't find one, sorry if
this has already been fixed in the CVS or already reported.
I've put the ogg file here for your convenience though it's in official tuxpuck
package:
http://people.mandrakesoft.com/~gc/files/nock.ogg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/237sound quality in high voice2017-04-08T10:58:44Zvgaborsound quality in high voice```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1...```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1.0.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/236Compile warnings in seeking_example.c2017-04-08T10:58:44ZtiCompile warnings in seeking_example.c```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALL...```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1
-DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1
-DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -DHAVE_FLOORF=1 -I. -I.
-I../include -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H -c seeking_example.c
cc: Warning: seeking_example.c, line 194: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 167: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 146: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,val,-1,pcmlength,bigassbuffer);
--------------------^
/bin/ksh ../libtool --mode=link cc -O -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H
-all-static -o seeking_example seeking_example.o ../lib/libvorbisfile.la
../lib/libvorbis.la -lm -logg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/234divide by 0 in psy.c2017-04-08T10:59:08Zroconnordivide by 0 in psy.c```
In bark_noise_hybridmp we have around line 640
if (fixed <= 0) return;
for (i = 0, fi = 0.f; i < (fixed + 1) / 2; i++, fi += 1.f) {
hi = i + fixed / 2;
lo = hi - fixed;
tN = N[hi] + N[-lo];
tX = X[hi] - X[-lo];
tX...```
In bark_noise_hybridmp we have around line 640
if (fixed <= 0) return;
for (i = 0, fi = 0.f; i < (fixed + 1) / 2; i++, fi += 1.f) {
hi = i + fixed / 2;
lo = hi - fixed;
tN = N[hi] + N[-lo];
tX = X[hi] - X[-lo];
tXX = XX[hi] + XX[-lo];
tY = Y[hi] + Y[-lo];
tXY = XY[hi] - XY[-lo];
A = tY * tXX - tX * tXY;
B = tN * tXY - tX * tY;
D = tN * tXX - tX * tX;
R = (A + fi * B) / D;
if (R > 0.f && R - offset < noise[i]) noise[i] = R - offset;
If fixed is 2, D can be 0, and a divide by 0 exception can be thrown.
I guess tXX has to be 0 as well.
There are probably other places where divide by 0's can occur. This happens to
be the first I have found.
Dividing by 0 is almost always an indication of a bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/233Improved DJGPP support2017-04-08T10:58:44ZxaviergonzImproved DJGPP support```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGP...```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGPP */
typedef short ogg_int16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
libvorbis, libvorbisenc, libvorbisfile:
Open up the file /lib/os.h, and near the end, right before the last
#endif, add the following code:
#ifdef DJGPP
# define rint(x) (floor((x)+0.5f))
#endif
Now with proper makefiles, the sources can be compiled properly under DJGPP. (I
tested it and it works under DJGPP once compiled that way)
Thanks for your time
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/232access violations and divides by 0 when usint ov_time_tell() with a not seeka...2017-04-08T10:59:27Zxaviergonzaccess violations and divides by 0 when usint ov_time_tell() with a not seekable stream```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;...```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
As you may easily notice, when the vf is *not* seekable, link = -1, and
therefore in the return, it tries to access vf->vi[-1].rate (access violation),
with the side effect of being that 0, so it also performs a divide by 0
operation and since the result value is a double, it returns a NAN -INF. So it
is clearly a bug, therefore I propose the following change:
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
else
return((double)vf->pcm_offset/vf->vi->rate);
}
which basicaly moves the return in the old function inside so it is only called
if the vf is seekable and adds a new return for non seekable files which
returns the current sample / current section rate, which is, that is, the
current second. Probably it doesn't work properly if the current section is
using a different rate than an old (possible) one, but it is always nicer than
an access violation and a divide by 0 and also a more accurate result than NAN -
INF :)
Thanks
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/230vorbis shared library not built on beos2017-04-08T10:58:44Zshattyvorbis shared library not built on beos```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefin...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libvorbis_la_LDFLAGS = -version-info @V_LIB_CURRENT@:@V_LIB_REVISION@:@V_LIB_AGE@
new version:
libvorbis_la_LDFLAGS = -no-undefined -version-info
@V_LIB_CURRENT@:@V_LIB_REVISION@:@V_LIB_AGE@
With this patch the library builds and works fine. (Tested with vorbis-tools.)
This patch informs libtool that this particular library has no undefined symbols
and so it can be built without problems on beos. (or any other platform without
the ability to compile/use libs with undefined symbols.)
An additional note: libvorbisenc and libvorbisfile both have undefined symbols
and can not be built as shared libraries on beos. They must be linked
statically. They are made as static libraries in the current version and they
work fine if linked to statically.
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/225Various qsort(3) callers pass incomplete comparison functions2017-04-08T10:58:44ZdevetzisVarious qsort(3) callers pass incomplete comparison functions```
Platform: SunOS x 5.9 Generic sun4u sparc SUNW,Ultra-5_10
Library: libvorbis-1.0 (vorbis1_0_public_release)
Arch: sparc-sun-solaris2.9
When calling qsort(3), the comparison function MUST return either -1, 1 or 0.
The following files...```
Platform: SunOS x 5.9 Generic sun4u sparc SUNW,Ultra-5_10
Library: libvorbis-1.0 (vorbis1_0_public_release)
Arch: sparc-sun-solaris2.9
When calling qsort(3), the comparison function MUST return either -1, 1 or 0.
The following files have "optimised" functions that do not return 0 for
equal-valued arguments:
lib/lsp.c
lib/psy.c
lib/sharedbook.c
vq/vqgen.c
The result under Solaris 9 (possibly other versions) is that qsort will call the
function with out-of-bounds arguments when encountering equal-valued
comparisons. oggenc, for example, SEGVs in psy.c[apsort] immediately upon
invocation.
The attached patch tweaks all potentially offending comparison functions, and
Works-For-Me.
/taso
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/224sort32a() in sharedbook.c2017-04-08T10:58:44Zmpxplaysort32a() in sharedbook.c```
It seems the sort32a() routine in sharedbook.c
gives back -1 if a==b . (I think so it should be 0 then)
Is this good?
Some stupid qsort() function (like Watcom's) can freeze with it.
Perhaps you should use the icomp() from the floor...```
It seems the sort32a() routine in sharedbook.c
gives back -1 if a==b . (I think so it should be 0 then)
Is this good?
Some stupid qsort() function (like Watcom's) can freeze with it.
Perhaps you should use the icomp() from the floor1.c
instead of this sort32a() ...
regards
Attila
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/221vorbis.m4 check fails with segfault2017-04-08T10:58:44Zdlehnvorbis.m4 check fails with segfault```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_...```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
(gdb) bt
#0 0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
#1 0x4002ce9b in vorbis_analysis_init () from /usr/lib/libvorbis.so.0
#2 0x080486c6 in main () at t.c:17
The following fixes the segfault but perhaps better return value checking should
be used since this is mainly just a link test vs a functional test:
diff -u -r1.2 vorbis.m4
--- vorbis.m4 13 Jul 2002 02:16:53 -0000 1.2
+++ vorbis.m4 29 Jul 2002 14:36:43 -0000
@@ -54,6 +54,7 @@
#include <stdlib.h>
#include <string.h>
#include <vorbis/codec.h>
+#include <vorbis/vorbisenc.h>
int main ()
{
@@ -62,7 +63,7 @@
vorbis_info vi;
vorbis_info_init (&vi);
- vorbis_encode_init (&vi, 2, 44100, -1, 128, -1);
+ vorbis_encode_init (&vi, 2, 44100, -1, 128000, -1);
vorbis_analysis_init (&vd, &vi);
vorbis_block_init (&vd, &vb);
/* this function was added in 1.0rc3, so this is what we're testing for */
```Monty MontgomeryMonty Montgomery