Vorbis tools issueshttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues2022-01-26T18:11:04Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2328MR: fix memleak with -c option2022-01-26T18:11:04Ztaz 007MR: fix memleak with -c optionHello, please merge this patch : https://gitlab.com/taz007/vorbis-tools/-/commit/70604b38f62fcabb37bc1b57dbb9e261c775e067
I can't make a proper MR as I don't have access to fork functionality.Hello, please merge this patch : https://gitlab.com/taz007/vorbis-tools/-/commit/70604b38f62fcabb37bc1b57dbb9e261c775e067
I can't make a proper MR as I don't have access to fork functionality.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2327Don't forget to sync translations2023-03-09T10:41:32ZMario BlättermannDon't forget to sync translationsHello,
as you might know, the translations of vorbis-tools are maintained at GNU TP [1]. Obviously the translations haven't been synced with the Git content for years. For example, I can't found my German translation which resides there...Hello,
as you might know, the translations of vorbis-tools are maintained at GNU TP [1]. Obviously the translations haven't been synced with the Git content for years. For example, I can't found my German translation which resides there for more than six years. At least the last two releases 1.4.1 and 1.4.2 don't contain it.
[1] http://translationproject.org/domain/vorbis-tools.htmlPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2326No git tags2020-08-15T19:17:21ZTomasz KłoczkoNo git tagsLooks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?Looks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2325ogg123: feeding FLAC file via STDIN fails2020-08-13T14:54:45ZSebastian Hübnerogg123: feeding FLAC file via STDIN failsHi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the og...Hi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
> cat HD_2020-01-30_465376506.flac | ogg123 -
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
```
If I give the FLAC file as a normal input it is working:
```
ogg123 HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Playing: HD_2020-01-30_465376506.flac
FLAC stream: 16 bits, 2 channel, 44100 Hz
Artist: Flamingo Pier
Encoded by: **removed**
Heardis_id: HD_2020-01-30_465376506
Title: Boogie Meltdown
ReplayGain (Track): -6.27 dB
ReplayGain Peak (Track): 0.986664
Done.
```
I tried it on Ubuntu 20.04 (vorbis-tools 1.4.0-11) and Ubuntu 18.04 (vorbis-tools 1.4.0-10.1) and both gave me the same error.
Is this a bug or just not possible with FLAC files?
thanks in advance :)https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2320ogginfo -q could be quieter2017-07-05T07:17:14ZTristan Millerogginfo -q could be quieterAccording to the built-in usage instructions and the man page, `ogginfo` has a "quiet" command-line option:
```
-q Make less verbose. Once will remove detailed informative
messages, two will remove warnings
```
Howev...According to the built-in usage instructions and the man page, `ogginfo` has a "quiet" command-line option:
```
-q Make less verbose. Once will remove detailed informative
messages, two will remove warnings
```
However, even when using this option multiple times, `ogginfo` always prints logging information about what file(s) it's processing:
```
$ ogginfo -q -q somefile.ogg
Processing file "somefile.ogg"...
```
Can I suggest that this logging information be suppressed when `-q` is used (or at least when it's used twice, or maybe even three times)? I sometimes want to call `ogginfo` from a shell script where all I care about is the return value, and any output at all is bothersome. I guess I could just redirect stdout to `/dev/null`, but many other tools that support a "quiet" flag do indeed suppress all non-essential informational output.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2300Write album art to encoded .ogg file2024-01-18T19:54:06ZtmpltWrite album art to encoded .ogg fileI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersI use oggenc to create Ogg Vorbis files to save space on my mobile devices. While oggenc seems to write most metadata to the created .ogg file, the album art isn't copied. Could this be implemented?
CheersMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2295oggdec error - seems to be endianness problem2018-01-22T04:18:25ZMikeoggdec error - seems to be endianness problemI am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctl...I am trying to use ezstream to send a vorbis ogg music file to icecast. The error simplifies down to this - when I use the following two commands to manually decode and then encode an ogg file, the resulting test.ogg file plays correctly
oggdec -R -b 16 -e 0 -s 1 -o file.raw file.ogg
oggenc -r -B 16 -C 2 -R 44100 --raw-endianness 0 -q 5 -o test.ogg file.raw
But if I try to pipe the output of oggdec into the input of offenc as ezstream would do, the resulting file is only static. The defective pipe command is
oggdec -R -b 16 -e 0 -s 1 -o - file.ogg | oggenc -r -B 16 -C 2 \
-R 44100 --raw-endianness 0 -q 5 -o test.ogg -
However if I reverse the endianness in the pipe command of oggdec to -e 1 the resulting test.ogg plays properly. Somewhere in the handling of stdout the endianness is being reversed. This only happens when piping.
Version info:
linux 4.6.2
vorbis-tools-1.4.0
libvorbis-1.3.5
libogg-1.3.2
icecast-2.4.3
ezstream-0.6
Hardware is an intel i5 based system.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2276oggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite ...2018-01-22T04:18:25ZWang Pengoggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite loop) with crafted input file1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
...1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
0xbffff254: 0x00 0x00 0x00 0x00 0xf8 0xff 0xff 0xff
here! 0xfffffff8 == *-8*
audio.c:134 *len = READ_U32_LE(buf+4);
(gdb)p/x *len
$7 = 0xfffffff8
audio.c:135 if(!seek_forward(in, *len))
audio.c:101 if( fseek(in, length, SEEK_CUR))
(gdb)p/x length
$15 = 0xfffffff8
In conclusion, fread() forwards the file position by 8 bytes and then fseek() backwards it by 8 bytes, meaning resets it;More worse,this happens within a while(1) loop,at audio.c:124 ,which results in the infinite loop.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2195Unreliable determining seekability in ogg1232018-01-22T04:18:25ZRaúl Salinas-MonteagudoUnreliable determining seekability in ogg123
In [vorbis-tools/ogg123/file_transport.c](https://trac.xiph.org/browser/trunk/vorbis-tools/ogg123/file_transport.c), the input is considered not to be seekable if "-" (stdin) is specified as input file.
In Unix, you can actually seek ...
In [vorbis-tools/ogg123/file_transport.c](https://trac.xiph.org/browser/trunk/vorbis-tools/ogg123/file_transport.c), the input is considered not to be seekable if "-" (stdin) is specified as input file.
In Unix, you can actually seek in stdin if it comes from a regular file (instead of from a pipe).
Seekable stdin:
ogg123 - < file.ogg
Non-seekable standard-specified file:
mkfifo fifo.ogg
ogg123 fifo.ogg
I propose to correctly determine the seekability by stat()ing the descriptor.
```
bool isSeekable(int fd) {
struct stat sb;
int res = fstat(fd, &sb);
if (res < 0) {
perror("fstat");
return -1;
}
return S_ISREG(sb.st_mode) !=0;
}
```
and then doing something like
```
private->seekable = isSeekable(fileno(private->fp));
```
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2137Oggenc division by zero issue2018-01-22T04:18:25ZParis ZoumpouloglouOggenc division by zero issueA crafted WAV file with number of channels set to 0 will cause oggenc to crash due to a division by zero issue at :
Stopped reason: SIGFPE
0x0804d497 in wav_open (in=0x805c368, opt=0xbffff2ec, oldbuf=0x805c4d0 "RIFF\f\002", buflen=0xc) ...A crafted WAV file with number of channels set to 0 will cause oggenc to crash due to a division by zero issue at :
Stopped reason: SIGFPE
0x0804d497 in wav_open (in=0x805c368, opt=0xbffff2ec, oldbuf=0x805c4d0 "RIFF\f\002", buflen=0xc) at audio.c:552
552 opt->total_samples_per_channel = len/(format.channels*samplesize);
Tests were performed using vorbis-tools 1.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2136Oggenc channel integer overflow2020-12-06T12:33:55ZParis ZoumpouloglouOggenc channel integer overflowI discovered an integer overflow issue in oggenc, related to the number of channels in the input WAV file. The issue triggers an out-of-bounds memory access which causes oggenc to crash here (audio.c) :
```
576 memcpy(wav->channel_permu...I discovered an integer overflow issue in oggenc, related to the number of channels in the input WAV file. The issue triggers an out-of-bounds memory access which causes oggenc to crash here (audio.c) :
```
576 memcpy(wav->channel_permute, wav_permute_matrix[wav->channels-1],
577 sizeof(int) * wav->channels);
```
Tests were performed using vorbis-tools 1.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2131[PATCH] vorbis-tools-1.4.0 - ogg123 Makefile overrides configure --docdir2018-01-22T04:18:25ZChris Mayo[PATCH] vorbis-tools-1.4.0 - ogg123 Makefile overrides configure --docdirSuggest:
```
--- vorbis-tools-1.4.0.orig/ogg123/Makefile.am
+++ vorbis-tools-1.4.0/ogg123/Makefile.am
@@ -19,7 +19,7 @@
localedir = $(datadir)/locale
DEFS = -DSYSCONFDIR=\"$(sysconfdir)\" -DLOCALEDIR=\"$(localedir)\" @DEFS@
-docdir ...Suggest:
```
--- vorbis-tools-1.4.0.orig/ogg123/Makefile.am
+++ vorbis-tools-1.4.0/ogg123/Makefile.am
@@ -19,7 +19,7 @@
localedir = $(datadir)/locale
DEFS = -DSYSCONFDIR=\"$(sysconfdir)\" -DLOCALEDIR=\"$(localedir)\" @DEFS@
-docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)
+docdir = @docdir@
mandir = @MANDIR@
bin_PROGRAMS = ogg123
```
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2128Configure script OV_ECTL_COUPLING_SET checking error2018-01-22T04:18:25ZLLConfigure script OV_ECTL_COUPLING_SET checking errorConfigure script for vorbistool 1.4.0 is broken in some cases. Checking OV_ECTL_COUPLING_SET results in error Vorbis >= 1.3.0 required. This occurs on systems where shared library search paths is not properly defined and the configure sc...Configure script for vorbistool 1.4.0 is broken in some cases. Checking OV_ECTL_COUPLING_SET results in error Vorbis >= 1.3.0 required. This occurs on systems where shared library search paths is not properly defined and the configure script was manually passed --with-ogg and -with-vorbis options with the proper paths to where the libraries are installed
The reason for this error may have been that compile variables $CFLAGS and $LIBS were set to default when they should have been set to include the $VORBIS_CFLAGS and $VORBIS_LIBS causing compiler failure to find include file vorbis/vorbisenc.h.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1988ogg123 doesn't play flac files with ID3 tags, no useful error given2018-01-22T04:18:26Zmyxalogg123 doesn't play flac files with ID3 tags, no useful error givenHi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should n...Hi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should not expext these to work.
I'd like to disagree with this and voice my concern that such a semi-common file format is not supported. I can understand not supporting a different format of tagging, but (I think) this should not interfere with playback itself. If playback of these files is not possible with the tags, then at least a more informative error message would be welcome. I took me quite a while to even figure out what the problem was, as the "flac" program showed no error or warning on testing or analyzing the file, and other programs (mplayer, VLC...) had no issue with the files in the first place.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1915'ignorelength' option does not work in oggenc2018-01-22T04:18:37ZRoman Volkov'ignorelength' option does not work in oggencHello, I am using the latest version of the vorbis-tools and I have found small, but very annoying bug. The oggenc tool ignores --ignorelength option. It causes cropping of the some big streams which are streamed through the pipe. I manu...Hello, I am using the latest version of the vorbis-tools and I have found small, but very annoying bug. The oggenc tool ignores --ignorelength option. It causes cropping of the some big streams which are streamed through the pipe. I manually fixed the bug, but not see that it fixed in the newest version of the vorbis-tools.
```
diff -Nuri vorbis-tools-1.4.0/oggenc/audio.c vorbis-tools-1.4.0-ignorelength/oggenc/audio.c
--- vorbis-tools-1.4.0/oggenc/audio.c 2010-03-24 12:27:14.000000000 +0400
+++ vorbis-tools-1.4.0-ignorelength/oggenc/audio.c 2012-03-03 19:33:28.000000000 +0400
@@ -547,6 +547,12 @@
of trying to abstract stuff. */
wav->samplesize = format.samplesize;
+
+ if (opt->ignorelength)
+ {
+ len = 0;
+ }
+
if(len)
{
opt->total_samples_per_channel = len/(format.channels*samplesize);
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1912oggenc(vorbis-tools) doesn't handle odd sized RIFF chunk2018-01-22T04:18:37Znu774oggenc(vorbis-tools) doesn't handle odd sized RIFF chunkWhen the size field of RIFF chunk header is odd, it is required to skip one more byte since RIFF chunks are word aligned.
The following part of find_wav_chunk() in audio.c:
```
if(memcmp(buf, type, 4))
{
*len = READ_U32_LE(buf+4);
...When the size field of RIFF chunk header is odd, it is required to skip one more byte since RIFF chunks are word aligned.
The following part of find_wav_chunk() in audio.c:
```
if(memcmp(buf, type, 4))
{
*len = READ_U32_LE(buf+4);
if(!seek_forward(in, *len))
return 0;
buf[4] = 0;
fprintf(stderr, _("Skipping chunk of type \"%s\", length %d\n"), buf, *len);
}
```
This should be fixed like the following:
```
- if(!seek_forward(in, *len))
+ if(!seek_forward(in, (*len + 1) & ~1))
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1910ogg123 -R doesn't reliably report the end of a file that has been playing2018-01-22T04:18:37ZHans Oesterholtogg123 -R doesn't reliably report the end of a file that has been playingWhen using ogg123 with -R, it is difficult to determine the end of
a song reliable.
mpg123 reports @P 0 when it is finished playing a song, which makes it possible to load a new file (almost) instantly. However, ogg123 doesn't report ...When using ogg123 with -R, it is difficult to determine the end of
a song reliable.
mpg123 reports @P 0 when it is finished playing a song, which makes it possible to load a new file (almost) instantly. However, ogg123 doesn't report @P 0.
Now we can try to determine if the file is finished playing by reading the time left from the @F, which will eventually drop to 0.
However, it sometimes doesn't! It stays on 0,11 or 0,02 or 0,08, or whatever.
To fix this, a final report should be added after the last song is finished playing. I've found out that this would be done in ogg123.c, in the subroutine 'display_statistics_quick'. I've changed the code from
```
void display_statistics_quick (stat_format_t *stat_format,
buf_t *audio_buffer,
data_source_t *source,
decoder_t *decoder)
{
print_statistics_arg_t *pstats_arg;
pstats_arg = new_print_statistics_arg(stat_format,
source->transport->statistics(source),
decoder->format->statistics(decoder));
if (audio_buffer) {
print_statistics_action(audio_buffer, pstats_arg);
} else
print_statistics_action(NULL, pstats_arg);
}
```
to:
```
void display_statistics_quick (stat_format_t *stat_format,
buf_t *audio_buffer,
data_source_t *source,
decoder_t *decoder)
{
print_statistics_arg_t *pstats_arg;
pstats_arg = new_print_statistics_arg(stat_format,
source->transport->statistics(source),
decoder->format->statistics(decoder));
if (options.remote) {
/* Display statistics via the remote interface */
remote_time(pstats_arg->decoder_statistics->current_time,
pstats_arg->decoder_statistics->total_time);
} else {
if (audio_buffer) {
print_statistics_action(audio_buffer, pstats_arg);
} else
print_statistics_action(NULL, pstats_arg);
}
}
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1907ogg123 chops 11, 13 or more channel vorbis audio2018-01-22T04:18:37ZMichael Stevensogg123 chops 11, 13 or more channel vorbis audioI do a lot of work with multichannel audio. Most 8, 10, 12 or 16 channels.
Recently I am using 11 channel vorbis files and find ogg123 garbles the playback. Sound like every 10th second a different channel is being played.
Same happens...I do a lot of work with multichannel audio. Most 8, 10, 12 or 16 channels.
Recently I am using 11 channel vorbis files and find ogg123 garbles the playback. Sound like every 10th second a different channel is being played.
Same happens for 11, 13, 15 channels! Looks like there is a problem with odd numbers of channels above 10. 9 is fine!
The problem occurs with ogg123 version 1.4.0. when playing back to an ALSA device. I have checked the problem is repeatable under following variations:
5 Different ALSA devices
2 Different Linux distributions
2 Different kernel versions
The multichannel audio files can be played by mplayer to ALSA without problems.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1895oggdec print progress information too fast. Slows process and system down.2018-01-22T05:00:03ZThomas Pfaffoggdec print progress information too fast. Slows process and system down.I'm using oggdec on OpenBSD where I do not have accelerated graphics. The fast output of progress information from oggdec slows not only the decode process down but also the system. For example "oggdec -Q -o bar.wav foo.ogg" takes abou...I'm using oggdec on OpenBSD where I do not have accelerated graphics. The fast output of progress information from oggdec slows not only the decode process down but also the system. For example "oggdec -Q -o bar.wav foo.ogg" takes about 1.2 seconds while "oggdec -o bar.wav foo.ogg" takes about 3.1 seconds. About 2 seconds wasted just to print progress information.
I made a quick hack that generates a SIGALRM every 250 ms or so that sets a variable telling the decoder to print progress information, i.e. "if (!quiet && seekable && update) { update = 0; ... }"... I'm not sure if this is the way to go but at least it fixes the problem for me. I can always just use -Q or hide the xterm but I want to see the progress information.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1858./configure should use pkg-config2018-01-22T04:18:37ZJohannes Zarl./configure should use pkg-configWhen flac, speex and/or ogg are installed in non-standard locations, configure does not find them, even though pkg-config knows about the locations.
For ogg, this is a minor nuisance (adding --with-ogg=$LIBOGG_ROOT works), but for flac ...When flac, speex and/or ogg are installed in non-standard locations, configure does not find them, even though pkg-config knows about the locations.
For ogg, this is a minor nuisance (adding --with-ogg=$LIBOGG_ROOT works), but for flac and speex there are no such configure parameters and one has to resort to more ugly clutches:
`CFLAGS=`pkg-config --cflags flac speex` LDFLAGS=`pkg-config --libs flac speex` ./configure `
I haven't checked, but maybe the same applies to libkate.
This bug is related to bug #1780.Michael SmithMichael Smith