Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2006-06-12T11:12:43Zhttps://gitlab.xiph.org/xiph/libao/-/issues/59RPm for RC2 doesn't build from source RPM at SuSE 7.22006-06-12T11:12:43ZmalakhanovRPm for RC2 doesn't build from source RPM at SuSE 7.2```
spec for libao-devel list documentation files in doc directory:
API DRIVERS WANTED USAGE, but there are no such files.
Also doc files are installed by Makefile which doesn't detect right directory
for documentation files. At SuSE 7.2...```
spec for libao-devel list documentation files in doc directory:
API DRIVERS WANTED USAGE, but there are no such files.
Also doc files are installed by Makefile which doesn't detect right directory
for documentation files. At SuSE 7.2 this is
/usr/share/doc/packages/<packages-name>.
Either detect right place for documentation files or let rpm build put it there.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/285the very first seconds of a wav is not encoded2006-06-12T11:09:50Zb_lamythe very first seconds of a wav is not encoded```
when encoding from a wav (oggenc my_sound.wav) and playing the very first second
of the sound is not played!
furthermore, when I insert a blank time at the beginning, it does just has if
the blank space wasn't there and the same dura...```
when encoding from a wav (oggenc my_sound.wav) and playing the very first second
of the sound is not played!
furthermore, when I insert a blank time at the beginning, it does just has if
the blank space wasn't there and the same duration of the sound is cut.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/positron/-/issues/361Most mp3s from Emusic.com are not recognized2006-06-12T11:08:51ZtboneMost mp3s from Emusic.com are not recognized```
Most of the MP3 files I download from EMusic.com are not recognized as music
files. They work fine in xmms.
I will include a link to some sample files.
When I tested this with beta-2, 20 out of 166 files were recognized. When I
u...```
Most of the MP3 files I download from EMusic.com are not recognized as music
files. They work fine in xmms.
I will include a link to some sample files.
When I tested this with beta-2, 20 out of 166 files were recognized. When I
used the latest cvs, 2 more were recognized.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/56&#34;ogg_packet_clear&#34; not exported in ogg.def2006-06-12T11:08:23Zadonnai"ogg_packet_clear" not exported in ogg.def```
The function "ogg_packet_clear" isn't listed in ogg.def so linking fails when
calling it. One exmaple, vorbiscomment, couldn't compile because of this bug.
``````
The function "ogg_packet_clear" isn't listed in ogg.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-tools/-/issues/111Errors in the man page for oggenc2006-06-12T11:04:47ZreaperErrors in the man page for oggenc```
The man page for oggenc has a few errors -
1. The header still says "Release candidate 2" instead of "Release candidate 3"
2. The BUGS section lists -m -M and -q as non-implemented options. They are
implemented in RC3
``````
The man page for oggenc has a few errors -
1. The header still says "Release candidate 2" instead of "Release candidate 3"
2. The BUGS section lists -m -M and -q as non-implemented options. They are
implemented in RC3
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/343[RFE] Use ISO C99 types if available2006-06-12T11:04:43Zbero[RFE] Use ISO C99 types if available```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of...```
Your configure scripts go through great lengths to figure out the proper variable
types for 8, 16, 32 and 64 bit signed and unsigned; ISO C99 compilers (e.g. gcc
3.x) are required to define them in <stdint.h>, saving quite a lot of trouble.
Attaching a patch that uses stdint.h if available and falls back to the old way of
doing things if the compiler is too old.
```Monty MontgomeryMonty Montgomeryhttps://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-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/441oggenc: return values aren't usable2006-06-12T11:02:29Zccheneyoggenc: return values aren't usable```
This bug is copied from Debian BTS bug #101946:
Oggenc seems to (at least sometimes) return 0 even if encoding doesn't
succeed. I use oggenc in script, when tranforming mp3 to ogg, so sane return
values wouldn't hurt.
``````
This bug is copied from Debian BTS bug #101946:
Oggenc seems to (at least sometimes) return 0 even if encoding doesn't
succeed. I use oggenc in script, when tranforming mp3 to ogg, so sane return
values wouldn't hurt.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/libao/-/issues/132Doesn't compile due to lack of RTLD_GLOBAL2006-06-12T10:59:37ZwooledgDoesn't compile due to lack of RTLD_GLOBAL```
I'm compiling on HP-UX 10.20 with the hp_dlfcn compatibility package installed.
There is no RTLD_GLOBAL in dlfcn.h, so libao doesn't build. I patched around it
like this:
--- src/ao_private.h 2001/12/17 14:06:50 1.6
+++ src/...```
I'm compiling on HP-UX 10.20 with the hp_dlfcn compatibility package installed.
There is no RTLD_GLOBAL in dlfcn.h, so libao doesn't build. I patched around it
like this:
--- src/ao_private.h 2001/12/17 14:06:50 1.6
+++ src/ao_private.h 2002/01/16 15:30:33
@@ -42,7 +42,7 @@
*
* ALSA requires RTLD_GLOBAL.
*/
-#if defined(__OpenBSD__)
+#if defined(__OpenBSD__) || defined(hpux)
#define DLOPEN_FLAG (RTLD_LAZY)
#else
#define DLOPEN_FLAG (RTLD_NOW | RTLD_GLOBAL)
but that's a sloppy way to do it; it should be handled by autoconf.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/36contrary to -h interpretation output is written to a file2006-06-12T10:59:12Zsmithcontrary to -h interpretation output is written to a file```
OggEnc v0.7 (libvorbis rc1)
The -h indicates output is written to stdout when used with --raw, at least
that's how I read it...l
INPUT FILES:
...
In this mode, output is to stdout unless an outfile filename is specified
with -o
...```
OggEnc v0.7 (libvorbis rc1)
The -h indicates output is written to stdout when used with --raw, at least
that's how I read it...l
INPUT FILES:
...
In this mode, output is to stdout unless an outfile filename is specified
with -o
however it write to .ogg by default. Obviously not a critical report but
I want to let you know we're out here trying stuff.
brian redman
159-190% LD_LIBRARY_PATH=/usr/local/lib oggenc --raw foo.aiff
Encoding "foo.ogg" -
Done encoding file "foo.ogg"
File length: 9m 34.0s
Elapsed time: 5m 20.4s
Rate: 1.7931
Average bitrate: 114.0 kb/s
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/80crc block generation doesn't set crc_ready2006-06-12T10:57:30Ztimjcrc block generation doesn't set crc_ready```
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
``````
the end of _ogg_crc_init() should actually read:
crc_ready=1; instead of the current crc_ready=0;
```Monty MontgomeryMonty Montgomeryhttps://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/libao/-/issues/107Incorrect version number in README2006-06-12T10:55:35ZgshangIncorrect version number in README```
This is actually for libao 0.8.2 as shipped with vorbis RC3, but there
wasn't a pulldown entry for that (which I guess is a bugzilla bug, hmmmm).
The README in libao 0.8.2 says the version is 0.8.0. Apart from that, it
seems to be ...```
This is actually for libao 0.8.2 as shipped with vorbis RC3, but there
wasn't a pulldown entry for that (which I guess is a bugzilla bug, hmmmm).
The README in libao 0.8.2 says the version is 0.8.0. Apart from that, it
seems to be fully up to date as far as I can tell.
Geoff.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/133libao dependency for libasound.so.22006-06-12T10:55:11ZBilllibao dependency for libasound.so.2```
When I try to install the libao-0.8.2-1 i386 RPM, under Red Hat 7.1, using
GnomeRPM, I am told it needs libasound.so.2
I am not able to find libasound on any of the RPM sites.
How do I correct this?
``````
When I try to install the libao-0.8.2-1 i386 RPM, under Red Hat 7.1, using
GnomeRPM, I am told it needs libasound.so.2
I am not able to find libasound on any of the RPM sites.
How do I correct this?
```Stan SeibertStan Seiberthttps://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/104ogg.m4 refers to ogg-config2006-06-12T10:47:55ZGitlab Botogg.m4 refers to ogg-config```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for m...```
Some leftovers in the ogg.m4 apparently, put me on a wild goosechase for a few
minutes :)
In ogg.m4, if configure fails to compile the test program, the error message
incorrectly mentions "ogg-config"
(Do I get extra credit for most trivial 'bug'?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/37Encoding quality (mostly voice)2006-06-12T10:46:56ZGitlab BotEncoding quality (mostly voice)```
Hi,
I have compared an OGG beta 4 audio file with AAC (fraunhofer encoder) and MP3
(fraunhofer encoder) all encoded at 128kbps.
OGG seems to be able to produce a highter quality audio file.
I only have one comment about voice encodi...```
Hi,
I have compared an OGG beta 4 audio file with AAC (fraunhofer encoder) and MP3
(fraunhofer encoder) all encoded at 128kbps.
OGG seems to be able to produce a highter quality audio file.
I only have one comment about voice encoding. I know this is still a beta
version (perhaps close to release) but I can definitely hear a loss in the
voice encoding.
Song: Tori Amos - Cornflake Girl.
I am using oggdrop.exe beta 4.
Let me know if you need more details.
Thanks,
Gianluca.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/libao/-/issues/418cvs_nighly libao ao_aixs.c build problem2006-06-12T10:44:12Ztomppacvs_nighly libao ao_aixs.c build problem```
libao Makefile tries to build src/ao_aixs.c on my Solaris box. This looks
something which should happen only with AIX
make
Making all in src
Making all in plugins
Making all in oss
Making all in esd
Making all in arts
Making all i...```
libao Makefile tries to build src/ao_aixs.c on my Solaris box. This looks
something which should happen only with AIX
make
Making all in src
Making all in plugins
Making all in oss
Making all in esd
Making all in arts
Making all in alsa
Making all in alsa09
Making all in sun
Making all in irix
Making all in macosx
Making all in nas
source='ao_aixs.c' object='ao_aixs.lo' libtool=yes \
depfile='.deps/ao_aixs.Plo' tmpdepfile='.deps/ao_aixs.TPlo' \
depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --mode=compile cc -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libao\" -DVERSION=\"0.8.3\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBPTHREAD=1 -DSIZEOF_SHORT=2
-DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DHAVE_SYS_AUDIOIO_H=1 -DHAVE_SYS_AUDIO_H=1 -I.
-I. -I../include/ao -I../include
-DAO_PLUGIN_PATH=\"/usr/local/lib/ao/plugins-2\" -xO4 -fast -w -fsimple
-native -xcg92 -g -c -o ao_aixs.lo `test -f 'ao_aixs.c' || echo './'`ao_aixs.c
cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libao\"
-DVERSION=\"0.8.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBPTHREAD=1
-DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DHAVE_SYS_AUDIOIO_H=1
-DHAVE_SYS_AUDIO_H=1 -I. -I. -I../include/ao -I../include
-DAO_PLUGIN_PATH=\"/usr/local/lib/ao/plugins-2\" -xO4 -fast -w -fsimple -native
-xcg92 -g -c ao_aixs.c -KPIC -DPIC -o ao_aixs.lo
"ao_aixs.c", line 130: undefined symbol: audio_init
"ao_aixs.c", line 130: syntax error before or at: init
"ao_aixs.c", line 131: undefined symbol: audio_control
"ao_aixs.c", line 132: undefined symbol: audio_change
"ao_aixs.c", line 137: undefined symbol: init
"ao_aixs.c", line 137: undefined struct/union member: srate
"ao_aixs.c", line 138: undefined struct/union member: bits_per_sample
"ao_aixs.c", line 139: non-unique member requires struct/union object: channels
"ao_aixs.c", line 139: cannot access member of non-struct/union object
"ao_aixs.c", line 140: undefined struct/union member: mode
"ao_aixs.c", line 140: undefined symbol: AUDIO_PCM
"ao_aixs.c", line 141: undefined struct/union member: flags
"ao_aixs.c", line 141: undefined symbol: AUDIO_BIG_ENDIAN
"ao_aixs.c", line 141: undefined symbol: AUDIO_TWOS_COMPLEMENT
"ao_aixs.c", line 142: undefined struct/union member: operation
"ao_aixs.c", line 144: undefined symbol: AUDIO_INIT
"ao_aixs.c", line 149: undefined symbol: change
"ao_aixs.c", line 149: cannot access member of non-struct/union object
"ao_aixs.c", line 150: undefined struct/union member: volume
"ao_aixs.c", line 151: undefined struct/union member: monitor
"ao_aixs.c", line 151: undefined symbol: AUDIO_IGNORE
"ao_aixs.c", line 152: undefined struct/union member: input
"ao_aixs.c", line 153: undefined struct/union member: output
"ao_aixs.c", line 153: undefined symbol: AUDIO_OUTPUT_1
"ao_aixs.c", line 155: undefined symbol: control
"ao_aixs.c", line 155: undefined struct/union member: ioctl_request
"ao_aixs.c", line 155: undefined symbol: AUDIO_CHANGE
"ao_aixs.c", line 156: undefined struct/union member: position
"ao_aixs.c", line 157: undefined struct/union member: request_info
"ao_aixs.c", line 159: undefined symbol: AUDIO_CONTROL
"ao_aixs.c", line 164: undefined symbol: AUDIO_START
cc: acomp failed for ao_aixs.c
*** Error code 1
make: Fatal error: Command failed for target `ao_aixs.lo'
Current working directory /v/t/src/ogg/build/ao/src
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /v/t/src/ogg/build/ao/src
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
```Stan SeibertStan Seiberthttps://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 Montgomery