Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2006-06-12T11:40:57Zhttps://gitlab.xiph.org/xiph/libao/-/issues/219libao rpm doesn't build/work on distributions w/o alsa (i.e. redhat)2006-06-12T11:40:57Znoalibao rpm doesn't build/work on distributions w/o alsa (i.e. redhat)```
The file libao.spec included in the libao distribution contains a
build-dependency on alsa-lib-devel, a package that is unavailable in several
major distributions. This prevents the libao package from being built and used
on for exam...```
The file libao.spec included in the libao distribution contains a
build-dependency on alsa-lib-devel, a package that is unavailable in several
major distributions. This prevents the libao package from being built and used
on for example redhat.
The src and binary rpms on www.vorbis.com also needs to be updated once this is
fixed.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/487MPD/mpg321 doesn't work with this mp32006-06-12T11:39:50ZstarzMPD/mpg321 doesn't work with this mp3```
OK, there's no 'Version 0.8.4' for libao in bugzilla so I couldn't put it as
0.8.4, so I just set it as CVS.
There is a problem in mpg321 & MPD (http://musicpd.org) with playing this file:
http://thelinuxshow.com/archives/2003/tls-1...```
OK, there's no 'Version 0.8.4' for libao in bugzilla so I couldn't put it as
0.8.4, so I just set it as CVS.
There is a problem in mpg321 & MPD (http://musicpd.org) with playing this file:
http://thelinuxshow.com/archives/2003/tls-11-25-2003.mp3
1) ALSA09 + 0.8.4 doesn't work
2) OSS + 0.8.4 does work
3) ALSA09 + 0.8.3 does work
4) OSS + 0.8.3 does work
5) ALSA09 + 0.8.3 + ao_alsa09.c from 0.8.4 doesn't work.
6) ALSA09 + 0.8.4 + ao_alsa09.c from 0.8.3 doesn't work
After all of this, I really don't know what the problem could be.
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/49Audible artefacts in oggenc output2006-06-12T11:39:43ZmccramerAudible artefacts in oggenc output```
Software: gcc 2.95.3/binutils 2.11.2/libc 2.1.3 CVS snapshot of the 15/16.
August.
Effect: Oggencing of a specific song (Klaus Schulze "P:T:O:") leads to
strong "plopp" and "ping" sounds in the resulting file. The wav file was ok
(c...```
Software: gcc 2.95.3/binutils 2.11.2/libc 2.1.3 CVS snapshot of the 15/16.
August.
Effect: Oggencing of a specific song (Klaus Schulze "P:T:O:") leads to
strong "plopp" and "ping" sounds in the resulting file. The wav file was ok
(checked).
Compiled the whole snapshot with/without different CFLAGS/CXXFLAGS settings.
The result was the same everytime, even the artefacts remains at the same
position/offset from the beginning of the file.
Unfortunatley the song is about 28 min. long.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/152MSVC project settings for ogg_static_d.lib cause linker errors when used with...2006-06-12T11:39:41ZGitlab BotMSVC project settings for ogg_static_d.lib cause linker errors when used with "Debug Multithreaded" libs```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL ...```
The project settings for ogg_static_d.lib default to "Debug Multithreaded
DLL". When I changed them to "Debug Multithreaded" to work with my
application, I still got linker errors that indicated something was linked with
the DLL libs. Specific errors:
Linking...
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _malloc already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _free already defined in libcmtd.lib
(dbgheap.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _memmove already defined in
libcmtd.lib(memmove.obj)
MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _realloc already defined in
libcmtd.lib(dbgheap.obj)
LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs;
use /NODEFAULTLIB:library
.\WinDebug/Game.exe : fatal error LNK1169: one or more multiply defined symbols
found
Error executing link.exe.
Cause: There are two files in the ogg_static project that are individually set
to use the "Debug Multithreaded DLL" libraries, and they do not change with the
project settings.
To fix: Open the ogg_static project with MSVC, go to Project->Settings, make
sure the active project ("Settings for:") is Win32Debug, select bitwise.c,
switch to the C++ tab, and hit the "Reset" button. This should not change the
file's settings, but it will set it to sync with the project settings, so that
changes to the entire Debug project will affect the individual file. Do the
same for framing.c.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/96genre tag parameter is now -G, but usage() of oggenc still points to -g2006-06-12T11:38:25Zxplogenre tag parameter is now -G, but usage() of oggenc still points to -g```
I've just (22/12/01) fetched the preRC3 vorbis set including oggenc and found
out that the parameter to set a genre at encodettime in oggenc was changed to -
G instead of -g. This change was documented in the manpage fine, however i...```
I've just (22/12/01) fetched the preRC3 vorbis set including oggenc and found
out that the parameter to set a genre at encodettime in oggenc was changed to -
G instead of -g. This change was documented in the manpage fine, however in the
programs usage() output it's still mentioned as -g.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/147Can't Use full filenames in oggenc since Vakor started committing afresh2006-06-12T11:37:34ZnisharfiCan't Use full filenames in oggenc since Vakor started committing afresh```
C:\>oggenc.postrc3 "D:\share\src\First Time\wav\track15.wav" --
output="D:\share\src\First Time\ogg\Battle Royal.ogg"
Opening with wav module: WAV file reader
Couldn't create directory "D:": Permission denied
ERROR: Could not creat...```
C:\>oggenc.postrc3 "D:\share\src\First Time\wav\track15.wav" --
output="D:\share\src\First Time\ogg\Battle Royal.ogg"
Opening with wav module: WAV file reader
Couldn't create directory "D:": Permission denied
ERROR: Could not create required subdirectories for output
filename "D:\share\src\First Time\ogg\Battle Royal.ogg"
the same error happens when I try to do the same at D:\ . However, when I run
the same command line from D:\cvs (an unrelated directory), I get the error
D:\cvs>oggenc.postrc3 "D:\share\src\First Time\wav\track15.wav" --
output="D:\share\src\First Time\ogg\Battle Royal.ogg"
Opening with wav module: WAV file reader
Couldn't create directory "D:": File exists
ERROR: Could not create required subdirectories for output
filename "D:\share\src\First Time\ogg\Battle Royal.ogg"
I'd bet this has something to do with the autocreate directory code that
Michael added; could this be tweaked to not try and overwrite the root
directory when using absolute paths?
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/486libogg2's bitpackers cannot be init. due to missing structs2006-06-12T11:35:35ZArc Rileylibogg2's bitpackers cannot be init. due to missing structs```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from o...```
In order to call oggpack_writeinit or oggpack_readinit you need to pass a oggpack_buffer, just
as you have to pass ogg_page and ogg_packet objects to other functions, however the
structure for oggpack_buffer has been removed from ogg2/ogg.h (only in ogginternal.h).
This needs to be fixed before any further work can go into py-ogg2 or libwrit.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/95cosmetic bug in oggenc -h (CVS)2006-06-12T11:34:14Zgregcosmetic bug in oggenc -h (CVS)```
-M, --max-bitrate Specify a maximum bitrate in kbps. Useful in
for streaming applications.
Remove the second instance of "in".
``````
-M, --max-bitrate Specify a maximum bitrate in kbps. Useful in
for streaming applications.
Remove the second instance of "in".
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/241Assertion failed2006-06-12T11:33:57ZjanAssertion failed```
``````
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/483Incorrect use of 'head' in autogen.sh2006-06-12T11:33:55Zrobert.mossIncorrect use of 'head' in autogen.sh```
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
``````
autogen.sh uses 'head -1' instead of 'head -n 1'. The former usage is
deprecated, and will not work on a system using the latest version of coreutils.
This will break the build. Attached is a patch which fixes this behaviour.
```https://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/positron/-/issues/379Detecting changes to files for sync2006-06-12T11:31:35Zapm13Detecting changes to files for sync```
It would be very useful if positron could detect file changes. Often times I will edit ID3 tags
between syncs (change genre, etc.) and would like those changes to appear on the neuros. This
could be accomplished either by naively...```
It would be very useful if positron could detect file changes. Often times I will edit ID3 tags
between syncs (change genre, etc.) and would like those changes to appear on the neuros. This
could be accomplished either by naively comparing the mtimes of the files, or even better by
using an rsync type algorithm for the sync (perhaps using pysync
http://freshmeat.net/projects/pysync/?topic_id=251%2C71%2C42%2C912 ).
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/478oggpackB not handling 9 bit values2006-06-12T11:29:55ZGhost UseroggpackB not handling 9 bit values```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the sa...```
There seems to be something screwy with the oggpackB implementation in libogg
1.1. I came across a problem with the theora setup header where if I write out
a value 2 as 9 bits (n_matricies-1) it gets read back as 32. Storing the same
value in 8 bits works. Also oggpackB_read(opb, 0) does not return 0 like
oggpack_read() does.
Unfortunately I've not been able to construct a simpler test case that
demonstrates the 9 bit issue, but I don't think this is a good sign:
running bitwise.c compiled with -D_V_SELFTEST :
[...LSb tests all ok...]
Small preclipped packing (MSb): ok.
Null bit call (MSb): looked at incorrect value!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/positron/-/issues/371Postitron crashes during rebuild2006-06-12T11:26:58ZManuel LoraPostitron crashes during rebuild```
manuel@localhost manuel $ positron rebuild
Creating empty databases...
pcaudio
failedhisi
audio
idedhisi
unidedhisi
Finding existing audio files on the Neuros...
Traceback (most recent call last):
File "/usr/bin/positron...```
manuel@localhost manuel $ positron rebuild
Creating empty databases...
pcaudio
failedhisi
audio
idedhisi
unidedhisi
Finding existing audio files on the Neuros...
Traceback (most recent call last):
File "/usr/bin/positron", line 175, in ?
main(sys.argv)
File "/usr/bin/positron", line 157, in main
cmd.run(config, myNeuros, remaining[1:])
File "/usr/lib/python2.2/site-packages/positron/cmd_rebuild.py", line 91, in r
un
silent=True)]
File "/usr/lib/python2.2/site-packages/positron/add_file.py", line 60, in gen_
filelist
allowed_types, silent))
File "/usr/lib/python2.2/site-packages/positron/add_file.py", line 60, in gen_
filelist
allowed_types, silent))
File "/usr/lib/python2.2/site-packages/positron/add_file.py", line 60, in gen_
filelist
allowed_types, silent))
File "/usr/lib/python2.2/site-packages/positron/add_file.py", line 40, in gen_
filelist
metadata = audiofile.detect(fullname)
File "/usr/lib/python2.2/site-packages/positron/audiofile.py", line 28, in det
ect
metadata = detect_func(filename)
File "/usr/lib/python2.2/site-packages/positron/audiofile.py", line 44, in det
ect_mp3
mp3info = MP3Info.MP3Info(f)
File "/usr/lib/python2.2/site-packages/positron/MP3Info.py", line 485, in __in
it__
self.genre = _genres[int(self.genre[1:-1])]
ValueError: invalid literal for int(): 17)(255
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/libao/-/issues/238FILENAME_MAX only 14 characters on HP-UX2006-06-12T11:25:58ZAlexander RossFILENAME_MAX only 14 characters on HP-UX```
HP-UX fails because in audio_out.c the code uses FILENAME_PATH. I think
either PATH_MAX from limits.h or use pathconf.
Also, SHARED_LIB_EXTENSION isn't set automatically. I'm not sure what
can be done without explicit
#ifdef _HPU...```
HP-UX fails because in audio_out.c the code uses FILENAME_PATH. I think
either PATH_MAX from limits.h or use pathconf.
Also, SHARED_LIB_EXTENSION isn't set automatically. I'm not sure what
can be done without explicit
#ifdef _HPUX_SOURCE
#endif
code.
Also, dlopen doesn't seem to work but hacking shl_open does. I don't really
know if it is worth the effort.
Cheers,
Ross
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/ogg/-/issues/464[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer poi...2006-06-12T11:25:54ZTim van Holder[bitwise.c: CVS HEAD] oggpack_writecopy_helper() incorrectly moves buffer pointer```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
an...```
In the HEAD (1.16) version of bitwise.c, the oggpack_writecopy_helper() function
bumps b->buffer (line 175) where previous versions bumped b->endbyte.
Since the 'buffer' field of an oggpack_buffer is an owned pointer when writing,
and is free()d in oggpack_writeclear(), this seems like a (fairly major) bug.
```Monty MontgomeryMonty Montgomeryhttps://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 Seiberthttps://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/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/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 Smith