Hi everyone, I'm going to take a media player to connect to my TV and since I have a lot of wavpack files (most dsd / wv) I wanted to know if there is a player that supports wavpack dsd .... My idea was this player https://dunehd-europe.com/index.php?page=pro4kplus in whose specifications it says that it supports the wavpack but I would like to be sure that it also supports the dsd compressed in wavpack. If you also have other players to suggest I thank.
Connect a notebook or mini-pc to the TV , control it via a wireless keyboard with built in trackpad like logitech.
Or even any Android smartphone with either the foobar2000 or VLC app, over Wi-Fi too (Miracast).
Me, I'm streaming my WavePack files from a NAS to the whole house.
Unfortunately adoption of WavPack DSD in hardware devices is slow. I have two portable media players (Cowon Plenue R (http://www.jetaudio.com/products/cowon/plenuer/) and Lotoo Paw Pico (http://m.lotoo.cn/en/pico-index.html)) that support both WavPack and DSD, but do not support WavPack DSD.
It's not always obvious why this is, but unfortunately I have not been able to get WavPack DSD into FFmpeg, which I suspect is the most common library out there providing WavPack support. Having a working and tested patch that meets all their rules is not always sufficient to get something into FFmpeg, so for now a player would have to use a recent version of libwavpack to provide DSD support.
In the meantime, the best thing to do is ask the manufactures if the support is there, and ask them to add it if it's not. You can even say the developer is willing to help for free... :)
It's not always obvious why this is, but unfortunately I have not been able to get WavPack DSD into FFmpeg, which I suspect is the most common library out there providing WavPack support. Having a working and tested patch that meets all their rules is not always sufficient to get something into FFmpeg
Finally, WavPackDSD decoder is included in ffmpeg - https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/9a13ed522f361cdc3fa424922d59aca214d55a15
But, if ffmpeg WavPackDSD decoder is multithreared, why wvunpack.exe and wavpack library are single-threaded only?
Because wvunpack.exe and wavpack are the official decoders, and FFmpeg implemented their own from scratch?
Also because it's entirely unneccessary? Unless you're on a potato of a machine, in which case you probably haven't got the threads to spare anyway.
Because wvunpack.exe and wavpack are the official decoders, and FFmpeg implemented their own from scratch?
WavPackDSD decoding in ffmpeg is implemented by bryant himself.
Also because it's entirely unneccessary? Unless you're on a potato of a machine, in which case you probably haven't got the threads to spare anyway.
Decoding 5 channels DSD256 compressed with WavPack in high mode on my core i3 3245 is only 0.8x realtime with single thread and is 2.7x realtime with multithreared decoder. So multithreading is not "entirely unneccessary".
Correction: it is 1.2x realtime with single thread. Still, difference is significant.
Oh, crap. I've never messed with anything higher than DSD64. And that decodes plenty fast, even with PCM conversion in the WavPack library to 1/8th the DSD rate.
... On second thought, I had no idea how slow it was. Sheesh. But at least it's not nearly as slow as DST decompression, which absolutely requires multithreading just to be real time. (F.ex. this DSD64 5.1 rip, encoded to WavPack using -hh, decodes at about 5.6x real time on one core, with PCM downsample. DST decompression of a single track would require at least 4 threads going full tilt to decode in real time.)
Oh well, I guess Bryant chose to prioritize getting it working in FFmpeg first. Maybe multithreaded optimizations can come to the command line and library decoders later?
Absolutely, multithread that for playback purposes. And to speed up correct seam correlation, after all the blocks in a thread set are decompressed, apply a gain offset to each following block so that its start lines up with the end of the previous block, since that's pretty much the only major downside to starting downsampling fresh in the middle of the stream.
First off, I was very surprised to see this go in to FFmpeg. Last time I submitted a patch for this in July I had a lot of back and forth with them and ended up having it rejected for what seemed to me to be an arbitrary reason. This time they pulled it in without a comment and I actually discovered it through Rollin's post!
The FFmpeg library provides everything to make multi-threading easy, and in fact the regular WavPack PCM decode (which I didn't write) has been multi-threaded all along (although it's fast enough that multi-threaded is a little silly). Once I added DSD to the framework, the only thing I had to do is figure out how to perform the final DSD to PCM conversion serially because the FIR filter requires the data from the previous frame to avoid clicks.
And for DSD on limited platforms, being multi-threaded does make a difference. On my RPi 3 (which has 4 cores) it makes it possible to decode and downmix 5.1 DSD64 in realtime (which isn't otherwise), and DSD256 would probably be the same.
As for making the command-line programs or libwavpack multi-threaded, I have thought about this but haven't started. It's not exactly trivial, and programs like Foobar2000 are able to use the library multi-threaded by file for large conversions.