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

Wavpack 4.31 release

A small update to WavPack was released and given the version 4.31

among some small changes the ReplayGain tool wvgain was added.

Changelog in next message
In theory, there is no difference between theory and practice. In practice there is.

Wavpack 4.31 release

Reply #1 –
A small update to WavPack was released and given the version 4.31

among some small changes the ReplayGain tool wvgain was added.

Code: [Select]
 wavpack.exe (command-line encoder) - 4.31
 wvunpack.exe (command-line decoder) - 4.31
 ------------------------------------------
  fixed: detect debug mode in all cases (win32 only)
  improved: use latest service pack and SDK for building (win32 only)
  improved: better directory choice for logging file (win32 only)
  improved: allow shell to expand wildcards (*nix only)
  added: option (-o) to specify output directory or path (*nix only)
  added: option (-t) to copy timestamp (*nix only)

 wvgain.exe (command-line ReplayGain scanner) - 4.31
 ---------------------------------------------------
  new

 WavPack Library Source Code - 4.31
 ----------------------------------
  fixed: failing seek with some files that had been played to the end
  fixed: small memory leak when opening hybrid lossless files
  improved: signed characters no longer must be default
  improved: APEv2 tags are read even if followed by ID3v1 tag
  improved: limited APEv2 tag editing capability
In theory, there is no difference between theory and practice. In practice there is.

Wavpack 4.31 release

Reply #2 –
Will any support for multi-track cue-embedded images be added to WVGain?

Wavpack 4.31 release

Reply #3 –
Great stuff

Just downloaded 4.3 a few times, so don't forget to refresh the page or clear your cache if you still get the old version.

Wavpack 4.31 release

Reply #4 –
Quote
Will any support for multi-track cue-embedded images be added to WVGain?
[a href="index.php?act=findpost&pid=349719"][{POST_SNAPBACK}][/a]

I'm sorry, but I don't have any plans to add any cuesheet specific functionality to WavPack right now. I'd like to, but I have so many other things I want to work on first (and so little free time) that I don't think it will happen for a while.

Wavpack 4.31 release

Reply #5 –
That's cool!

Wavpack 4.31 release

Reply #6 –
I just uploaded some Unixen builds of it to RareWares. Still missing the MacOS X build, because the SF Compile Farm machines are down...

Wavpack 4.31 release

Reply #7 –
small feature request:
an option that deletes any input file used

for example my command line is:
wavpack -m -t -d -w "CUESHEET=@*.cue" -w "LOG=@*.log"

this deletes the .wav file but not the CUE or the LOG. i have to do that manually at the moment. i think a -da (delete all?) switch might be really useful.

thanks, benjamin

Wavpack 4.31 release

Reply #8 –
Quote
small feature request:
an option that deletes any input file used

for example my command line is:
wavpack -m -t -d -w "CUESHEET=@*.cue" -w "LOG=@*.log"

this deletes the .wav file but not the CUE or the LOG. i have to do that manually at the moment. i think a -da (delete all?) switch might be really useful.

thanks, benjamin
[a href="index.php?act=findpost&pid=355411"][{POST_SNAPBACK}][/a]

Well, -da would not work because there already is a -a option. But it seems to me that not deleting the other files could be considered an oversight on my part, after all they are part of the "source". I may just have -d delete all sources. Thanks, I'll look at that for the next release.

Wavpack 4.31 release

Reply #9 –
Have installed Rockbox H300 Optimized on my iRiver H340 International now, so I'm currently an owner of a WavPack playing DAP...

However, I have encoded most of my WavPacks with the -h option. It seems most files playback just fine, but I had some stuttering on two or three files. When recoded with no options (lossless, normal) these files playback fine. So I should probably stay away from using -h when coding for the H340. Would I however gain anything significant by encoding asynchronously? E.g wavpack -x4 ?
If there's any gain in filesize only affecting encoding but not decoding it could be worth it, maybe....... Have anybody tested with any larger number of files?
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts
 

Wavpack 4.31 release

Reply #10 –
Quote
Have installed Rockbox H300 Optimized on my iRiver H340 International now, so I'm currently an owner of a WavPack playing DAP...

However, I have encoded most of my WavPacks with the -h option. It seems most files playback just fine, but I had some stuttering on two or three files. When recoded with no options (lossless, normal) these files playback fine. So I should probably stay away from using -h when coding for the H340. Would I however gain anything significant by encoding asynchronously? E.g wavpack -x4 ?
If there's any gain in filesize only affecting encoding but not decoding it could be worth it, maybe....... Have anybody tested with any larger number of files?
[a href="index.php?act=findpost&pid=360267"][{POST_SNAPBACK}][/a]

Glad to hear you got RockBox going on your H340! 

I have not experienced any problems with WavPack -h on my H120. Perhaps this is a H340 specific thing, or just something with the latest build that will get fixed. It should work with all files. If it always happens on a specific track maybe you can get it to me somehow and I can try it on my H120 with the latest code. Obviously something that needs to get downsampled to 44.1, or if you're playing games at the same time, could make a difference.

Of course, "high" mode will take more CPU and therefore drain the batteries faster... 

Adding the -x switch to the normal mode makes an average of about %0.5 improvement, and it actually makes decoding a little faster in most cases. This is about half of the improvement that you get with -h, however I've seen files that get quite a bit more or less.