Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2019-03-04T15:52:48Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1766vorbis_granule_time(): invalid integer constant2019-03-04T15:52:48ZJens Aytonvorbis_granule_time(): invalid integer constantvorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, ot...vorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, otherwise 0x7ffffffffLL.
This error is found in the 1.3.2 release and the current trunk. It was introduced in r17562.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/497Vorbis_I_spec.html needs updating2017-04-08T11:08:16ZKyungjoon LeeVorbis_I_spec.html needs updating```
http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html is outdated. On line 2166, it
mentions the old MIME type:
The correct MIME type of any Ogg file is <tt class="literal">application/x-
ogg</tt>.
CVS vorbis/doc/xml/a1-encapsulation_o...```
http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html is outdated. On line 2166, it
mentions the old MIME type:
The correct MIME type of any Ogg file is <tt class="literal">application/x-
ogg</tt>.
CVS vorbis/doc/xml/a1-encapsulation_ogg.xml and
http://xiph.org/ogg/vorbis/doc/vorbis-ogg.html are up-to-date.
```https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1085vorbiscomment doesn't preserve file permission bits2006-12-28T18:44:36Zcw264701vorbiscomment doesn't preserve file permission bitsI'm guessing that the utility actually creates a new file when tacking on the vorbis comment, which causes the permissions to be set like the default umask specifies.
There is another ticket, #136, describing the same problem, which was...I'm guessing that the utility actually creates a new file when tacking on the vorbis comment, which causes the permissions to be set like the default umask specifies.
There is another ticket, #136, describing the same problem, which was closed nearly five years ago. Apparently the bug has worked it's way back in. I'm on Ubuntu Linux 6.06, which provides _vorbiscomment_ via the _vorbis-tools_ package; this package is marked as version 1.1.1.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1439vorbiscomment gives a SIGSEGV (segmentation fault) with --tag2008-10-15T22:02:04Zjcreighvorbiscomment gives a SIGSEGV (segmentation fault) with --tagI expected --tag to work exactly like -t. Instead, it causes a segfault whenever it appears in the command line.
```
[from SVN checkout of R15399]
~/src/vorbis-tools/vorbiscomment$ ./vorbiscomment --version
vorbiscomment from vorbis-too...I expected --tag to work exactly like -t. Instead, it causes a segfault whenever it appears in the command line.
```
[from SVN checkout of R15399]
~/src/vorbis-tools/vorbiscomment$ ./vorbiscomment --version
vorbiscomment from vorbis-tools 1.3.0
~/src/vorbis-tools/vorbiscomment$ ./vorbiscomment --tag
Segmentation fault
~/src/vorbis-tools/vorbiscomment$ ./vorbiscomment -t
./vorbiscomment: option requires an argument -- t
vorbiscomment from vorbis-tools 1.3.0
by the Xiph.Org Foundation (http://www.xiph.org/)
<snip usage>
```
I realize it's incorrect to call --tag with no arguments, but the bug manifests with or without an argument. It appears to be somewhere in the option parsing:
```
~/src/vorbis-tools/vorbiscomment$ gdb ./vorbiscomment
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) run --tag
Starting program: /home/jason/src/vorbis-tools/vorbiscomment/vorbiscomment --tag
Program received signal SIGSEGV, Segmentation fault.
0x00007f033f96e050 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0x00007f033f96e050 in strlen () from /lib/libc.so.6
#1 0x00007f033f96dd86 in strdup () from /lib/libc.so.6
#2 0x00000000004038c4 in parse_options (argc=2, argv=0x7fff48512aa8, param=0x22c0050) at vcomment.c:524
#3 0x0000000000403dd6 in main (argc=2, argv=0x7fff48512aa8) at vcomment.c:176
(gdb)
```
I was able to reproduce this bug with trunk (revision 15399) and 1.2.0. This is on amd64 box running debian testing.
IvoIvohttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1098vorbiscomment insists filename arguments come last2008-02-16T00:39:00Zpwberryvorbiscomment insists filename arguments come lastThere is no way to specify the filename arguments (what are called file.ogg, in.ogg and out.ogg in the manpage) anywhere on the command line other than last. This makes it rather difficult to use the program with xargs where the input to...There is no way to specify the filename arguments (what are called file.ogg, in.ogg and out.ogg in the manpage) anywhere on the command line other than last. This makes it rather difficult to use the program with xargs where the input to xargs is used to specify comments.
I'd suggest adding --source and --target options that allow you to specify these before the other options, in the same way cp and mv let you specify the target directory with --target-directory.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1755vorbiscomment should allow for delimiter other than newline2018-01-22T04:18:38ZGitlab Botvorbiscomment should allow for delimiter other than newlineWhen vorbiscomment reads from a file, it would be nice if it could use a delimiter other than newline. That way a metadata field value could have a newline (which is the case for lyrics, for instance).
I wrote a patch that does just tha...When vorbiscomment reads from a file, it would be nice if it could use a delimiter other than newline. That way a metadata field value could have a newline (which is the case for lyrics, for instance).
I wrote a patch that does just that. I tested it on version 1.2, but it seems that newer versions of vorbiscomment don't change anything significant.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1452vorbiscomment should support viewing/editing comments on secondary Vorbis str...2018-01-22T04:18:37Zmgoldvorbiscomment should support viewing/editing comments on secondary Vorbis streamsIf an Ogg file contains multiple multiplexed Vorbis streams, vorbiscomment always works with the first one. There should be an option to view or edit comments on a secondary stream (probably selected by serial number). An option to list ...If an Ogg file contains multiple multiplexed Vorbis streams, vorbiscomment always works with the first one. There should be an option to view or edit comments on a secondary stream (probably selected by serial number). An option to list all supported streams would be helpful if this was implemented.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/655vorbiscomment toto.mp3 destroys the file2005-09-02T19:51:28ZGitlab Botvorbiscomment toto.mp3 destroys the fileWhen mistakenly using vorbiscomment to change the tags of an mp3 file :
vorbiscomment -w toto.mp3
the file toto.mp3 got destroyed! Not nice...
Bernard Helmstetter
When mistakenly using vorbiscomment to change the tags of an mp3 file :
vorbiscomment -w toto.mp3
the file toto.mp3 got destroyed! Not nice...
Bernard Helmstetter
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1381vorbiscomment: crash on ogg files with malformed comments2011-05-07T13:43:25Zthogervorbiscomment: crash on ogg files with malformed commentsWhile investigating vorbis changeset https://trac.xiph.org/changeset/14502 , I noticed that vorbiscomment crashes (SEGVs on out-of-bounds read) on ogg files with crafted comments (if file claims to contain large number of comments or lon...While investigating vorbis changeset https://trac.xiph.org/changeset/14502 , I noticed that vorbiscomment crashes (SEGVs on out-of-bounds read) on ogg files with crafted comments (if file claims to contain large number of comments or long individual comment).
Test cases attached.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2319vorbiscomment: remove specific tags2018-01-22T04:18:25ZGitlab Botvorbiscomment: remove specific tagsIt should be possible to remove tags with `vorbiscomment`.
Suggested parameter format:
1. Remove a tag with a certain value, e.g. one of several ARTISTs in the file
`$ vorbiscomment -a file.ogg --rm ARTIST=foo`
2. Remove all art...It should be possible to remove tags with `vorbiscomment`.
Suggested parameter format:
1. Remove a tag with a certain value, e.g. one of several ARTISTs in the file
`$ vorbiscomment -a file.ogg --rm ARTIST=foo`
2. Remove all artist tags
`$ vorbiscomment -a file.ogg --rm ARTIST`
3. Remove an artist and add add two new (e.g. when splitting a comma separated artist into two artist fields)
`$ vorbiscomment -a file.ogg --rm ARTIST="Foo, Bar" -t ARTIST=Foo -t ARTIST=Bar`
Considerations:
* It is possible that a tag with the same value exists multiple times (2x `ARTIST=foo`). When issuing the command to remove `ARTIST=foo`, both should be removed in my eyes.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/468vorbisenc api docs out of date2020-06-23T17:20:43ZGhost Uservorbisenc api docs out of date```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentat...```
The vorbisenc api documentation needs to be updated to describe the new managed
mode invocation.
A link to how to submit data for actual encoding would be good to, but that's
properly part of libvorbis, which still has no documentation at all.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/266vorbisfile and vorbisenc don't build as shared libraries2017-04-08T10:59:08Zshattyvorbisfile and vorbisenc don't build as shared libraries```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform...```
Because the vorbisfile and vorbisenc libraries refer to symbols from the vorbis
lib they error out with undefined symbols during linkage as a shared library.
The attached patch fixes this problem. This patch should be cross platform. It
may help other platforms to build these libraries as well. (cygwin?)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/551vorbisfile documentation incomplete2017-04-08T11:08:16ZJack Moffittvorbisfile documentation incomplete```
missing all the _lap() functions, ov_read_float() etc.
``````
missing all the _lap() functions, ov_read_float() etc.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2327vorbisfile free of uninitialized memory if seek fails2019-01-28T23:01:57ZGitlab Botvorbisfile free of uninitialized memory if seek failsIn vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a...In vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a bit more:
https://github.com/SFML/SFML/issues/1241Thomas DaedeThomas Daedehttps://gitlab.xiph.org/xiph/vorbis/-/issues/853vorbisfile is still deadlockable with I/O callback failures2017-04-08T10:59:27ZGitlab Botvorbisfile is still deadlockable with I/O callback failuresMy automated I/O failure scenario tester reliably deadlocks vorbisfile. Multiple callback return value checks are missing from the code, e.g. in _seek_helper; in particular case I've backtracked, _get_prev_page() enters infinite loop whe...My automated I/O failure scenario tester reliably deadlocks vorbisfile. Multiple callback return value checks are missing from the code, e.g. in _seek_helper; in particular case I've backtracked, _get_prev_page() enters infinite loop when seeking/reading fails. Let alone the fact that detection of seekable/nonseekable streams is a huge hack abusing seek callback return value rather rather than letting caller control it properly.Monty MontgomeryMonty Montgomeryhttps://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/ogg/-/issues/2228vorbisfile.c function ov_pcm_total add const to OggVorbis_File *2017-08-26T14:29:54Zirov13vorbisfile.c function ov_pcm_total add const to OggVorbis_File *subjsubjMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1236vorbisfile.h causes compiler warnings in client code2017-04-08T10:59:27ZGitlab Botvorbisfile.h causes compiler warnings in client codeAny code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_...Any code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_DEFAULT, OV_CALLBACKS_NOCLOSE, OV_CALLBACKS_STREAMONLY and OV_CALLBACKS_STREAMONLY_NOCLOSE.
Many developers like to compile with warnings turned on and many even like to use -Werror (which turns warnings into errors) during development. However, any code that includes <vorbisfile.h> cannot be commpiled with -Werror.
Monty's comment in the file says that these structs are defined as static as a workaround required on windows. Supporting windows is a good thing, but the current solution is not good enough.
One possible solution would be to enclose the definitions of these structs inside:
```
#ifdef EXPOSE_OV_CALLBACKS
#endif
```
People who use these structs can then define EXPOSE_OV_CALLBACKS before including vorbisfile.h.
It would be interesting to hear from windows developers who might be able to come up with other possible solutions to this problem.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1965vorbisfile: fclose not always called by ov_clear2017-11-01T04:49:44Ztangobravovorbisfile: fclose not always called by ov_clearI don't know if this is a bug in the documentation or in the implementation.
The comment in [/browser/trunk/vorbis/lib/vorbisfile.c#L1058](../tree/master//browser/trunk/vorbis/lib/vorbisfile.c#L1058) suggests ov_test followed by ov_clea...I don't know if this is a bug in the documentation or in the implementation.
The comment in [/browser/trunk/vorbis/lib/vorbisfile.c#L1058](../tree/master//browser/trunk/vorbis/lib/vorbisfile.c#L1058) suggests ov_test followed by ov_clear should close the file, but that currently doesn't happen in the error case.
[Line 915](../tree/master//trunk/vorbis/lib/vorbisfile.c#L915) sets vf->datasource to NULL
Then whenever ov_clear is called (either in the following line, or by the user) fclose is not called due to the check in [line 975](../tree/master//trunk/vorbis/lib/vorbisfile.c#L975).
The workaround in my calling code looks like this:
```
FILE * test_file = NULL;
test_file = fopen(filename.c_str(), "rb");
if(test_file == NULL)
return false;
OggVorbis_File test_ovfile;
int res = ov_test(test_file, &test_ovfile, NULL, 0);
// ov_clear is supposed to close the file but for some ov_test code paths
// this doesn't work, as the internal file pointer is set NULL. We'll do
// the fclose ourselves to be sure
fclose(test_file);
test_ovfile.datasource = NULL;
ov_clear(&test_ovfile);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2424WARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.c...2021-12-03T20:32:49ZAlex SirroshWARN connection/get_ssl_certificate Invalid cert file /home/icecast/icecast.certkeyVersion: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com...Version: icecast-2.4.4-2.1.x86_64 (opensuse)
Cert issuer: LetsEncrypt
File icecast.certkey is world-readable and contains concatenated fullchain.pem and a private key.
P.S.: Found a somewhat related issue on [github](https://github.com/AzuraCast/AzuraCast/issues/2692)