Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1493[PATCH] Patch to fix division by zero bug (from Aoyumi)2017-04-08T10:58:44ZGitlab Bot[PATCH] Patch to fix division by zero bug (from Aoyumi)Hi, dear developers!
I founded this patch in aoTuV b5.61 update test patch.
This bug also described in Ticket #1377.Hi, dear developers!
I founded this patch in aoTuV b5.61 update test patch.
This bug also described in Ticket #1377.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1486It falls into an infinite loop when ogg_pcm_seek is called for the ogv file.2017-04-08T10:59:27Znya24It falls into an infinite loop when ogg_pcm_seek is called for the ogv file.I try to read vorbis in the ogv file (theora file) by using vorbisfile(libvorbis 1.2.0).
The ogv file was made with ffmpeg2theora.
Reading succeeded.
However, processing doesn't return when ov_pcm_seek(&vf, 0) is called.
It seems to...I try to read vorbis in the ogv file (theora file) by using vorbisfile(libvorbis 1.2.0).
The ogv file was made with ffmpeg2theora.
Reading succeeded.
However, processing doesn't return when ov_pcm_seek(&vf, 0) is called.
It seems to fall into an infinite loop by _get_prev_page of vorbisfile.c.
Cannot ov_pcm_seek be used for the ogv file?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1463libvorbisfile performs many redundant seeks on file open2017-04-08T10:59:27Zkmartinlibvorbisfile performs many redundant seeks on file openAttempting to get ampache to send .ogg/.oga files to mpd for local replay results in either a very long delay before the file will play (180+ seconds) or in garbled output.
/var/log/apache2/access.log contains many instances of this for...Attempting to get ampache to send .ogg/.oga files to mpd for local replay results in either a very long delay before the file will play (180+ seconds) or in garbled output.
/var/log/apache2/access.log contains many instances of this for each .ogg file sent to mpd:
"GET /ampache/play/index.php?song=227&uid=1&sid=3d19432a90356a42dae5451c54b4d2b7&name=/Breakestra%20-%20Stand%20up.ogg HTTP/1.1" 206 3634 "-" "mpd/0.13.2"
In discussion with Karl Vollmer, the lead developer for amapche, he commented that
"it's treating the URL like a local file and trying to fseek() all over the place. If you wouldn't mind could you report a bug to the libogg people? tell them they are more then welcome to contact me if they have questions"
He can be reached at ampache.org. I would be happy to provide additional lo excerpts and other information if needed.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1458Problems in configure script - SPARC / Solaris 9 / -mv82009-04-16T16:46:46ZtwigathyProblems in configure script - SPARC / Solaris 9 / -mv8When compiling libvorbis on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy...When compiling libvorbis on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy.
I had a look at the configure log and found that the -mv8 switch for gcc no longer exists. Removing it allowed the configure to complete and the compile to run through cleanly.https://gitlab.xiph.org/xiph/vorbis/-/issues/1456CVE-2008-1420 patch breaks decoding of 1.0beta1 files2017-04-08T10:58:44ZmgoldCVE-2008-1420 patch breaks decoding of 1.0beta1 fileslibvorbis is no longer able to play files encoded with the 1.0beta1 encoder because of the changes made to res0.c in changeset [14598]. This was initially filed in the Debian BTS because I didn't realize the same change had been made to ...libvorbis is no longer able to play files encoded with the 1.0beta1 encoder because of the changes made to res0.c in changeset [14598]. This was initially filed in the Debian BTS because I didn't realize the same change had been made to the libvorbis trunk:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504421
A sample file is attached to that report.
I added some debugging statements and found it was the final (partvals != entries) check failing:
```
partvals (784) != entries (900); origdim=2 partitions=28
```
http://xiph.org/vorbis/ states "The bitstream format for Vorbis I was frozen Monday, May 8th 2000. All bitstreams encoded since will remain compatible with all future releases of Vorbis." It looks like 1.0beta1 was released on or after 2000-05-12, so files encoded by it should still be decodable.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1399unpredictable corruption in multichannel Ogg vorbis files2017-04-08T10:59:08Zrobunpredictable corruption in multichannel Ogg vorbis filesHas anyone else created Vorbis files with more than 6 channels? I'm a game developer trying to use multichannel Ogg Vorbis files for a PS3 and XBOX 360 title. Using the latest release libs and tools, I've created a Mac application that...Has anyone else created Vorbis files with more than 6 channels? I'm a game developer trying to use multichannel Ogg Vorbis files for a PS3 and XBOX 360 title. Using the latest release libs and tools, I've created a Mac application that weaves up to 8 stereo AIFF files into one 16 channel Ogg file. What I'm finding is that if anything more than 3 stereo files (corresponding to a 5.1 audio file) are encoded, then the encoded output becomes unstable. I hear vocoder like artifacts and garbled output on some of the stereo pairs. It should be noted that I'm using a linear permutation matrix, so that the output file maintains the original stereo pairs, ie 16 channels in -> 16 channels out.
I've built Universal Binary versions of the latest Ogg and Vorbis libs available for download, and meticulously tested my sample_read callback, and everything is doing the right thing. I've even built raw and AIFF versions of a 16 track file, verified the integrity of the data, and run them through the readily available command line encoders for PC and Unix. The output corruption is identical to what I experience on my own encoder.
Its incredibly frustrating, and seems to be content dependent. In some file groupings, it performs brilliantly (I love the sound of Vorbis much more than MP3) for 3 minutes, and then goes to crap. In others, the corruption is evident much earlier. It always appears at the same place for each file group, no matter what the encoding settings.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1395vorbis cross-compiling with mingw2017-04-08T10:59:27Zalexisvorbis cross-compiling with mingwWhen I tried to cross compile vorbis with mingw, it failed.
I added two things:
1) The LIBTOOL for win32 in the configure.in file:
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
Without that special macro a lot of things are simply not working...When I tried to cross compile vorbis with mingw, it failed.
I added two things:
1) The LIBTOOL for win32 in the configure.in file:
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
Without that special macro a lot of things are simply not working right.
2) The @OGG_LIBS@ on the vorbisfile library LDADD flags:
libvorbisfile_la_LIBADD = libvorbis.la @OGG_LIBS@
Without that, somehow the link fails saying that it cannot find the ogg functions.
Point (1) will for sure have no effect on the Linux version.
Change (2) may have an effect. Also it should be minimal (such as adding one entry in the list of libraries linked with libvorbisfile.
Alexis Wilke
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1377float point exception (division by zero)2017-04-08T10:58:44Zdancefloat point exception (division by zero)Hello guys,
I found bug in vorbis lib, float point division by zero exception under C++ Builder 6.
In C++ Builder by default turn on exceptions with invalid float point operations.
Bug
Vorbis version 1.2.0
file: floor1.c
line: 510
sta...Hello guys,
I found bug in vorbis lib, float point division by zero exception under C++ Builder 6.
In C++ Builder by default turn on exceptions with invalid float point operations.
Bug
Vorbis version 1.2.0
file: floor1.c
line: 510
static void fit_line(lsfit_acc *a,int fits,int *y0,int *y1)
{
...
double denom = 1./(an*fx2-fx*fx); //in some situation an*fx2-fx*fx can be 0.
// I change this line like
//double denom = (0. == (an*fx2-fx*fx)) ? 0:1./(an*fx2-fx*fx);
...
}Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1374Length of first buffer less than 4400 call ov_open_callbacks will get OV_EBAD...2017-04-08T10:59:27ZbornstubLength of first buffer less than 4400 call ov_open_callbacks will get OV_EBADHEADERI write a wrapper for vorbisfile to decode ogg vorbis data. Because it is designed to decode data that is received from internet. So I write a reading callback for ov_open_callbacks. At first everything works. And then, I found a tricky ...I write a wrapper for vorbisfile to decode ogg vorbis data. Because it is designed to decode data that is received from internet. So I write a reading callback for ov_open_callbacks. At first everything works. And then, I found a tricky problem :
IDecoder *pDecoder = new OggDecoder();
fstream inputFile("../test.ogg", ios_base::binary | ios_base::in);
const int SIZE = 4399;
unsigned char *pBuffer = new unsigned char[SIZE];
size_t size = inputFile.readsome((char *)pBuffer, SIZE);
If I read a chunk of data that its length is less than 4400. And pass it to the wrapper. I will get a OV_EBADHEADER result returned by ov_open_callbacks.
Why? Is that a bug? Or just a feature ? Should I pass data to vorbisfile at last 4400 bytes?
Thanks.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1370GCC on OS/2 does not support -Wextra2017-04-08T10:58:44Zdave.r.yeoGCC on OS/2 does not support -WextraHi, pulling svn code and attempting to build vorbis results in an error about GCC not understanding -Wextra. GCC is version 3.3.5
Simplest fix I could think of is in attached patch
Dave Yeo
dave.r.yeo@gmail.comHi, pulling svn code and attempting to build vorbis results in an error about GCC not understanding -Wextra. GCC is version 3.3.5
Simplest fix I could think of is in attached patch
Dave Yeo
dave.r.yeo@gmail.comMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1362logic bug in _add_serialno2017-04-08T10:59:27ZGitlab Botlogic bug in _add_serialnothis logic is wrong (though probably not exercised);
if serialno_list is NULL, it will try to dereference the null pointer.
if(serialno_list){
*serialno_list = _ogg_realloc(*serialno_list, sizeof(*serialno_list)*(*n));
}else{
...this logic is wrong (though probably not exercised);
if serialno_list is NULL, it will try to dereference the null pointer.
if(serialno_list){
*serialno_list = _ogg_realloc(*serialno_list, sizeof(*serialno_list)*(*n));
}else{
*serialno_list = _ogg_malloc(sizeof(**serialno_list));
}Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1361[PATCH] Vorbis x64 with MS V.Studio 2005+ compile fix2017-04-08T10:58:44ZDmitryKos[PATCH] Vorbis x64 with MS V.Studio 2005+ compile fixHello!
Vorbis library does not compile out of box under MS Studio 2005+ for x64 platform, failing on vorbis_ftoi. Generic fix for this issue is to wrap win32 platform to avoid compiler error as following:
in: os.h
static __inline int ...Hello!
Vorbis library does not compile out of box under MS Studio 2005+ for x64 platform, failing on vorbis_ftoi. Generic fix for this issue is to wrap win32 platform to avoid compiler error as following:
in: os.h
static __inline int vorbis_ftoi(double f){
#ifdef _M_IX86
int i;
__asm{
fld f
fistp i
}
return i;
#else
return (int)(f+.5);
#endif
}
Best regards,
Dmitry Kostjuchenko.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1352[PATCH] enable filter callback in ov_read()2017-04-08T10:58:44ZGitlab Bot[PATCH] enable filter callback in ov_read()Adding a separate ticket for libvorbis component of #381.Adding a separate ticket for libvorbis component of #381.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1344Leak after ov_read_float2017-04-08T10:59:27Zchris.r.waltonLeak after ov_read_floatI'm on Windows, using MSVC8.
If using ov_read_float instead of ov_read on an OggVorbis_File, there are exactly 228 leaks. I can confirm that the OggVorbis_File is being ov_clear()-ed correctly. All the leaks happen in res0_look, most of...I'm on Windows, using MSVC8.
If using ov_read_float instead of ov_read on an OggVorbis_File, there are exactly 228 leaks. I can confirm that the OggVorbis_File is being ov_clear()-ed correctly. All the leaks happen in res0_look, most of them are 8 or 12 bytes, with a few larger allocations. I've attached the output of VLD which describes the leaks. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1327libvorbis-1.2.0\win32\VS2005\libvorbis: missing static build configuration2020-06-12T23:53:11ZOlafvdSpeklibvorbis-1.2.0\win32\VS2005\libvorbis: missing static build configurationHi,
libvorbis-1.2.0\win32\VS2005\libvorbis is missing static build configurations. The VS6 project file does include those configurations, but they're missing from the VS7 and VS8 project files.Hi,
libvorbis-1.2.0\win32\VS2005\libvorbis is missing static build configurations. The VS6 project file does include those configurations, but they're missing from the VS7 and VS8 project files.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1324[PATCH] seek ver slow -> numeric overflow in ov_pcm_seek_page2017-04-08T10:59:27Zxiph-mueller[PATCH] seek ver slow -> numeric overflow in ov_pcm_seek_pageFor large streams or on platforms that do not support 64 bit integers this will effectively result in a _linear search_ which of course make *seeks extremly slow*.
In the successive approximation search of ov_pcm_seek_page() the express...For large streams or on platforms that do not support 64 bit integers this will effectively result in a _linear search_ which of course make *seeks extremly slow*.
In the successive approximation search of ov_pcm_seek_page() the expression
```
bisect=begin +
(target-begintime)*(end-begin)/(endtime-begintime) - CHUNKSIZE;
```
may cause an integer overflow, because it _multiplies_ the stream length by the stream size.
I recommend to use floating point arithmetics for this purpose since it is an approximation anyway. Changing the code as follows cures the problem.
```
bisect=begin
+ (ogg_int64_t)((double)(target-begintime)*(end-begin)/(endtime-begintime))
- CHUNKSIZE;
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1291[PATCH] Mark all the constant tables as constant2017-04-08T10:58:44ZDiego Elio Pettenò[PATCH] Mark all the constant tables as constantThe current status of libvorbis (and especially of libvorbisenc) is not one of the best for shared libraries, as it contains a lot of static and non-static non-constant tables, which are never ever modified.
I'm attaching a patch that m...The current status of libvorbis (and especially of libvorbisenc) is not one of the best for shared libraries, as it contains a lot of static and non-static non-constant tables, which are never ever modified.
I'm attaching a patch that marks all the tables as constant, so that they can be moved to .rodata and thus reduce the memory occupation of libvorbis and libvorbisenc. In particular, libvorbisenc had over 1.5MB of non-constant tables, which are now all constant.
The patch applies fine over current SVN trunk, although it cause an huge amount of warnings at the moment because a lot of structures request a "foo*" rather than "const foo*" even when they don't modify the content. Also functions don't always request "const foo*", so there are quite a few warnings thrown in for that too.
I fixed quite a few of them, but I just couldn't fix all of them at once, the size of the patch is already massive, and I risked to have it fail on SVN if I started fixing all of them. Please don't reject the patch for that, as it would be nitpickery against a fix that's very much useful.
If you want, after you applied this patch I can prepare a new one to shut up the warnings.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1290[PATCH] Remove unused static seq variable2017-04-08T10:58:44ZDiego Elio Pettenò[PATCH] Remove unused static seq variableThere are two static seq variables in floor1.c, one is totally unused, the other is only ever written to. The attached patch gets rid of them to avoid copy-on-write.There are two static seq variables in floor1.c, one is totally unused, the other is only ever written to. The attached patch gets rid of them to avoid copy-on-write.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1274ftell2017-04-08T10:59:27ZGitlab Botftellftell is not working...showing first time use in the functionftell is not working...showing first time use in the functionMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1265libvorbis-1.2.0 won't build under OS X 10.52017-04-08T10:58:44ZJeff Lyonlibvorbis-1.2.0 won't build under OS X 10.5libvorbis-1.2.0 won't build under OS X 10.5:
$ ./configure
checking build system type... powerpc-apple-darwin9.1.0
checking host system type... powerpc-apple-darwin9.1.0
checking target system type... powerpc-apple-darwin9.1.0
checking ...libvorbis-1.2.0 won't build under OS X 10.5:
$ ./configure
checking build system type... powerpc-apple-darwin9.1.0
checking host system type... powerpc-apple-darwin9.1.0
checking target system type... powerpc-apple-darwin9.1.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
file config.log was not created, so no further information in this error is available.
Monty MontgomeryMonty Montgomery