Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2008-02-16T00:39:00Zhttps://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/1097CURLOPT_MUTE deprecated and removed from recent curl versions2006-12-10T14:47:40ZgtgbrCURLOPT_MUTE deprecated and removed from recent curl versionsUsing recent version of curl, vorbis-tools cannot build successfully:
```
ogg123/http_transport.c: In function `set_curl_opts':
ogg123/http_transport.c:119: error: `CURLOPT_MUTE' undeclared (first use in this function)
```
For backward...Using recent version of curl, vorbis-tools cannot build successfully:
```
ogg123/http_transport.c: In function `set_curl_opts':
ogg123/http_transport.c:119: error: `CURLOPT_MUTE' undeclared (first use in this function)
```
For backwards compatibility, I suggest a change in ogg123/http_transport.c to make it look like this (simply add #ifdefs:)
{{{
[...]
if (inputOpts.ProxyTunnel)
curl_easy_setopt (handle, CURLOPT_HTTPPROXYTUNNEL, inputOpts.ProxyTunnel);
*/
#ifdef CURLOPT_MUTE
curl_easy_setopt(handle, CURLOPT_MUTE, 1);
#endif /* CURLOPT_MUTE */
curl_easy_setopt(handle, CURLOPT_ERRORBUFFER, private->error);
[...]
}}
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1092vorbis-tools doesn't compile ogg123 if libcurl is linked against c-ares2006-12-10T15:02:19Zhanvorbis-tools doesn't compile ogg123 if libcurl is linked against c-aresThis is what my libcurl libs look like:
```
~% pkg-config --libs libcurl
-lcurl -lcares -lidn -lssl -lcrypto -ldl -lz
```
But the vorbis-tools configure blindly assumes CURL_LIBS='-lcurl' will do.This is what my libcurl libs look like:
```
~% pkg-config --libs libcurl
-lcurl -lcares -lidn -lssl -lcrypto -ldl -lz
```
But the vorbis-tools configure blindly assumes CURL_LIBS='-lcurl' will do.Michael SmithMichael Smithhttps://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/1008[PATCH] Adding skeleton support in oggenc2009-04-19T20:11:04ZGitlab Bot[PATCH] Adding skeleton support in oggencThe attached patch with this ticket add supports for skeleton meta data output support in oggenc. The feature is disabled by default and can be enabled by using either -k or --skeleton switch.The attached patch with this ticket add supports for skeleton meta data output support in oggenc. The feature is disabled by default and can be enabled by using either -k or --skeleton switch.IvoIvohttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/982ogg123 does not play ogg file with also theora video2008-05-30T21:07:51ZGitlab Botogg123 does not play ogg file with also theora videoAnd says this:
Error opening Experience ubuntu.ogg using the oggvorbis module. The file may be corrupted.And says this:
Error opening Experience ubuntu.ogg using the oggvorbis module. The file may be corrupted.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/917[PATCH] ogg123's -k option should only skip audio from the
1st file on the co...2009-04-19T20:19:14Zaquegg[PATCH] ogg123's -k option should only skip audio from the
1st file on the command lineWhen using the -k (--skip) option, ogg123 currently
skips audio from each file on the command line. I
think it should only skip for the 1st file. Here is
the proposed fix to ogg123.c:
```
/* Skip over audio */
if (options.seekpos >...When using the -k (--skip) option, ogg123 currently
skips audio from each file on the command line. I
think it should only skip for the 1st file. Here is
the proposed fix to ogg123.c:
```
/* Skip over audio */
if (options.seekpos > 0.0) {
if (!format->seek(decoder, options.seekpos,
DECODER_SEEK_START)) {
status_error(_("Could not skip %f seconds of
audio."), options.seekpos);
if (audio_buffer != NULL)
buffer_thread_kill(audio_buffer);
return;
}
options.seekpos = 0.0; <--- Please add this line.
}
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/911OggEnc produces bad results with 32-bit IEEE float WAV input2008-08-25T03:39:39ZmwhitlockOggEnc produces bad results with 32-bit IEEE float WAV inputThe title pretty much says it all. I have a 5.1-channel WAVEFORMATEXTENSIBLE file with 32-bit IEEE floating point samples. OggEnc interprets the format incorrectly. It produces a 6-channel Vorbis file that has all kinds of weird noise...The title pretty much says it all. I have a 5.1-channel WAVEFORMATEXTENSIBLE file with 32-bit IEEE floating point samples. OggEnc interprets the format incorrectly. It produces a 6-channel Vorbis file that has all kinds of weird noise in it.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/880[PATCH] vorbiscomment and oggenc man page typos2006-12-09T00:30:38Zschizo[PATCH] vorbiscomment and oggenc man page typosThis includes 4 oggenc.1 fixes from A Costa <agcosta@gis.net> and 2 other fixes that may have already been submitted but don't appear to have been applied at svn.xiph.org.This includes 4 oggenc.1 fixes from A Costa <agcosta@gis.net> and 2 other fixes that may have already been submitted but don't appear to have been applied at svn.xiph.org.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/879[PATCH] vorbis-tools not built with LFS2006-12-09T00:50:26Zschizo[PATCH] vorbis-tools not built with LFSvorbis-tools builds without largefile support. I suggest this patch:
Index: vorbis-tools-1.1.1/configure.ac
===================================================================
--- vorbis-tools-1.1.1.orig/configure.ac 2005-06-27 ...vorbis-tools builds without largefile support. I suggest this patch:
Index: vorbis-tools-1.1.1/configure.ac
===================================================================
--- vorbis-tools-1.1.1.orig/configure.ac 2005-06-27 05:25:51.000000000 -0400
+++ vorbis-tools-1.1.1/configure.ac 2006-03-26 19:41:34.404157135 -0500
@@ -31,6 +31,8 @@
ALL_LINGUAS="be cs da es fr hr hu nl ro ru sv uk"
AM_GNU_GETTEXT
+AC_SYS_LARGEFILE
+
dnl --------------------------------------------------
dnl Set build flags based on environment
dnl --------------------------------------------------
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/869would be nice if oggenc would accept an ogg file as input2008-02-18T15:45:17Zeddiewould be nice if oggenc would accept an ogg file as inputWould be nice if I could "re-encode" and ogg file like this
oggenc myogg.ogg -o mynewogg.ogg -q 3
and have it retain all the metadata information in the original ogg file.
Would be nice if I could "re-encode" and ogg file like this
oggenc myogg.ogg -o mynewogg.ogg -q 3
and have it retain all the metadata information in the original ogg file.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/860[PATCH] Problem with locale detection2006-12-09T01:53:38ZGitlab Bot[PATCH] Problem with locale detectionCONFIG:
+ Linux-Slackware 10.2
+ libvorbis-1.1.2
+ libogg-1.1.3
Hello,
I have problem with accented characters. In one hand, when I write a tag with accent using vorbiscomment, accented characters are replaced with "#" in the output. ...CONFIG:
+ Linux-Slackware 10.2
+ libvorbis-1.1.2
+ libogg-1.1.3
Hello,
I have problem with accented characters. In one hand, when I write a tag with accent using vorbiscomment, accented characters are replaced with "#" in the output. In the other hand, when I read previous tagged files -- wich are read fine by my music player -- with accent, ogginfo (or vorbiscomment -l) replace accented characters with "?".
I downgraded to vorbis-tools-1.0.1 (from Slackware 10.1) and everything works fine. I guess it's a global problem of locale detection (FR_fr@euro, in my case), because I saw the output of 'vorbiscomment -h' was in French with version 1.0.1 and in English with version 1.1.1.
Best regards,
Seb.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/850oggdec -o - test.ogg | oggenc -q 9 -o testSmall.ogg -2006-12-10T13:16:17ZGitlab Botoggdec -o - test.ogg | oggenc -q 9 -o testSmall.ogg -would be nice is this was added to the examples in the man page since i am sure many want it and not quickly obviously scanning the man page unless you read the fine print. the unobvious part is how to send to stdout from oggdec, though ...would be nice is this was added to the examples in the man page since i am sure many want it and not quickly obviously scanning the man page unless you read the fine print. the unobvious part is how to send to stdout from oggdec, though it is mentioned in one of the first paragraphs
oggdec -o - test.ogg | oggenc -q 9 -o testSmall.ogg -Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/832Version strings out-of-sync with distribution version2006-12-17T07:33:15ZGitlab BotVersion strings out-of-sync with distribution versionThe version strings on the vorbis tools seem to be out-of-sync with the packaged version numbers. -v reports 'v1.0.1' in most of the tools; I'm not sure if this is on purpose, but it makes sanity check like "did I install it properly" n...The version strings on the vorbis tools seem to be out-of-sync with the packaged version numbers. -v reports 'v1.0.1' in most of the tools; I'm not sure if this is on purpose, but it makes sanity check like "did I install it properly" not as useful.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/828ogginfo crash2007-06-17T08:55:30ZGitlab Botogginfo crashogginfo crashes on me when scanning a certain ogg file.
the result follows:
```
Processing file "Piste audio 01.ogg"...
Note: Stream 1 has serial number 0, which is legal but may cause problems with s ome tools.
New logical stream (#1...ogginfo crashes on me when scanning a certain ogg file.
the result follows:
```
Processing file "Piste audio 01.ogg"...
Note: Stream 1 has serial number 0, which is legal but may cause problems with s ome tools.
New logical stream (#1, serial: 00000000): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3)
Channels: 2
Rate: 44100
Nominal bitrate: 160,064000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
TITLE=Piste audio 01
ARTIST=xx
ALBUM=yy
Warning: Illegal UTF-8 sequence in comment 3 (stream 1): invalid sequence
COMMENT=
*** glibc detected *** double free or corruption (fasttop): 0x0806aac8 ***
Abandon
```
the file probably is corrupt (though it plays fine) but ogginfo shouldn't crash.
please contact me at emule@mail.ru to arrange you getting a copy of that file
btw. i tried to send mail to the address in the man page <msmith@xiph.org> but it returned saying:
```
The original message was received at Thu, 26 Jan 2006 19:09:30 -0500
from dyn216-8-134-218.ADSL.mnsi.net [216.8.134.218]
----- The following addresses had permanent fatal errors -----
<msmith@xiph.org>
(reason: 550 Service unavailable; Client host [216.8.130.240] blocked using rbl-plus.mail-abuse.org)
----- Transcript of session follows -----
... while talking to smtp.osuosl.org.:
>>>>>> DATA
<<< 550 Service unavailable; Client host [216.8.130.240] blocked using rbl-plus.mail-abuse.org
550 5.1.1 <msmith@xiph.org>... User unknown
<<< 554 Error: no valid recipients
```
ogginfo 1.1.0
cheers.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/739ogg123 segfault under OpenBSD2008-05-29T23:09:00Zneuronenwerkogg123 segfault under OpenBSDThe ogg123 application segfaulted various times to me. It was not intentionally reproducible, but occured several time an hour while I was listening to an ogg-stream:
# ogg123 -b256 -p25 -v http://listen.fm4.amd.co.at:31337/fm4-mq.ogg
...The ogg123 application segfaulted various times to me. It was not intentionally reproducible, but occured several time an hour while I was listening to an ogg-stream:
# ogg123 -b256 -p25 -v http://listen.fm4.amd.co.at:31337/fm4-mq.ogg
I couldn't observe any special conditions when it crashed. I hope the appended bt will clear up things a bit, though I myself was not able to find something way strange in decode_packed_entry_number (codebook.c).
All the best,
/Markus
#0 0x0ee2892d in decode_packed_entry_number ()
from /usr/local/lib/libvorbis.so.4.0
#1 0x0ee287e2 in vorbis_book_decodevv_add ()
from /usr/local/lib/libvorbis.so.4.0
#2 0x0ee26874 in res2_inverse () from /usr/local/lib/libvorbis.so.4.0
#3 0x0ee27b05 in mapping0_inverse () from /usr/local/lib/libvorbis.so.4.0
#4 0x0ee1e09a in vorbis_synthesis () from /usr/local/lib/libvorbis.so.4.0
#5 0x0bc0a7e8 in _fetch_and_process_packet ()
from /usr/local/lib/libvorbisfile.so.4.0
#6 0x0bc0c67d in ov_read () from /usr/local/lib/libvorbisfile.so.4.0
#7 0x1c006b23 in ?? ()
#8 0x825dd800 in ?? ()
#9 0x3c005980 in environ ()
#10 0x00000100 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000002 in ?? ()
#13 0x00000001 in ?? ()
#14 0x825ddac8 in ?? ()
#15 0x00000100 in ?? ()
#16 0x89364b90 in ?? ()
#17 0x00000f00 in ?? ()
#18 0xcfbcfb98 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000000 in ?? ()
#21 0x000044e8 in ?? ()
#22 0xcfbcfbd8 in ?? ()
#23 0x1c0065c8 in ?? ()
#24 0x7ce7c500 in ?? ()
#25 0x3c005980 in environ ()
#26 0x00000100 in ?? ()
#27 0xcfbcfb94 in ?? ()
#28 0xcfbcfba0 in ?? ()
#29 0x3c004a80 in environ ()
#30 0x00001000 in ?? ()
#31 0x00000005 in ?? ()
#32 0x2676bc04 in ?? () from /usr/lib/libc.so.38.2
#33 0x00000002 in ?? ()
#34 0x00000000 in ?? ()
#35 0x00000000 in ?? ()
#36 0x7ce7c500 in ?? ()
#37 0x872d7090 in ?? ()
#38 0x3c002278 in __progname ()
#39 0x3c0021a0 in __progname ()
#40 0x037f0c7f in ?? ()
#41 0x00000000 in ?? ()
#42 0x1c0043c0 in ?? ()
#43 0x1c004498 in ?? ()
#44 0x00000000 in ?? ()
#45 0x00000002 in ?? ()
#46 0x00000001 in ?? ()
#47 0x0000ac44 in ?? ()
#48 0x00000002 in ?? ()
#49 0x00000000 in ?? ()
#50 0x00000002 in ?? ()
#51 0xcfbcfca4 in ?? ()
#52 0xcfbcfd0c in ?? ()
#53 0xcfbcfc08 in ?? ()
#54 0x00000000 in ?? ()
#55 0x1c005cd0 in ?? ()
#56 0x00000001 in ?? ()
#57 0x872d70d0 in ?? ()
#58 0xcfbcfca4 in ?? ()
#59 0x1c006304 in ?? ()
#60 0x7ce7c100 in ?? ()
#61 0x1c005cd0 in ?? ()
#62 0x0000005b in ?? ()
#63 0x00000000 in ?? ()
#64 0x00000002 in ?? ()
#65 0x00000202 in ?? ()
#66 0x00000000 in ?? ()
#67 0x00000001 in ?? ()
#68 0x00000000 in ?? ()
#69 0x127f0c7f in ?? ()
#70 0x00000001 in ?? ()
#71 0x843aa024 in ?? ()
#72 0xcfbcfcac in ?? ()
#73 0xcfbcfc64 in ?? ()
#74 0x098b9d11 in _dl_bind () from /usr/libexec/ld.so
Previous frame inner to this frame (corrupt stack?)
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/736incorrect 5.1 channel order handling in oggenc/oggdec2008-02-16T00:39:34ZGitlab Botincorrect 5.1 channel order handling in oggenc/oggdecOggenc appears not to remap 5.1 channel order from WAV order (L/R/C/LFE/BL/BR) to Vorbis order defined by xiph's specifications :
six channels : the stream is 5.1 surround. channel order: front left, front center, front right, rear left...Oggenc appears not to remap 5.1 channel order from WAV order (L/R/C/LFE/BL/BR) to Vorbis order defined by xiph's specifications :
six channels : the stream is 5.1 surround. channel order: front left, front center, front right, rear left, rear right, LFE
Tested with rarewares build 2005-07-10.
The same problem applies to oggdec (again assumes WAV channel order on libvorbis output, so it actually decodes incorrect oggenc output back to correct WAV).Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/729[PATCH] Default of dev option not 0 for alsa09 as stated in ogg123, no inform...2009-04-19T21:09:40Ztmpusr67[PATCH] Default of dev option not 0 for alsa09 as stated in ogg123, no information on valid options for devThe man page lists the default for the alsa09 dev option as "0". If that were the case the following two lines would be equivalent.
```
ogg123 -d alsa09 cdda.ogg
ogg123 -d alsa09 -o dev:0 cdda.ogg
```
However the first line play...The man page lists the default for the alsa09 dev option as "0". If that were the case the following two lines would be equivalent.
```
ogg123 -d alsa09 cdda.ogg
ogg123 -d alsa09 -o dev:0 cdda.ogg
```
However the first line plays music on card number 0. The second line gives the error:
```
ALSA lib pcm.c:2090:(snd_pcm_open_noupdate) Unknown PCM 0
ALSA snd_pcm_open error: No such file or directory
Error: Cannot open device alsa09
```
I can find no example of how to play sound from ALSA card number 1 on the web. That "-o card:" is ignored is a known bug (see below) and the only hits on Google for
```
ogg123 alsa09 "-o dev:" or "-o card:"
```
are
```
ogg123 -d alsa09 -o dev:dmixer
```
and
```
DA bug report logs: maintainer ccheney@debian.org
#298237: /usr/bin/ogg123: ogg123 ignores -o card:1 option for alsa09 Package:
vorbis-tools (1.0.1-1.2); Reported by: Nathan Hurst ...
bugs.donarmstrong.com/cgi-bin/pkgreport.cgi?maint=ccheney@debian.org&arch=source
```tan Seiberttan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/728NAME_MAX used incorrectly2006-06-12T10:29:06ZjoergNAME_MAX used incorrectlyCompilation fails on DragonFly since the code uses NAME_MAX
without including the right header file.
Fix is easy:
```
--- ogg123/playlist.c.orig 2005-08-17 20:03:15.000000000 +0000
+++ ogg123/playlist.c
@@ -19,6 +19,7 @@
#include ...Compilation fails on DragonFly since the code uses NAME_MAX
without including the right header file.
Fix is easy:
```
--- ogg123/playlist.c.orig 2005-08-17 20:03:15.000000000 +0000
+++ ogg123/playlist.c
@@ -19,6 +19,7 @@
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
+#include <limits.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
```Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/715[PATCH] ogg123, output via esd, hang after SIGINT2008-01-19T16:07:52Zvinschen[PATCH] ogg123, output via esd, hang after SIGINTThe following problem occurs under Cygwin with ogg123 from vorbis-tools 1.1.1:
When ogg123 is running playback via esd, pressing Ctrl-C will result in a hang in most
cases. I tracked it down to buffer.c, submit_data_chunk(). The hang ...The following problem occurs under Cygwin with ogg123 from vorbis-tools 1.1.1:
When ogg123 is running playback via esd, pressing Ctrl-C will result in a hang in most
cases. I tracked it down to buffer.c, submit_data_chunk(). The hang reliably occurs
when waiting for the "No room for data in buffer. Waiting." conditional wait. I have
applied the following patch to the Cygwin version, which seem to solve the problem.
I'm just not sure it's really the correct way to solve the problem. I'd appreciate
any feedback.
```
--- ogg123/buffer.c.ORIG 2005-06-03 12:15:09.000000000 +0200
+++ ogg123/buffer.c 2005-09-23 15:53:26.150989900 +0200
@@ -308,6 +308,11 @@ void submit_data_chunk (buf_t *buf, char
}
else {
+ if (buf->cancel_flag || sig_request.cancel)
+ {
+ UNLOCK_MUTEX(buf->mutex);
+ break;
+ }
/* No room for more data, wait until there is */
DEBUG("No room for data in buffer. Waiting.");
COND_WAIT(buf->write_cond, buf->mutex);
```
Greetings,
CorinnaMichael SmithMichael Smith