Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2006-06-12T11:08:23Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/56"ogg_packet_clear" 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/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/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/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/ogg/-/issues/229shared library not built2006-06-12T11:13:16Zshattyshared library not built```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to ...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libogg.so is not built. (libogg.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libogg_la_LDFLAGS = -version-info @LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
new version:
libogg_la_LDFLAGS = -no-undefined -version-info
@LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@
With this patch the library builds and works fine. (Tested with vorbis-tools.)
This patch informs libtool that this particular library has no undefined symbols
and so it can be built without problems on beos. (or any other platform without
the ability to compile/use libs with undefined symbols.)
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/72Unable to compile vorbis-tools due to problems with libgetopt2006-06-12T11:13:55ZelifarleyUnable to compile vorbis-tools due to problems with libgetopt```
I'm using MacOS X 10.1
cc -fno-common -O4 -Wall -fsigned-char -ffast-math -o oggenc oggenc.o audio.o
encode.o platform.o -L/usr/local/lib -lvorbisenc -lvorbis -lm -logg
../share/libutf8.a ../share/libgetopt.a
/usr/bin/ld: multiple ...```
I'm using MacOS X 10.1
cc -fno-common -O4 -Wall -fsigned-char -ffast-math -o oggenc oggenc.o audio.o
encode.o platform.o -L/usr/local/lib -lvorbisenc -lvorbis -lm -logg
../share/libutf8.a ../share/libgetopt.a
/usr/bin/ld: multiple definitions of symbol _getopt
/usr/lib/libm.dylib(getopt.o) definition of _getopt
../share/libgetopt.a(getopt.o) definition of _getopt in section (__TEXT,__text)
/usr/bin/ld: multiple definitions of symbol _optarg
/usr/lib/libm.dylib(getopt.o) definition of _optarg
../share/libgetopt.a(getopt.o) definition of _optarg in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol _opterr
/usr/lib/libm.dylib(getopt.o) definition of _opterr
../share/libgetopt.a(getopt.o) definition of _opterr in section (__DATA,__data)
/usr/bin/ld: multiple definitions of symbol _optind
/usr/lib/libm.dylib(getopt.o) definition of _optind
../share/libgetopt.a(getopt.o) definition of _optind in section (__DATA,__data)
/usr/bin/ld: multiple definitions of symbol _optopt
/usr/lib/libm.dylib(getopt.o) definition of _optopt
../share/libgetopt.a(getopt.o) definition of _optopt in section (__DATA,__data)
make[2]: *** [oggenc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/positron/-/issues/359positron breaks while adding/syncing and will not work thereafter2006-06-12T11:14:11Zjeanpositron breaks while adding/syncing and will not work thereafter```
While using positron to add some mp3s to my 20GB neuros under Gentoo 1.4-rc4
(kernel 2.4.20-gentoo-r5, modules: input, mousedev, keybdev, hid, usb-ohci,
usb-storage, running on a dual Athlon 2400-MP box [Iwill motherboard]), after
su...```
While using positron to add some mp3s to my 20GB neuros under Gentoo 1.4-rc4
(kernel 2.4.20-gentoo-r5, modules: input, mousedev, keybdev, hid, usb-ohci,
usb-storage, running on a dual Athlon 2400-MP box [Iwill motherboard]), after
successfully adding numerous files and several directories I started getting the
following:
positron add MCHawking
Traceback (most recent call last):
File "/usr/bin/positron", line 157, in ?
main(sys.argv)
File "/usr/bin/positron", line 142, in main
cmd.run(config, myNeuros, remaining[1:])
File "/usr/lib/python2.2/site-packages/positron/cmd_add.py", line 44, in run
audio_db = neuros.open_db("audio")
File "/usr/lib/python2.2/site-packages/positron/neuros.py", line 160, in open_db
self.db_formats[name]["no_flatten"])
File "/usr/lib/python2.2/site-packages/positron/db/WOID.py", line 76, in open
sai.open(saipath)
File "/usr/lib/python2.2/site-packages/positron/db/SAI.py", line 58, in open
header = struct.unpack(pattern, self.file.read(size_required))
IOError: [Errno 5] Input/output error
unmounting and remounting the neuros worked a couple of times, but now even that
will not clear up the problem. As the user trying to run the neuros command I
can touch and remove a file in WOID_DB, WOID_SYNC, music, and the root directory
of the device [I didn't try that in the firmware directory], so read/write
permissions are fine.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/54SmokeCity-UnderwaterLove sounds broken with OGG2006-06-12T11:18:59ZskoehlerSmokeCity-UnderwaterLove sounds broken with OGG```
I encoded a WAV of the mentioned Track and the ogg file (oggenc -b 192 xxx.wav)
sounds VERY bad at the beginning
you can request the OGG and a comparable MP3 encoded from the same WAV (lame -b
192 -h -m j xxx.wav)
it REALLY sound...```
I encoded a WAV of the mentioned Track and the ogg file (oggenc -b 192 xxx.wav)
sounds VERY bad at the beginning
you can request the OGG and a comparable MP3 encoded from the same WAV (lame -b
192 -h -m j xxx.wav)
it REALLY sounds HORRORABLE ..
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/68Mac OS X plugin loading through native API rather than dlopen compat library2006-06-12T11:19:08ZStan SeibertMac OS X plugin loading through native API rather than dlopen compat library```
This is a placeholder for Marquis Logan's patch to allow libao to load plugins
on OS X.
``````
This is a placeholder for Marquis Logan's patch to allow libao to load plugins
on OS X.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/458oggpackB_writeclear() uses different bit packing conventions for source and t...2006-06-12T11:19:10ZTimothy B. TerriberryoggpackB_writeclear() uses different bit packing conventions for source and target buffers```
bitwise.c:177:
if(bits)
w(b,(unsigned long)(ptr[bytes]),bits);
The above line assumes that the last (n%8) bits of the input buffer are always in
the least most significant bits of the last byte.
However, this means one ca...```
bitwise.c:177:
if(bits)
w(b,(unsigned long)(ptr[bytes]),bits);
The above line assumes that the last (n%8) bits of the input buffer are always in
the least most significant bits of the last byte.
However, this means one cannot copy the bits from another oggpack_buffer written
to with oggpackB_write(), as it stores them in the most significant bits of the
last byte.
I.e., oggpackB_write(&opb1,oggpackB_get_buffer(&opb2),oggpackB_bits(&opb2))
fails in general.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/46332-bit float input broken2006-06-12T11:20:05ZTimothy B. Terriberry32-bit float input broken```
When support for 24-bit integer .wav files was added, it broke existing 32-bit
float support, since the check for sample size is applied regardless of the
format type.
--- audio.c,v1.34
+++ audio.c
if( format.align == format.chann...```
When support for 24-bit integer .wav files was added, it broke existing 32-bit
float support, since the check for sample size is applied regardless of the
format type.
--- audio.c,v1.34
+++ audio.c
if( format.align == format.channels*samplesize &&
format.samplesize == samplesize*8 &&
(format.samplesize == 24 || format.samplesize == 16 ||
- format.samplesize == 8))
+ format.samplesize == 8 ||
+ (format.samplesize == 32 && format.format == 3)))
{
/* OK, good - we have the one supported format,
now we want to find the size of the file */
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/141please document decimal point arguments for -q option2006-06-12T11:20:10Zknweissplease document decimal point arguments for -q option```
The fact that it is possible to specify a quality number
with a decimal point isn´t documented (neither in the usage
string nor in man page).
``````
The fact that it is possible to specify a quality number
with a decimal point isn´t documented (neither in the usage
string nor in man page).
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/libao/-/issues/466libao 0.8.4 doesn't compile with --disable-esd2006-06-12T11:22:15Zberolibao 0.8.4 doesn't compile with --disable-esd```
[0.8.4 is missing in the Version list on enter_bug.cgi; this is about final
0.8.4 despite the cvs mark]
Trying to compile with esd disabled results in
configure: error: conditional "HAVE_ESD" was never defined.
Usually this m...```
[0.8.4 is missing in the Version list on enter_bug.cgi; this is about final
0.8.4 despite the cvs mark]
Trying to compile with esd disabled results in
configure: error: conditional "HAVE_ESD" was never defined.
Usually this means the macro was only invoked conditionally.
```Stan SeibertStan Seiberthttps://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/ogg/-/issues/295Runtime DLL used in Debug Mode2006-06-12T11:22:35ZGitlab BotRuntime DLL used in Debug Mode```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
deve...```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
developers (IMHO) use this under Win32.
The change is simple: "Project Settings" -> "C/C++" -> "Code Generation" and set
"Use run-time library" to "debug multithreaded" on the "ogg_static.dsp".
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/60src/Makefile.am doesn't work with outside-the-tree builds2006-06-12T11:23:31Zahltorpsrc/Makefile.am doesn't work with outside-the-tree builds```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
===...```
The Makefile.am in src/Makefile.am does not properly set the include path
if building in a separate obj directory. The patch below fixes that problem.
Index: Makefile.am
=========================================================
==========
RCS file: /usr/local/cvsroot/ogg/src/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- Makefile.am 2000/11/02 20:11:33 1.3
+++ Makefile.am 2001/10/08 01:29:52
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = foreign
-INCLUDES = -I../include
+INCLUDES = -I../include -I$(top_srcdir)/include
lib_LTLIBRARIES = libogg.la
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/46oggenc generates extra output lines when the status line is wider than the te...2006-06-12T11:23:47Zjgaughanoggenc generates extra output lines when the status line is wider than the terminal```
This also occurs with vorbis tools 1.0rc2.
When oggenc is encoding file with a long filename the status line in the output
can become longer than the width of the terminal. The line becomes wrapped and
each time the status line is ...```
This also occurs with vorbis tools 1.0rc2.
When oggenc is encoding file with a long filename the status line in the output
can become longer than the width of the terminal. The line becomes wrapped and
each time the status line is updated and extra line is added to the output.
Here's an example of the output from when I was encoding a track earlier today
(using abcde as frontend):
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.1%] [ 7m38s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.1%] [ 5m46s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.2%] [ 5m07s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.2%] [ 5m01s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.3%] [ 5m26s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.3%] [ 5m06s remaini
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/293oggenc --help and man oggenc differ about managed mode for bitrate switch2006-06-12T11:24:10Zw.haasoggenc --help and man oggenc differ about managed mode for bitrate switch```
hi,
oggenc --help says:
-b, --bitrate Choose a nominal bitrate to encode at. Attempt
to encode at a bitrate averaging this. Takes an
argument in kbps. This uses the bitrate managem...```
hi,
oggenc --help says:
-b, --bitrate Choose a nominal bitrate to encode at. Attempt
to encode at a bitrate averaging this. Takes an
argument in kbps. This uses the bitrate management
engine, and is not recommended for most users.
while man oggenc says:
-b n, --bitrate=n
Sets encoding to the bitrate closest to n (in
kb/s).
(nothing about the management engine)
and
--managed
Set bitrate management mode.
the part that -b uses the management engine by default seems to be wrong.
regards,
wernfried
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/91documentation doesn't mention gmake requirement2006-06-12T11:25:10Znisharfidocumentation doesn't mention gmake requirement```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neithe...```
comatoast@dymaxion: ~/cvsSandbox/ogg> make
Making all in src
Bad modifier: )
Unclosed variable specification
"Makefile", line 242: Need an operator
Fatal errors encountered -- cannot continue
*** Error code 1
unsurprisingly, neither $GZIP_ENV nor $TAR are defined in my shell.
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/libao/-/issues/240dlopen() fails upon loading plugins2006-06-12T11:25:17ZMichael Ritzertdlopen() fails upon loading plugins```
1) in contrast to my entry above this report concerns libao 0.8.3, not
0.8.2. bugzilla did not offer me to select this version. PLease fix the
corresponding form.
bug report:
after building ogg123 on my solaris7/sparc box i n...```
1) in contrast to my entry above this report concerns libao 0.8.3, not
0.8.2. bugzilla did not offer me to select this version. PLease fix the
corresponding form.
bug report:
after building ogg123 on my solaris7/sparc box i noticed that ogg123 showed
up only with the default drivers. i built the example program in libao's
doc subdirectory and noticed in a gdb session that the calls to dlopen()
failed. A research with google showed that the same problem has been
reported earlier for OpenBSD and for NetBSD. So i enforced the flag to the
dlopen() call to
#define DLOPEN_FLAG (RTLD_LAZY)
and the example program worked.
some thoughts to fix this:
the dlopen() problem occurs on OpenBSD, NetBSD, and possibly FreeBSD, and
it occurs on Solaris7 (and hence probably on most other svr4 systems)
On solaris boxes and the other commercial unices You have to deal with at
least two compilers.
So i suggest to enter a check into the configure script which tests for the
need of RTLD_LAZY or at least the system type and sets a preprocessor
symbol of, say, -DNEEDS_RTLD_LAZY according to the result of the test (or
the system type)
ao_private.h will be changed to check for NEEDS_RTLD_LAZY instead of OpenBSD
Thanks for writing this whole stuff!
Michael Ritzert
```Stan SeibertStan Seibert