Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-10-05T21:26:53Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2343cmake - neon optimizations doesn't compile on rp2020-10-05T21:26:53ZMarcus Asteborgcmake - neon optimizations doesn't compile on rpReference: https://github.com/xiph/opus/issues/203Reference: https://github.com/xiph/opus/issues/203https://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/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/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/-/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/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/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/Infrastructure/-/issues/2232mf5 requirements2020-07-13T16:20:45ZRalph Gilesmf5 requirements# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help...# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help prioritize.
Several options going forward
- re-install mf4 from scratch, have backups for when it fails again.
- Buy a replacement server (or several).
- Must have remote console support.
- osuosl prefers Dell PowerEdge.
- Use osuosl's openstack cluster.
- Redundant storage (but no geographical replication)
- Don't have to maintain underlying hosts.
- Can still contribute, probably by buying drives for the Ceph cluster.
The raid failure demonstrates we've not been doing a good job with administration. Whatever we do going forward, we need to make sure we have automated offsite backups and that it's much easier to configure and upgrade our various services, ideally from deployment templates stored in version control. We should periodically practice service migration and restoration.
## static sites 🔶
- Partially restored from git or older svn backup + archive.org.
- Served as static html or shtml from catfish.
- Working on auto-deployment from gitlab ci.
- Should move remaining sites from svn to git.
- media.xiph.org is served from beaufish, and wasn't affected.
## dynamic websites
- gitlab.xiph.org ✅
- vm already on catfish
- wiki.xiph.org ✅
- vm aleady on catfish
- dir.xiph.org ✅
- switched to beta vm on catfish
- awcy ✅
- vm already on catfish
- svn.xiph.org
- down, lost data
- ftp.osuosl.org has a current snapshot of releases and websites
- people.xiph.org ❌
- down, lost data.
- planet.xiph.org
- anyone still blogging?
- jenkins ❌
- down, lost data.
- should replace with gitlab-ci.
- munin ❌
- down, not high priority.
- Better replacements?
- review.xiph.org 🔶
- down, have a recent backup.
- not actively used: not planning to restore.
## releases 🔶
- downloads.xiph.org redirects from catfish to ftp.osuosl.org
- ftp site has current files.
- was backed by svn, lost recent history.
- restore svn and re-populate from ftp.osuosl.org?
- alternate: git? gitlab artifacts? Some other object store?
## shell server
- Several people used shell accounts on mf4.
- Do we need to keep providing this?
- Alternate: per-user containers? kubernetes?
## email ✅
- mail and lists already on a catfish vm.
## dns 🔶
- catfish temporarily authoritative
- Need another machine to be secondary
- alternate: Use registrar or osuosl.https://gitlab.xiph.org/xiph/vorbis/-/issues/2342Getting undefined reference to `_impure_ptr' on mingw compilation2020-07-08T14:20:51ZMoritz BenderGetting undefined reference to `_impure_ptr' on mingw compilationI downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.e...I downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: test_sharedbook-sharedbook.o:sharedbook.c:(.rdata$.refptr._impure_ptr[.refptr._impure_ptr]+0x0): undefined reference to `_impure_ptr'
collect2.exe: error: ld returned 1 exit status
```
Compilation did work on my wsl, so I'm not sure what this is about. I managed to get the static library by make -j ing, but I'd still like to know why this part fails and whether there is a way to avoid this.https://gitlab.xiph.org/xiph/vorbis/-/issues/2341Broken MSDN links2020-07-04T02:02:58ZRalph GilesBroken MSDN linksThe api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if ...The api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if the details are still correct. Behaviour may well have changed in the intervening decade.https://gitlab.xiph.org/xiph/opus/-/issues/2325float to short improvements2020-06-16T14:23:47ZMarcus Asteborgfloat to short improvements[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does S...[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does SSE2 even have a proper way to round without messing with rounding modeshttps://gitlab.xiph.org/xiph/opus/-/issues/2318Problem with `SATURATE` and `SROUND16 ` macros?2020-06-16T04:19:34ZVikram DattuProblem with `SATURATE` and `SROUND16 ` macros?Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and rou...Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and round-to-neareast 32-bit value. Result is a saturated 16-bit value */
#define SROUND16(x,a) EXTRACT16(SATURATE(PSHR32(x,a), 32767));
```
1.
As one can see clearly that macros `SATURATE` and `SATURATE16` are not similar when `SATURATE` is used for value 32767 or 32768.
Shouldn't the macro SATURATE be like:
`#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a + 1) ? -(a + 1) : (x)))`
or is it good as it is?
2.
The macro `SROUND16` uses `SATURATE` with value 32767.
Shouldn't it use SATURATE16 instead as it considers lower bound for 16 bits; -32768 as well?
Please note that this will in turn also enable some platform optimised instructions which saturate the value in certain bits.https://gitlab.xiph.org/xiph/libao/-/issues/1834plugin directory cannot be relocated (OS X)2020-06-14T10:13:32ZHans Oesterholtplugin directory cannot be relocated (OS X)I'm using flac123, which in turn uses libao for it's audio output. I'm creating an application to play music on Mac OS X. I compiled Gtk, mpg123, flac123 and libao in a development environment and next I need to install flac123/libao as ...I'm using flac123, which in turn uses libao for it's audio output. I'm creating an application to play music on Mac OS X. I compiled Gtk, mpg123, flac123 and libao in a development environment and next I need to install flac123/libao as part of CuePlay in the /Applications/CuePlay.app directory.
This means that /<home>/workspace/cueplay/lib/ao/plugin-4 is relocated to /Applications/CuePlay.app/lib/ao/plugin-4.
The consequence is that plugins do not load anymore.
I think this is a bug. On Mac OS X, one should be able to install a library with the application and not on a fixed location.
For me this is a blocker, because I can't distribute my (open source) application this way.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2210Warning: Carbon Component Manager is being depricated2020-06-14T10:09:15ZSethWarning: Carbon Component Manager is being depricatedApplications running in OS X 10.11 (El Capitan) have errors stating that Carbon Component Manager is deprecated:
This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support...Applications running in OS X 10.11 (El Capitan) have errors stating that Carbon Component Manager is deprecated:
This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/opus/-/issues/2326undefined behavior in silk_NSQ_del_dec_neon2020-06-14T07:36:42ZRalph Gilesundefined behavior in silk_NSQ_del_dec_neonCompiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behav...Compiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behavior [-Waggressive-loop-optimizations]
422 | NSQ->sLPC_Q14[ i ] = psDelDec->sLPC_Q14[ i ][ Winner_ind ];
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
silk/arm/NSQ_del_dec_neon_intr.c:421:9: note: within this loop
421 | for( ; i < NSQ_LPC_BUF_LENGTH; i++ ) {
| ^~~
```https://gitlab.xiph.org/xiph/opus/-/issues/2320silk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended ...2020-06-14T03:57:12ZRomansilk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended bufferThe problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_OR...The problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_ORDER ];
```
Attempt to read the buffer outside boundaries in silk_LPC_inverse_pred_gain_neon
```C
t0_s16x8 = vld1q_s16( A_Q12 + 0 );
t1_s16x8 = vld1q_s16( A_Q12 + 8 );
t2_s16x8 = vld1q_s16( A_Q12 + 16 );
```
Backtrace of methods
silk_LPC_inverse_pred_gain_neon
silk_NLSF2A
silk_find_LPC_FIXhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/2230Restore vorbis.com redirects2020-05-26T03:44:29ZRalph GilesRestore vorbis.com redirectsIIRC the vorbis.com website was full of obsolete information, so before the server crash we had it redirecting to xiph.org/vorbis. We should restore that.IIRC the vorbis.com website was full of obsolete information, so before the server crash we had it redirecting to xiph.org/vorbis. We should restore that.https://gitlab.xiph.org/xiph/opus/-/issues/2322Autogen failed on Cygwin2020-05-25T17:30:32ZredmanmaleAutogen failed on Cygwin`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoo...`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoolize failed with exit status: 1
```
Maybe it's because `ltmain.sh` is a symlink.
Building from tarball (without autogen) works fine.
**Env**
windows 10 x64
autoreconf 2.69
libtoolize 2.4.6
opus 1.3.1