Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-07-08T22:52:53Zhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/24Missing schemas2022-07-08T22:52:53ZAsh ClarkMissing schemasThe links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.The links to the XSPF schemas (RelaxNG v1, RNG v0, RNC, XSD) give 404s. I was able to use the online validator but would prefer to have a copy of the RNG for use with the oXygen Editor’s auto-validation feature.https://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/squishyball/-/issues/1squishyball fails to build against ncurses-6.3: `error: 'TERMINAL' {aka 'stru...2022-01-25T23:08:20ZSergei Trofimovichsquishyball fails to build against ncurses-6.3: `error: 'TERMINAL' {aka 'struct term'} has no member named 'Nttyb'`It's an upstream report of downstream build failure of `squishyball`: https://github.com/NixOS/nixpkgs/pull/146685#issuecomment-1019808697
`ncurses-6.3` removed from public API `Nttyb` and friends in https://github.com/mirror/ncurses/co...It's an upstream report of downstream build failure of `squishyball`: https://github.com/NixOS/nixpkgs/pull/146685#issuecomment-1019808697
`ncurses-6.3` removed from public API `Nttyb` and friends in https://github.com/mirror/ncurses/commit/493e2f7b3fc309879f561a094fdfc15e5304b3d6 effectively breaking the workaround of https://gitlab.xiph.org/xiph/squishyball/-/commit/ce3fabffc3906a23bec09f02db8fdf141f1d4068.
Full build log: https://hydra.nixos.org/log/8myp7pwz36lg93vkzphq2jm0xk4fq4mr-squishyball-19580.drv
Relevant bit:
```
mincurses.c: In function 'setup_term_customize':
mincurses.c:345:20: error: 'TERMINAL' {aka 'struct term'} has no member named 'Nttyb'
345 | term = cur_term->Nttyb;
| ^~
```https://gitlab.xiph.org/xiph/speexdsp/-/issues/4Compiler warnings with comparing singed and unsigned ints2022-01-23T06:22:59ZAnders JenboCompiler warnings with comparing singed and unsigned intsThese are now the only compiler warnings left when building DevilutionX, would be great if we can handle them so we can start checking for compiler warnings in the CI :)
```
In file included from speex_resampler/resample.c:100:
speex_re...These are now the only compiler warnings left when building DevilutionX, would be great if we can handle them so we can start checking for compiler warnings in the CI :)
```
In file included from speex_resampler/resample.c:100:
speex_resampler/resample_sse.h:45:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (i=0;i<len;i+=8)
~^~~~
speex_resampler/resample_sse.h:62:12: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(i=0;i<len;i+=2)
~^~~~
speex_resampler/resample_sse.h:84:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (i=0;i<len;i+=8)
~^~~~
speex_resampler/resample_sse.h:110:12: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(i=0;i<len;i+=2)
~^~~~
speex_resampler/resample.c:674:20: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (j=0;j<st->filt_len;j++)
~^~~~~~~~~~~~~
speex_resampler/resample.c:946:21: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:949:20: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1001:19: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1008:19: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for(j=0;j<ichunk;++j)
~^~~~~~~
speex_resampler/resample.c:1018:16: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (j=0;j<ochunk+omagic;++j)
~^~~~~~~~~~~~~~
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2344ov_fopen returns undocumented error value2022-01-01T03:49:16ZCarl Banksov_fopen returns undocumented error valueov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open t...ov_fopen is documented as returning one of several error codes, but if the call to fopen fails, it returns -1 (not among the error codes listed).
Recommend to just change documentation to say that a -1 return value means it can't open the file. I'd guess that a lot of the code out in the field just tests if return value is -1.https://gitlab.xiph.org/xiph/flac-website/-/issues/2119Outdated Git URL2021-12-23T15:10:42ZmiaOutdated Git URLThe download page still points to git.xiph.org. Should be updated.The download page still points to git.xiph.org. Should be updated.https://gitlab.xiph.org/xiph/icecast-ices/-/issues/2324Allow building even if libxml2 doesn't ship /usr/bin/xml2-config2022-07-11T00:17:22ZUnit 193Allow building even if libxml2 doesn't ship /usr/bin/xml2-configHowdy,
It seems to be common practice to use pkg-config for these options, but currently if libxml2-dev doesn't contain xml2-config, the package fails to build. The patch below moves to using pkg-config directly.
```
Description: Migr...Howdy,
It seems to be common practice to use pkg-config for these options, but currently if libxml2-dev doesn't contain xml2-config, the package fails to build. The patch below moves to using pkg-config directly.
```
Description: Migrate from using xml2-config to pkg-config
Author: Unit 193 <unit193@debian.org>
---
configure.ac | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/configure.ac 2020-10-07 20:29:12.654454622 -0400
+++ b/configure.ac 2020-10-07 20:29:12.646454694 -0400
@@ -166,9 +166,12 @@
AC_CHECK_FUNCS([gettimeofday ftime])
-XIPH_PATH_XML
-XIPH_VAR_APPEND([XIPH_CFLAGS], [$XML_CFLAGS])
-XIPH_VAR_PREPEND([XIPH_LIBS], [$XML_LIBS])
+PKG_CHECK_MODULES([LIBXML2], [libxml-2.0], [], [
+ AC_MSG_ERROR([${LIBXML2_PKG_ERRORS}. libxml2 is required.])
+])
+
+CFLAGS="${CFLAGS} ${LIBXML2_CFLAGS}"
+LIBS="${LIBS} ${LIBXML2_LIBS}"
XIPH_PATH_SHOUT(, AC_MSG_ERROR([must have libshout installed!]))
if test "$SHOUT_THREADSAFE" != "yes"
```https://gitlab.xiph.org/xiph/icecast-ices/-/issues/2323Ignores 'allow-repeats' setting when checking ogg serial2021-12-17T22:18:42ZUnit 193Ignores 'allow-repeats' setting when checking ogg serialOriginally reported in Debian bug [463351](https://bugs.debian.org/463351):
> I currently have a playlist that contains one file, so obviously I need
> to set 'allow-repeats'. However, even with that setting enabled, it
> won't repeat ...Originally reported in Debian bug [463351](https://bugs.debian.org/463351):
> I currently have a playlist that contains one file, so obviously I need
> to set 'allow-repeats'. However, even with that setting enabled, it
> won't repeat the one file because the serial matches (even if I make a
> copy of the file and add the copy to the playlist).
>
> I've changed im_playlist.c so that it checks pl->allow_repeat before
> checking the serial (patch attached).
And as such, it seems we've carried the following patch for the past 10(!) years:
```
Description: allow 'allow-repeats' setting when checking ogg serial
Author: C. Chad Wallace <cwallace@lodgingcompany.com>
Origin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463351#10
Bug-Debian: http://bugs.debian.org/463351
Forwarded: not-needed
---
src/im_playlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/src/im_playlist.c 2020-10-07 20:28:50.166655764 -0400
+++ b/src/im_playlist.c 2020-10-07 20:28:50.158655836 -0400
@@ -174,7 +174,7 @@
{
if (ogg_page_bos (&og))
{
- if (ogg_page_serialno (&og) == pl->current_serial)
+ if (!pl->allow_repeat && ogg_page_serialno (&og) == pl->current_serial)
LOG_WARN1 ("detected duplicate serial number reading \"%s\"", pl->filename);
pl->current_serial = ogg_page_serialno (&og);
```https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2333Support 30X Redirects2021-11-18T14:26:16ZJamie WoodsSupport 30X RedirectsIt would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regi...It would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regional clusters of servers)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/libao/-/issues/2322dynamic linking: initialize fails/crashes2021-10-22T19:06:35Zminttydynamic linking: initialize fails/crashesI'm trying to link libao dynamically, using dlopen.
It fails (i.e. crashes) on ao_initialize, however, while all other functions work as I can verify by a split up configuration, linking ao_initialize statically and all others dynamically.I'm trying to link libao dynamically, using dlopen.
It fails (i.e. crashes) on ao_initialize, however, while all other functions work as I can verify by a split up configuration, linking ao_initialize statically and all others dynamically.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2332Patch for macOS >= 11.x2021-10-26T13:06:10ZMichka PopoffPatch for macOS >= 11.xHi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically lo...Hi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically loading the library with
dlopen under some modes:
```
diff -u libshout-2.4.5-old/configure libshout-2.4.5/configure
--- libshout-2.4.5-old/configure 2021-10-21 12:28:29.000000000 +0200
+++ libshout-2.4.5/configure 2021-10-21 12:31:31.000000000 +0200
@@ -7582,17 +7582,12 @@
_lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
darwin1.*)
_lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- darwin*) # darwin 5.x on
- # if running on 10.5 or later, the deployment target defaults
- # to the OS version, if on x86, and 10.4, the deployment
- # target defaults to 10.4. Don't you love it?
- case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
- 10.0,*86*-darwin8*|10.0,*-darwin[91]*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
- 10.[012]*)
- _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- 10.*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+ darwin*)
+ case ${MACOSX_DEPLOYMENT_TARGET},$host in
+ 10.[[012]],*|,*powerpc*)
+ _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+ *)
+ _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
esac
;;
esac
```
This is a patch for the configure file, but it should be applied to the the libtool.m4 file. I am not an expert on how you have setup the m4 folder in your project, so I'll let you handle the addition of that patch.
For reference:
https://github.com/Homebrew/homebrew-core/pull/87694Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/18Clarification on order of content resolving and <location>-tags2021-11-10T03:27:52ZPhilipp SchafftClarification on order of content resolving and <location>-tags# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Sug...# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Suggested change
This should be changed and clarified.
Important:
* Such a list should keep in mind `<location>`-, `<link>`-, `<meta>`-, `<extension>`-tags, and "human-readable" elements.
* Keep the difference between transport qualities in mind (e.g. prefer local files over remote files).
* Clarify if finding a fetchable but unrenderable resource is a error condition that should stop rendering the current track. (e.g. if a `<location>`-tag links a FLAC but the player does not support FLAC if it should stop or try other `<location>`-tags to see if it finds a file in a format it supports.)
## Example list
* Try without accessing the network:
* All `<location>`-tags
* Ask your neighbour
* All resources found by fuzzy matching
* Retry with accessing the network.
* Fail
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/16Identifier for "human-readable" elements2021-11-10T03:27:12ZPhilipp SchafftIdentifier for "human-readable" elements# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tag...# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tags provide a very hard link to data while the "human-readable" elements provide a very soft link. The hard links fail when e.g. the playlist is moved or shared. The soft links fail when data is ambiguous or hard to match (e.g. different languages or spellings are used).
# Suggested change
It is suggested to extend the specification by adding an OPTIONAL attribute "`identifier`" to the "human-readable" elements (see list below). This `identifier`-attribute holds a single URI that works the same way as `<identifier>`. The URI itself is considered a machine readable key, however it is not defined what the result is when actually fetching the given resource.
## Special and non-"human-readable" elements the change shall also apply to
* The `<date>`-tag as defined in 4.1.1.2.8: In case of the `<date>`-tag the `identifier`-attribute refers to a specific and exact event (timestamp). This is useful to denote a "at the same time" relation. While use cases are limited the attribute shall be formally allowed.
* The `<image>`-tag as defined in 4.1.1.2.7 and 4.1.1.2.14.1.1.1.7, the `<license>`-tag as defined in 4.1.1.2.9: In case of the `<image>`- or `<license>`-tag the meaning of the `identifier`-attribute is the same as the meaning of the `<identifier>`-tag would be if the image or license would be given as a `<track>`. This allows resolving of well known images/data e.g. without an internet connection. Well known/common images and licenses may be shipped e.g. by the operating system or a player. A player could provide the user with a gallery of default images and as long as the user uses the same player no network traffic is required for those. While when moved/shared the URI from the tag can be used to resolve the image in a different player. This provides a more efficient way than embedding using data:-URIs.
## Possible updates to elements with an `identifier`-attribute
It should be considered to allow but not recommend tags with an `identifier`-attribute to be empty. Even if this change is not accepted it should be considered to require parsers to allow this while forbid generators to generate such playlists. This may also require an namespace update.
## List of "human-readable" elements
* 4.1.1.2.1 title
* 4.1.1.2.2 creator
* 4.1.1.2.3 annotation
* 4.1.1.2.8 date
* 4.1.1.2.14.1.1.1.3 title
* 4.1.1.2.14.1.1.1.4 creator
* 4.1.1.2.14.1.1.1.5 annotation
* 4.1.1.2.14.1.1.1.8 album
# See also
* If a specific behaviour on fetch/specific result is expected <link> provides a way to link additional metadata from external sources.
# Required version updates
This change will not require namespace update. A version update should be considered.
Allowing previously non-empty tags to be empty requires a namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/15Updates to Content resovers: Well known prefix resolving2021-11-10T03:26:51ZPhilipp SchafftUpdates to Content resovers: Well known prefix resolving# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try ot...# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try other "drives".
# Suggested update
I suggest this more general update:
A content resolver is allowed to alter and try URIs from `<location>` tags in the following way if and only if none of the URIs provided by the `<location>` tags could be opened. Such modified URIs SHOULD be tried before trying to resolve content by other means than `<location>` tags.
Content resolvers MAY replace well known prefixes from URIs with valid local variants of them. This included physical mountpoints as well as logical mount points. However content resolvers SHOULD NOT replace prefixes with of one logical type with values of other logical types.
Valid examples:
* `C:\music\bla.ogg -> D:\music\bla.ogg` (physical mount/logical type "drive" is replaced)
* `/home/foo/bla.ogg -> /home/bar/bla.ogg` (logical mount/logical type "home directory" is replaced)
* `C:\Program Files/My Player/Collection/bla.ogg -> /home/foo/Music/bla.ogg` (logical mount/logical type "music collection" is replaced)
Questionable examples:
* `D:\bla.ogg -> /home/foo/Music/bla.ogg` (physical -> logical mount/logical type "drive" -> "music collection"; However valid if D:\ is also known as the root of a music collection)
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/14Clarification on acceptance of relative URIs2021-11-10T03:28:26ZPhilipp SchafftClarification on acceptance of relative URIs# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the ...# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the URI is known to the generator or can be evaluated by the generator.
* Parsers MUST support absolute URIs in all cases and MAY report or reject relative URIs but SHOULD be able to handle them for backward compatibility.
* The content of the `<location>`-tag is excluded from the above rules. Relative URIs are still considered valid.
* Generators SHOULD NOT generate relative URIs in <location> elements that point to a level in a directory structure higher than their own. Generators SHOULD NOT us the parent directory operator ".." in URIs used in `<location>`.¹
In addition the current clarifications on URIs should be kept in the specification as they are relevant at least when working with legacy data. A note might be added clarifying the reason for them to be still present. Such as: "While relative URIs are not valid they may be present in data generated under earlier revisions of this specification, therefore these rules apply when such data is encountered.".
# Required version updates
This change will not require a version or namespace update.
¹ Those are actually two rules as e.g. "a/../b" is not referring to a higher level but makes it more complex for parsers to check.https://gitlab.xiph.org/xiph/rnnoise/-/issues/7using RNNoise in browser2021-08-09T07:44:17ZVishal dhullusing RNNoise in browserhi,i saw the browser implementation of RNNoise,i am curious to know how is this python model is being used in JS ? and where we are initializing it's weight in JS files ?
Thank youhi,i saw the browser implementation of RNNoise,i am curious to know how is this python model is being used in JS ? and where we are initializing it's weight in JS files ?
Thank youhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2274Mountpoint drops and comes back when switching songs via script2021-08-06T20:25:20ZcinderblockgamesMountpoint drops and comes back when switching songs via scriptI'm using
<filename>/ezstream/play-next.sh</filename>
<playlist_program>1</playlist_program>
to take control of the media that gets played, so I can add in stingers and whatever else. The issue, however, is that the mount poin...I'm using
<filename>/ezstream/play-next.sh</filename>
<playlist_program>1</playlist_program>
to take control of the media that gets played, so I can add in stingers and whatever else. The issue, however, is that the mount point drops when switching to the next file. Is there a way to keep this open so that clients don't get dropped and have to reconnect on every changeover?https://gitlab.xiph.org/xiph/libao/-/issues/2321libao's OS X stutters on closing audio2021-07-22T17:22:11ZGonzalo Garramunolibao's OS X stutters on closing audioThe MacOSX plugin in libao results in stutter (crackles) when closing the audio.The MacOSX plugin in libao results in stutter (crackles) when closing the audio.https://gitlab.xiph.org/xiph/opus/-/issues/2358Excessive noise generated by CELT PLC2021-06-24T16:30:44ZFrancis QuiersExcessive noise generated by CELT PLCWe recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-ba...We recently came across a situation where bursty loss resulted in relatively loud noise in output of the Opus decoder.
The previous frames (before the gap) were all encoded as CELT, and since the gap was more than 5 frames, the noise-based CELT PLC eventually got triggered (because of [this piece of logic](https://gitlab.xiph.org/xiph/opus/-/blob/v1.3.1/celt/celt_decoder.c#L531)), and this is when the noise starts.
The problem can be reproduced using the following branch, which is based on tag v1.3.1, plus an extra option in `opus_demo` in order to be able to feed a stream that does not include the "final range" check, but only each packet's length (or 0 for a lost packet) followed by the opus data:
https://gitlab.xiph.org/cisquiers/opus/-/tree/opus_demo_support_for_decoding_external_streams
The commands to run are the following:
```
./autogen.sh
./configure --enable-fixed-point
make
./opus_demo -d 48000 1 -external_stream stream.opus output.pcm
```
Input stream:
[stream.opus](/uploads/92e308f2c6374561db59e63ee5e967e8/stream.opus)
Output raw audio (mono, 16-bit, little-endian, 48kHz):
[output.pcm](/uploads/28f3afc3cf62f57df76f0c951f2feb82/output.pcm)
Note that I tried to reproduce the problem by starting from raw audio (either using silence, or a small negative DC as what the stream decodes to prior to the gap) and encoding it using `opus_demo`, but I wasn't unable to do so.
Unfortunately I don't have access to the original raw audio, or the source code for the client that generated this stream.
I cannot actually guarantee that the encoder that was used was a vanilla Opus release, without any custom modification that could perhaps have generated this (perhaps slightly unusual?) bitstream (particularly the DC offset). However, since the bitstream appears to be valid, perhaps the CELT decoder should still not generate such a noise in output in this case.