Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T11:08:16Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1541libvorbis: cleanup Vorbis_I_spec.tex2017-04-08T11:08:16ZMax Hornlibvorbis: cleanup Vorbis_I_spec.texThis patch cleans up doc/Vorbis_I_spec.tex, adds lots of comments, and tweaks the build rules to ensure Vorbis_I_spec.cfg is honored. It also changes the link color from red to blue, as requested by Monty :).This patch cleans up doc/Vorbis_I_spec.tex, adds lots of comments, and tweaks the build rules to ensure Vorbis_I_spec.cfg is honored. It also changes the link color from red to blue, as requested by Monty :).https://gitlab.xiph.org/xiph/vorbis/-/issues/1526vorbis encoder fails on ARM EABI systems - different output for same binary r...2017-04-08T10:59:08ZGitlab Botvorbis encoder fails on ARM EABI systems - different output for same binary run on different systemsPackage: libvorbis
Version: 1.2.0
The vorbis encoder does not work on ARM EABI systems, producing short .ogg files which are the right length in time, but decode to all zeros (silence).
Worse, the same binaries run on different ARM mac...Package: libvorbis
Version: 1.2.0
The vorbis encoder does not work on ARM EABI systems, producing short .ogg files which are the right length in time, but decode to all zeros (silence).
Worse, the same binaries run on different ARM machines produce different-length files of such garbage.
See http://bugs.debian.org/515949
Debian ARM EABI systems are available at the GCC compile farm, or I run a public-access one at n2100.martinwguy.co.uk - accounts on request to martinwguy@yahoo.it
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1523Patch to fix vorbis docbook compilation on trunk2017-04-08T10:58:44ZMax HornPatch to fix vorbis docbook compilation on trunkCurrently, building the docs on trunk is broken. The attached patch corrects this. First off, I replace some PNGs with recompressed versions (I used advpng -z4; if you want, you can just run that on all PNG files in doc/ instead of copyi...Currently, building the docs on trunk is broken. The attached patch corrects this. First off, I replace some PNGs with recompressed versions (I used advpng -z4; if you want, you can just run that on all PNG files in doc/ instead of copying the ones I attached).
Then I changed Makefile.am to use fop instead of pdfxmltex to build the PDF file. This works pretty well (with the exception of the PNG weirdness I mentioned).
As far as I can tell, this is one of the major blockers for new libvorbis 1.2.x releases.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1520Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1519Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1518Error playing file - Ogg Vorbis Mode 2 (6750)2019-07-01T08:51:48ZluyError playing file - Ogg Vorbis Mode 2 (6750)I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6...I keep getting errors playing back files that were encrypted with Vorbis.
MediaInfo report:
General
Complete name : C:\RT120307-0938.wav
Format : Wave
File size : 49.6 MiB
Duration : 1h 48mn
Overall bit rate : 64.0 Kbps
Audio
Format : Vorbis
Format settings, Floor : 1
Codec ID : 6750
Codec ID/Info : Mode 2
Duration : 1h 48mn
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 49.5 MiB (100%)
Writing library : libVorbis 1.0 RC3 (UTC 2001-12-31)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1499LibVorbis library build fails on Vista using MinGW 3.4.5 and MSYS (undefined ...2017-04-08T10:59:27ZedgarreynaldoLibVorbis library build fails on Vista using MinGW 3.4.5 and MSYS (undefined references to ogg functions)LibVorbis v1.2 won't build normally using MSYS and MinGW 3.4.5 on Vista using these steps :
```
./configure --prefix=/mingw
mingw32-make
mingw32-make install
```
It fails during mingw32-make because when the libvorbisfile library is bei...LibVorbis v1.2 won't build normally using MSYS and MinGW 3.4.5 on Vista using these steps :
```
./configure --prefix=/mingw
mingw32-make
mingw32-make install
```
It fails during mingw32-make because when the libvorbisfile library is being linked, it doesn't link against the libogg library.
I used a temporary hack to build all 3 vorbis libraries by setting the LIBS environment variable to -logg using "export LIBS=-logg". I don't know if the static version of ogg was the correct version to link against, but everything seems to be working properly. Using the LIBS variable however is incorrect, and in one place it linked against libogg twice using that method. (No harm done, but incorrect anyway).
I've attached a text build log of the failed process in it's entirety (scroll down to the undefined references to ogg functions near the end).
( BuildLog_LibVORBIS_failure.txt )
You can also see a thread I made about this on the Allegro forums at :
[http://www.allegro.cc/forums/thread/598976]
I believe I managed to track down the source of the offending compilation line in the generated libtool file in the main libvorbis directory, where the symbol _archive_cmds_ is being assigned its value. The _\$deplibs_ symbol in that line should probably have the value -logg or -logg.dll at this point, but I don't believe it has that value during the assignment.
I attached a second text file that shows this, as well as showing that the failed command from the build process works when -logg is added to it.
(LibVORBIS_Compile_Bug_Notes.txt)
Thanks for taking a look, and here's looking forward to a working MinGW build of libvorbis!
Edgar
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1496[PATCH] Mark few constant tables as constant2017-04-08T10:58:44ZEldar[PATCH] Mark few constant tables as constantThe Ticket #1291 applies to not all constant tables. I founded a few constant tables, which is not with const-modificator.The Ticket #1291 applies to not all constant tables. I founded a few constant tables, which is not with const-modificator.Monty MontgomeryMonty Montgomeryhttps://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 Montgomery