Skip to main content

Recent Posts

1
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%'.
2
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).
3
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...  :)
4
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 :(
5
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.
6
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.
7
Is it possible to get windows 10 accent color with jscript?
8
foo_jesus? If you don't want your config and settings saved foo_jesus would be the last thing to use.
9
Validated News / Re: Opus 1.2 is out!
Last post by Case -
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.
10
Validated News / Re: Opus 1.2 is out!
Last post by jmvalin -
Decoding of Opus 128k on Raspberry Pi 3 A53 (32 bits) takes ~33 MHz

I have tried on two A53 (64 bits) CPUs and 128k foobar2000's decoder required ~21-23 MHz (equally on both)
Maybe this difference is because of 32 and 64 bits or Raspberry Pi 3 is rather slow.
At least some of this would be the difference between 32-bit and 64-bit. There could also be compiler differences, the exact song that was used, and other minor things on top.

P.S. It's also interesting that an encoder requires ~50 MHz (x86)  for 1 channel speech 16 kHz @ 12 kbps.
But it takes less (~35 MHz)  for 2 channels, 48 kHz @ 128 kbps.

Means that SILK/Hybrid performs more analysis than CELT does (?)
The way SILK is structured, decoding is very cheap, but encoding requires more searching. It's not so much analysis like what CELT does when going from complexity 0 to 10, as just optimizing the decisions to minimize rate-distortion.