Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-08-03T06:12:52Zhttps://gitlab.xiph.org/xiph/ezstream/-/issues/1398Optional components not optional2017-08-03T06:12:52ZRon GageOptional components not optionalthe documentation and the configure help file clearly state that libogg is optional
configure ignores the "without-ogg" and the "without-vorbis" directives
removing libogg from the system causes configure to error: "Must have libogg 1....the documentation and the configure help file clearly state that libogg is optional
configure ignores the "without-ogg" and the "without-vorbis" directives
removing libogg from the system causes configure to error: "Must have libogg 1.x installed"
Please fix ezstream to allow building without ogg support.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/libao/-/issues/2006libao: 24-bit ALSA playback is broken2017-11-03T10:00:01ZAndrew Ekstedtlibao: 24-bit ALSA playback is brokenALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao ...ALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao used to do this correctly, but changeset r18883 (which made it in to libao 1.2) rewrote the padding code to also handle upconverting arbitrary sample sizes, by filling the low bytes with zeros. Unfortunately, ALSA's 24-bit padding works the other way around - the _high_ byte is supposed to be zero-filled. Needless to say, padding the wrong end doesn't work very well.
https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/1897python-shout: Incorrect len parameter type in PyArg_ParseTuple call2017-11-16T12:06:13ZStefan Umbreitpython-shout: Incorrect len parameter type in PyArg_ParseTuple callThe type of 'len' in the call to PyArg_ParseTuple with 's#' as second parameter in the pshoutobj_send function, should be int but is size_t (see Python doc at http://docs.python.org/c-api/arg.html).
This can lead to a segfault on 64-bi...The type of 'len' in the call to PyArg_ParseTuple with 's#' as second parameter in the pshoutobj_send function, should be int but is size_t (see Python doc at http://docs.python.org/c-api/arg.html).
This can lead to a segfault on 64-bit systems where size_t differs from int. The attached patch fixes this.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/1517How to caculate the OGG encoding complete percent correctly?2018-04-29T07:18:11ZJerry WangHow to caculate the OGG encoding complete percent correctly?Hi, gentalmen:
I am not sure where to post my question, may I post it here?
I am wondering how to caculate the OGG encoding complete percent.
Looked into the source of OggMuxFilter.h.
[http://www.xiph.org/dshow/uploads/docs/OggMuxFilt...Hi, gentalmen:
I am not sure where to post my question, may I post it here?
I am wondering how to caculate the OGG encoding complete percent.
Looked into the source of OggMuxFilter.h.
[http://www.xiph.org/dshow/uploads/docs/OggMuxFilter_8h-source.html]
It implements the IOggMuxProgress and IMediaSeeking interface.
The IOggMuxProgress exposes two methods to retrieve the bytes written and the progress time.
The IMediaSeeking exposes the methods to retrieve the current position. In the header file, it says:
```
00135 //IMediaSeeking Override to give progress. - This is unreliable !!
00136 virtual STDMETHODIMP GetPositions(LONGLONG *pCurrent, LONGLONG *pStop);
00137 virtual STDMETHODIMP GetCurrentPosition(LONGLONG *pCurrent);
```
Upon my test, *they are always unreliable*.
the getRate() method always return 1.0 and the position is always far far smaller than the truth.
After looked into the OggMuxFilter.cpp, the IOggMuxProgress and IMediaSeeking both use the *mInterleaver->progressTime()* to do progress caculation.
```
00417 STDMETHODIMP OggMuxFilter::GetPositions(LONGLONG *pCurrent, LONGLONG *pStop) {
00418 HRESULT locHR = BasicSeekPassThrough::GetPositions(pCurrent, pStop);
00419 debugLog<<"GetPos Before : "<<*pCurrent<<" - "<<*pStop<<endl;
00420 *pCurrent = mInterleaver->progressTime();
00421 debugLog<<"GetPos After : "<<*pCurrent<<" - "<<*pStop<<endl;
00422 return locHR;
00423 }
00112 STDMETHODIMP_(LONGLONG) OggMuxFilter::getProgressTime()
00113 {
00114 if (mInterleaver != NULL) {
00115 return mInterleaver->progressTime();
00116 } else {
00117 return -1;
00118 }
00119
00120 }
```
I can not get the correct complete percent by IOggMuxProgress or IMediaSeeking.
How to get the correct OGG encoding complete percent?
1. Any other interface I can use to do this stuff?
2. How to estimate the whole output file size? If I can know the final output ogg file size, I can get the percent by IOggMuxProgress::getBytesWritten
Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/positron/-/issues/481positron barfs on some MP3s --- 1.0 worked on them.2017-08-03T06:41:39ZGitlab Botpositron barfs on some MP3s --- 1.0 worked on them.```
anthony@bohr:anthony$ positron sync
Synchronizing Neuros music database.
Checking for new music... assical/Beethoven/Beethoven - Vio...
Traceback (most recent call last):
File "/usr/bin/positron", line 174, in ?
main(s...```
anthony@bohr:anthony$ positron sync
Synchronizing Neuros music database.
Checking for new music... assical/Beethoven/Beethoven - Vio...
Traceback (most recent call last):
File "/usr/bin/positron", line 174, in ?
main(sys.argv)
File "/usr/bin/positron", line 156, in main
cmd.run(config, myNeuros, remaining[1:])
File "/usr/lib/python2.3/site-packages/positron/cmd_sync.py", line 93, in run
silent=True))
File "/usr/lib/python2.3/site-packages/positron/add_file.py", line 69, in
gen_filelist
allowed_types, silent))
File "/usr/lib/python2.3/site-packages/positron/add_file.py", line 69, in
gen_filelist
allowed_types, silent))
File "/usr/lib/python2.3/site-packages/positron/add_file.py", line 42, in
gen_filelist
metadata = audiofile.detect(fullname)
File "/usr/lib/python2.3/site-packages/positron/audiofile.py", line 28, in detect
metadata = detect_func(filename)
File "/usr/lib/python2.3/site-packages/positron/audiofile.py", line 44, in
detect_mp3
mp3info = MP3Info.MP3Info(f)
File "/usr/lib/python2.3/site-packages/positron/MP3Info.py", line 534, in __init__
id3v2 = ID3v2(file)
File "/usr/lib/python2.3/site-packages/positron/MP3Info.py", line 239, in __init__
frame = ID3v2Frame(file, self.major_version)
File "/usr/lib/python2.3/site-packages/positron/MP3Info.py", line 128, in __init__
self.data = _strip_zero(file.read(self.size))
MemoryError
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/speex/-/issues/1094speexenc seg fault on amd642018-01-21T13:05:27ZGitlab Botspeexenc seg fault on amd64I'm getting core-dumps on AMD64 speex (ubuntu)
Is this a known bug?
I re-built from source, and got same results.
> speexenc -v
speexenc (Speex encoder) version 1.1.11.1 (compiled Dec 9 2005)
Copyright (C) 2002-2005 Jean-Marc Valin
> ...I'm getting core-dumps on AMD64 speex (ubuntu)
Is this a known bug?
I re-built from source, and got same results.
> speexenc -v
speexenc (Speex encoder) version 1.1.11.1 (compiled Dec 9 2005)
Copyright (C) 2002-2005 Jean-Marc Valin
> speexenc /tmp/d04t05.wav d04t05.spx
Encoding 16000 Hz audio using wideband (sub-band CELP) mode (mono)
Segmentation fault
> aplay /tmp/d04t05.wav
Playing WAVE '/tmp/d04t05.wav' : Signed 16 bit Little Endian, Rate 16000
Hz, Mono
> speexenc -w --vbr --dtx -V /tmp/d04t05.wav d04t05.spx
Encoding 16000 Hz audio using wideband (sub-band CELP) mode (mono)
Segmentation fault
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-website/-/issues/11703rd Party App: Link submission2017-08-26T22:33:52ZGitlab Bot3rd Party App: Link submissionAdd amptracker.com to the 3rd party apps section.Add amptracker.com to the 3rd party apps section.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/23dead link check2018-05-14T02:24:00ZJack Moffittdead link checkA dead link check needs to be performed for all sites, and those links need to
be fixed deleted. Is there an automated commandline tool that we can run
nightly on the server to do this?A dead link check needs to be performed for all sites, and those links need to
be fixed deleted. Is there an automated commandline tool that we can run
nightly on the server to do this?Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2255Invalid XML in Icecast statistics output due to lack of escaping2018-04-16T22:12:13ZThomas B. RückerInvalid XML in Icecast statistics output due to lack of escapingIcecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9...Icecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9.2</IP>
<UserAgent>Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 [FBAN/FBIOS;FBAV/46.0.0.54.156;FBBV/18972819;FBDV/iPhone5,3;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.3;FBSS/2; FBCR/AT&T;FBID/phone;FBLC/en_US;FBOP/5]</UserAgent>
<Connected>0</Connected>
<ID>2634887</ID>
</listener>
</source>
</icestats>
```
Note the unescaped &T; which is an undefined XML entity "T", and causes parsers to explode.
Expected behavior: text inside blocks should be html escaped or enclosed in a CDATA block, if I remember my XML correctly.
[Originally reported on github](https://github.com/xiph/Icecast-Server/issues/3) by [kenrestivo](https://github.com/kenrestivo)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2283Streaming over SSL disconnects2020-02-26T00:04:46ZBrendonStreaming over SSL disconnectsI reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications ar...I reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications are all served over SSL.
In order to avoid mixed content warnings, I built Icecast 2.4.3 with SSL support so I could get status info and serve the stream over SSL as well.
(None of the Debian or Ubuntu packages have been built with SSL yet for some reason.)
I'm using Debian 8 x64. libssl is 1.0.1t (which is the latest 1.0.1 LTS version). liquidsoap 1.1.1 is the source and connects to Icecast via port 80 on localhost (both liquidsoap and icecast are on the same VM).
I have six mounts configured all the same. liquidsoap is re-encoding the mp3s at a constant bitrate of 128k. I've uploaded a stripped down Icecast config.
Here is what happens: normally, streaming over SSL works perfectly fine. But sometimes, either right at stream start or at some seemingly random amount of time later, one of the mounts becomes "corrupted." The web player (using a simple <audio> tag) quickly buffers and disconnects. VLC reconnects and gets disconnected over and over.
I've tested this on my local network over wifi using the web player, VLC, and iTunes, and with ServeStream on Android over cellular. All same result.
If I connect to the stream via port 80, I do not get disconnected. I get disconnected from the stream ONLY when streaming over SSL and ONLY when the mount becomes corrupted.
Observations:
- This happens on every mount seemingly at random, but it seems that only ONE mount becomes corrupted at a time.
- Doesn't seem to be triggered by any one song, a track change, or anything else station related that I can find.
- Happens if I use ogg or mp3.
- Shutting down the liquidsoap instance for the corrupted mount, waiting a minute or so (a quick restart doesn't seem to fix it) and then restarting liquidsoap seems to resolve the issue (at least temporarily).
- Nothing in the logs that I can see, even with debug logging on:
[2016-08-21 20:30:08] DBUG stats/modify_node_event update "/electronic" listeners (1)
[2016-08-21 20:30:08] DBUG format/format_check_http_buffer processing pending client headers
[2016-08-21 20:30:08] DBUG client/client_send_bytes Client connection died
[2016-08-21 20:30:08] DBUG source/source_main Client removed
[2016-08-21 20:30:08] INFO source/source_main listener count on /electronic.mp3 now 0
These cycle over and over again as the client disconnects and reconnects. I can find nothing else in any of the logs on the system.
- This happens on both staging and production which is on two separate servers.
I was asked to run Icecast using valgrind. We saw lots of SSL errors, so one possible issue could be a buggy system libssl (which I do not think is the case at this point). I even got the latest OpenSSL 1.0.2h built and then built Icecast against that to rule out 1.0.1t causing a bunch of errors.
I will upload the Valgrind output for both 1.0.1t and 1.0.2h.
I simply started Icecast and then shut it down via ctrl-c. This was NOT running while experiencing a corrupted mount.
That's about as much information as I think I have at this point. I have decided to abandon using SSL for the streams as it simply does not seem to be production ready at this point. This will cause mixed content errors in our applications, but streaming over http seems much more stable.
I'd be happy to help provide more information if requested.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2060Typos in Vorbis I specification2017-11-01T04:49:44ZstefanTypos in Vorbis I specificationWhile reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
...While reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
_"window_blocksize(previous_window)/4+window_blocksize(current_window)/4"_
(remove the backslashes)
*Section 10.1*
_"The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the following values (read left to right then top to bottom):"_
_"consiting"_ should read _"consisting"_
It would mean a lot to me if you have time to fix them.https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1676vorbis-tools: ogg123 plays speex files wrong: lou and distorted2018-01-22T04:18:25ZJohn Ferlitovorbis-tools: ogg123 plays speex files wrong: lou and distortedOriginal debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312185
Sample file at http://www.metadecks.org/software/sweep/audio/demos/female_scrub.spx
PLays fine under mplayer. But under ogg123 sounds very distored, might be ...Original debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312185
Sample file at http://www.metadecks.org/software/sweep/audio/demos/female_scrub.spx
PLays fine under mplayer. But under ogg123 sounds very distored, might be clipping?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/icecast-ices/-/issues/1785[PATCH] spec file for building RPM of ices2017-11-05T22:14:59ZDave Miller[PATCH] spec file for building RPM of icesI wanted to install ices on an RPM-based system and although the compile is dead simple, it's still nice to keep track of stuff. I noticed there's a debian/rules for making a deb, but no spec file for making an RPM, so I made one (attac...I wanted to install ices on an RPM-based system and although the compile is dead simple, it's still nice to keep track of stuff. I noticed there's a debian/rules for making a deb, but no spec file for making an RPM, so I made one (attached).
It'll need to be updated with the version number at the top when the version changes.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/1747libogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to...2021-09-27T21:10:42ZMax Hornlibogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to be uncompilableTrying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw...Trying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c -o analysis.lo analysis.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c analysis.c -fno-common -DPIC -o .libs/analysis.o
In file included from /sw/include/ogg/ogg.h:25,
from analysis.c:21:
/sw/include/ogg/os_types.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint16_t'
/sw/include/ogg/os_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint32_t'
```
Analysis: os_types.h contains this:
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
typedef int16_t ogg_int16_t;
typedef u_int16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef u_int32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
```
However, the types u_int16_t and u_int32_t are not defined by inttypes.h resp. stdint.h
Indeed, the correct names for these types as defined by the [spec for stdint.h](http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) (and by transiency for inttypes.h) are uint32_t and uint16_t. So the simple fix is to change these two lines in libogg's os_types.h.
This may affect #elif cases for other ports which incorrectly expect the u_intFOO types to be defined in stdint.h / inttypes.h
Of course the fact remains that checking for __APPLE__ and __MACH__ is a very fragile way to check for types, and that I would still recommend that os_types.h is rewritten to first try whatever types configure detected, and only fallback to such #define hackery if no configure script can be used... See the (now closed) bug + patch #849.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/opus/-/issues/2215Opus encoder blends both audio channels in each audio channel in low bitrates2017-10-21T19:37:05ZPavel ChrpaOpus encoder blends both audio channels in each audio channel in low bitratesIn low bitrate encoding of a stereo file (WAV), the Opus codec seems to blend both audio channel in each audio channel. From my initial testing it seems that the border is around ~38-40kbps and the lower the bitrate is, the more signific...In low bitrate encoding of a stereo file (WAV), the Opus codec seems to blend both audio channel in each audio channel. From my initial testing it seems that the border is around ~38-40kbps and the lower the bitrate is, the more significant this seems. This may be a problem in recording of two speakers, where each of the speaker represent one of the audio channel.
*Steps*:
1. Install opus-tools 0.1.9-1 (e.g. _sudo apt-get install opus-tools_)
2. Encode stereo file by running _opusenc --bitrate 24 --hard-cbr --framesize 60_
3. Play the file and listen to each of the channels separately
*Expected*:
- both channels will retain only their audio footage
*Environment*:
- Ubuntu MATE 15.04 running on Dell Latitude E5430
- WAV info (file available at: [https://drive.google.com/folderview?id=0B_W_T_CohbhsfnNaOGZkb0NzekhKeDZDV2FnbFJTeUV4QzdBaDFPalpGQUdIVkJoTUpIVEk&usp=sharing]):
```
$ mediainfo ~/Desktop/1352389720037_5516_5517_31870.wav
General
Complete name : /home/pavel/Desktop/1352389720037_5516_5517_31870.wav
Format : Wave
File size : 2.81 MiB
Duration : 1mn 32s
Overall bit rate mode : Constant
Overall bit rate : 256 Kbps
Audio
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 1mn 32s
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 8 000 Hz
Bit depth : 16 bits
Stream size : 2.81 MiB (100%)
```
- Opus codec:
```
$ dpkg -l | grep opus
ii libopus0:amd64 1.1-0ubuntu2 amd64 Opus codec runtime library
ii opus-tools 0.1.9-1 amd64 Opus codec command line tools
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/theora/-/issues/1601wrapper script to combine mplayer with theora_encoder_example2017-08-20T01:57:18ZJohn Ferlitowrapper script to combine mplayer with theora_encoder_exampleForwarding a bug upstream from debian.
Hi,
I wrote this small script as a wrapper to actually make theora_encoder_example
useful. Without it, one would have to setup named pipes and mplayer processes
by hand, which is annoying and pos...Forwarding a bug upstream from debian.
Hi,
I wrote this small script as a wrapper to actually make theora_encoder_example
useful. Without it, one would have to setup named pipes and mplayer processes
by hand, which is annoying and possibly a showstopper for less experienced
users. Perhaps you could include it in the package.
https://gitlab.xiph.org/xiph/tremor/-/issues/2176Xiph Tremor code for Ogg decoder2017-09-02T15:25:02ZSonaliXiph Tremor code for Ogg decoderI'm using Xiph Tremor code for OGG-Vorbis decoder.
When 1Khz base frequency with 0db amplitude input signal is given to OGG-Vorbis decoder, clipping is observed in decoded PCM output.
Also in frequency analyzer tool, frequency spectrum o...I'm using Xiph Tremor code for OGG-Vorbis decoder.
When 1Khz base frequency with 0db amplitude input signal is given to OGG-Vorbis decoder, clipping is observed in decoded PCM output.
Also in frequency analyzer tool, frequency spectrum of decoded PCM output has harmonic distortions.
When same input is given to VLC player, output sound is good and frequency response of output is not having any distortions.
Has anyone come across such behavior?
any solution for this?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/1365xiph qt 0-1.1.8 doesn't work2018-04-29T09:16:10Zdneuxiph qt 0-1.1.8 doesn't workI have installed 0.1.8 in a user/library/components and ITunes still could not play ogg, then I also installed it in my root/library/components ir still does not play in ITunes nor in QT,
OSX 10.4.11, MAc G5 dual 2.7GBI have installed 0.1.8 in a user/library/components and ITunes still could not play ogg, then I also installed it in my root/library/components ir still does not play in ITunes nor in QT,
OSX 10.4.11, MAc G5 dual 2.7GBhttps://gitlab.xiph.org/xiph/ezstream/-/issues/1292Shoutcast support2017-08-03T06:12:52ZdavidmazurShoutcast supportI would like to know about the feasibility of supporting shoutcast servers in a future version of ezstream. Couldn't connect to the server after the admin changed to shoutcast from icecast after a drive failure, and after some troublesh...I would like to know about the feasibility of supporting shoutcast servers in a future version of ezstream. Couldn't connect to the server after the admin changed to shoutcast from icecast after a drive failure, and after some troubleshooting I narrowed my problems down to the fact that ezstream doesn't support shoutcast. Extensive googling makes it appear that command line utilities for streaming to a shoutcast server under Windows are currently non-existant. Ezstream previously worked well for me, and it would be great if it could fill the void.Moritz GrimmMoritz Grimm