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.0 Beta Release 3 (Read 37271 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.0 Beta Release 3

The third (and probably last) beta release of WavPack 4.0 includes the following:
  • Adobe Audition (Cool Edit) filter with 32-bit float & extra info support
  • more robust error decoding (with error muting)
  • new library interface to encoding functions
  • improved hybrid mode noise shaping
  • md5 signatures
download win32 executables and plugins
download sources


WavPack 4.0 Beta Release 3

Reply #2
With the addition of the Audition file filter, this package now incorporates all the important functionality of the 3.97 version. Therefore, assuming nothing untoward is discovered, I will be releasing 4.0 in a week or two.

I have incorporated all of robUx4's changes for Linux and OS-X compiles in the sources, so except for adding md5.c to the source list and fixing anything else I messed up, that should go painlessly.

Minor improvements / changes:
  • extra mode (-x) now has default level based on mode
  • new option to store floats (and larger ints) with resolution limited to 25 bits (saves space with virtually no audio degradation)
  • new option to minimize console messages (-q)
  • new option to ignore .wvc file during decode (-i)
  • new option to decode to raw audio only (-r)
  • full error reporting in foobar plugin
Quote
keep up the good work 

Thanks! 

 

WavPack 4.0 Beta Release 3

Reply #3
Sounds nice indeed, now to do the same with WavPack as done with MAC - insert CUE-file and EAC LOG-file into an APEv2 tag and voila, singlefile joy ;o)

I'll be checking this out at once.

WavPack 4.0 Beta Release 3

Reply #4
New foobar2000 wavpack input by Case available here.

Supports handling of internal cuesheets the same way monkeys input does allready.

Simply add a "cuesheet" tag to the file and paste your correct cuesheet into it.

Many thanks to Case for updating this.


@bryant:

Nice work.  Just finally played around with this a bit and it seems the normal compression setting is a very nice tradeoff between filesize and decoding speed.  Might even concider switching over entirely to wavpack now that case has added internal cuesheet support.


Here is a small comparison I made between the different wavpack modes and Monkeys Audio normal. Only did this on one album though, so I can't promise it is entirely valid for all types of music. Also compared to monkeys audio 3.97 and  not 3.99.  3.99 should be at least about 10% slower then 3.97 on decoding.

Done on Athlon XP 3000 with 1024 mb of ram.

Results:

Wavpack 4.0 beta3 decoding speed (Asian Dub Foundation - Enemy of the Enemy) :

normal:   ~70 times   351 mb
high:   ~36 times   341 mb
fast:   ~93 times   358 mb

Monkeys Audio 3.97:

normal:   ~46 times   340 mb

WavPack 4.0 Beta Release 3

Reply #5
picmixer & Case:

Thanks for the cuesheet support; I'll give that a try myself.  Is this something I could easily integrate into my foobar source?

BTW, picmixer, if decoding speed vs. filesize is your primary concern, you might want to give the -X switch a try. It slows encoding way down, but decoding is not affected and it can sometimes get you almost to the next higher mode with respect to compression ratio. (of course, maybe that's what you used...)

WavPack 4.0 Beta Release 3

Reply #6
Quote
BTW, picmixer, if decoding speed vs. filesize is your primary concern, you might want to give the -X switch a try. It slows encoding way down, but decoding is not affected and it can sometimes get you almost to the next higher mode with respect to compression ratio. (of course, maybe that's what you used...)

Hmh, no havent tried that yet. Thanks for the hint.

High decoding speed with the least tradeoff in filesize is indeed what I am after. Curious to see the results.

WavPack 4.0 Beta Release 3

Reply #7
Good stuff David, as always. 

I'll have a play with your "new and improved" hybrid mode noise shaping and let you know my thoughts.

Thanks for this.

Den

WavPack 4.0 Beta Release 3

Reply #8
Quote
New foobar2000 wavpack input by Case available here.

Supports handling of internal cuesheets the same way monkeys input does allready.

Simply add a "cuesheet" tag to the file and paste your correct cuesheet into it.

Is there any way to automate this from a batch file?

WavPack 4.0 Beta Release 3

Reply #9
Quote
I have incorporated all of robUx4's changes for Linux and OS-X compiles in the sources, so except for adding md5.c to the source list and fixing anything else I messed up, that should go painlessly.

Do you have a linux makefile for b3?  I'm not having much luck getting it to compile.


WavPack 4.0 Beta Release 3

Reply #11
Quote
Thanks for the cuesheet support; I'll give that a try myself. :) Is this something I could easily integrate into my foobar source?

Hi Dave,
Case made the source also available: foo_wavpack_src.zip

@ robUx4,
I've tried the beta2 makefile, but it didn't work. I did add the md5.c file to Makefile.wavpack and Makefile.wvunpack. Could you have a look?


WavPack 4.0 Beta Release 3

Reply #13
Good luck with it!

WavPack 4.0 Beta Release 3

Reply #14
The user documentation says that for every 14kbps over 320kbps the quantisation noise is lowered by about 1 dB. How does the -h and the new -x[n] option affect the hybrid quality? Also; does encoding to a 320kbps wv hybrid file result in a higher quality file than i.e. mp3 or ogg vorbis at the same bitrate?

WavPack 4.0 Beta Release 3

Reply #15
I guess my question put simple is this: Is it worth waiting 30 extra minutes using the -x switch when encoding an album in hybrid mode?

WavPack 4.0 Beta Release 3

Reply #16
Quote
I guess my question put simple is this: Is it worth waiting 30 extra minutes using the -x switch when encoding an album in hybrid mode?

The -x switch does improve the quality of the hybrid mode slightly (you can see this using the -n switch), but I don't think that alone would be worth the extra time. However, there are times when the -x switch makes a big difference (at least in the normal mode), like on this WavPack torture sample:

http://wavpack.com/Furious.wv

So, I would say that if have the time then it's worth using -x as an insurance against problem samples. If you don't have the time then it's not worth it...  ;-)

As for comparing WavPack's lossy mode with other lossy codecs at high bitrates, this is very difficult because they are almost all transparent (to most people and with most samples). However, there is some evidence that WavPack (and the other hybrid encoder OptimFROG) perform better with transcoding.

Also, WavPack lossy is not subject to the accumulation of artifacts that you get with repeated encode / decode cycles. For example, you can do dozens of encode / decode cycles with WavPack lossy at 512 kbps and the result will still sound fine (maybe equivalent to a single cycle at 320 kbps). Do this with other codecs and the non-linearities in frequency response and time-domain smearing will make the sample unlistenable. I'm not sure this has any relevance to normal usage, but it does demonstrate a difference in the techniques.

Hope this helps...

WavPack 4.0 Beta Release 3

Reply #17
Yes that helped a bunch. Thanks 


WavPack 4.0 Beta Release 3

Reply #19
@ David :

Where would our guys have to search if we want a simple lib to parse your framing ? Mosu thought about adding wavpack support to mkvtoolnix lately, but stopped it right after he learned from robux4 that there is  both an encoder and decoder library now, but there is no explicit part of the code allowing to parse a Wavpack stream and mux the packets in matroska.

Can you help us on this ? Is there a parsing code already, and we just dont find it ?

WavPack 4.0 Beta Release 3

Reply #20
Thanks robUx4. Two observations:

1. Wildcards don't work in Linux ('wavpack *.wav' doesn't work)
2. 'wvunpack -vm file.wv' gives this in Windows:
Code: [Select]
 WVUNPACK  Hybrid Lossless Wavefile Decompressor  Win32 Version 4.0b3  28-06-04
Copyright (c) 1998 - 2004 Conifer Software.  All Rights Reserved.

original md5 signature: 783bc77ac749566e2870d2a002d96236
unpacked md5 signature: 783bc77ac749566e2870d2a002d96236
verified 05 - A Forest.wv in 19.71 secs (lossless, 50.75%)


and this in Linux:

Code: [Select]
 WVUNPACK  Hybrid Lossless Wavefile Decompressor  Linux Version 4.0b3  28-06-04
Copyright (c) 1998 - 2004 Conifer Software.  All Rights Reserved.

unpacked md5 signature: b23456ef10fe4bacc64771ee8779fcdb
verified track_01.wv in 35.71 secs (lossless, 48.18%)

The original md5 signature is missing in Linux.

WavPack 4.0 Beta Release 3

Reply #21
Speek:
First of all, thanks to you and Case for making that foo_wavpack source available. I really appreciate it.

As for the Linux MD5 thing, I see that the files are not the same one. Have you tried both versions decoding the exact same file? I can't tell if the problem is that the Linux encoder is not putting the MD5 in the .wv file in the first place, or whether the decoder just can't see it. I assume you realize that you must use the -m when encoding to enable writing the MD5 into the file, that option is not just for displaying it.

BTW, thanks for your testing! 

ChristianHJW:
Not only can I help, but I want to help. If there's any functionality that you need that's not in there, I'm sure I can put it together very quickly.

As robUx4 says, there are library routines for both decoding existing WavPack files and for creating new WavPack files. The functions for creating WavPack files have no I/O calls in them; you simply pass raw audio data to the functions and they call you back with complete (no parsing required!) WavPack blocks (which I assume you guys just put into your container as is). You can put exactly as many samples in each block as you like because I provide a "flush" routine.

On the decode side, there is parsing code that is mixed with the file reading code and the code for seeking. However, I assumed that you would not use this because you would already know where the blocks started and ended because that's how I passed them to you in the first place. A couple calls to the decoder will unpack a single block into its raw samples again.

The only complication here is perhaps how multichannel audio is handled. On the encode side my functions expect the data to be interleaved through all channels (like a .wav file) and it automatically separates it into mono and stereo streams and packs them into their own blocks (all transparent to you). However, on decode your code would have to do the re-interleaving. I could provide some helping functionality here if needed.

But I think this is all very easy to accomplish; I just need to be made to understand exactly what you guys want. The WavPack code is done and ready to go.

WavPack 4.0 Beta Release 3

Reply #22
Quote
Speek:
First of all, thanks to you and Case for making that foo_wavpack source available. I really appreciate it.

As for the Linux MD5 thing, I see that the files are not the same one. Have you tried both versions decoding the exact same file? I can't tell if the problem is that the Linux encoder is not putting the MD5 in the .wv file in the first place, or whether the decoder just can't see it. I assume you realize that you must use the -m when encoding to enable writing the MD5 into the file, that option is not just for displaying it.

The foo_wavpack modification is entirely Case's work. I just supplied the link.

The MD5sum works fine in Linux too. I just forgot to add the -m switch when encoding.

One small thingy: in line 78 of wavpack.c you removed the '\n' at the end of the help text. This results in the prompt being on the same line as the last line of the help text in Linux.


WavPack 4.0 Beta Release 3

Reply #24
Hmm, yes wavpack "*.wav" does work. But what's the difference? (or where can I read about that?)

I made a simple bash script to play wavpack files in Linux. It needs aplay which is part of alsa-utils and should be available on most modern Linux distributions.

Usage:
1. Copy this text in a text file named something like 'wavpack123' (you can make up your own filename) and save it.
2. Put it somewhere in the PATH (i.e. /usr/local/bin).
3. Make it executable (chmod +x wavpack123)
4. cd into directory with wavpack files and do 'wavpack123 *' or 'wavpack123 filename' or 'wavpack123 file1 file2 file3' or 'wavpack123 file[1-3]'.
5. Improve the script, because I'm just a beginner and I'm sure there are may Linux users here that can do better

Code: [Select]
#!/bin/bash

if [ "$1" = "" ] || [ "$1" = "--help" ] || [ "$1" = "-h" ]
then
  echo "Usage: `basename $0` <files>. Wildcards can be used."
else
  until [ -z "$1" ]
  do
     if [ "$TERM" != "linux" ]
     then
        # We're on a X terminal (xterm, rxvt, etc.). Put filename in title bar.
        title=`basename "$1" .wv`
        echo -n -e "\e]2;$title\a"
     fi
     wvunpack "$1" - | aplay -q
     shift
  done
 
  if [ "$TERM" != "linux" ]
  then  
     echo -n -e "\e]2;Finished playing\a"
  fi
fi

exit 0