Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:59:08Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/302Broken file on Vorbis website2017-04-08T10:59:08ZoktalBroken file on Vorbis website```
The file http://www.xiph.org/ogg/vorbis/doc/vorbisenc/reference.html is
advertised as the Vorbisenc reference manual, but it is in fact just an old
version of the Vorbisfile reference manual.
``````
The file http://www.xiph.org/ogg/vorbis/doc/vorbisenc/reference.html is
advertised as the Vorbisenc reference manual, but it is in fact just an old
version of the Vorbisfile reference manual.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/301Icecast leaking memory when serving dynamic xsl pages.2018-03-06T12:50:21ZlaustbnIcecast leaking memory when serving dynamic xsl pages.```
Icecast appears to be leaking memory every time it's serving a dynmically generated status page
(eg "status.xsl"). The bug is easily reproducible by continuously fetching status pages via a
script and watching icecast grow via ps o...```
Icecast appears to be leaking memory every time it's serving a dynmically generated status page
(eg "status.xsl"). The bug is easily reproducible by continuously fetching status pages via a
script and watching icecast grow via ps or top. I've seen icecast grow to 140+ MB overnight (while I
was running a script periodically to gather statistics from the status.xsl page - this is before I
realised there was a problem), at which point I killed it. It seems to leak around 4kb each time.
Serving static files out of the webroot directory does not result in a leak.
When I first
noticed the problem, I was running an old (three months probably) CVS version. I did a fresh
checkout and recompile last night, but the problem still remains.
I'm running Debian Linux
3.0, with a home compiled 2.2.20 kernel and Debian's default gcc 2.95.4. The machine x86, Pentium
III (Coppermine).
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/300encoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION2017-04-08T10:59:08Zggyepesiencoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -...```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -M 128 samples.raw
is the command line producing the error (samples.raw has length 819 200 bytes).
NOTE: encoding in VBR mode succeeds:
C:\oggtools>oggenc -r -R 22050 -b 32 -M 128 samples.raw
Enabling bitrate management engine
Encoding "samples.raw" to
"samples.ogg"
at average bitrate 32 kbps (no min, max 128 kbps),
using full bitrate management engine
Encoding [ 0m02s so far] |
crashes while
C:\oggtools>oggenc -r -R 22050 -b 32 samples.raw
Encoding "samples.raw" to
"samples.ogg"
at approximate bitrate 32 kbps (VBR encoding enabled)
Encoding [ 0m01s so far] -
Done encoding file "samples.ogg"
File length: 0m 09.0s
Elapsed time: 0m 01.0s
Rate: 9.2880
Average bitrate: 38.0 kb/s
succeeds.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/299HTTP response code not set when requesting /allstreams.txt2018-03-06T12:50:21ZaletHTTP response code not set when requesting /allstreams.txt```
Reading my log files and also the code it seems that client->respcode is not set
when /allstreams.txt is requested, and so it may contain anything which was in
memory at the time of the client creation (malloc). This gives completely...```
Reading my log files and also the code it seems that client->respcode is not set
when /allstreams.txt is requested, and so it may contain anything which was in
memory at the time of the client creation (malloc). This gives completely
erroneous HTTP status which may possibly confuse client software.
Solution : why not set client->respcode to 200 by default at client creation time ?
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/298Probably OBO error in command line handling2018-03-06T12:50:21ZaletProbably OBO error in command line handling```
Hi,
It seems that the strncpy function is used to copy the config filename
(currently at line 94 of main.c). The manual page says that this function may
not add the terminating nul byte if there's none in the source string. It seems...```
Hi,
It seems that the strncpy function is used to copy the config filename
(currently at line 94 of main.c). The manual page says that this function may
not add the terminating nul byte if there's none in the source string. It seems
it's possible to pass a filename which is longer than 256 bytes with no nul, and
later on strdup is called on this filename (config.c) which may lead to
arbitrary long memory allocation and maybe other problems (security?)
adding "filename[255] = '\0';" after the initial strncpy should solve the problem.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/296[PATCH] Runtime DLL used in Debug Mode2017-04-08T10:58:44ZGitlab Bot[PATCH] Runtime 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 "vorbis_static.dsp",
"vorbisenc_static.dsp" and "vorbisfile_static.dsp".
This is an update against the version in CVS on 6/12/02.
```Monty MontgomeryMonty Montgomeryhttps://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/vorbis-tools/-/issues/294oggdec writes RIFF header even in raw mode2002-12-07T12:19:36ZMalte Uhloggdec writes RIFF header even in raw mode```
A break statement is missing after the 'o' case when parsing the command line
options, thus causing the raw flag to get messed up when "-R something"
preceedes "-o somefile". This also applies to the long options.
Here's the trivial...```
A break statement is missing after the 'o' case when parsing the command line
options, thus causing the raw flag to get messed up when "-R something"
preceedes "-o somefile". This also applies to the long options.
Here's the trivial fix in context diff format:
*** oggdec.c.orig 2002-12-05 15:39:43.000000000 +0100
--- oggdec.c 2002-12-05 15:57:43.000000000 +0100
***************
*** 99,104 ****
--- 99,105 ----
break;
case 'o':
outfilename = strdup(optarg);
+ break;
case 'R':
raw = atoi(optarg);
break;
```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/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/290ftell() callback uses long instead ogg_int64_t2017-04-08T10:59:27Zpeterftell() callback uses long instead ogg_int64_t```
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
``````
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/289[PATCH] MacOS building of ogg & vorbis somewhat 'hacky'2009-04-19T20:20:08ZGitlab Bot[PATCH] MacOS building of ogg & vorbis somewhat 'hacky'```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses tw...```
This is my first submission, so bear with me. ;) I'm working with the Torque
Game Engine (garagegames.com), and have a number of Mac projects trying to use
oggvorbis audio support. It has been a bit of a pain.
os_types.h uses two explicit macros to shunt MacOS and MacOSX builds. I've
locally worked up a solution that does the 'proper' detection of compiler(s) as
an peer solution.
In addition, the other 'hacky' piece is that ogg uses a 'fake' sys/types.h file
in order to compile. But any project trying to build against just the base
headers will then fail under Codewarrior/Mac (under GCC/Project Builder, a real
sys/types.h exists...). My solution was to inline the types, which should be
safe on the Mac given any Codewarrior from the last few years.
I'd love to get this, and other, Mac-side enhancements checked into the
mainline tree to try to improve the 'Mac user experience'. (Other things I've
done, and could clean up for submission, include a Carbon-safe build.)
Regards,
David Chait
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/288Syntax error in code prevents building2017-04-08T10:58:44ZandreaskSyntax error in code prevents building```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in li...```
Version is assumed to be 1.0rc3 - Got the sources today from
http://www.xiph.org/ogg/vorbis/download/
The file libvorbis/lib/lookup_data.h contains the following define
#define INVSQ2EXP_LOOKUP_MIN -32
This is used later in libvorbis/lib/lookup.c like this
return INVSQ2EXP_LOOKUP[a-INVSQ2EXP_LOOKUP_MIN];
Note the missing space between 'a-' and the macro.
On my HP/PA-RISC, with the native compiler this causes an syntax error.
The expansion of the code above is
a--32
This is at least ambiguous: 'a-- 32' vs 'a- -32', and the first interpreation
truly is a syntax error.
Best solution: Change the define to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The parentheses prevent any misinterpretation of the value.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/286authentication always fails if configure --prefix=/usr2018-03-06T12:50:21Zdoctorkaedingauthentication always fails if configure --prefix=/usr```
If 1.3.11 or 1.3.12 are compiled with --prefix=/usr, icecast always says "Bad
Password" when trying to give it an audio source with IceS or shout.
If compiled without --prefix=/usr, this behavior goes away.
``````
If 1.3.11 or 1.3.12 are compiled with --prefix=/usr, icecast always says "Bad
Password" when trying to give it an audio source with IceS or shout.
If compiled without --prefix=/usr, this behavior goes away.
```Jack MoffittJack Moffitthttps://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/vorbis/-/issues/284libvorbis crash2017-04-08T10:58:44ZStephanlibvorbis crash```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compile...```
I compiled oggvorbis on IRIX 6.5. I tried the encoder example of vorbis. It
crashed (coredump) with a memory error. I then found the precompiled libraries
on freeware.sgi.com and installed them. Same result. Simply a crash. I compiled
again using electric fence just to find out that it complains about mmap.
What exactly do you need to know in order to find a solution. This is the first
time I use bugzilla and I'm quite sure the above is not sufficient.
```titihttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/281A patch for an alsa input module2019-04-19T11:32:53ZjchuA patch for an alsa input module```
``````
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/279error in use of qsort2017-04-08T10:58:44ZThomas Gerekeerror in use of qsort```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler...```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler
(watcom 11.0a) the decoder hangs in qsort called in lib/sharedbook.c. if an
extra compare is added, all is fine.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/278reencodes mono files as DOUBLY FAST stereo2019-04-19T11:32:53Zdoctorkaedingreencodes mono files as DOUBLY FAST stereo```
This is probably a libvorbis bug, since it shows up in gnometoaster, too.
Ices reencodes mono ogg files as DOUBLE-SPEED mp3s. Sounds terrible.
``````
This is probably a libvorbis bug, since it shows up in gnometoaster, too.
Ices reencodes mono ogg files as DOUBLE-SPEED mp3s. Sounds terrible.
```Brendan Cully Brendan Cully https://gitlab.xiph.org/xiph/icecast-ices/-/issues/277resampling problems2019-04-19T11:32:53Zjstrawresampling problems```
ices seg faults every time we try to run it with resampling. Vakor suggested
that it is a config problem, so I am going to paste configs here.
we don't know if it is an ices or icecast problem, if this is the wrong place,
sorry, ple...```
ices seg faults every time we try to run it with resampling. Vakor suggested
that it is a config problem, so I am going to paste configs here.
we don't know if it is an ices or icecast problem, if this is the wrong place,
sorry, please put it where it should reside.
--ices resample--
<?xml version="1.0"?>
<ices>
<background>0</background> <!-- run in background? (unimplemented) -->
<logpath>/tmp</logpath> <!-- where logs, etc go. -->
<logfile>ices.log</logfile>
<loglevel>4</loglevel> <!-- 1=error,2=warn,3=info,4=debug -->
<consolelog>0</consolelog> <!-- logfile is ignored if this is set to 1 -->
<stream>
<metadata>
<name>Freenode Radio</name>
<genre>Various</genre>
<description></description>
</metadata>
<input>
<module>oss</module>
<param name="rate">44100</param> <!-- samplerate -->
<param name="channels">2</param> <!-- number of channels -->
<param name="device">/dev/dsp</param> <!-- audio device -->
<param name="metadata">1</param>
</input>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>*************</password>
<mount>/wopn-verylowbitrate.ogg</mount>
<encode>
<quality>-1</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>1</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>11025</out-rate>
</resample>
</instance>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>************</password>
<mount>/wopn-modem.ogg</mount>
<encode>
<quality>-1</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>1</downmix>
<resample>
<in-rate>44100</in-rate>
<out-rate>22050</out-rate>
</resample>
</instance>
<instance>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<password>*****************</password>
<mount>/wopn-broadband.ogg</mount>
<encode>
<quality>2</quality>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<downmix>0</downmix>
</instance>
</stream>
</ices>
-- icecast config --
<icecast>
<location>Freenode Radio</location>
<admin>staff@wopn.org</admin>
<limits>
<clients>50</clients>
<sources>4</sources>
<threadpool>5</threadpool>
<client-timeout>60</client-timeout>
<header-timeout>30</header-timeout>
<source-timeout>30</source-timeout>
</limits>
<source-password>****</source-password>
<relay-password>****</relay-password>
<directory>
<touch-freq>5</touch-freq>
<server>
<host>yp.icecast.org</host>
<touch-freq>15</touch-freq>
</server>
</directory>
<hostname>marconi.wopn.org</hostname>
<port>*****</port>
<!--<bind-address>127.0.0.1</bind-address>-->
<!--<master-server>127.0.0.1</master-server>-->
<!--<master-server-port>8001</master-server-port>-->
<!--<master-update-interval>120</master-update-interval>-->
<!--<master-password>hackme</master-password>-->
<fileserve>1</fileserve>
<paths>
<basedir>/home/wopn</basedir>
<logdir>/home/wopn/icecast_logs</logdir>
<webroot>/home/wopn/public_html</webroot>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
</logging>
<security>
<chroot>0</chroot>
<!-- <changeowner>
<user>nobody</user>
<group>nogroup</group>
</changeowner> -->
</security>
</icecast>
```Michael SmithMichael Smith