Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/204os.h patch for Borland C2017-04-08T10:58:44Zdaveos.h patch for Borland C```
Small changes necessary for compiling with BCC in Windows.
``````
Small changes necessary for compiling with BCC in Windows.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/199Dont free time_param[0]2017-04-08T10:59:08ZrisarisaDont free time_param[0]```
I compiled encoder_example.c and tested.
and found memory leak.
in vorbisenc.c
static int vorbis_encode_toplevel_setup(vorbis_info *vi,int small,int large,int
ch,long rate){
...
ci->time_param[0]=calloc(1,sizeof(_time_dummy));...```
I compiled encoder_example.c and tested.
and found memory leak.
in vorbisenc.c
static int vorbis_encode_toplevel_setup(vorbis_info *vi,int small,int large,int
ch,long rate){
...
ci->time_param[0]=calloc(1,sizeof(_time_dummy));
...
}
This heap memory is not called free().
because, in time0.c
static void time0_free_info(vorbis_info_time *i){
}
so,I added one line.
static void time0_free_info(vorbis_info_time *i){
free(i);
}
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/161-b -M does not fill in max bitrate field2017-04-08T10:58:44Zgreg-b -M does not fill in max bitrate field```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x...```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x00000020: 62 69 73 00 00 00 00 02 - 44 ac 00 00 ff ff ff ff bis.....D.......
0x00000030: 1f f4 01 00 ff ff ff ff - b8 01 4f 67 67 53 00 00 ..........OggS..
The min/max bitrate fields are still "ff ff ff ff" (-1). The nominal bitrate
field is correctly set to "1f f4 01 00" (128031).
```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/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/615ov_open_callbacks, ov_test_callbacks - documentation incorrect2017-04-08T11:08:16Zphil.hackettov_open_callbacks, ov_test_callbacks - documentation incorrectIn the Vorbisfile documentation, the function declarations in "ov_open_callbacks" and "ov_test_callbacks" both state that the "ov_callbacks" parameter is passed by value. Below this, in the "Parameters" part of the text these parameters...In the Vorbisfile documentation, the function declarations in "ov_open_callbacks" and "ov_test_callbacks" both state that the "ov_callbacks" parameter is passed by value. Below this, in the "Parameters" part of the text these parameters are stated as pointers to "ov_callbacks" structures. Obviously only one of these is true. It seems to me that the parameters in question are passed by value and not as pointers. (I speak as a Delphi/Pascal coder with a loose grasp of C!)https://gitlab.xiph.org/xiph/vorbis/-/issues/581configure script ignores all the --with-ogg* options2017-04-08T10:58:44Zgorlikconfigure script ignores all the --with-ogg* options```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system detail...```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system details:
debian testing kernel 2.6.8-alpha and 2.6.9-i386
libvorbis-1.1.0
```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/681[PATCH] psuedocode error for Floor1 description in the vorbis docs2017-04-08T11:08:16Zreinier[PATCH] psuedocode error for Floor1 description in the vorbis docs
# Location
The Floor1 description in the vorbis docs, found here:
http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-floor1.html
Contains a bug in the pseudocode rendering of reading out the header (section *header decode*).
# Fragment...
# Location
The Floor1 description in the vorbis docs, found here:
http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-floor1.html
Contains a bug in the pseudocode rendering of reading out the header (section *header decode*).
# Fragment
```
18) iterate [i] over the range 0 ... [floor1_partitions]-1 {
19) [current_class_number] = vector [floor1_partition_class_list] element [i]
20) iterate [j] over the range 0 ... ([floor1_class_dimensions] element [current_class_number])-1 {
21) vector [floor1_X_list] element ([j] + [floor1_values]) =
read [rangebits] bits as unsigned integer
}
22) [floor1_values] = [floor1_values] + [floor1_class_dimensions] element [i]
}
```
# Problem
Line 22 is wrong I think. The intent is to fill the floor1_X_List array with the correct number of 4-bit values. This entails increasing the value of 'floor1_values' with exactly as many values as we just read. However, the increment is:
_floor1_class_dimensions(i)_
whereas the number of 4-bit values read is equal to
_floor1_class_dimensions(floor1_partition_class_list(i))_ aka _floor1_class_dimensions(current_class_number)_.
# Background
I'm re-implementing vorbis, just a decoder, from scratch, in java, using just the docs. Whenever I find inconsistencies or confusion I 'cheat' and take a quick peek at the C sources. In this case, the C sources seem to suggest the documentation is wrong.
# Fix
Change line 22 in the pseudocode to:
```
22) [floor1_values] = [floor1_values] + [floor1_class_dimensions] element [current_class_number]
```
No further changes neccessary.
# Priority and Severity
As it's documentation, you can intrinsically work around any problems by just implementing it right. Assuming for a moment I'm the only one currently trying to hack out a new vorbis decoder from scratch, there's no rush whatsoever. Severity is medium; it's fairly easy to catch, and the free C sources available make it fairly easy to confirm the nature of this documentation bug.
https://gitlab.xiph.org/xiph/vorbis/-/issues/87Access violation for 1 channel (mono) wave files2017-04-08T10:58:44ZbenAccess violation for 1 channel (mono) wave files```
I downloaded the vorbis_nightly_cvs.tar.gz on 29 Nov 2001 and built it.
running oggenc is fine for stereo wave files, but for mono, I get an exception
in file vorbis/lib/psy.c, in function:
_vp_quantize_couple(vorbis_look_psy * 0x007...```
I downloaded the vorbis_nightly_cvs.tar.gz on 29 Nov 2001 and built it.
running oggenc is fine for stereo wave files, but for mono, I get an exception
in file vorbis/lib/psy.c, in function:
_vp_quantize_couple(vorbis_look_psy * 0x007b7e80, vorbis_info_mapping0 *
0x006a8dec, float * * 0x007089f8, float * * 0x0068f6fc, float * * 0x0068f700,
int * 0x0068f708, int 0) line 1021 + 32 bytes
in the following line:
float ang,mag,fmag=max(fabs(pcmM[j]),fabs(pcmA[j]));
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/551vorbisfile documentation incomplete2017-04-08T11:08:16ZJack Moffittvorbisfile documentation incomplete```
missing all the _lap() functions, ov_read_float() etc.
``````
missing all the _lap() functions, ov_read_float() etc.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/507line 95, typo: filed -> field2017-04-08T11:08:16ZKyungjoon Leeline 95, typo: filed -> field```
In line 95 of v-comment.html in CVS vorbis/doc/v-comment.html and
http://www.xiph.org/ogg/vorbis/doc/v-comment.html there is a typo.
> Below is a proposed, minimal list of standard filed names with a
filed -> field
``````
In line 95 of v-comment.html in CVS vorbis/doc/v-comment.html and
http://www.xiph.org/ogg/vorbis/doc/v-comment.html there is a typo.
> Below is a proposed, minimal list of standard filed names with a
filed -> field
```https://gitlab.xiph.org/xiph/vorbis/-/issues/292ov_pcm_total(&file, -1) says there's one more sample than there actually is2017-04-08T10:59:27ZAdamDobsonov_pcm_total(&file, -1) says there's one more sample than there actually is```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytes...```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytesRead = ov_read(pFile, ((char *)pBuffer) + nTotalRead,
nBytesToRead, 0, 2, 1, ¤t_section);
if (nBytesRead > 0)
{
nTotalRead += nBytesRead;
nLength -= nBytesRead;
}
else if (nBytesRead == 0)
{
OutputDebugString("EOF reached\n");
return;
}
else
{
OutputDebugString("Error in stream detected\n");
}
}
// We never get here EOF is always reached first
OutputDebugString("It worked\n");
}
This was done using the 1.0 win32 sdk (using static linked release libs) and
the files were encoded with oggdropXPd v1.1 (Compiled 20020719).
To make it work as expected I needed to change the first line to read:
int nLength = (ov_pcm_total(pFile, -1) - 1) * 4;
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/730libvorbis-1.1.0 and libvorbis-1.1.1 broken2017-04-08T10:58:44Zsge1899libvorbis-1.1.0 and libvorbis-1.1.1 brokenoggenc creates distorted ogg files from wav files, when using libvorbis-1.1.0 or libvorbis-1.1.1... i now use libvorbis-1.0.1-r2, which work without a hitch....
the resulting oggfile created with above mentioned libraries sound like th...oggenc creates distorted ogg files from wav files, when using libvorbis-1.1.0 or libvorbis-1.1.1... i now use libvorbis-1.0.1-r2, which work without a hitch....
the resulting oggfile created with above mentioned libraries sound like there were byte order problems inside the file... don't know yet... just wonder, why no one seems to have that problem... actually, it is completely reproducible here... i'm usig gentoo, so i just paste you my "emerge info", which shows up possibly important things such as my CFLAGS...
Cheers,
KanneMonty 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/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/187gcc 2.95.3 chokes on -mno-ieee-fp2017-04-08T10:58:44Zdoctorkaedinggcc 2.95.3 chokes on -mno-ieee-fp```
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
``````
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/582[PATCH] Problem during book initialisation2017-04-08T10:58:44ZFelix Leder[PATCH] Problem during book initialisation```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated...```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated. The behaviour of malloc/calloc in that case is "implementation
dependant".
Most "implementations" return a pointer. Then everything works fine. BUT if you
have an implementation (e.g. TI DSPs) that returns NULL in case of a
calloc/malloc(0) either a segmentation fault is produced or data from memory
position 0 on is overwritten. Neither is wanted.
This overwriting happens in _book_unquantize (sharedbook.c, l. 183) in line 215
and possibly in line 235.
A fix is to replace lines 204 & 225 in this file:
< if((sparsemap && b->lengthlist[j]) || !sparsemap){
------------------
> if(b->lengthlist[j]){
This bug may be related to bug #340
```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/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/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/11ld can't link *f math functions2018-04-25T07:27:12Zdrticld can't link *f math functions```
simply need to #define powf pow and other functions from math library.
maybe you do it already and it is only problem of shared include files among
platforms.
looks like this:
gcc -O20 -ffast-math -D__NO_MATH_INLINES -fsigned-char -...```
simply need to #define powf pow and other functions from math library.
maybe you do it already and it is only problem of shared include files among
platforms.
looks like this:
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 -L/packages/share/l
ibogg-1.0beta4//lib -logg -lm -L/packages/share/libogg-1.0beta4//lib -logg
Undefined first referenced
symbol in file
acosf ../lib/.libs/libvorbis.a(lsp.o)
logf ../lib/.libs/libvorbis.a(envelope.o)
expf ../lib/.libs/libvorbis.a(envelope.o)
rintf ../lib/.libs/libvorbis.a(psy.o)
atanf ../lib/.libs/libvorbis.a(psy.o)
powf ../lib/.libs/libvorbis.a(psy.o)
ld: fatal: Symbol referencing errors. No output written to decoder_example
collect2: ld returned 1 exit status
make[1]: *** [decoder_example] Error 1
make[1]: Leaving directory `/tmp/la/libvorbis-1.0beta4/examples'
make: *** [all-recursive] Error 1
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/29missing 'break;' under the 'default:' case in 'floor1.c'2017-04-08T10:59:27Ztommissing 'break;' under the 'default:' case in 'floor1.c'```
This breaks the build of the vorbis sdk for the win32 platform
resolution:
insert a 'break;' for the default case of 'switch(lmse)' in function 'static
int floor1_forward'
This is needed to compile under MS VC++ 6.0
``````
This breaks the build of the vorbis sdk for the win32 platform
resolution:
insert a 'break;' for the default case of 'switch(lmse)' in function 'static
int floor1_forward'
This is needed to compile under MS VC++ 6.0
```Monty MontgomeryMonty Montgomeryhttps://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/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/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/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/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/88Serious encoding flaws with certain music2017-04-08T10:59:08ZultimaSerious encoding flaws with certain music```
I've discovered that OGG RC2 does a piss-poor job (to put it lightly) of
encoding wavs derived from SNES music files. Lame MP3, by comparison, does an
excellent job. I felt that this deserved a bug report.
Here is the URL of a ZIP...```
I've discovered that OGG RC2 does a piss-poor job (to put it lightly) of
encoding wavs derived from SNES music files. Lame MP3, by comparison, does an
excellent job. I felt that this deserved a bug report.
Here is the URL of a ZIP file which contains the 128-kbit OGG, and the 128-bit
ABR LAME MP3. I'd also upload the WAV file but I'll wait for your feedback
first, as its 5 megs and I'm on 56K.
http://ultima.unrealpc.com/oggprob.zip
The file is
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/92vorbis/autogen.sh has two unpaired quote marks diff file here2017-04-08T10:58:44Znisharfivorbis/autogen.sh has two unpaired quote marks diff file here```
--- autogen.sh Thu Aug 23 10:39:54 2001
+++ autogen.sh.new Thu Dec 20 16:33:26 2001
@@ -21,7 +21,7 @@
(automake --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have automake installed to compile $p...```
--- autogen.sh Thu Aug 23 10:39:54 2001
+++ autogen.sh.new Thu Dec 20 16:33:26 2001
@@ -21,7 +21,7 @@
(automake --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have automake installed to compile $package."
- echo "Download the appropriate package for your system,
+ echo "Download the appropriate package for your system,"
echo "or get the source from one of the GNU ftp sites"
echo "listed in http://www.gnu.org/order/ftp.html"
DIE=1
@@ -30,7 +30,7 @@
(libtool --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have libtool installed to compile $package."
- echo "Download the appropriate package for your system,
+ echo "Download the appropriate package for your system,"
echo "or get the source from one of the GNU ftp sites"
echo "listed in http://www.gnu.org/order/ftp.html"
DIE=1
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/113vorbis_encode_setup_managed guesses bitrate after calculating quality factor2017-04-08T10:59:08ZGitlab Botvorbis_encode_setup_managed guesses bitrate after calculating quality factor```
Here's the patch:
=========================================================
==========
RCS file: /usr/local/cvsroot/vorbis/lib/vorbisenc.c,v
retrieving revision 1.33
diff -c -r1.33 vorbisenc.c
*** vorbisenc.c 2001/12/23 11:53:53 ...```
Here's the patch:
=========================================================
==========
RCS file: /usr/local/cvsroot/vorbis/lib/vorbisenc.c,v
retrieving revision 1.33
diff -c -r1.33 vorbisenc.c
*** vorbisenc.c 2001/12/23 11:53:53 1.33
--- vorbisenc.c 2002/01/03 08:51:44
***************
*** 914,936 ****
long nominal_bitrate,
long min_bitrate){
! double tnominal=nominal_bitrate;
! double approx_vbr=approx_bitrate_to_vbr(channels,(channels==2),
! (float)nominal_bitrate,rate);
int ret=0;
! if(approx_vbr<0)return(OV_EIMPL);
!
! if(nominal_bitrate<=0.){
! if(max_bitrate>0.){
! nominal_bitrate=max_bitrate*.875;
}else{
! if(min_bitrate>0.){
! nominal_bitrate=min_bitrate;
}else{
return(OV_EINVAL);
}
}
}
ret=vorbis_encode_setup_vbr(vi,channels,rate,approx_vbr);
if(ret){
--- 914,938 ----
long nominal_bitrate,
long min_bitrate){
! float tnominal=nominal_bitrate;
! double approx_vbr;
int ret=0;
!
! if(nominal_bitrate<=0){
! if(max_bitrate>0){
! tnominal=(float)max_bitrate*.875f;
}else{
! if(min_bitrate>0){
! tnominal=(float)min_bitrate;
}else{
return(OV_EINVAL);
}
}
}
+
+ approx_vbr=approx_bitrate_to_vbr(channels,(channels==2),
+ (float)tnominal,rate);
+ if(approx_vbr<0)return(OV_EIMPL);
ret=vorbis_encode_setup_vbr(vi,channels,rate,approx_vbr);
if(ret){
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/128vibrating distortion artifact (perhaps channel coupling related)2017-04-08T10:59:08Znoavibrating distortion artifact (perhaps channel coupling related)```
I have encountered an annoying artifact in rc3 that could be described as a
pumping or vibrating distortion. In the beginning of the provided sample the
artifact is easily noticed in the left channel, but later in the sample i belive...```
I have encountered an annoying artifact in rc3 that could be described as a
pumping or vibrating distortion. In the beginning of the provided sample the
artifact is easily noticed in the left channel, but later in the sample i belive
it is somewhat to the right in the stereo image.
The artifact dissapears somewhere around quality 9.0 and it does not exist in rc2.
I use the standard rpms rebuilt on a redhat-7.2 system with full errata
(gcc-2.96-98)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/134examples don't compile with C902017-04-08T10:58:44Zpapadopoexamples don't compile with C90```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
...```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
[..]
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -DHAVE_DLFCN_H=1
-DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -I. -I. -I../include
-I/usr/local/libogg/include -xO4 -fast -w -fsimple -native -xcg92 -fast
-DUSE_MEMORY_H -c encoder_example.c
"encoder_example.c", line 100: syntax error before or at: /
cc: acomp failed for encoder_example.c
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/vorbis/-/issues/143Memory leak2017-04-08T10:58:44ZGitlab BotMemory leak```
The function static decode_aux *_make_decode_tree(codebook *c) in the
file "SharedBook.c" has a major memory leak. It calls calloc() twice,
storing the pointers to ptr0 and ptr1. However, nowhere in the code is
there a call to fre...```
The function static decode_aux *_make_decode_tree(codebook *c) in the
file "SharedBook.c" has a major memory leak. It calls calloc() twice,
storing the pointers to ptr0 and ptr1. However, nowhere in the code is
there a call to free(). As a result, this function will leak the two blocks of
memory every time it is called.
Should be a 15 minute fix.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/166ov_clear()2017-04-08T10:59:27Zcomrade2kov_clear()```
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
``````
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/171vorbis does not work on KDE 3.02017-04-08T10:59:27Zmvogtvorbis does not work on KDE 3.0```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto s...```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto seek_error calls in ov_pcm_seek_page
> >do not set the return value in the error case.
> >
> Though there may be (it looks like there is) a bug here, this
> fix is definately incorrect (you've changed it to return the
> wrong error code - which in the buggy cases is better than no
> error code, admittedly). I'll take a closer look and see
> if I can fix it properly.
>
It was a quick and dirty fix, I know. But before I started
to make a cleaner one, I like to have a feedback that
its actually a bug.
> Your reasoning doesn't entirely make sense, in that the
> goto seek_error calls are never reached if the stream has
> been closed (as you say it has been in this case). Sounds
> like there's a nasty bug in your multimedia player as well.
>
I can explain the situation, it has to do with threads.
Vorbis decodes in its own thread and reads from the
callbacks the input data.
User presses "stop" in the player, then the "GUI" thread
closes the input fd. (stream is closed)
If vorbis is doing a seek this "race" occurs:
Row 1027
int ov_pcm_seek_page(OggVorbis_File *vf,ogg_int64_t pos){
int link=-1,ret=0; <- default to "success"
[...]
Row 1086
// here the stream is closed by the other thread (GUI)
result=_get_next_page(vf,&og,end-vf->offset);
// vorbis sees the "closed stream"
if(result==OV_EREAD) goto seek_error;
Row 1175
Row 1175
seek_error:
/* dump machine so we're in a known state */
vf->pcm_offset=-1;
_decode_clear(vf);
return ret; <- RETURN SUCESS !
ret has the value "0" here, although an error occured.
Because the _decode_clear(vf); frees internal structures but
does not indicate the error to the higher functions the
later code segfaults.
No, the current CVS commit:(1.60)
granulepos-=vf->pcmlengths[link*2];
---
>
> if(vf->seekable && link>0)
> granulepos-=vf->pcmlengths[link*2];
did not fix the bug.
This is my segfault:
KDE sound server:
[kde@mv kde]$ artsd -S 4096 -F 10
read on not open file want:8500
Segmentation fault
Command line KDE player:
[kde@mv lib]$ mpeglibartsplay -2 /mnt/diskD/save/ogg/Marque.ogg
cnt:0
Segmentation fault
The -2 is a stresstest to trigger the mentioned race.
You see that "read on not open file want:8500" is vorbis decode
thread, while the gui cloesed the fd.
(The "stresstest" is a common case in the kde player, thus
stresstest is a wrong name)
>Can you file this bug at http://bugs.xiph.org (bugzilla)
done.
regards,
Martin
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/189cc1 segmentation fault on compile2017-04-08T10:58:44Zjupitercc1 segmentation fault on compile```
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
``````
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/191libvorbis built with Sun Forte 6.1 compiler produces bogus output2017-04-08T10:58:44Zatomik_katlibvorbis built with Sun Forte 6.1 compiler produces bogus output```
This is an error in the libvorbis module when compiled under Sun's Forte 6.1 C
compiler suite.
Once compiled, a trace of the ogg123 program shows that ogg123 opens the audio
device and assigns a file descriptor, but all that os ev...```
This is an error in the libvorbis module when compiled under Sun's Forte 6.1 C
compiler suite.
Once compiled, a trace of the ogg123 program shows that ogg123 opens the audio
device and assigns a file descriptor, but all that os ever written to that
desciptor is a series of nulls.
libvorbis compiled under GCC 3.03 works fine.
I have not traced the bug any farther, but can provide the authors with object
files and compiled binaries for testing.
Geoff
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/221vorbis.m4 check fails with segfault2017-04-08T10:58:44Zdlehnvorbis.m4 check fails with segfault```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_...```
(This bug is against 1.0 which does not yet have a bugzilla tag.)
In the vorbis 1.0 debian packages the check code in vorbis.m4 fails with a segfault.
Program received signal SIGSEGV, Segmentation fault.
0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
(gdb) bt
#0 0x4002bad6 in vorbis_block_clear () from /usr/lib/libvorbis.so.0
#1 0x4002ce9b in vorbis_analysis_init () from /usr/lib/libvorbis.so.0
#2 0x080486c6 in main () at t.c:17
The following fixes the segfault but perhaps better return value checking should
be used since this is mainly just a link test vs a functional test:
diff -u -r1.2 vorbis.m4
--- vorbis.m4 13 Jul 2002 02:16:53 -0000 1.2
+++ vorbis.m4 29 Jul 2002 14:36:43 -0000
@@ -54,6 +54,7 @@
#include <stdlib.h>
#include <string.h>
#include <vorbis/codec.h>
+#include <vorbis/vorbisenc.h>
int main ()
{
@@ -62,7 +63,7 @@
vorbis_info vi;
vorbis_info_init (&vi);
- vorbis_encode_init (&vi, 2, 44100, -1, 128, -1);
+ vorbis_encode_init (&vi, 2, 44100, -1, 128000, -1);
vorbis_analysis_init (&vd, &vi);
vorbis_block_init (&vd, &vb);
/* this function was added in 1.0rc3, so this is what we're testing for */
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/233Improved DJGPP support2017-04-08T10:58:44ZxaviergonzImproved DJGPP support```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGP...```
By performing the following changes, a better DJGPP support can be achieved:
libogg:
Open up the file /include/ogg/os_types.h, and near the end, right after the
OS/2 GCC #elif, add the following:
#elif defined (DJGPP)
/* DJGPP */
typedef short ogg_int16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
libvorbis, libvorbisenc, libvorbisfile:
Open up the file /lib/os.h, and near the end, right before the last
#endif, add the following code:
#ifdef DJGPP
# define rint(x) (floor((x)+0.5f))
#endif
Now with proper makefiles, the sources can be compiled properly under DJGPP. (I
tested it and it works under DJGPP once compiled that way)
Thanks for your time
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/236Compile warnings in seeking_example.c2017-04-08T10:58:44ZtiCompile warnings in seeking_example.c```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_ALL...```
On DEC OSF1 (Compaq/HP Tru64 UNIX 5.x) with the native cc compiler, the
Vorbis 1.0 examples/seeking_example.c exhibited the following compile
warning messages:
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0\" -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 -DHAVE_FLOORF=1 -I. -I.
-I../include -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H -c seeking_example.c
cc: Warning: seeking_example.c, line 194: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 167: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,-1,val,pcmlength,bigassbuffer);
--------------------^
cc: Warning: seeking_example.c, line 146: The scalar variable "pos" is fetched
but not initialized. And there may be other such fetches of this variable that
have not been reported in this compilation. (uninit1)
_verify(&ov,pos,val,-1,pcmlength,bigassbuffer);
--------------------^
/bin/ksh ../libtool --mode=link cc -O -O3 -tune ev56 -arch ev56 -DUSE_MEMORY_H
-all-static -o seeking_example seeking_example.o ../lib/libvorbisfile.la
../lib/libvorbis.la -lm -logg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/237sound quality in high voice2017-04-08T10:58:44Zvgaborsound quality in high voice```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1...```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1.0.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/246Decoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over...2017-04-08T10:58:44ZgcDecoding of 11025 1.0rc3 encoded streams with 1.0 final decoder seems to over-read```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "noc...```
I'm a developer/packager for Mandrake. We have a bug in "tuxpuck-0.7.91", a
segfault appearing in the "free" call from libvorbis. After a little
investigation, it seems that this stream:
-=-=---=-=---=-=---=-=--
Processing file "nock.ogg"...
New logical stream (#1, serial: 62f352bc): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3)
Channels: 1
Rate: 11025
Nominal bitrate not set
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 721 bytes
Playback length: 0m:00s
Average bitrate: 49.798121 kbps
Logical stream 1 ended
-=-=---=-=---=-=---=-=--
which reports a "ov_pcm_total(vf, -1) * channels * 2" of 2554 bytes, when
getting read by ov_read, sends back to the caller 256 bytes, then 256, 256, 1152
and 2048, which makes a total of 3968 bytes - then tuxpuck crashes because
it malloc'ed only 2554 bytes in its buffer.
This bug seems confirmed by using "oggdec" which doesn't segfault but ends
reporting it was at 155.0% of the stream.
We're using the final 1.0 release of Ogg Vorbis (since Sun Jul 21 2002). I've
tried to query this bug database for a duplicate but didn't find one, sorry if
this has already been fixed in the CVS or already reported.
I've put the ogg file here for your convenience though it's in official tuxpuck
package:
http://people.mandrakesoft.com/~gc/files/nock.ogg
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/257OggEnc gives bad quality with synthetic speech2017-04-08T10:58:44ZtgirmannOggEnc gives bad quality with synthetic speech```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've...```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've tried other encoders too; at the same bit rates MP3 (LAME version 3.92 MMX)
suffers from similar problems but it sounds better (when using vbr) while
Musepack sounds almost perfectly.
(side note: when forcing LAME to 128 kbit/s the quality is really bad)
As I selected quality I want oggenc to allocate enough bits to achieve the
desired quality.
See attachment for reverence WAV and Ogg Vorbis examples.
(Yes I'm using OggEnc v1.0 (libvorbis 1.0))
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/306Get exception in OS Kernel when try to open a file2017-04-08T10:59:27ZandrewGet exception in OS Kernel when try to open a file```
I am the author of a freeware game that runs in Windows and I am evaluating Ogg
Vorbis as a sound file format to support in the game engine. I am trying to use
the vorbisfile API to open a .ogg file and decode it to PCM for use as ...```
I am the author of a freeware game that runs in Windows and I am evaluating Ogg
Vorbis as a sound file format to support in the game engine. I am trying to use
the vorbisfile API to open a .ogg file and decode it to PCM for use as a
DirectSound buffer. Unfortunately I fell at the first hurdle :( When I try to
use ov_open to access a file I have opened, I get an exception in kernel32.dll
The code I'm using in my test prog is:
// oggtest.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "vorbis\vorbisfile.h"
int main(int argc, char* argv[])
{
FILE *file;
OggVorbis_File vf;
if ((file = fopen("test.ogg", "rb")) == NULL)
return -1;
if (ov_open(file, &vf, NULL, 0) < 0)
return -1;
ov_clear(&vf);
return 0;
}
I hope you can answer what the problem is or I won't be able to add this
support :/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/316libvorbis package does not build on RH 8.02017-04-08T10:58:44Zmark7libvorbis package does not build on RH 8.0```
libvorbis's spec file fails to build on RH 8.0.
Here's a patch:
--- libvorbis.spec 2002-07-19 02:48:15.000000000 -0400
+++ ../../SPECS/libvorbis.spec 2003-02-10 09:26:26.000000000 -0500
@@ -81,14 +81,14 @@
%{_includedir}/vor...```
libvorbis's spec file fails to build on RH 8.0.
Here's a patch:
--- libvorbis.spec 2002-07-19 02:48:15.000000000 -0400
+++ ../../SPECS/libvorbis.spec 2003-02-10 09:26:26.000000000 -0500
@@ -81,14 +81,14 @@
%{_includedir}/vorbis/codec.h
%{_includedir}/vorbis/vorbisfile.h
%{_includedir}/vorbis/vorbisenc.h
-%{_libdir}/libvorbis.a
-%{_libdir}/libvorbis.so
-%{_libdir}/libvorbisfile.a
-%{_libdir}/libvorbisfile.so
-%{_libdir}/libvorbisenc.a
-%{_libdir}/libvorbisenc.so
+%{_libdir}/*.a
+%{_libdir}/*.so
+%{_libdir}/*.la
%changelog
+* Mon Jan 10 2003 Mark Jonathan Schreiber <mark7@andrew.cmu.edu>
+- included *.la files in libvorbis-devel
+
* Sun Jul 14 2002 Thomas Vander Stichele <thomas@apestaart.org>
- Added BuildRequires:
- updated for 1.0 release
```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/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/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/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/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/480another segfault in libvorbis (triggered by CVS ices2 this time)2017-04-08T10:58:44Zgtgbranother segfault in libvorbis (triggered by CVS ices2 this time)```
Here's the backtrace. Please see bug #479 for a detailed description about my
system, the malloc.conf stuff etc.
#0 0x21d0298 in local_book_besterror (book=0x3c0e6bc8, a=0x3c2017a8)
at /usr/ports/mystuff/audio/libvorbis/w-libv...```
Here's the backtrace. Please see bug #479 for a detailed description about my
system, the malloc.conf stuff etc.
#0 0x21d0298 in local_book_besterror (book=0x3c0e6bc8, a=0x3c2017a8)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:341
341 *a++ -= *ptr++;
#1 0x21d0320 in _encodepart (opb=0x3c05ad6c, vec=0x3c2017a8, n=32,
book=0x3c0e6bc8, acc=0x0)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:354
354 int entry=local_book_besterror(book,vec+i*dim);
#2 0x21d0c6e in _01forward (vb=0x3c05ad68, vl=0x3c0d8900, in=0x3c035bb4, ch=1,
partword=0x3c2011a8, encode=0x21d02c0 <_encodepart>)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:578
578 ret=encode(&vb->opb,in[j]+offset,samples_per_partition,
#3 0x21d16e5 in res2_forward (vb=0x3c05ad68, vl=0x3c0d8900, in=0x3c037c14,
out=0x0, nonzero=0x3c037c04, ch=2, partword=0x3c2011a8)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:806
#4 0x21d3309 in mapping0_forward (vb=0x3c05ad68) at
/usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/mapping0.c:631
#5 0x21c407b in vorbis_analysis (vb=0x3c05ad68, op=0x0) at
/usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/analysis.c:47
#6 0x1c008c13 in encode_dataout (s=0x3c05ac00, og=0x3c037e7c) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.0-Beta2/src/encode.c:
213
#7 0x1c008366 in reencode_page (s=0x3c01e000, buf=0x3c006340,
outbuf=0x3c037ee8, outlen=0x3c037ee4)
at /usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/reencode.c:220
#8 0x1c009f04 in process_and_send_buffer (sdsc=0x3c012980, buffer=0x3c006340)
at /usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/stream_shared.c:121
#9 0x1c0069bb in ices_instance_stream (arg=0x3c012980) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.0-Beta2/src/stream.c:
254
#10 0x1c00e5ee in _start_routine (arg=0x3c00c4f0) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/thread/thread.c:655
#11 0xc38dcbd in _thread_start ()
#12 0x1f in ?? ()
Cannot access memory at address 0xffffffff.
Again, if I can help with more info, like certain variable/pointer values,
please let me know. I'll keep binary and coredumps.
Moritz
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/493ov_read_float segfaults on oggflac streams2017-04-08T10:59:27Zjwmov_read_float segfaults on oggflac streams```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
...```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
segfault.
As ov_read_float and ov_read are similar, I expect the same applies for
ov_read.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/505Compilation error with define INVSQ2EXP_LOOKUP_MIN2017-04-08T10:58:44ZjskinnerCompilation error with define INVSQ2EXP_LOOKUP_MIN```
File "lookup_data.h" line 71:
#define INVSQ2EXP_LOOKUP_MIN -32
should be changed to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The value for INVSQ2EXP_LOOKUP_MIN should be in brackets because it is
negative... otherwise the compile...```
File "lookup_data.h" line 71:
#define INVSQ2EXP_LOOKUP_MIN -32
should be changed to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The value for INVSQ2EXP_LOOKUP_MIN should be in brackets because it is
negative... otherwise the compiler pukes in "lookup.c" on line 43:
return INVSQ2EXP_LOOKUP[a-INVSQ2EXP_LOOKUP_MIN];
The preprocessor changes that to:
return INVSQ2EXP_LOOKUP[a--32];
and pukes on the double minus signs.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/566Freeze/infinite loop on old test file2017-04-08T10:59:27ZkcarnoldFreeze/infinite loop on old test file```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop ...```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop (in ov_open, I'll guess, from where it stopped). ogginfo says:
Negative granulepos on vorbis stream outside of headers. This file was created
by a buggy encoder
I'm marking this "major" because it happens reliably with such small data.
Hopefully it's reproducable on others' systems; if not, I can help debug. This
is the vorbis-tools Debian package, though, and it works very reliably on
everything else.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/580divide by zero error2017-04-08T10:58:44Zjohnhdivide by zero error```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0...```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0, all was ok & the resultant OGG file could still be played (used winAmp).
Built v1.1 of ogg, vorbis, vorbisenc & vorbisfile with borland c++ builder v6 &
tested with builds of oggenc & oggdec on this dev. platform. Have emailed the
offending WAV file to Mike Smith - was generated by using directSound (v9) audio
capture api. Problem also occurred on a WAV decoded from an MP3 using LAME.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/583Compiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase2017-04-08T10:59:08ZGitlab BotCompiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I...```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I
get around 270kbps for a -q6 encode). Other than the bitrate / filesize
increase, the encoded files sound the same.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1142Vorbis encoder segfault2017-04-08T10:58:44ZrowenVorbis encoder segfaultI am getting an access violation from libvorbis while encoding. I'm using libvorbis-1.1.2, but I have tried the latest subversion code (as of 3/5/07) without any improvement. Unfortunately, I can't duplicate the problem with the debug ...I am getting an access violation from libvorbis while encoding. I'm using libvorbis-1.1.2, but I have tried the latest subversion code (as of 3/5/07) without any improvement. Unfortunately, I can't duplicate the problem with the debug build of the library, so I can't give a full backtrace.
Here are the details that I have:
The error is an access violation reading 0x00FCD818
My code is based on the encoder example included with libvorbis, with some light modifications - the largest being that a fixed bitrate is used instead of vbr. With my code built in debug mode, but the libraries built in release mode, I can trace the access violation to the vorbis_analysis function - which I think is kind of a dispatch function, so thats probably not much help.
I'm building on Windows XP Pro SP2 with VC++ express edition 2005 (8.0.507727.42). I'm using the win32/build_vorbis_dynamic.bat and the other included .bat files to build DLLs for vorbis, vorbisenc, vorbisfile, and ogg.
I have built a stand-alone executable that can duplicate the problem with some test audio data. The stand-alone program is also based off of encoder_example.c and simply encodes some test audio data in a similar way to what my application does.
There are two audio streams used in my test program:
One is raw 16-bit PCM audio data with a sample rate of 44100.
The other is the same audio stream, resampled to 22050 samples per second (still 16-bit PCM).
The bug only seems to occur if the 44100 sample is encoded with a bit rate of 48, and then the 22050 sample is encoded twice with a bit rate of 32.
I don't see a way to attach files to a ticket, so send me an email and I can send you the test app and test data.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1158impossible validation case in specification of floor02017-04-08T11:08:16Zsean2impossible validation case in specification of floor0(I'm not sure if this is the right component to assign specification bugs to, but there is no separate component for them.)
Section 6.2.1, floor header decode, says:
```
7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size...(I'm not sure if this is the right component to assign specification bugs to, but there is no separate component for them.)
Section 6.2.1, floor header decode, says:
```
7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits],
[floor0_amplitude_offset] or [floor0_number_of_books] are less than zero, the stream is not decodable
```
This is not meaningful; all the variables listed above are indicated in the previous lines to be read as _unsigned_ values from the stream, so they couldn't possibly be less than 0.
https://gitlab.xiph.org/xiph/vorbis/-/issues/1232[PATCH] Add -Wdeclaration-after-statement to CFLAGS2017-04-08T10:58:44Zmle[PATCH] Add -Wdeclaration-after-statement to CFLAGSgcc-4.1 seems to default to conforming to the C99 standard which allows declarations after statements, ie
```
void whatever (int param)
{
if (param == 0)
return ;
int a = 10 ;
return a ;
}
```
The above is reported as...gcc-4.1 seems to default to conforming to the C99 standard which allows declarations after statements, ie
```
void whatever (int param)
{
if (param == 0)
return ;
int a = 10 ;
return a ;
}
```
The above is reported as an error in compilers which conform to earlier C standards.
The problem is that anyone working with a C99 compiler can accidentally commit code that breaks the compile for some other compilers.
The solution (at least for C99) is to compile with the -Wdeclaration-after-statement CFLAG, but not all versions of gcc recognise that flag. Fortunately its possible to detect whether gcc accepts this CFLAG at configure time.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1236vorbisfile.h causes compiler warnings in client code2017-04-08T10:59:27ZGitlab Botvorbisfile.h causes compiler warnings in client codeAny code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_...Any code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_DEFAULT, OV_CALLBACKS_NOCLOSE, OV_CALLBACKS_STREAMONLY and OV_CALLBACKS_STREAMONLY_NOCLOSE.
Many developers like to compile with warnings turned on and many even like to use -Werror (which turns warnings into errors) during development. However, any code that includes <vorbisfile.h> cannot be commpiled with -Werror.
Monty's comment in the file says that these structs are defined as static as a workaround required on windows. Supporting windows is a good thing, but the current solution is not good enough.
One possible solution would be to enclose the definitions of these structs inside:
```
#ifdef EXPOSE_OV_CALLBACKS
#endif
```
People who use these structs can then define EXPOSE_OV_CALLBACKS before including vorbisfile.h.
It would be interesting to hear from windows developers who might be able to come up with other possible solutions to this problem.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1258Add defines to exclude encoder specific parts from library2017-04-08T10:58:44ZGitlab BotAdd defines to exclude encoder specific parts from librarySeveral things can be removed from the library at compile time by using #defines if only a vorbis decoder is needed. These include, but are not limted to:
* Floor packer + Floor forward function
* Residue packer + Residue forward func...Several things can be removed from the library at compile time by using #defines if only a vorbis decoder is needed. These include, but are not limted to:
* Floor packer + Floor forward function
* Residue packer + Residue forward function
* Mapping packer + Mapping forward function
* Codebook packer/encoder
* Bitrate management (bitrate.c)
* vorbis_block_internal and functions that deal with it.
* Envelope code (envelope.c)
* Psychoaucostic model code (psy.c)
* Analysis file (analysis.c)
* info packers (info.c)
* smallft.c
This reduces the size of the generated code from >100kb to ~60kb.
Monty 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 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/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/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/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/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/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/2343Accessing elements outside of array boundaries2021-06-06T17:28:26ZdokutokuAccessing elements outside of array boundarieshttps://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of th...https://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of the array in line 347.
```c
if(halfoc>=P_BANDS-2)halfoc=P_BANDS-2;
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2344ov_fopen returns undocumented error value2022-01-01T03:49:16ZCarl Banksov_fopen returns undocumented error valueov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open t...ov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open the file. I'd guess that a lot of the code out in the field just tests if return value is -1.https://gitlab.xiph.org/xiph/vorbis/-/issues/2345Please give a example of how to use RTP vorbis2022-02-18T07:12:32Zyi xinPlease give a example of how to use RTP vorbishttps://gitlab.xiph.org/xiph/vorbis/-/issues/2346About ogg123 can't adjust volumn2022-07-18T03:11:47ZHangAbout ogg123 can't adjust volumnDear All:
I'm really sorry to bother you,I am using vorbis-toos to develop and I want to adjust the volume,but I don't find the relevant usage method。
I don't know ogg123 is or not support adjust the volume with software method(Ps:I ha...Dear All:
I'm really sorry to bother you,I am using vorbis-toos to develop and I want to adjust the volume,but I don't find the relevant usage method。
I don't know ogg123 is or not support adjust the volume with software method(Ps:I have no sound card,only use pcm),Hope everybody helps answer,thanks very much!https://gitlab.xiph.org/xiph/vorbis/-/issues/2347a potential bug of NPD2022-09-13T10:38:25Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gener...Hi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![1662360760592](https://user-images.githubusercontent.com/87304478/188383134-07ef0506-a2c9-4a29-861a-b132c5c0d7f1.jpg)
Although the code shown is for version 1.3.6 but is still exist in current version
would you can help to check if this bug is true?thank you for your effort and patience!https://gitlab.xiph.org/xiph/vorbis/-/issues/2348Darwin configure passes invalid flag -force_cpusubtype_ALL2023-09-16T21:23:08ZFX CoudertDarwin configure passes invalid flag -force_cpusubtype_ALLFlag -force_cpusubtype_ALL is passed by configure (see https://gitlab.xiph.org/xiph/vorbis/-/blob/master/configure.ac#L205) unconditionally. This darwin flag was was only ever valid for PowerPC, and ignored for Intel and now Apple Silico...Flag -force_cpusubtype_ALL is passed by configure (see https://gitlab.xiph.org/xiph/vorbis/-/blob/master/configure.ac#L205) unconditionally. This darwin flag was was only ever valid for PowerPC, and ignored for Intel and now Apple Silicon (ARM). In recent versions, the linker now flatly refuses is (in Xcode 15):
ld: unknown options: -force_cpusubtype_ALL
It should either be selectively passed for PowerPC or, at this stage, removed entirely.https://gitlab.xiph.org/xiph/vorbis/-/issues/2349misleading-indentation warning in lib/block.c2023-10-28T13:04:48ZJörn Heusippmisleading-indentation warning in lib/block.c```
lib/block.c: In function 'vorbis_analysis_buffer':
lib/block.c:395:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^~
lib/block.c:395:37:...```
lib/block.c: In function 'vorbis_analysis_buffer':
lib/block.c:395:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^~
lib/block.c:395:37: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
395 | if(b->header)_ogg_free(b->header);b->header=NULL;
| ^
lib/block.c:396:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
396 | if(b->header1)_ogg_free(b->header1);b->header1=NULL;
| ^~
lib/block.c:396:39: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
396 | if(b->header1)_ogg_free(b->header1);b->header1=NULL;
| ^
lib/block.c:397:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
397 | if(b->header2)_ogg_free(b->header2);b->header2=NULL;
| ^~
lib/block.c:397:39: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
397 | if(b->header2)_ogg_free(b->header2);b->header2=NULL;
| ^
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2350strict-prototypes warning in lib/vorbisfile.c2023-10-28T13:03:55ZJörn Heusippstrict-prototypes warning in lib/vorbisfile.c```
lib/vorbisfile.c:1913:12: warning: function declaration isn't a prototype [-Wstrict-prototypes]
1913 | static int host_is_big_endian() {
| ^~~~~~~~~~~~~~~~~~
``````
lib/vorbisfile.c:1913:12: warning: function declaration isn't a prototype [-Wstrict-prototypes]
1913 | static int host_is_big_endian() {
| ^~~~~~~~~~~~~~~~~~
```