Skip to main content

Recent Posts

1
Validated News / Re: Opus 1.2 is out!
Last post by kode54 -
Have you checked Homebrew?
2
Validated News / Re: Downtime
Last post by kode54 -
Will the IP be changing? It may be worth setting the current A record to a lower expiration time so any transition is handled quickly.
3
Listening Tests / Re: 192kHz Samples -- But Not Really?
Last post by kode54 -
It's not that it has a 16 bit synth. It's that I use a band-limited synthesizer to compose all of those chip emulators, which quickly simulates super sampling them at their native sample rate and downsampling to the output rate. It works by using pre-downsampled sinc pulses, which are mixed into an accumulator buffer for every synthesized delta, or change in amplitude in the chip waveforms. This accumulator buffer is then summed up into a running total, and a high pass filter is applied to the running total to simulate a leaky circuit and prevent DC offsets from happening too much.

This synthesizer, to remain reasonably fast, operates in 32 bit precision, and outputs 16 bit samples. The actual chips had way less sample precision than 16 bit, more like 8 bit, but they had high sample rates on their side, and high precision was not really necessary for such simple waveforms.
4
Depends on what you are experimenting with in the configuration.

Library > Configure > "Default User Interface" > Import Theme (previously saved Export Theme)

does what you want if you are working on the appearance.
5
AAC - General / Re: EAC and Nero AAC not working
Last post by firewallguy -
I followed the instructions in the Wiki, tried both with and without metadata with the same result.  EAC completes the rip to .wav but then throws up the error at compression because I ticked the 'Check for external programs return code'.

Oher options are as per the wiki, command line options without metadata: '-if %source% -of %dest%'.
6
WavPack / Re: How about multi-threaded wvunpack?
Last post by dutch109 -
Thanks lvqcl, this makes sense. Since ffmpeg does not have the asm optimizations that libwavpack has, it should be slower. Of course, it's always possible that on a particular architecture, having the right -mtune could make ffmpeg faster on that machine.

On my system (Arch Linux, core i7 950), FFmpeg is compiled with -march=native -mtune=native.
For what it's worth, a quick test (tested WavPack file was encoded with -hhx6):
Code: [Select]
$ wavpack --version
wavpack 5.1.0
libwavpack 5.1.0

$ ffmpeg -version
ffmpeg version 3.3.2 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.1.1 (GCC) 20170516
configuration: --prefix=/usr --extra-cflags=-I/opt/cuda/include --extra-ldflags='-L/opt/cuda/lib64 -Wl,-rpath -Wl,/opt/intel/mediasdk/lib64' --toolchain=hardened --enable-rpath --enable-gpl --enable-version3 --enable-nonfree --disable-static --enable-shared --enable-avresample --enable-cuda --enable-cuvid --enable-libnpp --enable-libmfx --enable-nvenc --enable-omx --enable-omx-rpi --enable-avisynth --enable-chromaprint --enable-decoder=atrac3 --enable-decoder=atrac3p --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gpl --enable-gray --enable-iconv --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcelt --enable-libdc1394 --enable-libfdk-aac --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libilbc --enable-libkvazaar --enable-libmodplug --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopencv --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxcb --enable-libxcb-shm --enable-libxcb-xfixes --enable-libxcb-shape --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lzma --enable-netcdf --enable-openal --enable-opencl --enable-opengl --enable-openssl --enable-sdl2 --enable-vaapi --enable-vdpau --enable-videotoolbox --enable-xlib --enable-zlib
libavutil      55. 58.100 / 55. 58.100
libavcodec     57. 89.100 / 57. 89.100
libavformat    57. 71.100 / 57. 71.100
libavdevice    57.  6.100 / 57.  6.100
libavfilter     6. 82.100 /  6. 82.100
libavresample   3.  5.  0 /  3.  5.  0
libswscale      4.  6.100 /  4.  6.100
libswresample   2.  7.100 /  2.  7.100
libpostproc    54.  5.100 / 54.  5.100

$ cat Vulgar\ Display\ of\ Power.wv > /dev/null

$ time wvunpack -q Vulgar\ Display\ of\ Power.wv -o - > /dev/null

real 0m21,754s
user 0m21,710s
sys 0m0,040s

$ time ffmpeg -loglevel quiet -threads 1 -i Vulgar\ Display\ of\ Power.wv -c:a pcm_s16le -f null /dev/null

real 0m27,633s
user 0m27,530s
sys 0m0,100s

$ time ffmpeg -loglevel quiet -i Vulgar\ Display\ of\ Power.wv -c:a pcm_s16le -f null /dev/null

real 0m7,354s
user 0m47,360s
sys 0m0,190s


So wvunpack is faster than FFmpeg for single threaded decoding, but with 8 threads FFmpeg is a lot faster (as expected).
7
WavPack / Re: How about multi-threaded wvunpack?
Last post by bryant -
FFmpeg's wavpack decoder is multithreaded and is much faster than wvunpack even with 1 thread.

I just tested wavpack 5.1.0 and ffmpeg 3.3.1 and ffmpeg was noticeably slower in single-thread mode.

Thanks lvqcl, this makes sense. Since ffmpeg does not have the asm optimizations that libwavpack has, it should be slower. Of course, it's always possible that on a particular architecture, having the right -mtune could make ffmpeg faster on that machine.

As for the OP, I have thought about how this could be done with pthreads, and it's not that difficult because every WavPack block is independently decodable. The only thing I would worry about would be whether disk I/O would start to become the bottleneck, but based on what you've been doing, that's not the case. This is on my list of things to try one day...  :)
8
Validated News / Re: Opus 1.2 is out!
Last post by bstrobl -
Is anyone still using Win32? I was under the impression everyone was on Win64 by now. Then again, I don't use Windows at all...

I do use 32 bit Windows in a VM for testing purposes (lower resource requirements), no current Mac version available at the moment :(
9
Validated News / Re: Opus 1.2 is out!
Last post by quadH -
Is anyone still using Win32? I was under the impression everyone was on Win64 by now. Then again, I don't use Windows at all...
Are you kidding? I bet there are still more users on 32-bit Windows than there are users on non-Windows desktop OSes. That's at least the data Steam HW survey shows.
The average opusenc user is probably a lot more likely to use 64-bit Windows or a non-Windows OS than the average Steam user.

32-bit Windows compiles should still be provided, though.
10
Validated News / Downtime
Last post by spoon -
Tomorrow (Monday 26th June) Hydrogenaud.io will go down for approximately 30 minutes. This is to transfer it to a backup server as the server it is currently running on is showing early signs of reliability issues.

Any issues please post here so they can be tracked and responded to quickly.