Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-01-22T04:18:25Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/250Encoding at a wrong bitrate by default2018-01-22T04:18:25Zpmwhite1104Encoding at a wrong bitrate by default```
By default, the advertised bitrate is 80 kbps. However, when you encode a file
without modifying the default bitrate, it's encoded at a nominal bitrate of 64
kbps. If I modify the bitrate to something else, then back to 80 kbps, it w...```
By default, the advertised bitrate is 80 kbps. However, when you encode a file
without modifying the default bitrate, it's encoded at a nominal bitrate of 64
kbps. If I modify the bitrate to something else, then back to 80 kbps, it works
fine.
```starclassstarclasshttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/341encoding broken for blocks !2007-06-23T09:26:42Ztimjencoding broken for blocks !```
the encoding engine encodes junk at the start of ogg
files if blocksizes other than 1024 are used.
a simple test case is created by changing oggenc like:
-#define READSIZE 1024
+#define READSIZE (16 * 1024)
and encoding myencoderbug....```
the encoding engine encodes junk at the start of ogg
files if blocksizes other than 1024 are used.
a simple test case is created by changing oggenc like:
-#define READSIZE 1024
+#define READSIZE (16 * 1024)
and encoding myencoderbug.wav, this happens with
recent CVS as of 20030514.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/474encoding crashes on SunOS due to improper use of `qsort'2017-04-08T10:59:08Zdvdkhlngencoding crashes on SunOS due to improper use of `qsort'```
I just tracked down and fixed a bug on SunOS where each and every attempt to
oggencode a wave-file crashed. Backtrace shows the crash to occur at
psy.c:_vp_noise_normalize_sort,
at the call to `qsort', within the callback `apsort'....```
I just tracked down and fixed a bug on SunOS where each and every attempt to
oggencode a wave-file crashed. Backtrace shows the crash to occur at
psy.c:_vp_noise_normalize_sort,
at the call to `qsort', within the callback `apsort'.
qsort was called with following args:
qsort ((float **) 0xffbfefb8, 8, 4, apsort)
apsort was called with following args:
apsort (a=0xffbfefb4, b=0xffbfefbc)
As one can see 0xffbf4fb4<0xffbfefb8, a array underrun occured. A description
of what seems to be the same problem dates back to 1999:
http://www.geocrawler.com/mail/msg.php3?msg_id=1607386&list=117.
The problem seems to be the "misuse" of qsort, validating the specification:
`apsort' returns `-1' even for equal values. A patch that makes it return `0'
for equals fixes the problem. Patch at:
http://user.cs.tu-berlin.de/~dvdkhlng/bugfix-qsort-20031103.diff
Some more info:
uname -a
SunOS siesta 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-4
gcc --version
gcc (GCC) 3.3.1
~/bin/oggenc --version
OggEnc v1.0 (libvorbis 1.0)
Oggenc also crashed when I tried to run it about half a year ago on an earlier
version of SunOS, here at my university. I didn't do any debugging back then.
Could it be, that this bug affects libvorbis on *all* SunOS installations?
David Kuehling
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/300encoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION2017-04-08T10:59:08Zggyepesiencoding crashes sometimes with EXCEPTION_ACCESS_VIOLATION```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -...```
Encoding in bitrate managed mode crashes sometimes with
EXCEPTION_ACCESS_VIOLATION. I have a sample file deterministically producing
the error with oggenc.exe. Please let me know if you need this file.
> oggenc -r -R 22050 -b 32 -M 128 samples.raw
is the command line producing the error (samples.raw has length 819 200 bytes).
NOTE: encoding in VBR mode succeeds:
C:\oggtools>oggenc -r -R 22050 -b 32 -M 128 samples.raw
Enabling bitrate management engine
Encoding "samples.raw" to
"samples.ogg"
at average bitrate 32 kbps (no min, max 128 kbps),
using full bitrate management engine
Encoding [ 0m02s so far] |
crashes while
C:\oggtools>oggenc -r -R 22050 -b 32 samples.raw
Encoding "samples.raw" to
"samples.ogg"
at approximate bitrate 32 kbps (VBR encoding enabled)
Encoding [ 0m01s so far] -
Done encoding file "samples.ogg"
File length: 0m 09.0s
Elapsed time: 0m 01.0s
Rate: 9.2880
Average bitrate: 38.0 kb/s
succeeds.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/opus/-/issues/2224Encoding gives different result on x86(Mac) and Arm(iPhone)2017-10-21T19:37:05ZDaniel ArmyrEncoding gives different result on x86(Mac) and Arm(iPhone)For some reason, my standard test vector does not encode to the same data on my Mac(x86) as on my iPhone(Arm). Specifically, the results are almost the same except for a few bytes in the middle of the second frame.
I have (or rather wil...For some reason, my standard test vector does not encode to the same data on my Mac(x86) as on my iPhone(Arm). Specifically, the results are almost the same except for a few bytes in the middle of the second frame.
I have (or rather will) attach a self-contained C file that illustrates the issue and the script I used to build the opus lib.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/524Encoding in status.xsl2018-03-06T12:50:22ZzverekEncoding in status.xsl```
The problem is: can't see right non-english (russian) id3 mp3 tags text in
status.xsl. fexed by adding `encoding="iso-8859-1"` in xsl:output tag. I've
been told it _shouldn't_ help, but it did. So probably there is a bug some
wher...```
The problem is: can't see right non-english (russian) id3 mp3 tags text in
status.xsl. fexed by adding `encoding="iso-8859-1"` in xsl:output tag. I've
been told it _shouldn't_ help, but it did. So probably there is a bug some
where..
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/578Encoding large number of files in one go crashes system2007-06-17T08:51:57ZGitlab BotEncoding large number of files in one go crashes system```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Qual...```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Quality: 6, no special options), the whole system reproducibly froze (3x) after
approximately 1 GB of source data had been processed.
Suspecting OggDrop, I generated a batch file that individually called oggenc for
each one of the remaining 200 files. Running the batch file in turn reproducibly
led (4x) to a blue screen (IRQL_NOT_LESS_OR_EQUAL variety). The crash once again
occured after about 1 GB of source data.
I have just finished encoding all files by dropping the remaining 100 files into
OggDrop *one CD at a time* without incident.
I do not think that the actual file content has anything to do with the problem,
as the files affected by crashes were all handled without problems when I
subsequently resumed encoding with the exact same file.
My system is stable and I think I can rule out completely unrelated causes for
the crashes, which occurred exactly, and only, when I used OggDrop/OggEnc. I had
extensively used OggDrop before without any problems, but only for one CD at a
time.
Of course, it is possible or even probable that the actual fault does not lie
with OggEnc/OggDrop, but the Windows Kernel/Explorer and was merely triggered
through the interaction with OggEnc. Still, I find my system's behavior quite
bizarre. While I could at least in principle imagine how a large number of files
could crash OggDrop, I have no idea why OggEnc should be affected by being run
50 times in a row.
I know this bug report is only partially helpful - if I can reproduce the blue
screen one more time, I will add the detailed information (especially which
module caused it).
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/libao/-/issues/37Encoding quality (mostly voice)2006-06-12T10:46:56ZGitlab BotEncoding quality (mostly voice)```
Hi,
I have compared an OGG beta 4 audio file with AAC (fraunhofer encoder) and MP3
(fraunhofer encoder) all encoded at 128kbps.
OGG seems to be able to produce a highter quality audio file.
I only have one comment about voice encodi...```
Hi,
I have compared an OGG beta 4 audio file with AAC (fraunhofer encoder) and MP3
(fraunhofer encoder) all encoded at 128kbps.
OGG seems to be able to produce a highter quality audio file.
I only have one comment about voice encoding. I know this is still a beta
version (perhaps close to release) but I can definitely hear a loss in the
voice encoding.
Song: Tori Amos - Cornflake Girl.
I am using oggdrop.exe beta 4.
Let me know if you need more details.
Thanks,
Gianluca.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/theora/-/issues/2287encoding: x86 assembler code in versions >20071116 (possibly >= 1.0 ?) trigge...2017-08-20T01:57:18Zztsdztsdencoding: x86 assembler code in versions >20071116 (possibly >= 1.0 ?) triggers segfaults when linked to musl libcx86 assembler code in libtheora versions >20071116 (possibly >= 1.0 ?) seems to trigger segfaults when linked to musl libc.
The segfaults appear reliably but depend on both the input data and the quality settings. A higher quality setti...x86 assembler code in libtheora versions >20071116 (possibly >= 1.0 ?) seems to trigger segfaults when linked to musl libc.
The segfaults appear reliably but depend on both the input data and the quality settings. A higher quality setting correlates to crashing easier.
This is observed when building against musl, independent of musl versions, affects builds here and otherwise in Alpine Linux where ffmpeg exhibits the same problem when encoding to Theora.
Disabling the assembler optimizations with configure --disable-asm produces working tools in my tests.https://gitlab.xiph.org/xiph/libao/-/issues/1005enhacements for libao 0.8.62006-07-19T08:07:47ZGitlab Botenhacements for libao 0.8.6it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound ...it is mentioned in the TODO file of libao 0.8.6-1 (from debian sarge) that it is a "TODO" that libao do on the fly sample rate conversion.
it would be nice that converted to 2 channels if number of channels is not supported by the sound card (e.g. my i810 only supports 2 channels)
it would be useful that ao_open_live returned a detailed description of the error when failing, since now it only returns NULL and sends things like "libao - OSS cannot set channels to 1" to stderr.
and also it would be nice a uniform method for selecting which sound card to use. say, sound card number n, with 0<=n. currently oss and alsa09 have different options for selecting sound card number and it needs a device name.Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/opus/-/issues/1926Enhanced spatialization can lead to high-frequency swishiness after mixing do...2018-11-26T18:44:40ZkarlnordstromEnhanced spatialization can lead to high-frequency swishiness after mixing down to monoEnhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in ster...Enhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in stereo, and
2. the decoder side mixes the audio down to mono.
This can occur when the receiving side has a mono speaker. This is likely to occur in multi-chat with a mix of devices doing hands-free communication.
Reproducing the problem:
1. Capture far-field (across the room) speech with stereo mics.
2. Encode and decode with Opus.
3. Mix down to mono.
4. Listen.
Expected result:
Mono audio without audio artifacts.
Observed result:
High frequency "swishiness" due to high-frequency phase issues.
One (sub-optimal) solution is to just use the right or left channel for the mono signal instead of mixing the audio down to mono. However, this means that the mono signal will lose key information from the other channel.
The following patch eliminates the above-mentioned artifacts by not doing additional spatialization:
```
$ git diff
diff --git a/celt/bands.c b/celt/bands.c
index 62f0ee7..f493a81 100644
--- a/celt/bands.c
+++ b/celt/bands.c
@@ -794,7 +794,7 @@ static void compute_theta(struct band_ctx *ctx, struct split_ctx *sctx,
} else if (stereo) {
if (encode)
{
- inv = itheta > 8192;
+ inv = 0; // Don't reverse phase. leads to high-freq "swishiness" on mixdown to mono.
if (inv)
{
int j;
```
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/2323Equivalent bitrate calculation is broken for <20ms frame sizes2020-05-26T04:56:56ZHector MartinEquivalent bitrate calculation is broken for <20ms frame sizesThis leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2...This leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2.5`
Yields output that, when mono downmixed, sounds completely terrible, which definitely shouldn't happen at those bitrates (phase inversion intensity stereo should not be used).
Fix: [0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch](/uploads/0cc8ff9d0576f97bfad81e649c8e67ec/0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/895error : xmlEncodeEntitiesReentrant : char out of range2018-03-06T12:49:49ZJ.Antonioerror : xmlEncodeEntitiesReentrant : char out of rangeI am receiving the following error: "error : xmlEncodeEntitiesReentrant : char out of range
It happens when a station is sending accents within the metatags.
For example: "La Estación de la Asociación Mexicana de Pediatría" appears as ...I am receiving the following error: "error : xmlEncodeEntitiesReentrant : char out of range
It happens when a station is sending accents within the metatags.
For example: "La Estación de la Asociación Mexicana de Pediatría" appears as "La Estaci??e la Asociaci??exicana de Pediatría".
Happens with any source client I have tried: Sam, Oddcast, etc.
It totally breaks the status.xsl ... for example, "Radio Pediatría" turns into "Radio Pediatr?/td>" (it eats away the < in front of the </td>) and this in turns breaks other applications which read the stats from status.xls... like Sam2.
We have experienced this issue because most of our stations use accents.Icecast 2.3Karl HeyesKarl Heyeshttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/3Error by llvm MemorySanitizer2023-01-29T17:10:05ZPhilipp SchafftError by llvm MemorySanitizerCurrently the CI fails with a MemorySanitizer error when compiled with clang.
From IRC:
> based on the error message and 'quelle: internet' it seems that it's a brokeness in llvm.
> I *think* it is triggered by librhash trying to check ...Currently the CI fails with a MemorySanitizer error when compiled with clang.
From IRC:
> based on the error message and 'quelle: internet' it seems that it's a brokeness in llvm.
> I *think* it is triggered by librhash trying to check if it has optimised code it can load for the given platform.
> the problem with false positives however is that if you blindly ignore them maybe one day a true positive is around to hit you from behind.
I'm not sure if skipping that step is the right thing. However it clearly seems to be an option to me at this point.
Generally libigloo does a lot of low level memory management. Hence it's good to have those extra checks.https://gitlab.xiph.org/xiph/theora/-/issues/1335error during make check2008-04-11T06:09:39ZGitlab Boterror during make check```
granulepos.c:107: th_granule_frame returned incorrect results
FAIL: granulepos
...[cut]...
PASS: granulepos_theora
===================
1 of 9 tests failed
===================
``````
granulepos.c:107: th_granule_frame returned incorrect results
FAIL: granulepos
...[cut]...
PASS: granulepos_theora
===================
1 of 9 tests failed
===================
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2434Error GPG key sign for repository (update needed on icecast.org)2022-04-12T12:00:45ZNicolas DerambureError GPG key sign for repository (update needed on icecast.org)Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and...Hello,
I've installed the icecast2 package from the opensuse repository some weeks ago doing this :
`sh -c "echo deb http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/ ./ >>/etc/apt/sources.list.d/icecast.list"`
and :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`
Then I gave more weight to the package from opensuse repository using APT pinning in order to download from opensuse and not from debian official repositories.
But today, doing apt update, I get this error :
`W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10 ./ InRelease: The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>
W: Failed to fetch http://download.opensuse.org/repositories/multimedia:/xiph/Debian_10/./InRelease The following signatures were invalid: EXPKEYSIG 77EC2301F23C6AA3 multimedia OBS Project <multimedia@build.opensuse.org>`
It seems the key is not signing correctly the repository now.
I've done again the command :
`wget -qO - http://icecast.org/multimedia-obs.key | sudo apt-key add -`, but the error still persists.
Any change on your side ?
Side question : do you plan to make an icecast package for Debian 11 too ? We need to keep an old server on Debian 10 only for Icecast, and we'll be enchanted to switch it off ;)
Thx !https://gitlab.xiph.org/xiph/theora/-/issues/1144Error in Theora Format Specification2017-04-07T23:20:35ZpmuetError in Theora Format SpecificationThere is an error in the Theora I Specification, linked here: www.xiph.org/theora/doc/Theora_I_spec.pdf (December 21, 2006 version). On page 53, section 6.4.3 Computing a Quantization Matrix.
The erronous statements read:
```
sum from q...There is an error in the Theora I Specification, linked here: www.xiph.org/theora/doc/Theora_I_spec.pdf (December 21, 2006 version). On page 53, section 6.4.3 Computing a Quantization Matrix.
The erronous statements read:
```
sum from qrj = 0 to qri - 1 of qi >= QRSIZES[qti][pli][qrj]
sum from qrj = 0 to qri of qi <= QRSIZES[qti][pli][qrj]
```
They should read:
```
sum from qrj = 0 to qri - 1 of QRSIZES[qti][pli][qrj] >= qi
sum from qrj = 0 to qri of QRSIZES[qti][pli][qrj] <= qi
```https://gitlab.xiph.org/xiph/vorbis/-/issues/279error in use of qsort2017-04-08T10:58:44ZThomas Gerekeerror in use of qsort```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler...```
the files lib/sharedbook.c, lib/psy.c and lib/lsp.c use the c function qsort
with wrong argument function. The compare functions sort32a, apsort and comp
return a value not zero even if the compared values are equal. with my compiler
(watcom 11.0a) the decoder hangs in qsort called in lib/sharedbook.c. if an
extra compare is added, all is fine.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/2178error message when installing xiphQT 0.1.9 on MacBook OS X 10.10.22018-04-29T09:16:10Zraphaelerror message when installing xiphQT 0.1.9 on MacBook OS X 10.10.2/Volumes/XiphQT\ 0.1.9/XiphQT.component/Contents/MacOS/XiphQT ; exit;
-bash: /Volumes/XiphQT 0.1.9/XiphQT.component/Contents/MacOS/XiphQT: cannot execute binary file/Volumes/XiphQT\ 0.1.9/XiphQT.component/Contents/MacOS/XiphQT ; exit;
-bash: /Volumes/XiphQT 0.1.9/XiphQT.component/Contents/MacOS/XiphQT: cannot execute binary fileArek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1889Error pages needs update2018-03-06T12:49:48ZPhilipp SchafftError pages needs updateThe error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has le...The error pages generated by icecast are currently hardcoded. Some contain invalid HTML.
Please provide a valid but very simple HTML file for the HTTP errors 400 and 404. I will also take such error pages for 401 and 403 but that has less priority.
The pages (except for 401) all take an string telling the user about the error. Please just leave '%s' in the 'template' where it should go.
current pages look like this:
```
<b>%s</b>
```Icecast 2.4.0Thomas B. RückerThomas B. Rücker