Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/86RC2 @ 160kB/s misencodes or misdecodes one specific file2017-04-08T10:58:44ZgumbootRC2 @ 160kB/s misencodes or misdecodes one specific file```
This applies to one specific file out of >1000, and only at 160kB/s with RC2,
but I can repeat it, using the Debian packages (latest for Woody).
Sound appears further left, while the right speaker occasionally pops and
squeaks. Som...```
This applies to one specific file out of >1000, and only at 160kB/s with RC2,
but I can repeat it, using the Debian packages (latest for Woody).
Sound appears further left, while the right speaker occasionally pops and
squeaks. Sometimes, if the file is stopped at the right point the speaker will
pop again (perhaps a DC component).
Email me and tell me where to upload/email the file or a segment of the file.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/84overflow in vorbis_staticbook_unpack()2017-04-08T10:58:44ZSegher Boessenkooloverflow in vorbis_staticbook_unpack()```
...for length ordered books. the inner (j) loop should check for overflowing
the outer (i) loop.
``````
...for length ordered books. the inner (j) loop should check for overflowing
the outer (i) loop.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/82float values aren't accesible through libvorbis2017-04-08T10:59:27Ztimjfloat values aren't accesible through libvorbis```
for synthesis apps that do their own mixing and operate on floats,
libvorbisfile does not provide any way to get at the float buffers
directly as provided by the vorbis decoder, forcing people to reimplement
the vorbisfile logic if t...```
for synthesis apps that do their own mixing and operate on floats,
libvorbisfile does not provide any way to get at the float buffers
directly as provided by the vorbis decoder, forcing people to reimplement
the vorbisfile logic if they want decoder float output.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/81CHUNKSIZE too small2017-04-08T10:59:27ZtimjCHUNKSIZE too small```
according to the spec, a vorbis page may be 255*255+header bytes
big.
_get_prev_page() only seeks backwards by CHUNKSIZE bytes, where
CHUNKSIZE is defined to be 8500 bytes.
that means, _get_prev_page() may fail to find the previous
p...```
according to the spec, a vorbis page may be 255*255+header bytes
big.
_get_prev_page() only seeks backwards by CHUNKSIZE bytes, where
CHUNKSIZE is defined to be 8500 bytes.
that means, _get_prev_page() may fail to find the previous
page eventhough it's operation on a spec conforming ogg stream.
though it's prolly inefficient for _get_prev_page() to seek
back by ~64k by default, it should be able to revert to that
much backstepping if nothing is found in the first 8500, so as
to work correctly on conforming ogg streams.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/79doc/programming.html still says packet->frameno2017-04-08T10:58:44Ztimjdoc/programming.html still says packet->frameno```
packet->frameno has be renamed to granulepos according to Vakor.
``````
packet->frameno has be renamed to granulepos according to Vakor.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/77unaligned access on 64-bit platform2019-07-01T08:51:48Zchouserunaligned access on 64-bit platform```
I was getting the following error when playing some (not all) ogg vorbis streams:
Unaligned access pid=54825 <ogg123> va=0x11fff96b4 pc=0x3ffbffe9ba0
ra=0x3ff801b4b68 inst=0xa6100000
Segmentation fault (core dumped)
The crash is ha...```
I was getting the following error when playing some (not all) ogg vorbis streams:
Unaligned access pid=54825 <ogg123> va=0x11fff96b4 pc=0x3ffbffe9ba0
ra=0x3ff801b4b68 inst=0xa6100000
Segmentation fault (core dumped)
The crash is happening in icomp(), lib/floor1.c. I tracked it down to the qsort
that calls icomp() passing an incorrect size argument. It uses sizeof(int) when
it means sizeof(int*). This only shows up on machines where a pointer is begger
than an int, that is generally 64-bit platforms.
Here is a patch for 1.0rc2 -- I couldn't determine if you've already fixed this
problem because I wasn't able to get anon cvs working.
--- lib/floor1.c.orig Mon Aug 13 07:33:39 2001
+++ lib/floor1.c Fri Nov 9 15:29:56 2001
@@ -226,7 +226,7 @@
/* also store a sorted position index */
for(i=0;i<n;i++)sortpointer[i]=info->postlist+i;
- qsort(sortpointer,n,sizeof(int),icomp);
+ qsort(sortpointer,n,sizeof(int*),icomp);
/* points from sort order back to range number */
for(i=0;i<n;i++)look->forward_index[i]=sortpointer[i]-info->postlist;
--Chouser
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/73Infinite loop when trying to read the header of a small file2017-04-08T10:59:27ZMatTissInfinite loop when trying to read the header of a small file```
Try to encode chimes.wav at 128kbps. Then read the header. You get stalled.
The offending code (in vorbisfile.c):
static long _get_prev_page(OggVorbis_File *vf,ogg_page *og){
long begin=vf->offset;
long ret;
int offset=-1;
w...```
Try to encode chimes.wav at 128kbps. Then read the header. You get stalled.
The offending code (in vorbisfile.c):
static long _get_prev_page(OggVorbis_File *vf,ogg_page *og){
long begin=vf->offset;
long ret;
int offset=-1;
while(offset==-1){
begin-=CHUNKSIZE;
_seek_helper(vf,begin);
while(vf->offset<begin+CHUNKSIZE){
ret=_get_next_page(vf,og,begin+CHUNKSIZE-vf->offset);
if(ret==OV_EREAD)return(OV_EREAD);
if(ret<0){
break;
}else{
offset=ret;
}
}
}
begin is smaller than CHUNKSIZE and the while loop never ends.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/66Sample encoder output sounds like a tape on fast forward2017-04-08T10:58:44ZstarclassSample encoder output sounds like a tape on fast forward```
When the encoder in vorbis/examples is used to compress a WAV sample,
the output of the resulting ogg file sounds like a tape player
on fast cue forward.
``````
When the encoder in vorbis/examples is used to compress a WAV sample,
the output of the resulting ogg file sounds like a tape player
on fast cue forward.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/65autoconf option cleanup/enhancement2017-04-08T10:58:44ZStan Seibertautoconf option cleanup/enhancement```
This bug is for tracking changes that need to be made to the autoconf script
in libvorbis.
As of right now, the suggested changes are:
--with-ogg-prefix => --with-ogg
--with-ogg-includes: For setting the ogg include dir if differe...```
This bug is for tracking changes that need to be made to the autoconf script
in libvorbis.
As of right now, the suggested changes are:
--with-ogg-prefix => --with-ogg
--with-ogg-includes: For setting the ogg include dir if different than the
default
--with-ogg-libraries: For setting the ogg library dir if different than the
default
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis/-/issues/64libvorbisfile fails when xmms 1.2.5 tries to load it2017-04-08T10:59:27Zkio.smallwoodlibvorbisfile fails when xmms 1.2.5 tries to load it```
gcc --version
2.95.2
Here are the details from xmms bugzilla, my comments follow.
After building and installing the libogg and libvorbis libraries, and
rebuilding xmms to include the Ogg Vorbis input option, the libvorbisfile.so.0
...```
gcc --version
2.95.2
Here are the details from xmms bugzilla, my comments follow.
After building and installing the libogg and libvorbis libraries, and
rebuilding xmms to include the Ogg Vorbis input option, the libvorbisfile.so.0
builds without error, but when I try xmms on an ogg file, I get the error message: ld.so.1: xmms: fatal: relocation error: file /usr/local/lib/libvorbisfile.so.0: symbol __floatdidf: referenced symbol not found This is Sparc-Solaris-8, gcc-2.95.2
------- Additional Comments From Håvard Kvålen 2001-08-16 11:22 -------
This seems to be a problem with libvorbisfile, not xmms. I think that
__floatdidf is a symbol from libgcc, you probably will need to link
libvorbisfile against that.
------- Additional Comments From jchack@nnmc.nextel.com 2001-09-29 02:18 -------
*** Bug 367 has been marked as a duplicate of this bug. ***
I am having exactly this problem however oggenc and ogg123 work without error. Is the only fix to get libgcc and tell the configure script to somehow use that? I do not have access to CVS and am limited to using source tarballs.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/62libvorbis example fails to build with solaris math libs2017-04-08T10:58:44ZGitlab Botlibvorbis example fails to build with solaris math libs```
gcc --version
2.95.3
I had a poke around but could not find this logged already:
gmake[1]: Entering directory `/DATA/build/libvorbis-1.0beta4/examples'
gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0beta4\" -DHAVE_ALLOCA_H=1 -DHAVE_ALL...```
gcc --version
2.95.3
I had a poke around but could not find this logged already:
gmake[1]: Entering directory `/DATA/build/libvorbis-1.0beta4/examples'
gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0beta4\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLO
CA=1 -I. -I. -I../include -O20 -ffast-math -D__NO_MATH_INLINES -fsigned-ch
ar -mv8 -DUSE_MEMORY_H -c decoder_example.c
/bin/sh ../libtool --mode=link gcc -O20 -ffast-math -D__NO_MATH_INLINES -fsigne
d-char -mv8 -DUSE_MEMORY_H -static -o decoder_example decoder_example.o ../lib/
libvorbis.la -lm -logg
mkdir .libs
gcc -O20 -ffast-math -D__NO_MATH_INLINES -fsigned-char -mv8 -DUSE_MEMORY_H -o de
coder_example decoder_example.o ../lib/.libs/libvorbis.a -lm -logg -lm -logg
../lib/.libs/libvorbis.a(envelope.o): In function `_ve_envelope_init':
envelope.o(.text+0x154): undefined reference to `expf'
../lib/.libs/libvorbis.a(envelope.o): In function `_ve_envelope_search':
envelope.o(.text+0x884): undefined reference to `logf'
envelope.o(.text+0x8d0): undefined reference to `logf'
../lib/.libs/libvorbis.a(psy.o): In function `setup_curve':
psy.o(.text+0xe4): undefined reference to `expf'
etc
However I can't find the function calls it is wingeing about;
there is no expf() in _ve_envelope_init for example.
Is this a compiler bug? I use solaris nm & ld.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/61ov_open returns OV_EBADHEADER on many samples2017-04-08T10:59:27Zjgibartov_open returns OV_EBADHEADER on many samples```
A lot of vorbis ogg files will not open using ov_open because the API returns
OV_EBADHEADER .
These samples will open and play using winamp plugin, which seems not to be
using the ov_open api.
Example : electricskychurch_deus.og...```
A lot of vorbis ogg files will not open using ov_open because the API returns
OV_EBADHEADER .
These samples will open and play using winamp plugin, which seems not to be
using the ov_open api.
Example : electricskychurch_deus.ogg on http://www.vorbis.com/music.psp
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/57&#34;vorbis_commentheader_out&#34; not exported in vorbis.def2017-04-08T10:58:44Zadonnai"vorbis_commentheader_out" not exported in vorbis.def```
The function "vorbis_commentheader_out" isn't listed in vorbis.def so linking
fails when calling it. One exmaple, vorbiscomment, couldn't compile because of
this bug.
``````
The function "vorbis_commentheader_out" isn't listed in vorbis.def so linking
fails when calling it. One exmaple, vorbiscomment, couldn't compile because of
this bug.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/55Chirping artifact produced with -b 160 and below2017-04-08T10:58:44ZdrewChirping artifact produced with -b 160 and below```
I was listening to an album I had encoded and I noticed a slight "chirp" at the
end of a song. It occurs with -b 128 and -b 160, but not with -b 192 and above.
A FLAC-encoded sample and the artifact which occurs can be downloaded h...```
I was listening to an album I had encoded and I noticed a slight "chirp" at the
end of a song. It occurs with -b 128 and -b 160, but not with -b 192 and above.
A FLAC-encoded sample and the artifact which occurs can be downloaded here:
http://cesspool.net/sample.flachttp://cesspool.net/sample.ogg
$ oggenc --version
OggEnc v0.8 (libvorbis rc2)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/53Audible artifacts in 128Kbps encoding with RC22017-04-08T10:58:44Zjonathan_ingramAudible artifacts in 128Kbps encoding with RC2```
The URL points to a directory containing 'segment.wav', a 3 second sample taken
7 seconds into the song 'Sweet Thing' by Van Morrison, from the 1968
album 'Astral Weeks'.
When encoded at 128Kbps with the RC2 encoder under Linux (M...```
The URL points to a directory containing 'segment.wav', a 3 second sample taken
7 seconds into the song 'Sweet Thing' by Van Morrison, from the 1968
album 'Astral Weeks'.
When encoded at 128Kbps with the RC2 encoder under Linux (Mandrake 8.0 / i386),
the high notes in the left channel sound 'crunchy' and noisy. The encoded file
is also in the directory pointed to by the above URL.
--
I hope this was the right section to assign this bug to.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/52vorbis/lib/envelope.c causes gcc internal error2017-04-08T10:58:44Zaltair1710vorbis/lib/envelope.c causes gcc internal error```
When using gcc 2.95.3 on i686-pc-linux-gnu, vorbis/lib/envelope.c causes gcc to
emit:
"gcc:Internal compiler error: program cc1 got fatal signal 11"
This error is present in rc1, rc2 and current cvs sources.
The full command used ...```
When using gcc 2.95.3 on i686-pc-linux-gnu, vorbis/lib/envelope.c causes gcc to
emit:
"gcc:Internal compiler error: program cc1 got fatal signal 11"
This error is present in rc1, rc2 and current cvs sources.
The full command used in compile is:
/usr/bin/gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc2\" -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 -I. -I.
-I../include -O20 -ffast-math -mno-ieee-pf -D_REENTRANT -fsigned-char
-march=i686 -O3 -DUSE_MEMORY_H -c envelope.c -Wp,-MD,.deps/envelope.TPlo -fPIC
-DPIC -o .libs/envelope.lo
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/35two configure script problems in 1.0-pr12017-04-08T10:58:44Zcardhoretwo configure script problems in 1.0-pr1```
(This is with 1.0 prerelease.)
When I install libvorbis in /opt/libvorbis, and then try to build XMMS or
vorbis-tools, the configure script complains that it can't compile the
vorbis-test program. If I disable the test using --disa...```
(This is with 1.0 prerelease.)
When I install libvorbis in /opt/libvorbis, and then try to build XMMS or
vorbis-tools, the configure script complains that it can't compile the
vorbis-test program. If I disable the test using --disable-vorbistest, then the
program builds fine.
When I configured vorbis-tools, libao wasn't added to the INCLUDES in one of the
Makefiles (forgot which one) so I had to add it by hand.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis/-/issues/34PNG images don't have -kb options2017-04-08T10:58:44ZingoralfblumPNG images don't have -kb options```
The PNG images for the documentation in the CVS in ogg/doc and vorbis/doc are
declared as text files in CVS, so when checking out on Windows platforms, where
the line ending is CR LF instead of a single LF the images are corrupt. To ...```
The PNG images for the documentation in the CVS in ogg/doc and vorbis/doc are
declared as text files in CVS, so when checking out on Windows platforms, where
the line ending is CR LF instead of a single LF the images are corrupt. To fix
this, set the -k'b' option on these files.
This also applies to the gif images in the mgm module.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/32'win32/*.bat' do not handle SRCROOT long path names with spaces correctly2017-04-08T10:58:44Ztom'win32/*.bat' do not handle SRCROOT long path names with spaces correctly```
as an example, from a DOS box, type:
set SRCROOT=c:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if...```
as an example, from a DOS box, type:
set SRCROOT=c:\Xiph CVS\
call build_vorbis_static.bat
produces the error:
cvs==. was unexpected at this time.
and does *not* set %SRCROOT% to any value
resolution:
replace the line:
if .%SRCROOT%==. set SRCROOT=c:\src
with the line:
if ".%SRCROOT%"=="." set SRCROOT=c:\src
```starclassstarclasshttps://gitlab.xiph.org/xiph/vorbis/-/issues/31'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea2017-04-08T10:58:44Ztom'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we s...```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we see just 'msdev' without a
path):
call vcvars32.bat
```starclassstarclass