Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:59:08Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/474encoding crashes on SunOS due to improper use of `qsort'2017-04-08T10:59:08Zdvdkhlngencoding crashes on SunOS due to improper use of `qsort'```
I just tracked down and fixed a bug on SunOS where each and every attempt to
oggencode a wave-file crashed. Backtrace shows the crash to occur at
psy.c:_vp_noise_normalize_sort,
at the call to `qsort', within the callback `apsort'....```
I just tracked down and fixed a bug on SunOS where each and every attempt to
oggencode a wave-file crashed. Backtrace shows the crash to occur at
psy.c:_vp_noise_normalize_sort,
at the call to `qsort', within the callback `apsort'.
qsort was called with following args:
qsort ((float **) 0xffbfefb8, 8, 4, apsort)
apsort was called with following args:
apsort (a=0xffbfefb4, b=0xffbfefbc)
As one can see 0xffbf4fb4<0xffbfefb8, a array underrun occured. A description
of what seems to be the same problem dates back to 1999:
http://www.geocrawler.com/mail/msg.php3?msg_id=1607386&list=117.
The problem seems to be the "misuse" of qsort, validating the specification:
`apsort' returns `-1' even for equal values. A patch that makes it return `0'
for equals fixes the problem. Patch at:
http://user.cs.tu-berlin.de/~dvdkhlng/bugfix-qsort-20031103.diff
Some more info:
uname -a
SunOS siesta 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-4
gcc --version
gcc (GCC) 3.3.1
~/bin/oggenc --version
OggEnc v1.0 (libvorbis 1.0)
Oggenc also crashed when I tried to run it about half a year ago on an earlier
version of SunOS, here at my university. I didn't do any debugging back then.
Could it be, that this bug affects libvorbis on *all* SunOS installations?
David Kuehling
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/468vorbisenc api docs out of date2020-06-23T17:20:43ZGhost Uservorbisenc api docs out of date```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentat...```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentation at all.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/467Extraneous 'f' parameter in ov_open_callbacks documentation2020-06-13T00:42:20ZmatExtraneous 'f' parameter in ov_open_callbacks documentation```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-pas...```
The docs look quite good, but I noticed one minor error.
There is no parameter 'f' to ov_open_callbacks, but it is documented
in http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_open_callbacks.html
I think this is just a cut-and-paste error from the ov_open docs.
'datasource' needs to be documented instead.
As a minor nit, the documentation also talks about calling 'fclose' on
the file pointer, which is not necessarily appropriate for ov_open_callbacks.
I am using ov_open_callbacks because my data is not coming from a FILE *.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/453uninitialized variables in lib/psy.c:bark_noise_hybridmp()2017-04-08T10:58:44Zko6pc7k02uninitialized variables in lib/psy.c:bark_noise_hybridmp()```
floats A, B and D are not initialized to 0.0 (would 0.0 be OK value, anyways?).
when I initialized them to 0.0 in the beginning of bark_noise_hybridmp,
libvorbis produces different output from the same input.
I can't hear much diffe...```
floats A, B and D are not initialized to 0.0 (would 0.0 be OK value, anyways?).
when I initialized them to 0.0 in the beginning of bark_noise_hybridmp,
libvorbis produces different output from the same input.
I can't hear much difference, but there is a difference.
for example, encoding fatboy.wav with quality 5.0:
-rw-rw---- 1 safari safari 153883 2003-09-14 03:26:55.000000000 +0300
fat-q5-psy.ogg
-rw-rw---- 1 safari safari 153900 2003-09-14 03:25:34.000000000 +0300
fat-q5.ogg
(-psy is the version with A, B, D initialized...)
$ cmp -l fat-q5.wav fat-q5-psy.wav
23619 63 62
23623 44 42
23627 235 232
23631 370 367
23635 215 217
23639 153 160
23643 357 367
23647 244 252
23651 254 255
23655 333 324
23659 262 243
...
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/451`make dist' tries to build the docs even with --disable-docs2017-04-08T11:08:16Zgtgbr`make dist' tries to build the docs even with --disable-docs```
I did the following on OpenBSD 3.4 (as of 20030910), all necessary tools are
installed.
$ ./autogen.sh --help
...
[edit configure script, remove "--no-verify" parameter]
$ ./configure --sysconfdir=/etc --localstatedir=/var --with-o...```
I did the following on OpenBSD 3.4 (as of 20030910), all necessary tools are
installed.
$ ./autogen.sh --help
...
[edit configure script, remove "--no-verify" parameter]
$ ./configure --sysconfdir=/etc --localstatedir=/var --with-ogg=/usr/local --
disable-docs
...
$ make dist
Now it hangs for ages on
xsltproc --xinclude --output Vorbis_I_spec.html ./xml/spec-
html.xsl ./xml/Vorbis_I_spec.xml
Network activity indicates that this thing is now downloading lots of stuff
from 209.202.168.105:80 (redirects to www.oasis-open.org)
This should be fixed - I neither want to build the docs, nor do I want to build
anything in the first place... all I want is a .tar.gz source package of
current CVS.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/434ov_test/ov_test_open do not produce same results as ov_open2017-04-08T10:59:27Zvega_jamesov_test/ov_test_open do not produce same results as ov_open```
I first found this bug in the 1.0 release in Debian's unstable branch. I have
also confirmed that it still exists in CVS as of the filing of this bug
(08-29-2003).
Attempting to open and access an Ogg Vorbis file using ov_test() and...```
I first found this bug in the 1.0 release in Debian's unstable branch. I have
also confirmed that it still exists in CVS as of the filing of this bug
(08-29-2003).
Attempting to open and access an Ogg Vorbis file using ov_test() and
ov_test_open() does not produce the same results as using ov_open(). ov_open()
successfully opens the Ogg Vorbis file whereas ov_test_open() returns an
OV_EINVAL error.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/426ov_read() halt file descriptor2017-04-08T10:59:27Zksangho77ov_read() halt file descriptor```
ioMemFile(my class as FILE*) has ogg file in memory
after ov_read() call, ioMemFile's virtual table is null
when ov_read() call,
ov_read( &vf, ...... 0, 2, 1, (int*)pMemFile );
and..ov_read()
if(bitstream)*bitstream=vf->current...```
ioMemFile(my class as FILE*) has ogg file in memory
after ov_read() call, ioMemFile's virtual table is null
when ov_read() call,
ov_read( &vf, ...... 0, 2, 1, (int*)pMemFile );
and..ov_read()
if(bitstream)*bitstream=vf->current_link; (in vorbisfile.c, 1569 line)
vf->current_link is null and my ioMemFile's virtual table ptr set to null :(
so I cannot use ioMemFile pointer
is it a bug? or my fault? so how can solve ...plz help me..
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/363autogen.sh incorrect for OSX2017-04-08T10:58:44Zhast510autogen.sh incorrect for OSX```
Okay, here's the deal. I did some heavy tweaking of autogen.sh to get this to
compile on 10.2.6, but it was convoluted. Now that I have done some further
examining, I think I have a more elegant solution. I believe OS X comes ship...```
Okay, here's the deal. I did some heavy tweaking of autogen.sh to get this to
compile on 10.2.6, but it was convoluted. Now that I have done some further
examining, I think I have a more elegant solution. I believe OS X comes shipped
with glibtool, and glibtoolize instead of libtool, and libtoolize. I believe it
also comes with libtool, and libtoolize, but libtool does not support the
--version option, and libtoolize is NOT installed. Therefore, I changed libtool
to glibtool, and libtoolize, to glibtoolize. Just a heads up. BTW, if this is
not the appropriate place to publish a bug, could the project maintainer email
me? This is my first time filing a bug for an open-source project through this
system.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/348proper pkg-config files should be generated and installed 2017-04-08T10:58:44Zsxpertproper pkg-config files should be generated and installed ```
Proper pkg-config files should be generated and installed in
$(prefix)/lib/pkg-config for all libraries so that it's much easier to find them.
``````
Proper pkg-config files should be generated and installed in
$(prefix)/lib/pkg-config for all libraries so that it's much easier to find them.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/340[PATCH] segfault in decoding: bad book-&gt;dec_codelengths address2017-04-08T10:58:44ZAndrew S. Williams[PATCH] segfault in decoding: bad book->dec_codelengths address```
i'm using vorbisgain v0.32 (a third party tool)
a seg fault is occurring within libvorbis, so maybe it is a bug in libvorbis
itself..
the seg fault can occur at any point in the analysing stage, and occurs often
(for me at least) wit...```
i'm using vorbisgain v0.32 (a third party tool)
a seg fault is occurring within libvorbis, so maybe it is a bug in libvorbis
itself..
the seg fault can occur at any point in the analysing stage, and occurs often
(for me at least) with low quality encoded files.
audio-q1.ogg is a large ogg vorbis file (about 35Mb), quality 1.
> gdb vorbisgain
(gdb) run audio-q1.ogg
Starting program: /usr/local/bin/vorbisgain audio-q1.ogg
Analyzing files...
Gain | Peak | Scale | New Peak | Track
----------+--------+-------+----------+------
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x280a6994 in decode_packed_entry_number (book=0x809e3c8, b=0xbfbff5a8)
at codebook.c:345
345 if(book->dec_codelengths[lo]<=read){
(gdb) print book->dec_codelengths
$1 = 0x800 <Error reading address 0x800: Bad address>
(gdb) print lo
$2 = 0
(gdb) print hi
$3 = 0
(gdb) bt
#0 0x280a6994 in decode_packed_entry_number (book=0x809e3c8, b=0xbfbff5a8)
at codebook.c:345
#1 0x280a67d2 in vorbis_book_decodevv_add (book=0x809e3c8, a=0xbfbff1a8,
offset=288, ch=2, b=0xbfbff5a8, n=32) at codebook.c:460
#2 0x280a4499 in res2_inverse (vb=0xbfbff5a4, vl=0x8084240, in=0xbfbff1a8,
nonzero=0x1, ch=2) at res0.c:859
#3 0x280a58e2 in mapping0_inverse (vb=0xbfbff5a4, l=0x8098000)
at mapping0.c:701
#4 0x2809b2c9 in vorbis_synthesis (vb=0xbfbff5a4, op=0x2) at synthesis.c:76
#5 0x280b3484 in _fetch_and_process_packet (vf=0xbfbff360, op_in=0x0, readp=1)
at vorbisfile.c:481
#6 0x280b5a68 in ov_read_float (vf=0xbfbff360, pcm_channels=0xbfbff354,
length=1024, bitstream=0xbfbff358) at vorbisfile.c:1612
#7 0x0804a7f4 in free ()
#8 0x08049a37 in free ()
#9 0x0804a16d in free ()
#10 0x080493d5 in free ()
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/339ov_read() should default to native byte order2017-04-08T10:59:27ZMichel Daenzerov_read() should default to native byte order```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian sys...```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian systems, the
vast majority of apps need the data to be in native byte order, in particular
those that process the data after decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/337oggenc segfaults in apsort() in psy.c on solaris 5.92017-04-08T10:58:44Zsimonoggenc segfaults in apsort() in psy.c on solaris 5.9```
I haven't been able to determin the cause. But I have run it under dbx to find
out where it's coring and whats causing the core. Going from qsort() in psy.c to
apsort() in the same file some how corrupts the pointers. I'm not sure if...```
I haven't been able to determin the cause. But I have run it under dbx to find
out where it's coring and whats causing the core. Going from qsort() in psy.c to
apsort() in the same file some how corrupts the pointers. I'm not sure if this
is a vorbis thing or a sun thing. But considering i've managed to encode one
file sucessfully, i think it's something to do with the contents of the wav files.
(dbx) run -q 5 /tmp/test.wav
Running: oggenc -q 5 /tmp/test.wav
(process id 16546)
Opening with wav module: WAV file reader
Encoding "/tmp/test.wav" to
"/tmp/test.ogg"
at quality 5.00
signal SEGV (no mapping at the fault address) in apsort at line 953 in file "psy.c"
953 if(fabs(**(float **)a)>fabs(**(float **)b)) return -1;
(dbx) where
=>[1] apsort(a = 0xffbfedec, b = 0xffbfedf4), line 953 in "psy.c"
[2] qsort(0xffbfedf0, 0x8, 0x4, 0xff35f0a0, 0xffbfe998, 0x80), at 0xff0cb60c
[3] _vp_noise_normalize_sort(p = 0x8f860, magnitudes = 0xccaa0, sortedindex =
0xffbfeea0), line 994 in "psy.c"
[4] mapping0_forward(vb = 0xffbff4b8), line 532 in "mapping0.c"
[5] vorbis_analysis(vb = 0xffbff4b8, op = (nil)), line 48 in "analysis.c"
[6] oe_encode(0xffbff6f0, 0x1c, 0x400, 0x33f40, 0x37888, 0xc00), at 0x16f20
[7] main(0xffffffff, 0x0, 0x32280, 0x33f20, 0x33f40, 0x34a80), at 0x13844
(dbx) print a,b,*a,*b
a = 0xffbfedec
b = 0xffbfedf4
*a = (void)
*b = (void)
(dbx) up
0xff0cb60c: qsort+0x00f4: jmpl %l1, %o7
(dbx) up
Current function is _vp_noise_normalize_sort
994 qsort(work,partition,sizeof(*work),apsort);
(dbx) print partition
partition = 8
(dbx) for i in 0 1 2 3 4 5 6 7; do print *work[$i];done
*work[0] = 0.0
*work[1] = 0.0
*work[2] = 0.0
*work[3] = 0.0
*work[4] = 0.0
*work[5] = 0.0
*work[6] = 0.0
*work[7] = 0.0
(dbx)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/335Linking Problems2017-04-08T10:59:27ZcaseyLinking Problems```
There are some linking problems in the win32 cvs...fix by adding the following to...
vorbisfile.def:
ov_crosslap
vorbis.def:
vorbis_synthesis_lapout
vorbis_synthesis_restart
vorbis_window
worked for the dynamic builds, at least.
``````
There are some linking problems in the win32 cvs...fix by adding the following to...
vorbisfile.def:
ov_crosslap
vorbis.def:
vorbis_synthesis_lapout
vorbis_synthesis_restart
vorbis_window
worked for the dynamic builds, at least.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/334[PATCH] vorbis.m4 creates a conftest.c program that crashes.2017-04-08T10:58:44Zmatt[PATCH] vorbis.m4 creates a conftest.c program that crashes.```
On NetBSD-1.6 on i386, when I used the XIPH_PATH_VORBIS() macro form vorbis.m4,
configure tells me detecting of libvorbis failed. When I look in config.log,
I see that the conftest program that is created crashes with a Segfault.
See...```
On NetBSD-1.6 on i386, when I used the XIPH_PATH_VORBIS() macro form vorbis.m4,
configure tells me detecting of libvorbis failed. When I look in config.log,
I see that the conftest program that is created crashes with a Segfault.
See http://www.mafr.de/misc/conftest.c for the file along with the used
compiler flags. The crash is somewhere in vorbis_analysis_init().
On Linux, it works without any problems.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/327Undefined variable used in high level residue decode pseudo code2017-04-08T11:08:16ZjripleyUndefined variable used in high level residue decode pseudo code```
Under "Audio packet decode and synthesis - residue decode":
[channels_in_bundle] isn't defined anywhere, and it should most likely be [ch].
``````
Under "Audio packet decode and synthesis - residue decode":
[channels_in_bundle] isn't defined anywhere, and it should most likely be [ch].
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/326Typo and bug in high level residue decode pseudo code2017-04-08T11:08:16ZjripleyTypo and bug in high level residue decode pseudo code```
Under "Audio packet decode and synthesis - residue decode", the lines:
2. for each channel [j] in order from 0 ... [audio_channels]
1. if channel [j] is in submap [i] (vector [vorbis_mapping_mux] element [j] is
equal to [i])
Shou...```
Under "Audio packet decode and synthesis - residue decode", the lines:
2. for each channel [j] in order from 0 ... [audio_channels]
1. if channel [j] is in submap [i] (vector [vorbis_mapping_mux] element [j] is
equal to [i])
Should obviously be:
2. for each channel [j] in order from 0 ... [audio_channels] - 1
1. if channel [j] in submap [i] (vector [vorbis_mapping_mux] element [j] is
equal to [i])
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/325Possibly incorrect window calculation in documentation2017-04-08T11:08:16ZjripleyPossibly incorrect window calculation in documentation```
Under "Audio packet decode and synthesis - packet type, mode and window
decode", the line:
window([i]) = sin(.5 * PI * sin^2( ([i]-[right_window_start]+.5) / [right_n] *
.5 * PI/2. + .5 * PI) )
looks like it's got a typo in it, "...```
Under "Audio packet decode and synthesis - packet type, mode and window
decode", the line:
window([i]) = sin(.5 * PI * sin^2( ([i]-[right_window_start]+.5) / [right_n] *
.5 * PI/2. + .5 * PI) )
looks like it's got a typo in it, "PI/2.", which generates an incorrect
looking curve. Removing it seems to generate the right curve.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/324Line of pseudo code with no effect2017-04-08T11:08:16ZjripleyLine of pseudo code with no effect```
Under "packet type, mode and window decode", the following line has no effect
and probably shouldn't be there:
2. [left_window_start]
``````
Under "packet type, mode and window decode", the following line has no effect
and probably shouldn't be there:
2. [left_window_start]
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/323floor1_inverse_dB_table has slight errors2017-04-08T10:58:44Zjripleyfloor1_inverse_dB_table has slight errors```
The table in floor1.c appears to be generated by:table[x] = pow(10, ((x - 255) * (140 / 256) / 20))Which is basically 256 entries spanning 140dB. This doesn't quite match the numbers in the table - it's off by a very small amount. I ...```
The table in floor1.c appears to be generated by:table[x] = pow(10, ((x - 255) * (140 / 256) / 20))Which is basically 256 entries spanning 140dB. This doesn't quite match the numbers in the table - it's off by a very small amount. I think that the table was generated with slight accumulated errors.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/322win32 function calling convention unspecified.2017-04-08T10:59:27Zbambrywin32 function calling convention unspecified.```
All functions are declared in the .h files without calling convension. If the
code using your lib doesn't use the same default calling convension, it either
do not link or break.
This cannot be fixed by recompiling the libs with th...```
All functions are declared in the .h files without calling convension. If the
code using your lib doesn't use the same default calling convension, it either
do not link or break.
This cannot be fixed by recompiling the libs with the same calling convention
as the application, some file of vorbis.lib are not compiling under vc and
stdcall as default calling convension: callback function for qsort need to be
prefixed with cdecl. Also the callback structure should define it's own
calling convension (probably cdecl too)
You could either fix all h file to prefix the calls to what is in the lib, or
fix the compile problems of vorbis.lib to compile whatever calling convention
is used in the lib.
Beside that, i was able to compile and add ogg/vorbis support to my soft very
quickly. It's also quite fast! good work!.
Thanks
Benoit.
```Monty MontgomeryMonty Montgomery