Skip to main content

Topic: WavPack 5.0.0 Final Release (Read 16088 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Re: WavPack 5.0.0 Final Release
Reply #75
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).

  • Kraeved
  • [*]
Re: WavPack 5.0.0 Final Release
Reply #76
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?

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Re: WavPack 5.0.0 Final Release
Reply #77
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 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.

  • Porcus
  • [*][*][*][*][*]
Re: WavPack 5.0.0 Final Release
Reply #78
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?)

  • Kraeved
  • [*]
Re: WavPack 5.0.0 Final Release
Reply #79
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 benefits of the latter, i.e. lower energy consumption 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, Unfortunately or fortunately, they were not saved.
  • Last Edit: 17 May, 2017, 09:58:08 AM by Kraeved

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Re: WavPack 5.0.0 Final Release
Reply #80
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.

  • Kraeved
  • [*]
Re: WavPack 5.0.0 Final Release
Reply #81
- 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?

  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Re: WavPack 5.0.0 Final Release
Reply #82
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.