Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-09-29T09:18:55Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2341Mono file size is larger than Stereo file size, for same content and settings...2020-09-29T09:18:55ZTonuricsMono file size is larger than Stereo file size, for same content and settings. [Stereo uses lower bitrate.]Hello, I have some old Mono audio recordings from a CD that are stored in Stereo FLAC files. If I transcode one into a Stereo OPUS file using:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -metadata...Hello, I have some old Mono audio recordings from a CD that are stored in Stereo FLAC files. If I transcode one into a Stereo OPUS file using:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -metadata replaygain_album_gain= -metadata replaygain_album_peak= -metadata replaygain_reference_loudness= -metadata replaygain_track_gain= -metadata replaygain_track_peak= -af volume=replaygain=album -loglevel quiet ./output.opus`
Results in a 7,299,479 byte (7.0 MiB) file.
```
encoder=Lavc58.91.100 libopus
Pre-skip: 312
Playback gain: 0 dB
Channels: 2
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 7299479 bytes (overhead: 0.656%)
Playback length: 6m:04.933s
Average bitrate: 160 kbit/s, w/o overhead: 159 kbit/s
```
Since the audio is Mono: I thought it would be interesting to throw away the right channel. And I used this command to transcode:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -map_channel 0.0.0 -metadata replaygain_album_gain= -metadata replaygain_album_peak= -metadata replaygain_reference_loudness= -metadata replaygain_track_gain= -metadata replaygain_track_peak= -af volume=replaygain=album -loglevel quiet ./output.opus`
Results in a 8,804,150 byte (8.4 MiB) file.
```
encoder=Lavc58.91.100 libopus
Pre-skip: 312
Playback gain: 0 dB
Channels: 1
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 8804150 bytes (overhead: 0.556%)
Playback length: 6m:04.933s
Average bitrate: 193 kbit/s, w/o overhead: 191.9 kbit/s
```
Which was surprising, as I expected little to no difference between the file sizes. It appears that OPUS is using a bitrate of 160k for the Stereo version, instead of the requested 192k bitrate [which is being used in Mono].
To ensure this wasn't an issue coming from ffmpeg, I transcoded the same file using opusenc:
`opusenc --bitrate 192k ./input.flac ./output.opus`
Results in a 7,307,706 byte (7.0 MiB) file.
```
ENCODER=opusenc from opus-tools 0.2
ENCODER_OPTIONS=--bitrate 192k
Pre-skip: 312
Playback gain: -12.2891 dB
Channels: 2
Original sample rate: 44100 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 7307706 bytes (overhead: 0.667%)
Playback length: 6m:04.933s
Average bitrate: 160.2 kbit/s, w/o overhead: 159.1 kbit/s
```
Which are virtually the same results as ffmpeg.
This seems like a bug. At the very least, I would expect the Stereo bitrates to be closer to 192k.
Or maybe this some sort a Mono documentation issue? [i.e. VBR doesn't work?]
Thanks for reading.
System details:
```
Linux 5.8.12-arch1-1 #1 SMP PREEMPT Sat, 26 Sep 2020 21:42:58 +0000 x86_64 GNU/Linux
ffmpeg n4.3.1
libopusenc 0.2.1
opusenc opus-tools 0.2 (using libopus 1.3.1)
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2393playlist.log not supporting Unicode/UTF-8 chars2021-10-26T00:48:31ZMike Mackayplaylist.log not supporting Unicode/UTF-8 charsWhen a songs metadata contains Unicode/UTF-8 Chars, the playlist.log file is not writing them correctly. For example, when playing a track by Björk, the Artist name was correctly shown on the stream and in the main web GUI, however the p...When a songs metadata contains Unicode/UTF-8 Chars, the playlist.log file is not writing them correctly. For example, when playing a track by Björk, the Artist name was correctly shown on the stream and in the main web GUI, however the playlist.log file had "Bj?rk" instead.https://gitlab.xiph.org/xiph/opus/-/issues/2340CMake - Improve compiler checks for intrinsics and prefix definitions with CO...2020-09-11T21:54:39ZMarcus AsteborgCMake - Improve compiler checks for intrinsics and prefix definitions with COMPILER_reference: https://github.com/xiph/opus/issues/198
set(SSE1_SUPPORTED 1 PARENT_SCOPE)
COMPILER_SSE1_SUPPORTED etcreference: https://github.com/xiph/opus/issues/198
set(SSE1_SUPPORTED 1 PARENT_SCOPE)
COMPILER_SSE1_SUPPORTED etchttps://gitlab.xiph.org/xiph/opus/-/issues/2339libopus 1.2.1 - Windows - Integer division by zero2020-09-01T20:43:17ZAlexander Matveevlibopus 1.2.1 - Windows - Integer division by zeroHi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(6...Hi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(693)
opus_decode + 218 (edited) \src\opus_decoder.c(782)
Unhandled exception at (edited): Integer division by zero.
/* Number of output samples */
*nSamplesOut = silk_DIV32( nSamplesOutDec * decControl->API_sampleRate, silk_SMULBB( channel_state[ 0 ].fs_kHz, 1000 ) );
We do not know how we can reproduce this issue. We started seeing this issue a year ago and we still receive these crash reports.
Please investigate the issue or suggest us what we should debug.
Thank you for helping!
Alexhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2319Building errors2020-10-21T08:53:09ZAtomtmBuilding errorsTrying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libsho...Trying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libshout, please wait....
aclocal -I m4
autoheader
libtoolize --automake
automake --add-missing
configure.ac:235: error: required file 'src/common/net/Makefile.in' not found
configure.ac:235: error: required file 'src/common/timing/Makefile.in' not found
configure.ac:235: error: required file 'src/common/thread/Makefile.in' not found
configure.ac:235: error: required file 'src/common/avl/Makefile.in' not found
configure.ac:235: error: required file 'src/common/httpp/Makefile.in' not found
src/Makefile.am:22: error: required directory src/common/avl does not exist
src/Makefile.am:22: error: required directory src/common/net does not exist
src/Makefile.am:22: error: required directory src/common/timing does not exist
src/Makefile.am:22: error: required directory src/common/httpp does not exist
src/Makefile.am:6: error: required directory src/common/thread does not exist
```
when using `./autogen.sh`. Any ideas please ?https://gitlab.xiph.org/xiph/opus/-/issues/2338cmake: wrong project version propagated to pkg-config file2020-11-21T18:29:34ZDonato Sciarracmake: wrong project version propagated to pkg-config fileWhen building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus pr...When building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus project version: 1.3.1
>>>
the "Opus library version" is propagated in the pkg-config file (at the time of writing 0.8.0). I discovered this while building tag 1.3.1 locally. Including opus in my cmake project as `pkg_check_modules(OPUS REQUIRED "opus")` returned:
> -- Found opus, version 0.8.0
I can live with it locally but I think it would good to fix it!https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2326No git tags2020-08-15T19:17:21ZTomasz KłoczkoNo git tagsLooks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?Looks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2325ogg123: feeding FLAC file via STDIN fails2020-08-13T14:54:45ZSebastian Hübnerogg123: feeding FLAC file via STDIN failsHi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the og...Hi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
> cat HD_2020-01-30_465376506.flac | ogg123 -
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
```
If I give the FLAC file as a normal input it is working:
```
ogg123 HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Playing: HD_2020-01-30_465376506.flac
FLAC stream: 16 bits, 2 channel, 44100 Hz
Artist: Flamingo Pier
Encoded by: **removed**
Heardis_id: HD_2020-01-30_465376506
Title: Boogie Meltdown
ReplayGain (Track): -6.27 dB
ReplayGain Peak (Track): 0.986664
Done.
```
I tried it on Ubuntu 20.04 (vorbis-tools 1.4.0-11) and Ubuntu 18.04 (vorbis-tools 1.4.0-10.1) and both gave me the same error.
Is this a bug or just not possible with FLAC files?
thanks in advance :)https://gitlab.xiph.org/xiph/opus-tools/-/issues/2315Opusenc produces broken samples (wrong quantization) with 24-bit source2020-11-26T19:55:30ZstevenleleOpusenc produces broken samples (wrong quantization) with 24-bit source# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01...# Original Issue
I was encoding a specific sample of music (24 bits, 48 kHz) with `opusenc` in `opus-tools 0.2 (Opus 1.3)` and noticed a significant artifact in the beginning.
**More description:** You can hear the artifact within 00:01. It's a broken "boom"-like sound.
Check the image below. The waveform graph has significant changes.
![comparison](/uploads/c4cc70aaf6ce4a578820caeb699f80dc/comparison.png)
This is how I encoded:
```
>opusenc sample.flac --bitrate 256 sample.opus
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2993392 bytes, 4555 packets, 94 pages
Bitrate: 261.351 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
# Update
I tried using `FFmpeg` to convert the original file into 16 bits (original is 24 bits).
```
>ffmpeg -i sample.wav -f wav -c pcm_s16le sample_16bit.wav
```
Then I encoded again with the same settings.
```
>opusenc sample_16bit.wav --bitrate 256 sample_16bit.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.3 (audio)
-----------------------------------------------------
Input: 48 kHz, 2 channels
Output: 2 channels (2 coupled)
20ms packets, 256 kbit/s VBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 31.1 seconds
Runtime: 1 second
(91.1x realtime)
Wrote: 2990541 bytes, 4555 packets, 94 pages
Bitrate: 261.103 kbit/s (without overhead)
Instant rates: 1.2 to 510.4 kbit/s
(3 to 1276 bytes per packet)
Overhead: 0.576% (container+metadata)
```
The result turned out to be good.
Check the image below. The waveform graph has **no** significant changes now.
![comparison_2](/uploads/e1d820a879c854670ff562cd4b1e5d1d/comparison_2.png)
So there may be issue in quantization of 24-bit (or high bit depth?) samples.
# Sample Download
The updated sample files are [here](https://www.mediafire.com/file/jiat0cn2cjccu2y/sample_new.7z/file).
All source samples are converted to FLAC files for better compression.
The 16-bit sample is converted from the 24-bit one; the 24-bit one is the original, not padded.https://gitlab.xiph.org/xiph/opus/-/issues/2337cmake - Add some missing options to CMakebuild2022-06-30T05:00:08ZMarcus Asteborgcmake - Add some missing options to CMakebuild--disable-hardening
--enable-fixed-point-debug
--enable-fuzzing
--enable-check-asm
--enable-assertions--disable-hardening
--enable-fixed-point-debug
--enable-fuzzing
--enable-check-asm
--enable-assertionshttps://gitlab.xiph.org/xiph/opus/-/issues/2336cmake - Rename options in CMake to have 1-1 mapping to autotools2020-11-21T06:58:42ZMarcus Asteborgcmake - Rename options in CMake to have 1-1 mapping to autotoolsdisable in autotools should be disable in cmake etc.disable in autotools should be disable in cmake etc.https://gitlab.xiph.org/xiph/opus/-/issues/2335Remove WINCE define from source2020-11-21T06:59:12ZMarcus AsteborgRemove WINCE define from sourceWINCE is no longer relevant platform and defines can be removed from Opus sourceWINCE is no longer relevant platform and defines can be removed from Opus sourcehttps://gitlab.xiph.org/xiph/opus/-/issues/2334cmake - Build all tests and programs for Opus in CMake build2020-08-09T04:24:33ZMarcus Asteborgcmake - Build all tests and programs for Opus in CMake buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildhttps://gitlab.xiph.org/xiph/opus/-/issues/2333cmake - Add Doxygen doc generation to CMakebuild2020-08-09T04:24:52ZMarcus Asteborgcmake - Add Doxygen doc generation to CMakebuildhttps://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://gitlab.xiph.org/xiph/opus/-/issues/2332cmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake build2020-11-21T06:59:41ZMarcus Asteborgcmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake buildCurrently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.Currently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.https://gitlab.xiph.org/xiph/opus/-/issues/2331Enable NEON optimizations for Windows ARM642020-08-09T04:09:13ZMarcus AsteborgEnable NEON optimizations for Windows ARM64Windows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 deviceWindows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 devicehttps://gitlab.xiph.org/xiph/opus/-/issues/2330Make decoder state completely relocatable by avoiding inline pointer to mode2020-08-06T12:42:35ZDan RavivMake decoder state completely relocatable by avoiding inline pointer to modeCurrently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing th...Currently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing this use case is the `mode` pointer at the start of `CELTDecoder`. A clean decoder state on one machine has identical bytes to those of a clean state on another machine with the same architecture, except for possibly the bytes of the `mode` pointer - even when the mode itself is the same.
I'm not sure how to fix this in a way compatible with any custom mode, but it would be nice to be able to do this for the default mode, at least.https://gitlab.xiph.org/xiph/ogg/-/issues/2300Check for overflow on growing buffer2020-08-09T22:44:22ZClément BœschCheck for overflow on growing bufferHi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318Misc memory fixes2020-10-21T08:50:28ZClément BœschMisc memory fixesHi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sy...Hi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch](/uploads/8e33e8f69d5bef238e5b7bcb51df3c92/0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2392Tag for 2.4.4 is missing2024-01-06T20:01:19ZDavid RungeTag for 2.4.4 is missingHi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-serv...Hi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-server/-/tags
It would be very awesome if you could add the tag so that reproducibility can be ensured.Thomas B. RückerThomas B. Rücker