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 4.3 discussion (Read 4481 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.3 discussion

Since the version being discussed is still 4.2, is there any chance of a similarly optimised version of 4.22? I understand the only major fixes between the two versions were to do with either (pardon my memory) high-resolution or multichannel audio, but I still like keeping up-to-date!

Edit: Back on topic.

WavPack 4.3 discussion

Reply #1 –
is the source available for 4.2+ (*NIX) ?

WavPack 4.3 discussion

Reply #2 –
Quote
Since the version being discussed is still 4.2, is there any chance of a similarly optimised version of 4.22? I understand the only major fixes between the two versions were to do with either (pardon my memory) high-resolution or multichannel audio, but I still like keeping up-to-date!
[a href="index.php?act=findpost&pid=333977"][{POST_SNAPBACK}][/a]

The sources for 4.22 have not been released, so this would be quite difficult. 

The issue with 4.2 is exceedingly rare and can only occur when the -h and -x modes are used together. In that case I would suggest a verify pass to make sure no corrupt files are created (and even if they are created, they won't be corrupt with the next version decoder).

I am finishing up 4.3 now, and that will be a full release with sources (including *nix). If I had known how long it was going to be for 4.3 I would have released sooner. What do they say about the best laid plans...? 

WavPack 4.3 discussion

Reply #3 –
Quote
The issue with 4.2 is exceedingly rare and can only occur when the -h and -x modes are used together. [a href="index.php?act=findpost&pid=334102"][{POST_SNAPBACK}][/a]

I've been using 4.2 on 16 bit 44.1 kHz files. I thought this bug only affected files with larger resolution/frequency. Is there a way to verify if I am affected by this bug  without reripping.

Quote
I am finishing up 4.3 now, and that will be a full release with sources (including *nix).[a href="index.php?act=findpost&pid=334102"][{POST_SNAPBACK}][/a]

Sweet. Would you briefly tell us what to expect in the new version?
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.

WavPack 4.3 discussion

Reply #4 –
thanks for your great work, david


-mike

WavPack 4.3 discussion

Reply #5 –
David, thanks for clarifying.

WavPack 4.3 discussion

Reply #6 –
@atici:


As David pointed out, there is no bug in the encoder (so fear no re-ripping). The bug is only in the decoder and for high resolution formats (24bit, not sure at what sampling rate) for files encoded with  the -h and -x parametes toghether.

Sergio

EDIT: David explains much better (and with authority) in the next post. Disregard this post!
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

WavPack 4.3 discussion

Reply #7 –
Quote
Quote
The issue with 4.2 is exceedingly rare and can only occur when the -h and -x modes are used together. [a href="index.php?act=findpost&pid=334102"][{POST_SNAPBACK}][/a]

I've been using 4.2 on 16 bit 44.1 kHz files. I thought this bug only affected files with larger resolution/frequency. Is there a way to verify if I am affected by this bug  without reripping.

Quote
I am finishing up 4.3 now, and that will be a full release with sources (including *nix).[a href="index.php?act=findpost&pid=334102"][{POST_SNAPBACK}][/a]

Sweet. Would you briefly tell us what to expect in the new version?
[a href="index.php?act=findpost&pid=334146"][{POST_SNAPBACK}][/a]

It is much more likely to happen with 24-bit data that has been oversampled (i.e. DVD-audio). I tried to generate a file that would make it happen with 16-bit data and failed, but I am not willing to say it's impossible. Considering how much 16-bit data has gone through WavPack 4, it doesn't seem very likely.

However, just doing a -v verify with wvunpack will make sure your files are okay. And, like I said before, even if you do find a bad one, the new decoder will fix it.

In addition to the above fix, the enhancements for 4.3 are actually not too sexy. They include new options to run at low priority and discard extra RIFF chunks (a la FLAC), the metadata-from-file improvements from Synthetic Soul and Martin H, an error-handling change also suggested by Synthetic Soul, the integration of the "debug" mode into the standard version (by just renaming the .exe), some enhancements to the robustness of the playback code, a feature to make using the library to create WavPack files easier, and probably some little things I can't think of.

I wanted to put in the smart noise-shaping feature suggested by Shadowking (and I actually developed it) but then decided after some discussion with another HA member that breaking the decoder would be a bad idea. I will still be able to implement the noise-shaping change in the existing framework, but it will require more effort and I didn't want to delay this release any longer.

WavPack 4.3 discussion

Reply #8 –
Haha, I knew I was forgetting some (I was at work). I also added support for non-standard sampling rates and fixed the problem triggered by very wide screen formats (compiler bug, it turned out).

WavPack 4.3 discussion

Reply #9 –
Keep up the good work, looking forward to seeing 4.3

WavPack 4.3 discussion

Reply #10 –
Me too... although I don't think I'll be re-encoding my album images!