Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-12-06T12:09:49Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2214compiler warning on assert in resample.c2020-12-06T12:09:49Zvespertocompiler warning on assert in resample.cHi, while installing vorbis-tools in Gentoo, the following warning is issued by the installer:
```
QA Notice: Package triggers severe warnings which indicate that it may exhibit random runtime failures.
resample.c:177:34: warning:...Hi, while installing vorbis-tools in Gentoo, the following warning is issued by the installer:
```
QA Notice: Package triggers severe warnings which indicate that it may exhibit random runtime failures.
resample.c:177:34: warning: comparison with string literal results in unspecified behavior [-Waddress]
```
This is caused by an assert using == on strings. I've never seen any of the Vorbis code but i assume this warning can be fixed with the attached patch.
oggenc -V reports «oggenc from vorbis-tools 1.4.0» but i didn't find that specific version in the bug submission form.
The system is amd64.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2212oggenc aiff_open buffer overflow2018-01-22T05:18:41Zpengsuoggenc aiff_open buffer overflowI discovered an buffer overflow issue in oggenc/audio.c when it tries to open invalid aiff file.
...I discovered an buffer overflow issue in oggenc/audio.c when it tries to open invalid aiff file.
```
274 if(fread(buffer,1,len,in) < len)
```
The 'len' here can be controlled by user indirectly via:
```
260 if(!find_aiff_chunk(in, "COMM", &len))
```
The attached aiff file can be used to reproduce this issue. I was testing with 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/2149oggdec internationalization is broken2018-01-22T04:21:18ZMartin Steghöferoggdec internationalization is brokenWhile trying to fix a different Debian bug in "oggdec", I've discovered that the "oggdec" executable uses the "_" (underscore) macro for internationalization and has translations of the relevant strings available in the .po files, but ne...While trying to fix a different Debian bug in "oggdec", I've discovered that the "oggdec" executable uses the "_" (underscore) macro for internationalization and has translations of the relevant strings available in the .po files, but nevertheless outputs everything in English. This is probably due to a lack of initialization of the internationalization modules in that executable. I'm contributing a patch that adds the necessary initializations (copied from the other executables in vorbis-tools).Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2148Crash/hang: oggdec doesn't stop on decoding error2018-01-22T04:21:36ZMartin SteghöferCrash/hang: oggdec doesn't stop on decoding errorIt was reported to [Ubuntu's (629135)](https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/629135) and [Debian's (772978)](https://bugs.debian.org/772978) bug tracking systems that trying to decode a given (broken) ogg/vorbis inp...It was reported to [Ubuntu's (629135)](https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/629135) and [Debian's (772978)](https://bugs.debian.org/772978) bug tracking systems that trying to decode a given (broken) ogg/vorbis input file, oggdec crashes or goes into an infinite loop (depending on the libvorbis version), while showing "hole in data" warnings.
I've looked into this and realized that libvorbis doesn't actually return the `OV_HOLE` "hole in data" error code (which would be recoverable), but a different (fatal) decoding error. However, oggdec treats all negative return values coming from `ov_read` as `OV_HOLE` errors and therefore as recoverable. So it keeps on calling `ov_read`, which may either crash (libvorbis' data structures may be uninitialized) or simply not progress and therefore capture oggdec in an infinite loop.
I suggest to fix it by applying the attached patch, which makes oggdec exit with an error message on fatal decoding errors. The error string is "borrowed" from ogg123 and therefore already translated into several languages.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/2029[patch] vorbis-tools-1.4.0 has missing linkage to mathlib2018-01-22T04:52:24Zssuominengentoo[patch] vorbis-tools-1.4.0 has missing linkage to mathlibhttp://bugs.gentoo.org/513942
Fix building with `./configure --enable-ogg123 --without-flac --without-speex --without-kate` and `make`:
libtool: link: gcc -Wall -ffast-math -fsigned-char -O2 -pipe -march=native -Wl,-O1 -Wl,--hash-style...http://bugs.gentoo.org/513942
Fix building with `./configure --enable-ogg123 --without-flac --without-speex --without-kate` and `make`:
libtool: link: gcc -Wall -ffast-math -fsigned-char -O2 -pipe -march=native -Wl,-O1 -Wl,--hash-style=gnu -o oggenc oggenc.o audio.o encode.o platform.o resample.o skeleton.o -Wl,--as-needed ../share/libutf8.a ../share/libgetopt.a -lvorbisenc -lvorbis -logg
resample.o:resample.c:function res_init: error: undefined reference to 'sin'
collect2: error: ld returned 1 exit status
libtool: link: gcc -Wall -ffast-math -fsigned-char -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -o ogg123 audio.o buffer.o callbacks.o cfgfile_options.o cmdline_options.o file_transport.o format.o http_transport.o ogg123.o oggvorbis_format.o playlist.o status.o remote.o transport.o vorbis_comments.o vgfilter.o ../share/libutf8.a ../share/libgetopt.a -lvorbisfile -lvorbis -logg -lao -lnsl -lcurl -lpthread
vgfilter.o:vgfilter.c:function vg_init: error: undefined reference to '__pow_finite'
vgfilter.o:vgfilter.c:function vg_init: error: undefined reference to '__pow_finite'
vgfilter.o:vgfilter.c:function vg_filter: error: undefined reference to 'tanh'
vgfilter.o:vgfilter.c:function vg_filter: error: undefined reference to 'tanh'
collect2: error: ld returned 1 exit status
This is using the new GNU gold linker:
$ ld -v
GNU gold (GNU Binutils 2.24) 1.11
Happens because -lm gets appended to the libraries list only with, for example, --with-flac but vgfilter.c and resample.c are always
using functions from the mathlib.
Therefore, always link to mathlib.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2025Vorbis tools do not build with gcc 4.9 and "-Werror=format-security" flag2018-01-22T04:22:07ZMarcin JuszkiewiczVorbis tools do not build with gcc 4.9 and "-Werror=format-security" flagvorbis-tools-1.4.0-12.fc21 FTBFS if "-Werror=format-security" flag is used.
..
status.c: In function ‘print_statistics_line’:
status.c:151:7: error: format not a string literal and no format arguments [-Werror=format-security]
le...vorbis-tools-1.4.0-12.fc21 FTBFS if "-Werror=format-security" flag is used.
..
status.c: In function ‘print_statistics_line’:
status.c:151:7: error: format not a string literal and no format arguments [-Werror=format-security]
len += sprintf(str+len, stats->formatstr);Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2009segfault when trying to encode trivial raw input2020-12-06T14:48:21Zhannosegfault when trying to encode trivial raw inputI was recently trying to create a trivial vorbis file containing just a bit of silence. I thought feeding oggenc a bit if zeros as raw input should do. So I came up with this command line:
dd if=/dev/zero bs=1 count=1 | oggenc -r - -o ou...I was recently trying to create a trivial vorbis file containing just a bit of silence. I thought feeding oggenc a bit if zeros as raw input should do. So I came up with this command line:
dd if=/dev/zero bs=1 count=1 | oggenc -r - -o out.ogg
However, it segfaults. I tried it on different systems and this does not happen everywhere. My system is a 64 bit Gentoo Linux (vorbis-tools 1.4.0, libvorbis 1.3.4, libogg 1.3.1) on a T61 thinkpad laptop. Tried it on an old acer 32 bit laptop with Ubuntu and the same problem didn't happen.
If you need more info to track it down please ask.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2007[charset.c:58]: (style) Same expression on both sides of '||'.2018-01-22T04:18:25ZDavid Binderman[charset.c:58]: (style) Same expression on both sides of '||'.Source code is
if (!*s1 || !*s1)
Suggest new code
if (!*s1 || !*s2)
Source code is
if (!*s1 || !*s1)
Suggest new code
if (!*s1 || !*s2)
https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1989vorbis-tools-1.4.0/share/charset.c:58: possible coding typo ?2018-01-22T04:54:21ZDavid Bindermanvorbis-tools-1.4.0/share/charset.c:58: possible coding typo ?
Static analysis tool cppcheck says
[charset.c:58] -> [charset.c:58]: (style) Same expression on both sides of '||'.
Source code is
for (;; s1++, s2++) {
if (!*s1 || !*s1)
break;
maybe
for (;; s1++, s2++) {
if (!*s...
Static analysis tool cppcheck says
[charset.c:58] -> [charset.c:58]: (style) Same expression on both sides of '||'.
Source code is
for (;; s1++, s2++) {
if (!*s1 || !*s1)
break;
maybe
for (;; s1++, s2++) {
if (!*s1 || !*s2)
break;
would be better code.
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/1956[PATCH] ogg123 hangs with certain OGG files2018-01-22T04:36:51Zquipyowert[PATCH] ogg123 hangs with certain OGG filesVersion: vorbis tools v1.4.0
System: OpenSUSE 12.1 Linux 3.1.10 32 bit single CPU without hyperthreading.
Reproducibility: Reproducible every time
Sending a SIGINT to Ogg123 while it is playing any of certain ogg files makes it hang. ...Version: vorbis tools v1.4.0
System: OpenSUSE 12.1 Linux 3.1.10 32 bit single CPU without hyperthreading.
Reproducibility: Reproducible every time
Sending a SIGINT to Ogg123 while it is playing any of certain ogg files makes it hang. With some of those files, ogg123 hangs when it has finished playing the file, but with the others it seems to hang somewhere in the middle of playing the file. Each of the attached ogg files taken from ManaPlus (except reminder.ogg) will make ogg123 hang. When it hangs, it will not print any more output or respond to anything. This hang happens both with the ogg123 from the OpenSUSE vorbis-tools-1.4.0 package and the ogg123 I compiled from the vorbis-tools source code myself.
I compiled ogg123 with the DEBUG_BUFFER macro defined, ran it, and looked through the resulting log file. From the information in that log combined with using GDB, I found that ogg123 was hanging in the pthread_cond_wait system call waiting for the other thread to signal it, but the other thread had already exited.
The attached patch fixes this by turning the conditional wait into a timed wait to receive a signal or 1 second to pass. I've only tried this patch on a 32-bit machine, so it might not work on a 64bit machine. This change also makes ogg123 start playing the next file when it is given a SIGINT instead of uselessly freezing on the first file, which it does when starting "ogg123 *.ogg" with the unpatched ogg123 in a directory full of ogg files.
To reproduce on Linux:
1. run "ogg123 attention.ogg" (or another ogg file that hangs it)
2. Wait for ogg123 to show the bar that shows how much of the file it has played.
3. Send ogg123 a SIGINT using Ctrl+C before the bar disappears.
4. ogg123 will hang.
Reproducing under GDB:
1. run "gdb --args ogg123 attention.ogg"
2. type "handle SIGINT nostop print pass"; answer Y
3. type "run".
4. Wait for ogg123 to show the bar that shows how much of the file it has played.
5. Press Control+C before that bar disappears. Ogg123 will now hang.
6. Press Control+Z to get back to the GDB prompt.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1934Different problems while encoding2018-01-22T04:20:54ZcacaDifferent problems while encodingHi friends,
First of all thank you for you great effort! I am not used to this kind of testing on development projects, and so please correct me if I am tracking badly this bug or message, or this is not the appropiated place.
I'm usin...Hi friends,
First of all thank you for you great effort! I am not used to this kind of testing on development projects, and so please correct me if I am tracking badly this bug or message, or this is not the appropiated place.
I'm using last oggenc exe from vorbis-tools 1.2.0 (win32 binaries)349K 530f79112f5a12f60a878ebd62013521
from your web and I am facing some problems.
I'm doing some tests with different combinations of sampling, #channels and bits, using the RAW mode as in
$> oggenc --raw --raw-chan=2 --raw-bits=16 --raw-rate=44100 --quality=4 --output=44-2-16.ogg 44-2-16.wav
I tried to compress samples of following combinations of the same analog source of music: 44-2-16,44-2-8, 44-1-16, 44-2-8, 22-2-16, 22-2-8, 22-1-16, 22-1-8
First of all I don't know why, encoding any 16 bits stereo sample in raw mode swaps audio channels in my output file. I mean, if a guitar plays in the right channel in the original wavs, its still there when I convert from 8 bits, but swapped after doing it from 16 bits. That does not occur if I use oggenc -q 4 instead, but not with --raw specs (exactly as described above).
Secondly, I don't understand why if ogg detects automatically input channels, sampling, etc., and it seems so because files are differing in just some few bytes, why aren't outputted files identical whether I use spec'ed raw inputs or average behaviour?
And last of all, is it normal that having the original source coded in 8 bits or 16 does not affect the size of the compressed output? I mean, same audio source coded in mono or a half of the sampling freq reduces a lot the outputted ogg, but is not the case when switching between 16/8bit samples, which are really half/double the size.
I tried reading wiki and everything, hope this questions are not really covered with an obvious explanation somewhere and so they are not bugs.
P.S: I used Windows soundrecorder for generating initial sampled and then reopened and saved the file according to every different bit/channel/sampling combination (all outputs have coherent size, reduced by 2 for any 44->22 or stereo->mono or 16bit->8bit factor).
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 Smith