Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2007-07-03T23:12:34Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1PCM wave files with extended format chunk in header aren't recognised2007-07-03T23:12:34ZmarcPCM wave files with extended format chunk in header aren't recognised```
If you try to encode a PCM wav file which has an extended format chunk
(of type WAVEFORMATEX), the encoder will return:
"Warning: Unrecognised format chunk in WAV header", and then an error message.
The extended format chunk is optio...```
If you try to encode a PCM wav file which has an extended format chunk
(of type WAVEFORMATEX), the encoder will return:
"Warning: Unrecognised format chunk in WAV header", and then an error message.
The extended format chunk is optional, but allowed by the standard.
Here is the structure of the extended format chunk
typedef struct waveformat_extended_tag {
WORD wFormatTag; /* format type */
WORD nChannels; /* number of channels (i.e. mono, stereo...) */
DWORD nSamplesPerSec; /* sample rate */
DWORD nAvgBytesPerSec; /* for buffer estimation */
WORD nBlockAlign; /* block size of data */
WORD wBitsPerSample; /* Number of bits per sample of mono data */
WORD cbSize; /* The count in bytes of the extra size */} WAVEFORMATEX;
A quick solution would be to simply change the following bit of code from the
function wav_open in audio.c
if(len!=16)
{
fprintf(stderr, "Warning: Unrecognised format chunk in WAV
header\n");
return 0; /* Weird format chunk */
}
if(fread(buf,1,16,in) < 16)
{
fprintf(stderr, "Warning: Unexpected EOF in reading WAV
header\n");
return 0;
}
with the following
if(len<16)
{
fprintf(stderr, "Warning: Unrecognised format chunk in WAV
header\n");
return 0; /* Weird format chunk */
}
if(fread(buf,1,len,in) < len)
{
fprintf(stderr, "Warning: Unexpected EOF in reading WAV
header\n");
return 0;
}
optionally you could also check that:
(READ_U16_LE(buf+16) + 18) == len
```Jack MoffittJack Moffitthttps://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-tools/-/issues/3filename error in RPM spec file2006-06-12T11:02:55Zluigiwalserfilename error in RPM spec file```
In the vorbis-tools spec file, in the files section the manpages are listed with
full filenames with .gz extensions. On some systems (like Mandrake) after the
build, the manpages end up with .bz2 extensions (don't ask me why) so the...```
In the vorbis-tools spec file, in the files section the manpages are listed with
full filenames with .gz extensions. On some systems (like Mandrake) after the
build, the manpages end up with .bz2 extensions (don't ask me why) so the RPM
doesn't get created unless the extension is changed in the spec file. The
portable solution would be to use * for the extension in the spec file (like
ogg123.1*, maybe some systems don't compress them at all) like most people do.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/5Core dump2009-04-19T21:19:35ZdknotoCore dump```
Core dump - floating point exception on Alpha EV56/EB164 21164 processor.
Distribution: RH 7.0
Kernel: 2.2.17-4
GCC: 2.96 20000731
``````
Core dump - floating point exception on Alpha EV56/EB164 21164 processor.
Distribution: RH 7.0
Kernel: 2.2.17-4
GCC: 2.96 20000731
```Jack MoffittJack Moffitthttps://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/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/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/ogg/-/issues/13Minor portability issues2006-06-12T11:22:27ZaegiskMinor portability issues```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF...```
Lines 74, 76, 78, and 81 are missing explicit typecasts to unsigned char (VC++ 6
is complaining).
Lines 177 and 209 are assigning -1 to an unsigned long. This is unspecified
according to the C specification. Change to 0xFFFFFFFF?
I'll attach a patch if desired.
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/libao/-/issues/15core dump in ao_close2006-06-12T11:04:14Zwizcore dump in ao_close```
ao_close does a NULL pointer dereference if you only ao_initialize(), get_default_device(), append_device(), and then ao_close (like ogg123 does), but play no file in the mean time (which can happen if you specify an invalid ogg file...```
ao_close does a NULL pointer dereference if you only ao_initialize(), get_default_device(), append_device(), and then ao_close (like ogg123 does), but play no file in the mean time (which can happen if you specify an invalid ogg file for play, e.g. a directory). Simple test: `mkdir test && ogg123 test'. I traced it a bit, and found out that it dies in ao_close().
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/20Win32 DLL version of vorbisenc.dll beta 4 broken?2017-04-08T10:59:08ZfmjWin32 DLL version of vorbisenc.dll beta 4 broken?```
Hi,
The VorbisEnc.DLL always crashes on me during vorbis_encode_init().
To see the problem, open up the oggdrop source code in VC++ 6.0.
This compiles fine as is (using the static libraries). Now change the three
*_static.lib into ...```
Hi,
The VorbisEnc.DLL always crashes on me during vorbis_encode_init().
To see the problem, open up the oggdrop source code in VC++ 6.0.
This compiles fine as is (using the static libraries). Now change the three
*_static.lib into *.lib in order to link with the DLL's instead. Deocde a file
an two stack levels down in vorbis_encode_init() it will die on a call to an
invalid address. Seems to be the same with both the debug and the release
version of the DLL.
Please do let me know when a.s.a.p. if the issue is resolved or if you can not
duplicate it.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/21oggpack_read() return value not well defined2006-06-12T11:31:37ZSegher Boessenkoologgpack_read() return value not well defined```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs ...```
If <long> is 32 bit on your platform, the return value -1 can mean
two different things: an out of data error occured, or we just read
32 bits, all 1.
And there's a signed/unsigned issue as well.
I'll convert everything that needs to be unsigned, in ogg as well as
in vorbis.
This will get rid of a lot of compiler warnings on non-x86 and non-gcc
platforms...
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/libao/-/issues/22RAW audio output driver2006-06-12T10:48:32ZStan SeibertRAW audio output driver```
Several people have asked me for a driver that will output raw audio samples.
The required patches can be found in this archived message:
http://www.xiph.org/archives/vorbis-dev/200103/0098.html
Please incorporate this soon.
``````
Several people have asked me for a driver that will output raw audio samples.
The required patches can be found in this archived message:
http://www.xiph.org/archives/vorbis-dev/200103/0098.html
Please incorporate this soon.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/23oggenc manpage and --help disagree on default bitrate2006-06-12T10:41:39Zjemorrisoggenc manpage and --help disagree on default bitrate```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 k...```
The oggenc manpage says
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s). Defaults to 160 kb/s for stereo.
And oggenc --help says (under MODES)
The default is the 128 kbps mode.
(I think line 54 of oggenc.c sets the actual default to 128.)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/24missing 'ogg_stream_packetpeek' export in 'win32/ogg.def'2006-06-12T10:30:29Ztommissing 'ogg_stream_packetpeek' export in 'win32/ogg.def'```
This breaks the build of the vorbis for the win32 platform
``````
This breaks the build of the vorbis for the win32 platform
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/ogg/-/issues/25'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea2009-04-19T20:39:35Ztom'win32/*.bat', harcoded path to 'vcvars32.bat' might be a bad idea```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we s...```
'win32/*.bat' all contain:
call "c:\program files\microsoft visual studio\vc98\bin\vcvars32.bat"
maybe this should be replaced with:
call "%MSDevDir%\..\..\vc98\bin\vcvars32.bat"
or (if we assume it is pathed, since later on we see just 'msdev' without a
path):
call vcvars32.bat
```starclassstarclasshttps://gitlab.xiph.org/xiph/ogg/-/issues/26'win32/*.bat' do not handle SRCROOT long path names with spaces correctly2006-06-12T10:56:22Ztom'win32/*.bat' do not handle SRCROOT long path names with spaces correctly```
as an example:
set SRCROOT=e:\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 SRC...```
as an example:
set SRCROOT=e:\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/27missing 'vorbis_packet_blocksize' export in 'win32/vorbis.def'2017-04-08T10:59:27Ztommissing 'vorbis_packet_blocksize' export in 'win32/vorbis.def'```
This breaks the build of vorbis for the win32 platform
``````
This breaks the build of vorbis for the win32 platform
```starclassstarclasshttps://gitlab.xiph.org/xiph/vorbis/-/issues/28missing 'floor1.c' in both 'win32/vorbis_dynamic.dsp' &amp; 'win32/vorbis_sta...2017-04-08T10:59:27Ztommissing 'floor1.c' in both 'win32/vorbis_dynamic.dsp' & 'win32/vorbis_static.dsp'```
This breaks the build of vorbis for the win32 platform
``````
This breaks the build of vorbis for the win32 platform
```starclassstarclasshttps://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 Montgomery