Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-01-22T04:18:37Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1521Raw output can result in Buffer write failed.2018-01-22T04:18:37ZwernerRaw output can result in Buffer write failed.Hello,
BpmDj http://bpmdj.yellowcouch.org/ relies on ogg123 to decode an audiostream and write it to disk. Recently it sometimes works it sometimes doesn't. In particular when the source file is on an nfs share and the output file is o...Hello,
BpmDj http://bpmdj.yellowcouch.org/ relies on ogg123 to decode an audiostream and write it to disk. Recently it sometimes works it sometimes doesn't. In particular when the source file is on an nfs share and the output file is on a local disk, while the machine is under load ogg123 will give the error
Error: buffer write failed
and the output file will be incomplete. The command I issue is
$ ogg123 -q -d raw -f test.raw /music/cd085/Yvette\[BuzzFuzz\].ogg
Error: buffer write failed
This is rather problematic since BpmDj relies on ogg123 to be able to export the stream without trying it a couple of times. The version of ogg is
$ ogg123 -V
ogg123 from vorbis-tools 1.2.0
at a debian platform. Is this a known issue or is there any particular reason why it behaves like that ?
With kind regards,
Werner,-
http://werner.yellowcouch.org/
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1685ogginfo: speedier operation2018-01-22T04:18:37ZJohn Ferlitoogginfo: speedier operationReported by Clint Adams at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340888
I want an option for ogginfo to not read the entire .ogg, but to use
ov_time_tell() or something to determine the length of the vorbis
stream.
Reported by Clint Adams at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340888
I want an option for ogginfo to not read the entire .ogg, but to use
ov_time_tell() or something to determine the length of the vorbis
stream.
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/1686vorbis-tools: should accept input in libsndfile formats2018-01-22T04:18:37ZJohn Ferlitovorbis-tools: should accept input in libsndfile formatsReported by Rogério Brito at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488458
It would be highly desirable to have oggenc to have its input section
driven by libsndfile1, as that would allow, for instance, the
codification of spe...Reported by Rogério Brito at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488458
It would be highly desirable to have oggenc to have its input section
driven by libsndfile1, as that would allow, for instance, the
codification of speech files taken from regular S1MP3 recorders to be
vorbis files (some S1MP3 files record their files not in plain PCM
format, but in IMA ADPCM format).
I am member of the upstream team of maintainers of lame and it currently
has its input as libsndfile1 which makes things very flexible for users.
Since I would prefer to put the lectures that I give on-line, I would be
much more comfortable using Vorbis instead of MP3.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1570vorbis-tools-1.2.0 (ogg123) prints binary data into stdout (console)2018-01-22T04:18:37ZSamuli Suominenvorbis-tools-1.2.0 (ogg123) prints binary data into stdout (console)(This bug was created as a clone of http://bugs.gentoo.org/show_bug.cgi?id=267646)
Note that the original bug has a example .ogg for reproducing attached, so please check that out.
(Just a side note: e.g. flac123 doesn't have this prob...(This bug was created as a clone of http://bugs.gentoo.org/show_bug.cgi?id=267646)
Note that the original bug has a example .ogg for reproducing attached, so please check that out.
(Just a side note: e.g. flac123 doesn't have this problem)
ogg123 (ogg123 from vorbis-tools 1.2.0):
If it see a tag present, it echoes it.
The first problem is that it echoes the "Comment" tag (if it presents) twice.
The second (and much worse) problem is that it tries to echo tags like "Cover"
(graphics, though console couldn't correctle display it).
Reproducible: Always
Steps to Reproduce:
1. Get an ogg-coded file wicth clear tags;
2. Write the comment tag with easytag;
3. Try to play it with ogg123 and see the display;
4. Add to this file some picture (for example .jpg) as a cover;
5. Try to play it with ogg123 and see the display.
Actual Results:
For step 3:
"Comment: blah-blah-blah
Comment: blah-blah-blah"
For step 5:
Coverartmime: image/jpeg
Coverartdescription: potan2.jpg
Coverart: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAA... (continue echoing jpg)
Expected Results:
For step 3:
"Comment: blah-blah-blah"
For step 5:
To ignore the presence of Cover* tags.
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/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/1600vcut produces Ogg files with Negative granulepos (-1) on vorbis stream outsid...2018-01-22T04:18:37ZGitlab Botvcut produces Ogg files with Negative granulepos (-1) on vorbis stream outside of headers.Running ogginfo on an output file created by vcut presents the error:
Negative or zero granulepos (-1) on vorbis stream outside of headers. This file was created by a buggy encoder whereas running ogginfo on the source Ogg file does no...Running ogginfo on an output file created by vcut presents the error:
Negative or zero granulepos (-1) on vorbis stream outside of headers. This file was created by a buggy encoder whereas running ogginfo on the source Ogg file does not present the error, but does produce the warning
Warning: sequence number gap in stream 1. Got page 171463 when expecting page 3.
The source file was a captured radio stream with time stamps that begin much >0:00. If there is interest, I can try to create another smaller sample file which can be used to recreate the error.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1696oggenc progress indication2018-01-22T04:18:37ZGitlab Botoggenc progress indicationWould be nice if oggenc could indicate how many seconds have been processed instead of (or additional to) the current indication how long oggenc is running. (when feeding oggenc via a pipe like:
```
ffmpeg -v -10 -threads 4 -i "test_en_...Would be nice if oggenc could indicate how many seconds have been processed instead of (or additional to) the current indication how long oggenc is running. (when feeding oggenc via a pipe like:
```
ffmpeg -v -10 -threads 4 -i "test_en_aid_128__09_38_42_868_01.ac3" -acodec pcm_s16le -ac 6 -ar 48000 -f wav - | oggenc -r -b 128 -C 6 -R 48000 --ignorelength --utf8 -o "test_en_aid_128__09_38_42_868_02.ogg" -
```
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/1743oggdec prints version string to the data stream when decoding to stdout2018-01-22T04:18:37Ztropfenschlagoggdec prints version string to the data stream when decoding to stdouthere an example:
```
$ oggdec --output - foo.ogg 2>/dev/null
oggdec from vorbis-tools 1.4.0
RIFF [and some more binary data]
```
I propose you print out the version string to stderr when in normal operation. I have attached a patch whi...here an example:
```
$ oggdec --output - foo.ogg 2>/dev/null
oggdec from vorbis-tools 1.4.0
RIFF [and some more binary data]
```
I propose you print out the version string to stderr when in normal operation. I have attached a patch which should solve the problem ~~[untested!]~~ [now tested]Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1749Permutation row for 6.1 channel audio setup in oggenc (trunk) seems to be wro...2018-01-22T04:18:37ZMichal SoltysPermutation row for 6.1 channel audio setup in oggenc (trunk) seems to be wrong (+patch)oggenc from vorbis-tools (trunk version) has following permutation row for 6.1 channel setup:
0 2 1 4 5 6 3
But:
1) according to vorbis specs, the order should be:
FL, FC, FR, SL, SR, BC, LFE
2) according to wave extensible, 0x70F e...oggenc from vorbis-tools (trunk version) has following permutation row for 6.1 channel setup:
0 2 1 4 5 6 3
But:
1) according to vorbis specs, the order should be:
FL, FC, FR, SL, SR, BC, LFE
2) according to wave extensible, 0x70F expects:
FL, FR, FC, LFE, BC, SL, SR
So the proper permutation matrix should likely be:
0 2 1 5 6 4 3
If I adjust the matrix and recompile, I get proper channel order from e.g. libavcodec.Monty MontgomeryMonty Montgomeryhttps://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/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/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/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/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/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/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/speex/-/issues/1511add Haiku types in speex_types.h2018-01-21T13:05:26ZGitlab Botadd Haiku types in speex_types.hPatch to add Haiku types for speex.Patch to add Haiku types for speex.Jean-Marc ValinJean-Marc Valin