Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2006-06-12T11:37:34Zhttps://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/vorbis/-/issues/304VorbisFile library crashs when ov_open/ov_test is called the 2nd time2017-04-08T10:59:27ZyuriVorbisFile library crashs when ov_open/ov_test is called the 2nd time```
There is a problem with the VorbisFile library. It only works when I open an
OGG file for
the 1st time. After I closed the file and try to open another one or the same
it crashs. It seems it applies to the use of either ov_open or ...```
There is a problem with the VorbisFile library. It only works when I open an
OGG file for
the 1st time. After I closed the file and try to open another one or the same
it crashs. It seems it applies to the use of either ov_open or ov_test
functions or their combination.
I wrote a test app that illustrates the bug. It crashs with a message
"Unmapped memory exception". It's available at
http://home.earthlink.net/~yurigulyaev/oggvorbisproject32.sit.hqx
My platform is Mac OS 9.2 and CodeWarrior 8.0. I got the same result with
CodeWarrior 7.0.
From what I read on the net I see that this bug exists on other platforms
too.
BTW, I had to compile shared libs on my own because the OggVorbis
SDK for Mac OS
comes with shared libs that don't export any functions and thus unusable.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2338SSL support on Ubuntu 18.042019-01-26T10:42:02ZSimon CechacekSSL support on Ubuntu 18.04Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get I...Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get INFO connection/get_ssl_certificate No SSL capability` message, I pre-installed OpenSSL befory icecast installation."
any Idea how to fix this?
I also tried to build by Icecast from the source with the custom path ovf openssl pramater enabled (just put there the default openssl path) and it worked, but this icecast is installed as an app and not as a service, so don't how to reload config without dropping listeners (i need to add relays withour restarting the server as it will server as a proxy).
Thanks for all your time!https://gitlab.xiph.org/xiph/xiph-qt/-/issues/1126Playback of Ogg Theora file stalls2007-08-26T18:45:49ZflynPlayback of Ogg Theora file stallsI have a 700MB Ogg Theora video that I wish to play using Apple's QuickTime player. I have installed 0.1.5 of the Xiph QuickTime components. The video plays fine using Mac OS X 10.4.8/VLC and Linux/totem/gstreamer. However, when I loa...I have a 700MB Ogg Theora video that I wish to play using Apple's QuickTime player. I have installed 0.1.5 of the Xiph QuickTime components. The video plays fine using Mac OS X 10.4.8/VLC and Linux/totem/gstreamer. However, when I load it using Apple's QuickTime player, the player stalls for several minutes before the video is played. The pause is 7 minutes long. During this time, the QuickTime player does not respond to user input. Once the player starts responding to user input again, it will play the video.Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/160Win32 Vorbis Tools is missing documentation2002-08-09T16:22:14ZtoddWin32 Vorbis Tools is missing documentation```
I didn't even know there was any documentation for these, but I heard from
Segher Boessenkool that there are supposed to at least be man pages for each of
the tools. However, in the 1.0rc3 ZIP file, there are none. Just the
exec...```
I didn't even know there was any documentation for these, but I heard from
Segher Boessenkool that there are supposed to at least be man pages for each of
the tools. However, in the 1.0rc3 ZIP file, there are none. Just the
executables.
```Jack MoffittJack Moffitthttps://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/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/xiph-qt/-/issues/846No audio at all2007-03-23T23:19:13ZGitlab BotNo audio at allI searched through the database, but nothing there really helped me.
I just installed the AC3 codec for A52 audio in Quicktime, and just got all my video working, then installed this ogg codec and now nothing works. At least, no audio ...I searched through the database, but nothing there really helped me.
I just installed the AC3 codec for A52 audio in Quicktime, and just got all my video working, then installed this ogg codec and now nothing works. At least, no audio works. How do I completely remove it? I removed just the /library/quicktime .component file, but what else do I need to remove?Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/168%n to -n should be more flexible2002-03-22T14:45:39Zjdahlin%n to -n should be more flexible```
%n should support something like this:
%2n -> ' 1', ' 2', ..., '10', '11' (always 2 in width)
%02n -> '01', '02', ..., '10', '11' (always 2 in width, pad with zeros)
%-2n -> '1 ', '2 ', ..., '10,, '11' (always 2 in width, align lef...```
%n should support something like this:
%2n -> ' 1', ' 2', ..., '10', '11' (always 2 in width)
%02n -> '01', '02', ..., '10', '11' (always 2 in width, pad with zeros)
%-2n -> '1 ', '2 ', ..., '10,, '11' (always 2 in width, align left)
I feel that %0xN is most important of the three.
```Michael SmithMichael Smithhttps://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/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/1138nothing gets installed2008-11-14T17:19:21ZStephan Jacobnothing gets installedI can't install any of your downloads onto my OS X 10.4.8 machine ... the installer starts, but then it doesn't offer a destination ...I can't install any of your downloads onto my OS X 10.4.8 machine ... the installer starts, but then it doesn't offer a destination ...Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/172Oggenc RC3 Cannot handle Very Long Pathnames2002-04-07T21:14:58ZkoranskyOggenc RC3 Cannot handle Very Long Pathnames```
I have found that Oggenc.exe does not run if the pathnames to the files are
very long. I have double checked with LAME and MPEG Plus, they run with no
problem. Very long pathnames are needed with my music collection for detailed
d...```
I have found that Oggenc.exe does not run if the pathnames to the files are
very long. I have double checked with LAME and MPEG Plus, they run with no
problem. Very long pathnames are needed with my music collection for detailed
descriptions.
```Michael SmithMichael Smithhttps://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/xiph-qt/-/issues/1117Opening OGG container containing vorbis audio stream and xvid video stream wi...2007-03-24T01:05:27ZGitlab BotOpening OGG container containing vorbis audio stream and xvid video stream will only yield a quicktime file with audio trackWhen opening an ogm container file that contains 'XiVs' Vorbis audio stream and 'XVID' video stream using xiph-qt 0.15 or current svn build [12311], it will only return a quicktime movie with the audio trackWhen opening an ogm container file that contains 'XiVs' Vorbis audio stream and 'XVID' video stream using xiph-qt 0.15 or current svn build [12311], it will only return a quicktime movie with the audio trackArek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/173oggenc ignores bitrate setting2002-03-27T06:54:03Zflifsonoggenc ignores bitrate setting```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening...```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening with wav module: WAV file reader
Encoding "11_wrong_em_boyo.ogg" [ 99.9%] [ 0m00s remaining] \
Done encoding file "11_wrong_em_boyo.ogg"
File length: 3m 13.0s
Elapsed time: 0m 56.9s
Rate: 3.3988
Average bitrate: 347.9 kb/s
[flifson@asgard london_calling]$ oggenc -v
OggEnc v0.8 (libvorbis rc2)
I'm using 0.8rc2. Does this not have bitrate limits enabled?
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/230vorbis shared library not built on beos2017-04-08T10:58:44Zshattyvorbis shared library not built on beos```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefin...```
When compiling everything goes smoothly except that a small warning is displayed:
warning: undefined symbols not allowed in beos shared libraries
And libvorbis.so is not built. (libvorbis.a is built) The fix is to add
-no-undefined to the libtool link arguments. (in Makefile.am/Makefile.in)
old version:
libvorbis_la_LDFLAGS = -version-info @V_LIB_CURRENT@:@V_LIB_REVISION@:@V_LIB_AGE@
new version:
libvorbis_la_LDFLAGS = -no-undefined -version-info
@V_LIB_CURRENT@:@V_LIB_REVISION@:@V_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.)
An additional note: libvorbisenc and libvorbisfile both have undefined symbols
and can not be built as shared libraries on beos. They must be linked
statically. They are made as static libraries in the current version and they
work fine if linked to statically.
Andrew Bachmann
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2342Security vulnerability: buffer overflow in URL authentication allows remote c...2018-11-05T08:00:08ZNick RolfeSecurity vulnerability: buffer overflow in URL authentication allows remote code executionHello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeo...Hello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeof(post) - post_offset,
"&%s%s=%s",
url->prefix_headers ? url->prefix_headers : "",
cur_header, header_valesc);
```
If the string to be written is longer than `sizeof(post) - post_offset`, `snprintf` will truncate the string, but will return *the number of bytes it would have written if the buffer were large enough*. This means that `post_offset` is incremented to be larger than `sizeof(post)`, and any subsequent iteration of the loop will write beyond the end of the buffer.
## Proof of concept
I configured a mount using URL authentication that forwards two headers:
```
<mount type="normal">
<mount-name>/auth_url.ogg</mount-name>
<authentication type="url">
<option name="headers" value="x-foo,x-bar"/>
...
</authentication>
</mount>
```
My Icecast server was running on localhost, port 8000, and then I ran the following Bash script:
```
foo=$(python -c "print('a' * 3950)")
bar=123456789123456789
curl -H "x-foo: $foo" -H "x-bar: $bar" http://localhost:8000/auth_url.ogg
```
The `x-foo` header was truncated, but it caused `postoffset` to be incremented beyond the size of the buffer, as described above. The subsequent handling of the `x-bar` header overwrote other stack contents, causing my Icecast server to crash:
```
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)
```
By controlling the length of the `x-foo` header, and the contents of the `x-bar` header, it seems likely that remote code execution would be possible.
## Related bug
Our automated analysis highlighted this bug, and another similar misuse of `snprintf` in `format_prepare_headers` in `format.c`, but I did not investigate whether that one would be exploitable.
Those analysis results are visible here: https://lgtm.com/projects/g/xiph/Icecast-Server/alerts/?mode=tree&ruleFocus=1505913226124
## Disclosure
Please let me know when you have fixed the vulnerability, so that we can coordinate our disclosure with yours. For reference, here is a link to our vulnerability disclosure policy: https://lgtm.com/security
Thanks!
--Nick Rolfe, Semmle Security Research TeamThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/1121Readme gives incorrect installation instructions2008-10-31T17:37:20Zdesertstrm2002Readme gives incorrect installation instructionsThe file itself works perfectly. All of my .ogg music files are now playing. However, the installation instructions tell Windows users to place the XiphQT.qtx file into the QTComponents folder. That is incorrect. It must be placed in...The file itself works perfectly. All of my .ogg music files are now playing. However, the installation instructions tell Windows users to place the XiphQT.qtx file into the QTComponents folder. That is incorrect. It must be placed into the QTSystem folder. Cheers!!
-KyleArek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/186encoder stops when encoded file gets larger than RAM memory2002-04-22T08:56:57ZGitlab Botencoder stops when encoded file gets larger than RAM memory```
Hi,
i sometimes real-time-encode long radio streams by piping the wav-stream to
oggenc's standard input.
but for very long sessions this does not work, because the encoded file cannot
get larger than my physical RAM memory (in my c...```
Hi,
i sometimes real-time-encode long radio streams by piping the wav-stream to
oggenc's standard input.
but for very long sessions this does not work, because the encoded file cannot
get larger than my physical RAM memory (in my case 192MB ram, whitch is about
220 minutes of music).
it would be nice, if one could encode music of about 24 hours without
having 1,4 Gig of memory available.
```Michael SmithMichael Smith