Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2020-06-13T00:34:33Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1783vorbis.pc.in assumes -lm, this should be detected first and then added if needed2020-06-13T00:34:33Zscottmc2vorbis.pc.in assumes -lm, this should be detected first and then added if neededNot all platforms require -lm, so instead of assuming -lm is needed, a check should be done and then add it in if needed. Perhaps change vorbis.pc.in to use ${libm}, default it to "" and change it to "-lm" There is an AC_CHECK_LIB (m, c...Not all platforms require -lm, so instead of assuming -lm is needed, a check should be done and then add it in if needed. Perhaps change vorbis.pc.in to use ${libm}, default it to "" and change it to "-lm" There is an AC_CHECK_LIB (m, cos, VORBIS_LIBS="-lm", VORBIS_LIBS="") in confirgure.ac, so perhaps it's as simple as changing the -lm in vorbis.pc.in to ${vobis_libs} or something like that.
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/2340divide by zero issue2020-06-11T04:25:08Zniugxdivide by zero issuethere is divide by zero issue when parameter word of ov_read_filter is 0 in vorbisfile.c file.
parameter word set by ov_read API, and user can set any value to word.
long ov_read_filter(OggVorbis_File *vf,char *buffer,int length,
.....there is divide by zero issue when parameter word of ov_read_filter is 0 in vorbisfile.c file.
parameter word set by ov_read API, and user can set any value to word.
long ov_read_filter(OggVorbis_File *vf,char *buffer,int length,
...
if(samples>0){
/* yay! proceed to pack data into the byte buffer */
long channels=ov_info(vf,-1)->channels;
long bytespersample=word * channels;
vorbis_fpu_control fpu;
// bytespersample is 0 when parameter word is 0, then divide by zero.
if(samples>length/bytespersample)samples=length/bytespersample;
POC:
modify parameter word of line 67 of vorbisfile_example.c to 0, like following:
long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,0,1,¤t_section);
compile vorbisfile_example and run like this :
cat xxxx.ogg | .libs/vorbisfile_example
floating point exception occured.
If you indentify this issue as a vulnerability, please provide me with following information:
1.the affected versions.
2.patch
3.please assign a CVE-ID, discoverer is Guoxiang Niu, EaglEye Team
thank youhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2120CHANGES changelog for libvorbis not updated since libvorbis 1.3.32020-06-10T22:01:44ZTim SmallCHANGES changelog for libvorbis not updated since libvorbis 1.3.3The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.https://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/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/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/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/1766vorbis_granule_time(): invalid integer constant2019-03-04T15:52:48ZJens Aytonvorbis_granule_time(): invalid integer constantvorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, ot...vorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, otherwise 0x7ffffffffLL.
This error is found in the 1.3.2 release and the current trunk. It was introduced in r17562.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2079tagcompare() uses toupper() and is sensitive to the current locale2019-02-02T04:30:06ZDavid Kingtagcompare() uses toupper() and is sensitive to the current localeI use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if th...I use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if the user's locale is (for example) Turkish, the dotted lower-case i 'i' is transformed to the dotted upper-case i 'İ', rather than the expected dotless upper-case i 'I'. This causes problems for tag names with 'i' characters in the Turkish locale, and maybe there are other examples too.
It would be nice if tagcompare() used a locale-insensitive upper-casing function, so that I do not have to do this in my application (ignoring the fact that calling setlocale() in an application which uses threads is asking for trouble).Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1784Track length do not show up in audio players2019-01-28T23:42:18Zpål smievollTrack length do not show up in audio playersYes I was very happy when i found this exe that would give me ogg playback in WMP11. But I have to work around a weird problem with my ogg music files. I converted them from wave to ogg quality 7 vorbis VBR using VLC mediaplayer. Now the...Yes I was very happy when i found this exe that would give me ogg playback in WMP11. But I have to work around a weird problem with my ogg music files. I converted them from wave to ogg quality 7 vorbis VBR using VLC mediaplayer. Now the weird part: Only VLC and ( especially ) Winamp plays the ogg files flawlessly with the correct track-length and seek bar function. This is a shame since I find Ogg vorbis VBR q7 to be the most Awesome lossy format. I even heard that q 5 vbr is sufficient. I wonder if any android mobile smartphone plays VBR ? Will send VLC this report also. There is hope for vbr ogg in wmp11 because it seems to open "ogg variable bit rate files" correctly if you right click and choose open with wmp11, now that is weird. It must be something about the players inability to read the correct track length from the ogg vbr files. This may be due to the conversion process in VLC from wave to ogg vbr ? Maybe the files dont get the correct track length after convertion. But then again its weird that some player gets it right. Is there any program to edit ogg track length etc.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2333Infinite loop in _get_prev_page_serial2019-01-28T23:34:17ZStefan LednickyInfinite loop in _get_prev_page_serialWe are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop...We are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop. The outer loop then seeks back to the beginning, and starts reading again, until we get the OV_EOF again in the inner loop... repeat infinitely.
OV_EOF, and possibly other error codes, should perhaps also return or be somehow handled so that it doesn't result in an infinite loop. I'm also guessing _get_prev_page has the same issue.https://gitlab.xiph.org/xiph/vorbis/-/issues/2327vorbisfile free of uninitialized memory if seek fails2019-01-28T23:01:57ZGitlab Botvorbisfile free of uninitialized memory if seek failsIn vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a...In vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a bit more:
https://github.com/SFML/SFML/issues/1241Thomas DaedeThomas Daedehttps://gitlab.xiph.org/xiph/vorbis/-/issues/2339Remove C++ comments2019-01-28T23:00:38ZHenry BentRemove C++ commentsThere are the following c++ style comments which should not be in plain c files:
-lib/res0.c (lines 33 and 34)
-lib/sharedbook.c (lines 53 and 305)There are the following c++ style comments which should not be in plain c files:
-lib/res0.c (lines 33 and 34)
-lib/sharedbook.c (lines 53 and 305)https://gitlab.xiph.org/xiph/vorbis/-/issues/8ov_open() causes crashes when compiled with msvc++ 6.0 and with vorbis sdk2018-12-13T03:37:32Zkandqofcov_open() causes crashes when compiled with msvc++ 6.0 and with vorbis sdk```
I downloaded the vorbis file example from
http://www.xiph.org/ogg/vorbis/doc/vorbisfile/vorbisfile_example_c.html and
compiled it with Visual C++ 6.0 service pack 4 with the vorbis SDK and recieved
no errors or warnings. When I r...```
I downloaded the vorbis file example from
http://www.xiph.org/ogg/vorbis/doc/vorbisfile/vorbisfile_example_c.html and
compiled it with Visual C++ 6.0 service pack 4 with the vorbis SDK and recieved
no errors or warnings. When I run the example program, it crashes at the
ov_open() function in both windows 98 first edition and windows 2000 sp1.
I also tried downloading another example program at
http://www.alphalink.com.au/~tjaden/hacks/vorbillegro.c and got the same
problem.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/7Vorbis decode example code fails to produce valid pcm data if not stereo2018-12-13T03:37:32ZcmeinhardtVorbis decode example code fails to produce valid pcm data if not stereo```
The code in decoder_example.c works fine as long as one does not decode audio
data that has been encoded from a non stereo source.
The original code in the decoder_example.c file looks like this:
for(i=0;i<vi.channels;i++){
ogg_...```
The code in decoder_example.c works fine as long as one does not decode audio
data that has been encoded from a non stereo source.
The original code in the decoder_example.c file looks like this:
for(i=0;i<vi.channels;i++){
ogg_int16_t *ptr=convbuffer+i;
float *mono=pcm[i];
for(j=0;j<bout;j++){
int val=mono[j]*32767.f;
if(val>32767){val=32767; clipflag=1;}
if(val<-32768){val=-32768; clipflag=1;}
*ptr=val;
ptr+=2;
}
}
This works just fine on stereo. ptr is set to the right interleaved start
address. But in the following loop ptr should fill all samples on one channel.
So ptr is incremented to jump over the other channels. Here's the bug
in the original code, ptr+=2 is hardcoded for stereo output.
Without hardcoding, here's the working code:
for(i=0;i<vi.channels;i++){
ogg_int16_t *ptr=convbuffer+i;
float *mono=pcm[i];
for(j=0;j<bout;j++){
int val=mono[j]*32767.f;
if(val>32767){val=32767; clipflag=1;}
if(val<-32768){val=-32768; clipflag=1;}
*ptr=val;
ptr+=vi.channels;
}
}
I have tested it on several audio sources, its all working. But I have not
tested it on >2 channel audio sources. I believe it should work, but no proof
from me...
>8) Best regards
Christian Meinhardt
Neuland Multimedia GmbH
www.neulandmm.de
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/6libvorbis doesn't link with envelope.c 1.34 change2018-12-13T03:37:32Zsnicolailibvorbis doesn't link with envelope.c 1.34 change```
I did a cvs pull Sunday afternoon CST March 4, 2001.
envelope.c 1.34 did an include of iir.c, and it's also in the project itself.
CW 5.3 complains of duplicate descriptors (i.e. duplicate functions). My
workaround is to remove ...```
I did a cvs pull Sunday afternoon CST March 4, 2001.
envelope.c 1.34 did an include of iir.c, and it's also in the project itself.
CW 5.3 complains of duplicate descriptors (i.e. duplicate functions). My
workaround is to remove iir.c from the project.
The bigger issue is how to get inlining and other performance enhancements
```Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis/-/issues/2wrong variable in RPM spec files2018-12-13T03:22:22Zluigiwalserwrong variable in RPM spec files```
on the ./configure lines in the RPM spec files (for all modules, including
vorbis-tools) the variable RPM_FLAGS is incorrect and should be RPM_OPT_FLAGS
First reported on IRC 2-25-2001
``````
on the ./configure lines in the RPM spec files (for all modules, including
vorbis-tools) the variable RPM_FLAGS is incorrect and should be RPM_OPT_FLAGS
First reported on IRC 2-25-2001
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/2337vorbis-java status? official binaries? maven?2018-11-30T19:59:19ZAndrey Bvorbis-java status? official binaries? maven?I am sorry if that's a bit off-topic, but what is the status of vorbis-java?
I see http://svn.xiph.org/trunk/vorbis-java/ is available and it's great, but are there any official versions / builds etc? Any binaries is any public maven by...I am sorry if that's a bit off-topic, but what is the status of vorbis-java?
I see http://svn.xiph.org/trunk/vorbis-java/ is available and it's great, but are there any official versions / builds etc? Any binaries is any public maven by any chance?https://gitlab.xiph.org/xiph/vorbis/-/issues/1566segmentation fault in vorbis_synthesis_headerin() when playing file2018-11-06T20:03:54Zkeelerdasegmentation fault in vorbis_synthesis_headerin() when playing fileThe attached ogg file (with vorbis audio inside) causes a segmentation fault in ogg123 1.2.0 (and happens to cause unbounded memory consumption when opened with firefox 3.6a1pre).The attached ogg file (with vorbis audio inside) causes a segmentation fault in ogg123 1.2.0 (and happens to cause unbounded memory consumption when opened with firefox 3.6a1pre).Monty MontgomeryMonty Montgomery