Quote from: lvqcl on 15 December, 2016, 06:48:06 AMSeeking speed or decoding speed?Well that's a very good point. I now realise that either could affect the scan speed. I just tested a 4min track and in flac it took 0.43sec to scan & load. The same track in WavPack took 1.35secs. Now these are not particularly long times, however with long tracks DJ's seem to get antsy if the track doesn't appear in the display almost instantly.
Seeking speed or decoding speed?
One point at last, which does not work out as hoped for - it is written, that wavpack can compress dsd in DSDIFF and thats correct. But very often DSDIFF (dff-files) contain DST-content and this can NOT get converted. The input-file may not be compressed with DST.EDIT:Interestingly the compression-rate is very different in DSD64/128/256.DSD64/256 have a rate between 45 and 50% --> very goodDSD128 has a rate between 20 and 25% --> not that good...Is there a reason for this behaviour?
I don't quite get it, if Wavpacked DSD cannot be played as DSD in Foobar what is the point in using it? wouldn't it make more sense to convert DSD to, say, 44.1/16 PCM with the SACD plugin instead and get way smaller files?
When i transform a dsf to wavpack-file the CPU-load is about 15% and only 4 of the existing 8 kernels are working.What is the reasons for this?
This could certainly be fixed by using some portable threading library (like pthreads) but would be a lot of work (and potential source of bugs) and I figure that encoding is not done often enough to matter.
Should it be "For 5.0.0, the new stream is the default and the CONFIG_OPTIMIZE_MONO flag is ignored" ?
Is there a reason that loading the tags from Wavpack files takes longer?
This is very surprising, but good news...thanks for letting us know!Unfortunately I was not able to try it. The only system I have access to right now is a virtual WinXP machine, and the plugin fails to load (which is a little weird, because the 1.0.3 version loads okay and I have the WavPack DLL in my path in case that's needed).Anyway, based on what Case said above, I am a little concerned about how this might affect Foobar2000 working correctly with WavPack files. You mentioned that the tags seem to be missing, and I wonder if regular WavPack PCM still works at all. If nothing else maybe a new filename extension for WavPack DSD files would help (I would prefer to avoid that however).I suspect that there might be a little work to make this work smoothly, but it's certainly a start.
New information ,foo_input_sacd 1.0.5 Released Tag Mission problem solved! Now Enjoy with wavpack-dsd with Foobar2000!BTW, I',m trying to use command-line tool to convert wavpack-dsd to aac for mobile device.But seems FFmpeg and Qaac doesn't avalable for it. Any tips? Now the only solution seems to use wavunpack for wv(dsd)->dsf->ffmpeg ...
Messing with wavpack again since I got tired of spotty support for .tak on linux, is it me or is hybrid a bad idea for hi-res material? A 24Bit 96kHz album ended up about 15% bigger than .tak and still about 10% bigger than .flac -8
Quote from: ChronoSphere on 31 December, 2016, 09:40:44 AMMessing with wavpack again since I got tired of spotty support for .tak on linux, is it me or is hybrid a bad idea for hi-res material? A 24Bit 96kHz album ended up about 15% bigger than .tak and still about 10% bigger than .flac -8Hmm. That does not sound right. I only have one 24/96 track available right now to try, but I just did and using the parameters of -hb1024ccx6 for WavPack and -8 for FLAC 1.3.0 the difference was less than 0.1%. On the other hand, the worst parameters I could come up with (-fb2c) was about 5% worse.What parameters are you using?