Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://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/ogg/-/issues/229shared library not built2006-06-12T11:13:16Zshattyshared library not built```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to ...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libogg_la_LDFLAGS = -version-info @LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
new version:
libogg_la_LDFLAGS = -no-undefined -version-info
@LIB_CURRENT@:@LIB_REVISION@:@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.)
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/228oggenc segfaults on some .wav files2002-08-24T06:46:27Zjddoggenc segfaults on some .wav files```
Have found several .wav's that oggenc will core dump on. Platform is
Solaris 8 on UltraSparc running in 64-bit mode (compiling as 32-bit).
Example file: http://www.nnaf.net/~jdd/oggenc_core.wav
That file contains the first 10 seco...```
Have found several .wav's that oggenc will core dump on. Platform is
Solaris 8 on UltraSparc running in 64-bit mode (compiling as 32-bit).
Example file: http://www.nnaf.net/~jdd/oggenc_core.wav
That file contains the first 10 seconds or so (1 mb) of Ozzy Osbourne's
Mr. Tinkertrain.
Here is the stack trace:
(gdb) set args -o blah.ogg /tmp/oggenc_core.wav
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0xff24b7b4 in apsort (a=0xffbeef4c, b=0xffbeef54) at psy.c:953
953 if(fabs(**(float **)a)>fabs(**(float **)b))return -1;
(gdb) where
#0 0xff24b7b4 in apsort (a=0xffbeef4c, b=0xffbeef54) at psy.c:953
#1 0xff14b24c in qsort () from /usr/lib/libc.so.1
#2 0xff24bc6c in _vp_noise_normalize_sort (p=0x59708, magnitudes=0x93fe0,
sortedindex=0xffbef010) at psy.c:994
#3 0xff259220 in mapping0_forward (vb=0xffbef478) at mapping0.c:532
#4 0xff244068 in vorbis_analysis (vb=0xffbef478, op=0x0) at analysis.c:47
#5 0x1877c in oe_encode (opt=0xffbef7c0) at encode.c:283
#6 0x131e0 in main (argc=4, argv=0xffbef93c) at oggenc.c:337
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/227Final Linking needs different pthread parameter on OpenBSD2018-03-06T12:50:21ZgtgbrFinal Linking needs different pthread parameter on OpenBSD```
The last step when compiling Icecast2 from CVS under OpenBSD 3.1 fails with
ld: -lpthread: no
match
It works when using -pthread instead (I just went into the src directory and pasted the
corrected version of the last gcc commandl...```
The last step when compiling Icecast2 from CVS under OpenBSD 3.1 fails with
ld: -lpthread: no
match
It works when using -pthread instead (I just went into the src directory and pasted the
corrected version of the last gcc commandline to make it work).
This bug in the configure
script is known for a while, I just thought you guys might want it in Bugzilla (easier to remember
than "wasn't there some problem on some OS"). :)
```Jack MoffittJack Moffitthttps://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/ogg/-/issues/222devel rpm doesn't include aclocal/ogg.m42002-07-29T18:45:54Znoadevel rpm doesn't include aclocal/ogg.m4```
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
``````
The devel rpm doesn't include /usr/share/aclocal/ogg.m4 in it's file list,
therefore it doesn't get pacakged and distributed.
Should be fixed I guess.
```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 Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/220encoder_example segfaults on SunOS 4.x2017-04-08T10:58:44Ztiencoder_example segfaults on SunOS 4.x```
Running the encoder example causes a segfault in libvorbis-1.0 on SunOS 4.1.3.
The gdb back trace is as follows:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GDB is free software ...```
Running the encoder example causes a segfault in libvorbis-1.0 on SunOS 4.1.3.
The gdb back trace is as follows:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.15.1 (sparc-sun-sunos4.1.3_U1),
Copyright 1995 Free Software Foundation, Inc...
Core was generated by `encoder_example'.
Program terminated with signal 11, Segmentation fault.
#0 0x16ea8 in inspect_error (x0=16, x1=46, y0=653, y1=-1, mask=0x1a4808,
mdct=0x1a4a08, info=0x11e790) at floor1.c:543
543 int base=dy/adx;
(gdb) bt
#0 0x16ea8 in inspect_error (x0=16, x1=46, y0=653, y1=-1, mask=0x1a4808,
mdct=0x1a4a08, info=0x11e790) at floor1.c:543
#1 0x1740c in floor1_fit (vb=0xf7fff708, look=0x1a7a38, logmdct=0x1a4a08,
logmask=0x1a4808) at floor1.c:667
#2 0x1af2c in mapping0_forward (vb=0xf7fff708) at mapping0.c:423
#3 0x7fd0 in vorbis_analysis (vb=0xf7fff708, op=0x0) at analysis.c:47
#4 0x2598 in main () at encoder_example.c:216
(gdb)
libogg and libvorbis are both compiled with gcc 2.95.2. The compiler flags
are the default settings after running configure.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/219libao rpm doesn't build/work on distributions w/o alsa (i.e. redhat)2006-06-12T11:40:57Znoalibao rpm doesn't build/work on distributions w/o alsa (i.e. redhat)```
The file libao.spec included in the libao distribution contains a
build-dependency on alsa-lib-devel, a package that is unavailable in several
major distributions. This prevents the libao package from being built and used
on for exam...```
The file libao.spec included in the libao distribution contains a
build-dependency on alsa-lib-devel, a package that is unavailable in several
major distributions. This prevents the libao package from being built and used
on for example redhat.
The src and binary rpms on www.vorbis.com also needs to be updated once this is
fixed.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/218Icecast 2.0 segfaults if already running on same port2018-03-06T12:50:21ZwsuffIcecast 2.0 segfaults if already running on same port```
Error was partly found via my error. Icecast2 was running from a prior session
on 8020. Unknowning to that I tryed to start it again w/ my only config which
uses port 8020
# ./icecast -c ../icecast.xml
Could not create listener socke...```
Error was partly found via my error. Icecast2 was running from a prior session
on 8020. Unknowning to that I tryed to start it again w/ my only config which
uses port 8020
# ./icecast -c ../icecast.xml
Could not create listener socket on port 8020
Changed groupid to 99.
Changed userid to 99.
Segmentation fault
Granted this isn't a major issue but couldn't it just terminate peacefully if
the listener socket is unavail
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/216libvorbis-1.0 encoder_example seg faults2017-04-08T10:58:44Ztilibvorbis-1.0 encoder_example seg faults```
This is for libvorbis-1.0
I don't know if this is an endian or alignment issue (which may affect more
platforms than just HP-UX, but running the encode_example causes a seg fault.
Here is a gdb backtrace:
$ ./encoder_example < ~/aud...```
This is for libvorbis-1.0
I don't know if this is an endian or alignment issue (which may affect more
platforms than just HP-UX, but running the encode_example causes a seg fault.
Here is a gdb backtrace:
$ ./encoder_example < ~/audio.wav > ~/audio.ogg
Memory fault(coredump)
$ gdb encoder_example core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa1.1-hp-hpux9.01"...
Core was generated by `encoder_exampl'.
Program terminated with signal 11, Segmentation fault.
#0 mdct_forward (init=0x4016ffa8, in=0x7b033cc0, out=0x7b033968) at mdct.c:298
298 x2[2] = MULT_NORM(r1 * T[1] + r0 * T[0]);
(gdb) bt
#0 mdct_forward (init=0x4016ffa8, in=0x7b033cc0, out=0x7b033968) at mdct.c:298
#1 0x13760 in _ve_amp (ve=0x7fffffed, gi=0x7b033cc0, data=0xd,
bands=0x4016ffc0, filters=0x40170668, pos=0) at envelope.c:121
#2 0x13c64 in _ve_envelope_search (v=0x7b033628) at envelope.c:243
#3 0xa544 in vorbis_analysis_blockout (v=0x7b033628, vb=0x7b033698)
at block.c:504
#4 0x6f14 in main () at encoder_example.c:237
(gdb)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/215cryptic compile failure when libogg is too old2017-04-08T10:58:44Znoacryptic compile failure when libogg is too old```
I think this should have it's bugzilla entry, since it is a real problem for
inexperienced users.
Problem: If a user tries to compile libvorbis 1.0 with libogg < 1.0 using the
good old './configure; make' formula the compile fails ...```
I think this should have it's bugzilla entry, since it is a real problem for
inexperienced users.
Problem: If a user tries to compile libvorbis 1.0 with libogg < 1.0 using the
good old './configure; make' formula the compile fails with the cryptic
../lib/.libs/libvorbis.a(mapping0.o): In function `mapping0_forward':
mapping0.o(.text+0xd91): undefined reference to `oggpack_writealign'
This can be fixed by uncommenting the line
dnl AC_CHECK_LIB(ogg, oggpack_writealign, , AC_MSG_ERROR(Ogg >= 1.0 required !))
in configure.in
```Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/Infrastructure/-/issues/214version 1.0 is not added yet to libvorbis, libogg and vorbis-tools programs2017-04-07T16:51:23Znoaversion 1.0 is not added yet to libvorbis, libogg and vorbis-tools programs```
I cannot file bugs against version 1.0 for the libvorbis component. Since
libvorbis-1.0 can be downloaded and has bugs, I believe this is a bug :)
``````
I cannot file bugs against version 1.0 for the libvorbis component. Since
libvorbis-1.0 can be downloaded and has bugs, I believe this is a bug :)
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/213cvs oggenc makes VBR files with upper/lower bitrate of 0.000000 kb/s2002-07-19T06:31:00ZKyungjoon Leecvs oggenc makes VBR files with upper/lower bitrate of 0.000000 kb/s```
I encoded somthing with cvs oggenc's VBR mode, and ran ogginfo on it.
Nominal bitrate: 112.001000 kb/s
Upper bitrate: 0.000000 kb/s
Lower bitrate: 0.000000 kb/s
IMHO upper/lower should not be set when using VBR modes. Upper bitrate...```
I encoded somthing with cvs oggenc's VBR mode, and ran ogginfo on it.
Nominal bitrate: 112.001000 kb/s
Upper bitrate: 0.000000 kb/s
Lower bitrate: 0.000000 kb/s
IMHO upper/lower should not be set when using VBR modes. Upper bitrate being
equal to Lower bitrate seems awkward too..
```Michael SmithMichael Smith