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 51601 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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).

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?
• We can do better about lossy music: Opus complexity & qAAC dependence on Apple is a departure from Vorbis & Musepack breakthroughs
• Clipping-free MP3 encoding for vintage gear: SoX to 44.1 kHz → LoudMax -1 dB ISP → ADClip8 → Smart dither 16 bit → Lame3995o -Q1
• Plz, update WavPack hybrid & FSLAC

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.

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?)

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.
• We can do better about lossy music: Opus complexity & qAAC dependence on Apple is a departure from Vorbis & Musepack breakthroughs
• Clipping-free MP3 encoding for vintage gear: SoX to 44.1 kHz → LoudMax -1 dB ISP → ADClip8 → Smart dither 16 bit → Lame3995o -Q1
• Plz, update WavPack hybrid & FSLAC

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.

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?
• We can do better about lossy music: Opus complexity & qAAC dependence on Apple is a departure from Vorbis & Musepack breakthroughs
• Clipping-free MP3 encoding for vintage gear: SoX to 44.1 kHz → LoudMax -1 dB ISP → ADClip8 → Smart dither 16 bit → Lame3995o -Q1
• Plz, update WavPack hybrid & FSLAC

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.

Re: WavPack 5.0.0 Final Release

Reply #83
bryant, you must be energized by what lies ahead. :)
• We can do better about lossy music: Opus complexity & qAAC dependence on Apple is a departure from Vorbis & Musepack breakthroughs
• Clipping-free MP3 encoding for vintage gear: SoX to 44.1 kHz → LoudMax -1 dB ISP → ADClip8 → Smart dither 16 bit → Lame3995o -Q1
• Plz, update WavPack hybrid & FSLAC

 

Re: WavPack 5.0.0 Final Release

Reply #84
Did you not notice the message over your reply box indicating that you were bumping a topic from last June?