HydrogenAudio

Hydrogenaudio Forum => Validated News => Topic started by: bryant on 2016-12-09 18:38:06

Title: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-09 18:38:06
Major changes:

complete changelog (http://www.wavpack.com/changelog.txt)
download link (http://www.wavpack.com/downloads.html)

Thanks to everyone at HA who helped with this along the way!
Title: Re: WavPack 5.0.0 Final Release
Post by: Rollin on 2016-12-09 20:34:57
Some info from my tests.
Playback of DSD compressed with wavpack is gapless in foobar2000! Unlike foo_input_sacd (1.0.2) which adds noticeable clicks between tracks when playing separated dff files. Also, some multichannel DSD files which are unplayable with foo_input_sacd, become playable in foobar2000 when compressed with wavpack. Example of such file: https://www.dropbox.com/s/ezsichx10tah9yp/short.dff?dl=0 (https://www.dropbox.com/s/ezsichx10tah9yp/short.dff?dl=0)
And good old frontend from 2002 still works even for DSD compression  :D
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-09 21:30:53
Hey, that's great news about the gapless...I actually had not thought to try that because I don't have any complete DSD albums (yet).

As for that short multichannel file, for some reason the 8 channels are all unassigned in the .dff file, so maybe that's what foo_input_sacd doesn't like.
Title: Re: WavPack 5.0.0 Final Release
Post by: andrew.46 on 2016-12-11 05:57:45
Great to see this new release!! I spent a bit of effort a while ago adding Wavpack support to the Linux command line audio CD ripper / encoder and old and new versions are working there beautifully :).

A little aside from this: I am wondering if I am the only person who cannot get the new Wavpack running with qaac under Wine and Linux? A slightly rambling bug report here... (https://github.com/nu774/qaac/issues/39) Nice to know if I am the only one.

And again: thanks for Wavpack :)
Title: Re: WavPack 5.0.0 Final Release
Post by: andrew.46 on 2016-12-11 08:59:34
A little aside from this: I am wondering if I am the only person who cannot get the new Wavpack running with qaac under Wine and Linux? A slightly rambling bug report here... (https://github.com/nu774/qaac/issues/39) Nice to know if I am the only one.

Never mind the latest official dlls have solved the issue :)
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-11 23:34:33
Quote
Never mind the latest official dlls have solved the issue :)
I looked over that issue thread a couple months ago and never really had a clue why you were seeing what you were seeing. Some weird interaction of mingw / qaac / wine / wavpack? It would be interesting to find out what was going on, but it's good that the official DLLs seem to work well.

Also, thanks again for the support in abcde...I'm finally going to be able to give that a shot now that 5 is out!
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-14 04:33:16
Hi , I've tried wavpack 5.0 to compress dsd to wv.
The compression ratio is really good.
But I have a question for the playback.
While playing in foobar2000, it recognize the wv(dsd high) in a 352800khz 24bit pcm music,
is it normal?
And does it still lossless for dsd playback?
Because in dsf format it show 2822400 Hz in foobar2000 so I`m a little confused.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-14 05:09:34
In foobar2000, the WavPack library is converting the DSD to 24-bit 352.8 kHz and that's what foobar2000 is playing. I thought that they were going to display the actual DSD sample rate (I even provided an API for this specifically), but it might be that they didn't get around to that, or there's a bug somewhere.

But I do know that whether you play a WavPack DSD or a DSF file directly, they are lossless, but the conversion to PCM is done as the file is read (before the DSP and everything else). Foobar2000 cannot handle DSD internally, and cannot write DSD to a DAC (DoP).
Title: Re: WavPack 5.0.0 Final Release
Post by: guruboolez on 2016-12-14 09:07:36
foobar2000 can handle DSD as DSD stream and output it to a DAC… but not natively. The foo_input_sacd allows this. And it works well. The external DAC may indicate what kind of stream is decoded (PCM, DSD, resolution…) and it confirms that DSD playback is possible with DSF, DFF, SACD-ISO.
I can not try anymore, because my DAC is dead. But I'm sure there must be a way to handle Wavpack DSD as DSD  :)
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2016-12-14 09:50:48
As far as I understand, foo_input_sacd is an input plugin that outputs DSD itself and bypasses  fb2k audio chain.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-14 10:24:05
foobar2000 can handle DSD as DSD stream and output it to a DAC… but not natively. The foo_input_sacd allows this. And it works well. The external DAC may indicate what kind of stream is decoded (PCM, DSD, resolution…) and it confirms that DSD playback is possible with DSF, DFF, SACD-ISO.
I can not try anymore, because my DAC is dead. But I'm sure there must be a way to handle Wavpack DSD as DSD  :)
Yes, I'm using  foo_input_sacd  and I have a dac that can play dsd natively.
But foobar2000 play wavpack-dsd just as a pcm.
While playing dsf that't no problem.
(Sorry for my English)
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-14 19:30:04
Ah yes, you guys are right. I thought that foo_input_sacd worked just like foo_input_dsdiff except that it handled ISO files, but I just tried it and it can output directly to a compatible DAC. Thanks for clearing that up!

Since foo_input_sacd works so well, it might make sense to add WavPack support to that. I don't know enough about the foobar internals to know how that would work with respect to plugin priority and tagging, but it seems like one way to go.
Title: Re: WavPack 5.0.0 Final Release
Post by: conta69 on 2016-12-14 19:31:16
@samidare1234

When you created the WavPack-dsd Foobar, than this is the mistake. In Foobar it is not possible to convert a dsf-file to a dsd-wv preserving the dsd-content. Everything gets converted to PCM. Look here (https://hydrogenaud.io/index.php/topic,113220.msg932216.html#msg932216).

You have to convert the dsf-file with the command-line interface to preserve dsd.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-14 19:41:34
You have to convert the dsf-file with the command-line interface to preserve dsd.
This is also true.

If you look at the file properties in Foobar, down at the bottom there should be <DSD_SAMPLERATE> if this is a true WavPack DSD file. Otherwise it really is 24-bit PCM.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-15 03:08:24
@samidare1234

When you created the WavPack-dsd Foobar, than this is the mistake. In Foobar it is not possible to convert a dsf-file to a dsd-wv preserving the dsd-content. Everything gets converted to PCM. Look here (https://hydrogenaud.io/index.php/topic,113220.msg932216.html#msg932216).

You have to convert the dsf-file with the command-line interface to preserve dsd.

Yes , I use command-line to convert dsf to wavapck-dsd  with this command:
wavpack.exe "input.dsf" -hh
Does it correct? Or some other command need for specific dsd that I missed?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-15 04:25:44
wavpack.exe "input.dsf" -hh
Yes, this is the correct command to produce a lossless DSD WavPack file. (Actually -h is enough...the "very high" mode does nothing additional, yet).

What conta69 was explaining is that you cannot use foobar to do the encode using the converter tool because it will make a PCM WavPack file, which you don't want.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-15 06:47:08
wavpack.exe "input.dsf" -hh
Yes, this is the correct command to produce a lossless DSD WavPack file. (Actually -h is enough...the "very high" mode does nothing additional, yet).

What conta69 was explaining is that you cannot use foobar to do the encode using the converter tool because it will make a PCM WavPack file, which you don't want.


Thanks for the explanation.
I doesn't use the foobar2000 to do the encoding. Just use Command Prompt to encode.
But Foobar2000 with foo_sacd_input still doesn't recongonize the wavpack-dsd as a dsd file.
If need I'll make some screenshots.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-15 07:52:45
But Foobar2000 with foo_sacd_input still doesn't recongonize the wavpack-dsd as a dsd file.
If need I'll make some screenshots.
I do not think screenshots are needed, because I think what you are seeing is exactly what is expected.

Foobar2000 is recognizing the WavPack-DSD file as DSD, but it is not playing it as a DSD file because it does not know how to do that. Only the foo_input_sacd plugin knows how to play a DSD file natively, but foo_input_sacd does not know about WavPack.

If you look in Foobar2000 properties for the DSD WavPack file, it should show <DSD_SAMPLERATE> and  <DSD_BITSPERSAMPLE> at the bottom in the “other” section. It does not show that with WavPack PCM files.
Title: Re: WavPack 5.0.0 Final Release
Post by: Case on 2016-12-15 09:52:39
Couple of notes:

It would require changes in the foobar2000 itself to enable foo_input_sacd to take over WavPack DSD handling. And native DSD hangling would also require a lot of core changes. I know Peter isn't interested in the latter at all.

Real DSD samplerates and bitdepths are reported in special fields in foobar2000 because of compatibility. Internal alpha version reported things correctly and a few components broke down.

I bought a DSD capable DAC to prepare for possible future special DSD support testing. Audio quality wise there's absolutely no difference if DAC is fed PCM or DSD but for me usability with PCM is way superior. Seeking is instant, playback is gapless, you can use DSPs and ReplayGain. DSD is just an absolutely awful transport format.
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2016-12-15 11:06:54
but for me usability with PCM is way superior. Seeking is instant, playback is gapless, you can use DSPs and ReplayGain. DSD is just an absolutely awful transport format.
"It's only audiophile if it's inconvenient." (Kohlrabi signature).
Title: Re: WavPack 5.0.0 Final Release
Post by: Steve Grant on 2016-12-15 11:27:10
This may not be the correct place, in which case apologies. I was using Wavpack as my preferred lossless format with the Bass library from Un4seen. In my programme, I completely scan a loaded track for level before presenting it to the user for playing. I only recently found that it was much quicker (at least 3 times) to scan an identical Flac track. Is there anything that can be done about the Wavpack seeking speed. All my files are encoded -h direct from my CD's with dBpoweramp. 
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2016-12-15 11:48:06
Seeking speed or decoding speed?
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-15 13:00:35
But Foobar2000 with foo_sacd_input still doesn't recongonize the wavpack-dsd as a dsd file.
If need I'll make some screenshots.
I do not think screenshots are needed, because I think what you are seeing is exactly what is expected.

Foobar2000 is recognizing the WavPack-DSD file as DSD, but it is not playing it as a DSD file because it does not know how to do that. Only the foo_input_sacd plugin knows how to play a DSD file natively, but foo_input_sacd does not know about WavPack.

If you look in Foobar2000 properties for the DSD WavPack file, it should show <DSD_SAMPLERATE> and  <DSD_BITSPERSAMPLE> at the bottom in the “other” section. It does not show that with WavPack PCM files.

Yes, It showes <DSD_SAMPLERATE> and  <DSD_BITSPERSAMPLE>.
Thanks a lot!
I'll try to add feature request to the author of foo_input_sacd for wavpack-dsd handling.
 
Title: Re: WavPack 5.0.0 Final Release
Post by: Steve Grant on 2016-12-15 13:55:37
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: conta69 on 2016-12-16 08:58:05
Yesterday i tested some DSD128 and DSD256 dsf-files.
--> the converting to wavpack worked out without any problem.  :)
Also the playback of the songs on my quite weak and outdated system was perfect! (... and gapless!!)

Then i converted them back to dsf with wvunpack. The dos "comp"-command gave me the result: no differences. Thats what i call real lossless converting!

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?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-17 01:05:13
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-17 01:08:00
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).
Title: Re: WavPack 5.0.0 Final Release
Post by: Jackal29a on 2016-12-17 11:22:45
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?

Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-17 19:48:18
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: Jackal29a on 2016-12-18 10:49:53
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...







Title: Re: WavPack 5.0.0 Final Release
Post by: prezi on 2016-12-18 12:28:08
This what you are talking about is just matter of time.
Title: Re: WavPack 5.0.0 Final Release
Post by: conta69 on 2016-12-18 17:33:51
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-19 04:01:58
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: conta69 on 2016-12-19 08:23:58
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: Porcus on 2016-12-19 09:55:11
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?
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2016-12-19 22:51:52
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" ?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-20 05:17:04
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)!
Title: Re: WavPack 5.0.0 Final Release
Post by: Fairy on 2016-12-22 20:49:17
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?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-22 22:05:18
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: DARcode on 2016-12-24 14:47:15
Hey David, thanks for the early Xmas present.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-30 14:12:15
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?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-30 20:13:19
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-31 04:54:05
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-31 05:01:06
Ah, that's good!  :)
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2016-12-31 13:38:52
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 ...
 
Title: Re: WavPack 5.0.0 Final Release
Post by: ChronoSphere on 2016-12-31 14:40:44
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

Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-31 20:25:33
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.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2016-12-31 20:27:10
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?
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-01 12:25:33
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 ?
Title: Re: WavPack 5.0.0 Final Release
Post by: ChronoSphere on 2017-01-01 12:34:09
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
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-01 14:31:47
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 ?
Well, seems if we convert a tagged dsf to wavpack-dsd.
wavpack doesn't convert the tag to apev2 and just store the original tag for restoring.
So I think the last foo_input_sacd and qaac doesn't reconnize the tag is correct.
Seems after converting to  wavpack-dsd I need to retag all of them once.
Can wavpack make an option to convert the original dsf tag to apev2 type automatically?
Title: Re: WavPack 5.0.0 Final Release
Post by: ChronoSphere on 2017-01-01 18:48:13
What exactly does wavpack omit when using fast instead of high mode? I can't seem to hear a difference on the lossy part, but manual states that there is a negative effect on lossy quality in fast mode. Is it only really showing on low bitrates?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-01 23:32:13
Can wavpack make an option to convert the original dsf tag to apev2 type automatically?
Yes, this is something I did not get a chance to look into before. As you know, DSF files can have ID3 tags at the end, and WavPack saves these as the audio data “wrapper” so that the original file can be restored by wvunpack. You can actually see the presence and size of this tag by using the -ss option of wvunpack. Some of the DSF files I have obtained have as much as 3 MB of information in those tags (photos and scans mostly I assume, but I never looked).

It is possible for apps using libwavpack to obtain this info, but it can't be edited.

As you say, it should be possible to translate this to APEv2 tags, although I'm not sure that that would be completely unambiguous. Does anyone know how easy this would be offhand? It seems to me there were many versions and parsing complications with ID3 tags.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-01 23:44:48
What exactly does wavpack omit when using fast instead of high mode? I can't seem to hear a difference on the lossy part, but manual states that there is a negative effect on lossy quality in fast mode. Is it only really showing on low bitrates?
Basically, switching from “high” to “fast” is going to increase the noise a little and hurt the compression a little. You can use the -n option to see this, and I just measured 3 dB higher noise and about 1% worse compression. Of course, by changing the bitrate you can shift the cost around. So, for example, by increasing the bitrate here by 100 kbps you can reduce the noise back down so that the “fast” mode will have the quality as “high”.

I am not surprised that you could not hear a difference. At these bitrates the noise will normally be way below even the noise floor of the recording. Here's a spectrum of the signal (cyan) and added noise (magenta) for a 24/96 recording (NIN) encoded at 1024 kbps (don't remember the mode, probably “high”). Especially since it's shifted up in frequency, that noise is not going to be audible even without the masking effect of the source audio!

(http://www.wavpack.com/images/NIN-01.png)

This is why I've always advocated WavPack lossy as a potentially efficient format for high-resolution recordings. I suspect that part of the reason this has not caught on is that the audience that might be receptive to it is so limited. Subjectivists are skeptical of anything lossy regardless of the technical arguments for it (and perhaps, even if they tried it, hesitant to admit that it sounds the same). On the other hand, objectivists will immediately convert any high-resolution recordings they come across to 16/44.
Title: Re: WavPack 5.0.0 Final Release
Post by: shadowking on 2017-01-07 09:04:52
Thank you David for the new version & continued development.
Title: Re: WavPack 5.0.0 Final Release
Post by: ChronoSphere on 2017-01-07 16:51:22
Well, I ended up going with -b384fcx6, since I can't hear the difference anyway, and the slightly lower compression ratio doesn't bother me. I guess once some people read that -f adds noise, they just jump to -h without testing.

Subjectivists are skeptical of anything lossy regardless of the technical arguments for it (and perhaps, even if they tried it, hesitant to admit that it sounds the same). On the other hand, objectivists will immediately convert any high-resolution recordings they come across to 16/44.
I'd do the latter too, except I like to keep the original files untouched - simply because they're original. Now, if there was an option to have the lossy part as 16/44 with the correction file restoring the original bit/sampling rate.... though I think that would blow up the combined filesize a lot, kind of like keeping a too low bitrate for high res did for me.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-08 00:32:23
Seems after converting to  wavpack-dsd I need to retag all of them once.
Can wavpack make an option to convert the original dsf tag to apev2 type automatically?
I have done this. Read about it here (https://hydrogenaud.io/index.php/topic,113438).
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-08 09:30:51
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.
Title: Re: WavPack 5.0.0 Final Release
Post by: arkhh on 2017-01-08 23:16:28
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.
The results from foobar2000 and the command-line should be the same. If there is a size difference the tags may be responsible for that. Even then, the difference in size should be minimal unless you are placing cover-art in tags. Finally, once you have copied the tags to the wavpack files, the size should end up being the same. I'd just go with foobar2000 since it's more convenient.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-09 00:57:30
Thanks you David for the new tool, though I finished retaging for all wv-dsd.

I would like to ask one more help.

Now I want to convert all my thounds flac files to wavpack .
And I want the tag from flac.
Using Foobar200 can do it but I notice that if I use foobar2000, the output wavpack file is a little bigger than using command-line in same setting.
I don't know why but I want to keep the file smallest so I decide to use command-line.
But for using command-line I can't copy tags from flac to wavpack.
Would you please to make wavpack.exe easily using like qaac can use the external library for converting from flac than can transfer the tag or make WVTAG can simply do
wvtag input.flac output.wv
to copytag into APEv2 and store to wv?
Thanks a lot.
The results from foobar2000 and the command-line should be the same. If there is a size difference the tags may be responsible for that. Even then, the difference in size should be minimal unless you are placing cover-art in tags. Finally, once you have copied the tags to the wavpack files, the size should end up being the same. I'd just go with foobar2000 since it's more convenient.

NO,even no any tags. The size is not the same . So,I am very confused.
I will update some resaults here later if I have free time today.
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-09 11:48:50
Do some compare using Foobar2000 AND command to encode wavpack
Both I use the same wavpack 5.0 x64 encoder and same setting which should make same resault normally.

test.WAV( without Any Tag)
size:399 MB (418,387,916 bytes)

Use foobar2000: use : -i -q -hh -x6 -m - %d
size:178 MB (187,597,128 bytes)

Use comman-line:wavpack -hhx6 -m test.wav
size:178 MB (187,587,640 bytes)


So why? Is it a bug in Foobar2000 on Encoding Wavpack or not?
Because I tried the same thing before on Flac it make the same size on output files.
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2017-01-09 16:14:05
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-09 17:35:57
So why? Is it a bug in Foobar2000 on Encoding Wavpack or not?
Because I tried the same thing before on Flac it make the same size on output files.
I would suggest using the command-line wvunpack with -ss to compare the output files. First you can see if the audio MD5s actually match (perhaps there's audio processing being done?) and you can also check if there's an invisible tag added (or anything different, actually).

As for importing FLAC tags in WavPack, I can see why that would handy, but it's really beyond the scope of what I think belongs in WavPack. I would have to include or link to libflac somehow, which could cause problems, or write my own parser, which I think would be a big project. For ID3v2 I wrote my own parser in a few days because it's a standard part of the DSF format, but I'm still worried that tags will come along that break it (I didn't implement anything that I didn't have a sample file for).
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-10 04:52:53
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
OH! By using this the file size becomes same with command-line!
Thanks a lot!
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-10 05:49:29
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
That's funny! I wondered why you suggested this because I didn't think that using pipes (and the -i option) should make a difference.

Anyway, it obviously does and I figured out why, and it's definitely not intended behavior. It will be fixed next release.

Thanks for pointing this out, but I have a question. How did you know this was going to do that?  :)
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-10 11:00:54
Try foobar2000 with the following line:
-q -hh -x6 -m %s %d
That's funny! I wondered why you suggested this because I didn't think that using pipes (and the -i option) should make a difference.

Anyway, it obviously does and I figured out why, and it's definitely not intended behavior. It will be fixed next release.

Thanks for pointing this out, but I have a question. How did you know this was going to do that?  :)

Hello David, would it be long for this realse ? 
Thanks !
Title: Re: WavPack 5.0.0 Final Release
Post by: lvqcl on 2017-01-10 16:27:53
How did you know this was going to do that?  :)
I thought that wavpack reserves some space for seektable or something like this (and reserves more space if wave length is unknown)
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-10 17:54:51
Ah, that makes sense, maybe FLAC does something like that too?

But no, WavPack does not have seektables and there shouldn't be any difference between the various options. But the “ignore length” option (and some others) were accidentally triggering the write of a redundant status word, so every block was 2 bytes longer than it should have been. No ill effect, but not as intended.

Samidare1234, maybe a week or two for the next release.
Title: Re: WavPack 5.0.0 Final Release
Post by: ChronoSphere on 2017-01-15 16:06:07
Just dropping this here, since I don't want to specifically make a new thread about it: I just finished converting my library from TAK to WV hybrid. The overall increase in space usage is 6.78% with -b384fx6 (302.522GiB tak -> 323.039GiB wv+c)

This is about what I expected, it was about the size of my library in FLAC before moving to TAK, plus a slight increase from using hybrid. Overall, I'm satisfied - I could probably push the size down by switching to -h, but I'd die of old age at those de-/encoding speeds. I wonder what black magic TAK uses to reach such compression levels and still maintain high de-/encoding speeds. Though this speed is offset by abysmal support, which pushed me to abandon it.

Wavpack on the other hand is well supported on all platforms I use, so thank you, bryant, for developing this codec!
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-15 21:49:25
I'm glad WavPack is working our for you...it's always nice to hear someone finds it useful!

BTW, this won't affect your encodings, but the new version (5.1.0) should be released in just a few days.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-21 01:12:21
As promised, WavPack 5.1.0 is released. It's available in the same place as always (http://www.wavpack.com/downloads.html).

Compared to 5.0.0, this is a minor update, but has a few fixes and improvements:


Many thanks to all HA members who contributed to this by incorporating WavPack into their projects, with testing and suggestions, and of course by just using WavPack; it is all greatly appreciated!  :)
Title: Re: WavPack 5.0.0 Final Release
Post by: samidare1234 on 2017-01-21 04:38:34
Thanks David! Does this new version change any filesize on lossless files and dsd files?
I mean if I want smallest file do I need to re-encode to WavPack 5.1 ?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-01-21 06:50:39
I left it off the list, but yes, I fixed the issue you found where the -i option was causing an extra (unneeded) 2 bytes per block. Now the file sizes should always be the same with the same settings.

And that's the only file size change I made, so you should not need to re-encode, assuming you used the settings that lvqcl suggested. Thanks again to both of you for finding that!
Title: Re: WavPack 5.0.0 Final Release
Post by: dutch109 on 2017-01-21 17:39:07
  • added: all new command-line tagging utility (wvtag)
Thank you for this, I used to manually compile apetag (http://robert.muth.org/Apetag/) just to edit WavPack files in my scripts.
Title: Re: WavPack 5.0.0 Final Release
Post by: prezi on 2017-03-19 01:10:10
How to split dsd wv file with cue file?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-05-08 06:14:36
Sorry for the late response on this...I saw the original post and then got distracted before answering.  :(

AFAIK, there is no solution for this. Something like Foobar2000 would work, but I'm guessing you would end up with 88.2 KHz PCM files, which I assume is not what you want.

I have thought it would be nice to build a cue splitter into wvunpack (or maybe a new "wvsplit"), but that would be complicated and I'm sort of short on time these days.

If you just wanted to extract a single DSD file from a full image you could use the --start and --end options of wvunpack to get a specific region, although that would be a lot of trouble for a full album (and of course it wouldn't supply any tagging).
Title: Re: WavPack 5.0.0 Final Release
Post by: Kraeved on 2017-05-14 11:18:58
Original: https://transfer.sh/16enp6/Opium.dsf SHA1: a62910c66da0c83c93316f091e368a2739fb04b7
Compressor: WAVPack 5.1.0
Command: wavpack.exe --import-id3 Opium.dsf
Result: Opium.wv

Now let’s reverse the process and see what happens.

Command: wvunpack.exe Opium.wv
Result: Opium.dsf SHA1: f11ccd1b72baeb5cd6bd3cea87c7c0d143c933c4

Hashes mismatch means original is not restored, why?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-05-14 21:07:34
Thanks for reporting this issue and making the file available!

I actually found a few files like this when I was developing the DSD mode. The problem is that the DSF spec (http://dsd-guide.com/sites/default/files/white-papers/DSFFileFormatSpec_E.pdf) clearly states that the unused portion of the final block should be zeroed (0x00), but your file is padded with 0x97. This is why the wavpack program displays blocks not padded with NULLs, MD5 will not match! when encoding this file.

If you decode the WavPack back to DSF you will see that only 7136 bytes near the end are different because WavPack fills the padding bytes with 0x00 per the spec, and they are not part of the audio, so all of the “playable” audio is identical.

I thought a long time about what to do with these files, and with more work I may have been able to come up with something better than this warning, but it's also a little sad that software engineers can't follow a 6-page spec (which, despite it's obvious shortcomings, if pretty clear about that).

As is stands, the WavPack files you made have the correct audio and will restore back to correct but not identical DSF files. Even without stored MD5 sums, WavPack still verifies each block using it's own method, so you don't have to worry about the files being corrupted in the future without your knowledge.

BTW, on this particular file (and probably the others on the album), the high mode (-h) compresses considerably better than the default mode, although at 128X they will require a fair amount of CPU to decode.
Title: Re: WavPack 5.0.0 Final Release
Post by: Porcus on 2017-05-15 15:24:39
I thought a long time about what to do with these files, and with more work I may have been able to come up with something better than this warning
Would a --keep-noncompliant-padding option resolve it?
(Or at worst: would plugging a "--enforce-compliant-padding" and changing the default to noncompliant save you work in terms of fewer questions to answer?)
Title: Re: WavPack 5.0.0 Final Release
Post by: Kraeved on 2017-05-17 14:09:18
The problem is that the DSF spec clearly states that the unused portion of the final block should be zeroed (0x00), but your file is padded with 0x97…
WavPack files you made have the correct audio and will restore back to correct but not identical DSF files.
Thank you for explanation, David. Consider adding it to WavPack’s manual.

Quote from: bryant
On this particular file (and probably the others on the album), the high mode (-h) compresses considerably better than the default mode.
I thoroughly evaluated WavPack since 5.1 had been introduced, actually converted media collection into -hx1.
Recently reverted back to FLAC -8 because of asymmetric (https://tldrify.com/n69) benefits of the latter, i.e. lower energy consumption (https://en.wikipedia.org/wiki/Efficient_energy_use) while playing.
However WavPack served me well to compress 32-bit float mic records — perhaps grandchildren would like to use them one day.

Another concern here is tags.
Passing --import-id3 switch transfers existing tags from DSF to WV, decompression transfers all of them back with success.
But when intermediate Opium.wv is loaded into Foobar2000, only basic tags are displayed, the rest are not as if they are missing.
I even tried to cope with confusion by transferring ostensibly missing tags manually (http://wiki.hydrogenaud.io/index.php?title=Foobar2000:How_to_transfer_tags_between_two_sets_of_tracks), Unfortunately or fortunately, they were not saved.
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-05-21 04:25:22
Thanks for giving WavPack a try and providing feedback!

A couple things come to mind. If decoding speed (i.e., low energy consumption) is paramount, then the best encode parameters would be -fx6. That will get you pretty close to FLAC performance, IIRC. But obviously FLAC is a great choice too.

As for the tags imported by --import-id3, I checked your Opium file and wow, that's got a lot of tags! When I converted the tags to APEv2 using Foobar2000 there were 35, and that didn't include the replay gain tags. I don't think it will be that hard to implement transferring the others; I'll try to get something into the next release.

And yeah, I agree that something about the invalid padding should go in the manual.
Title: Re: WavPack 5.0.0 Final Release
Post by: Kraeved on 2017-06-02 11:03:22
- As for the tags imported by --import-id3 ... I'll try to get something into the next release.
- And yeah, I agree that something about the invalid padding should go in the manual.

David, could you let us know when will this happen, please?
Title: Re: WavPack 5.0.0 Final Release
Post by: bryant on 2017-06-02 17:08:20
Of course. I'm busy at [real] work now, so it won't be right away, but it should not be too long either. I'll PM you when I have something you can try out.
Title: Re: WavPack 5.0.0 Final Release
Post by: Kraeved on 2018-02-06 13:09:40
bryant, you must be energized by what lies ahead. :)
Title: Re: WavPack 5.0.0 Final Release
Post by: kode54 on 2018-02-07 00:31:45
Did you not notice the message over your reply box indicating that you were bumping a topic from last June?