Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack 5.0.0 Final Release (Read 51929 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: WavPack 5.0.0 Final Release

Reply #25
Seeking 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.

Yeah, fast decoding is one of FLAC's strong suites. The “fast” mode of WavPack gets pretty close, but the “high” (-h) mode that you used is easily half as fast (although 1.35 seconds for a 4 minute track is not exactly crawling).

Using the command line program you could try transcoding a track (or a folder of them) to “fast” mode and test it again. Use the command “wavpack file.wv -fx6v” or “wavpack *.wv -fx6v” to get the best compression with the fastest decode speed (the actual transcoding will be petty slow, but the resulting files will not be that much bigger than what you have and will decode twice as fast, or so). Note that the transcoding will copy all the tags and any extra RIFF info, and won't delete the original until the transcoding is verified.

Re: WavPack 5.0.0 Final Release

Reply #26
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 good
DSD128 has a rate between 20 and 25% --> not that good...
Is there a reason for this behaviour?

Yes, I would have to include a DST decoder to make that work, and, of course, the file would end up being bigger than the original...  :)

As for the worse performance for DSD128, what I have found is that there are differences between different files (and I have seen as bad as 25%), but it actually seems to be more related to the type of DSD encoding filters rather than the actual DSD rate. In fact, the worst one I've seen was also a DSD128, but looking at the noise spectrum it was obviously just a poorly upsampled DSD64. Other “native” DSD128s worked much better.

BTW, it seems like you might be using just the regular mode. The “high” works quite a bit better with some of those “bad” encodes (although that's going to mean more CPU to decode, especially at DSD128 or DSD256 and an older computer).

 

Re: WavPack 5.0.0 Final Release

Reply #27
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?


Re: WavPack 5.0.0 Final Release

Reply #28
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?

Well, Foobar2000 isn't the only player in the world. MPD on Linux was already updated to play WavPack DSD natively, and perhaps other players will too in the future.

Even if someone plans to always play their DSD recordings by converting to PCM during playback, that doesn't necessarily mean that they want to do the [lossy] conversion to PCM now and delete the purchased original.

Lossless audio compression has always been to about replacing (not supplementing) the original with something consuming less space.

Re: WavPack 5.0.0 Final Release

Reply #29
Thanks for the answer.
I didn't know about MPD playing WV'ed DSD to native DSD, very interesting. It'll very, very nice if Foobar did the same though I won't hold my breath waiting for it to happen. I'm sure Maxim (SACD plugin author) would be willing to help if necessary. I believe most people who have DSD music want to play it native (count me as one of them), those who don't would most probably just get PCM versions and skip all the hassle but who knows...








Re: WavPack 5.0.0 Final Release

Reply #30
This what you are talking about is just matter of time.

Re: WavPack 5.0.0 Final Release

Reply #31
A short remark to the dsf-wv-conversation speed:
My system is a Intel i7 PC with Win7-64bit.
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?
It seems, that the prozessing-speed could be increased a lot.

Re: WavPack 5.0.0 Final Release

Reply #32
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?
The WavPack library and the command-line programs are single-threaded, so on an 8 core machine you'll only get 12.5% maximum.

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.

Re: WavPack 5.0.0 Final Release

Reply #33
Quote
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.

Thanks for the info. You are perfectly right - in reality this doesn't matter. If you intend to encode your whole library, it will allway took over night...  :)
I asked for curiosity -  and the possibility that i overlooked something.

Re: WavPack 5.0.0 Final Release

Reply #34
But external applications can convert eight files at a time by calling eight WavPack instances. I think foobar2000 does that with WavPack as well as with other conversions?

Re: WavPack 5.0.0 Final Release

Reply #35
From http://www.wavpack.com/WavPack5PortingGuide.pdf
"For 5.0.0, the new stream is the default and the CONFIG_OPTIMIZE_FLAG is ignored"
Should it be "For 5.0.0, the new stream is the default and the CONFIG_OPTIMIZE_MONO flag is ignored" ?

Re: WavPack 5.0.0 Final Release

Reply #36
Should it be "For 5.0.0, the new stream is the default and the CONFIG_OPTIMIZE_MONO flag is ignored" ?
Oops, yes it should. I'll fix that.
Thanks for letting me know (and for checking out the document)!

Re: WavPack 5.0.0 Final Release

Reply #37
I did a little test. Nothing scientific...

I noticed it took a bit longer to load Wavpack files in Foobar, but thought it could be my imagination, so I did a little test.

Loading 29153 files in foobar (tagged). I've got exact the same collection in flac and wavpack. The FLAC folder took 11m08s to load in Foobar. The Wavpack version took quite a bit longer (16m11s).

Is there a reason that loading the tags from Wavpack files takes longer?

Re: WavPack 5.0.0 Final Release

Reply #38
Is there a reason that loading the tags from Wavpack files takes longer?
I think that Foobar2000 does not use the WavPack library at all to read or write the APEv2 tags on WavPack files (Peter has his own library for this because other formats use the same tags), so there probably has not been any change between this and previous versions.

However, APEv2 tags are stored at the end of files and I believe FLAC tags are at the beginning, so perhaps the additional seeking explains the difference in loading time.

Re: WavPack 5.0.0 Final Release

Reply #39
Hey David, thanks for the early Xmas present.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Re: WavPack 5.0.0 Final Release

Reply #40
A Good News Here!!!
Last time I asked the author of the foo_input_sacd of supporting WAVPACK-DSD.
Today he realeased the version 1.0.4
Now we can play WAVPACK-DSD on foobar2000!!!.
Thank to him and
Thanks  Bryant !!!

-----------------------------
update

A new problem is if we use sacd foo_input_sacd 1.0.4 then the tags become blank
Maybe it is able to fix by the author of foo_input_sacd?

Re: WavPack 5.0.0 Final Release

Reply #41
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.

Re: WavPack 5.0.0 Final Release

Reply #42
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.

For Regular WavPack Pcm it works well still.

Re: WavPack 5.0.0 Final Release

Reply #43
Ah, that's good!  :)

Re: WavPack 5.0.0 Final Release

Reply #44
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 ...
 

Re: WavPack 5.0.0 Final Release

Reply #45
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


Re: WavPack 5.0.0 Final Release

Reply #46
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 ...
Well, not much stuff supports the WavPack DSD at this point, obviously. However, wvunpack does support pipes, so you could do what you suggest with FFmpeg and pipes and not have to create intermediate files on disk.

Another thing to try is to use the --wav option on wvunpack to output PCM instead of DSD. If the command-line AAC encoder will accept 24/352 then that will work great.

None of these methods will copy tags though. I realize it's not command-line, but Foobar2000 would work great for this, even without the foo_input_sacd component.

Re: WavPack 5.0.0 Final Release

Reply #47
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
Hmm. 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?

Re: WavPack 5.0.0 Final Release

Reply #48
Today Qaac released the 1.6.2 ver and support for the wavpack-dsd decode as pcm ,
so now I can use qaac to convert wv-dsd to aac file.
But tags missing occuered.
I wonder some information for Qaac's developer to solve this problem.
Doesn's wavpack-dsd use apev2 tags ?

Re: WavPack 5.0.0 Final Release

Reply #49
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
Hmm. 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?
Ah, I used hb384cx4, the same as I'm using for redbook audio. I guess that's the problem. I increased the bitrate to 900kbps and the sizes have shrunk considerably (11%), so that's probably the reason. I'm only losing an average of about 3.5% of compression overall compared to TAK m4, though, which is way less than I expected. Now if only the decoding speed was higher (verifying rips with CTDB takes a while), but then I'd have to compromise on compression again... :D