Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:59:08Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/302Broken file on Vorbis website2017-04-08T10:59:08ZoktalBroken file on Vorbis website```
The file http://www.xiph.org/ogg/vorbis/doc/vorbisenc/reference.html is
advertised as the Vorbisenc reference manual, but it is in fact just an old
version of the Vorbisfile reference manual.
``````
The file http://www.xiph.org/ogg/vorbis/doc/vorbisenc/reference.html is
advertised as the Vorbisenc reference manual, but it is in fact just an old
version of the Vorbisfile reference manual.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/300encoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION2017-04-08T10:59:08Zggyepesiencoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -...```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -M 128 samples.raw
is the command line producing the error (samples.raw has length 819 200 bytes).
NOTE: encoding in VBR mode succeeds:
C:\oggtools>oggenc -r -R 22050 -b 32 -M 128 samples.raw
Enabling bitrate management engine
Encoding "samples.raw" to
"samples.ogg"
at average bitrate 32 kbps (no min, max 128 kbps),
using full bitrate management engine
Encoding [ 0m02s so far] |
crashes while
C:\oggtools>oggenc -r -R 22050 -b 32 samples.raw
Encoding "samples.raw" to
"samples.ogg"
at approximate bitrate 32 kbps (VBR encoding enabled)
Encoding [ 0m01s so far] -
Done encoding file "samples.ogg"
File length: 0m 09.0s
Elapsed time: 0m 01.0s
Rate: 9.2880
Average bitrate: 38.0 kb/s
succeeds.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/296[PATCH] Runtime DLL used in Debug Mode2017-04-08T10:58:44ZGitlab Bot[PATCH] Runtime DLL used in Debug Mode```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
deve...```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
developers (IMHO) use this under Win32.
The change is simple: "Project Settings" -> "C/C++" -> "Code Generation" and set
"Use run-time library" to "debug multithreaded" on "vorbis_static.dsp",
"vorbisenc_static.dsp" and "vorbisfile_static.dsp".
This is an update against the version in CVS on 6/12/02.
```Monty MontgomeryMonty Montgomeryhttps://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 Montgomery