HydrogenAudio

Lossless Audio Compression => WavPack => Topic started by: bryant on 2004-05-07 06:01:11

Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-05-07 06:01:11
The second beta release of WavPack 4.0 includes the following:download win32 executables plus winamp2/5 & foobar2000 plugins (http://wavpack.com/beta2.zip)
download sources (http://wavpack.com/beta2src.zip)
Title: WavPack 4.0 Beta Release 2
Post by: xmixahlx on 2004-05-07 07:05:29
excellent!

so porting to, say, libwavpack library and wavpack frontend for *NIX seems much more achievable now?  i'm IN.

btw, who is interested in this porting endeavor? can i see a raise of hands?


thanx david!
Title: WavPack 4.0 Beta Release 2
Post by: aabxx on 2004-05-07 07:19:22
I tried the new asymmetrical encoding... very slow to encode, but
should according to readme not affect decode-time. Every encoder is
set to max compression.

A typical modern pop song: 34 468 604 bytes
Flac                                : 23 215 157 bytes (48,475% compression)
Old Wavpack                    : 22 776 702 bytes (51,333% compression)
New Wavpack                  : 20 465 194 bytes (68,425% compression)

Expect the monkey audios and optimfrogs of this world to easily beat
the new wavpack, at least at higher settings, but compared to its main
competitor and open source colleague FLAC and the old version it's looking
good! Besides it's all about the hybrid mode hehe ;)

But this could have been a fluke, of course ;) Hopefully someone will
do thorough testing on it soon, including decode-times.
Title: WavPack 4.0 Beta Release 2
Post by: NRAninja on 2004-05-07 07:23:19
Hello bryant,

I like Wavpack 4 very much. I noticed in the readme that you were planning on supporting MD5 and cuesheets. Is cuesheet support going to be like Monkey's APL or what?

I was also wondering if you planned on implementing replaygain. What I mean is something like a switch in wavpack.exe that can go through a folder and add replaygain to the tags like how metaflac and vorbisgain do it. I would like to be able to encode and replaygain in one step using UniversalFront or a perl script a friend of mine wrote.

Thank you,
ninja
Title: WavPack 4.0 Beta Release 2
Post by: Tec9SD on 2004-05-07 07:37:13
Quote
I was also wondering if you planned on implementing replaygain. What I mean is something like a switch in wavpack.exe that can go through a folder and add replaygain to the tags like how metaflac and vorbisgain do it. I would like to be able to encode and replaygain in one step using UniversalFront or a perl script a friend of mine wrote.

I too would really enjoy having Replay Gain support.
Replay Gain, native support, is along with its cuesheet implementation are major reasons which make FLAC my favorite lossless codec.

This would help me to consider a switch.

Many thanks for everything Bryant.

Take care, tec

-----
Also Bryant, would this be the thread you prefer for us to add suggestions or feature requests?
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-07 08:07:10
We're planning to have WavPack handling natively in Matroska so ReplayGain should be handled in there (the container).
Title: WavPack 4.0 Beta Release 2
Post by: NumLOCK on 2004-05-07 09:29:50
Quote
A typical modern pop song: 34 468 604 bytes
Flac                                 : 23 215 157 bytes (48,475% compression)
Old Wavpack                    : 22 776 702 bytes (51,333% compression)
New Wavpack                   : 20 465 194 bytes (68,425% compression)

Shouldn't it rather be (in your notation):

Flac: 32.64%
Old Wavpack: 33.92%
New Wavpack: 40.62%

Title: WavPack 4.0 Beta Release 2
Post by: tcmjr on 2004-05-07 14:24:40
Hey Bryant , nice to see you again  Had an Hdd crash , as lost all my .wv collection using 4 beta 1  was working flawless.

According to my testes wavpack -h is a little bit better than flac -8 being the ecoding speed MUCH MUCH faster.
-hx6 indeed takes a LOOOONG time and not much compression gain for most of my samples. -hx3 gives me times compared to flac and a little bit better compress for its time.
Title: WavPack 4.0 Beta Release 2
Post by: mrbruno on 2004-05-07 17:12:50
hi !

wavpack seems to be a very interesting encoder... but
what about tags ? does it support it ?
Title: WavPack 4.0 Beta Release 2
Post by: Tomb on 2004-05-07 17:19:50
You can tag with ID3v1, ID3v2 or APE2. I tag with APE2 as per Case's guide. (http://www.saunalahti.fi/cse/EAC/index.html)
Title: WavPack 4.0 Beta Release 2
Post by: mrbruno on 2004-05-07 17:27:36
well, I'd like to tag wavpack files with ID3 tags...
In fact,  if I could just copy ID3 tags from MP3 files
to wavpack files that would be fine !
(I don't use eac to create my wavpack files,
because I'm using wavpack to encode audio
that I recorded from FM radio (talk shows).
Title: WavPack 4.0 Beta Release 2
Post by: rjamorim on 2004-05-07 18:12:07
Quote
Quote
I was also wondering if you planned on implementing replaygain. What I mean is something like a switch in wavpack.exe that can go through a folder and add replaygain to the tags like how metaflac and vorbisgain do it. I would like to be able to encode and replaygain in one step using UniversalFront or a perl script a friend of mine wrote.

I too would really enjoy having Replay Gain support.
Replay Gain, native support, is along with its cuesheet implementation are major reasons which make FLAC my favorite lossless codec.

This would help me to consider a switch.

ReplayGain and CueSheet (Including CD text  ) are planned for the mid-term. For short term, porting and creation of a library.

It accepts ID3v1 and APEv2 tags without problems. I'm not sure about ID3v2, but even if it's not officially supported, the decoder can easily skip them.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-07 18:19:35
I'm currently porting the sources to Linux (keeping Win32 compatibility). It's harder than expected but still feasable. Then I'll try to port it to big endian machines (OS X).

I'll publish the modified sources ASAP.
Title: WavPack 4.0 Beta Release 2
Post by: emtee on 2004-05-07 18:21:23
What about seeking? I remember version 3.97 had some seeking problems in winamp.
Title: WavPack 4.0 Beta Release 2
Post by: Speek on 2004-05-07 19:07:40
Quote
What about seeking? I remember version 3.97 had some seeking problems in winamp.

From the readme:
WavPack 4.0 is intended to eliminate all of the shortcomings of the previous WavPack, the most obvious of which is the slow seeking.

Added WavPack 4.0 beta 2 to my comparison (http://members.home.nl/w.speek/comparison.htm).
Title: WavPack 4.0 Beta Release 2
Post by: tcmjr on 2004-05-07 19:17:30
Quote
What about seeking? I remember version 3.97 had some seeking problems in winamp.

WavPack 4.0 is intended to eliminate all of the shortcomings of the previous
WavPack, the most obvious of which is the slow seeking.

and


First of all, the new WavPack format is block oriented, which facilitates fast
seeking. Also, since each block is independently decodable, the format is
streamable and inherently error-resistant (although the decoder and winamp
plugin do not yet take advantage of this). In fact, the blocks can be separated
and embedded into another container format and still be decoded transparently
by the Wvunpack program!
Title: WavPack 4.0 Beta Release 2
Post by: Tec9SD on 2004-05-07 19:27:12
Quote
well, I'd like to tag wavpack files with ID3 tags...
In fact,  if I could just copy ID3 tags from MP3 files
to wavpack files that would be fine !

Mp3tag (http://www.mp3tag.de/en/) should be able to to do what you are interested in.

I don't believe I've tried tagging Wavpack with it before, so I'm unsure every type of tag Mp3tag will allow. It's certainly worth a try though.

Speek's Tag frontend (http://members.home.nl/w.speek/tag.htm) & Tagger by Max Bureck (http://www.tagger.de.vu/) are both front-ends to Case's Tag (http://www.saunalahti.fi/~cse/html/tag.html).

If you are planning to use ID3v2 tags, Tag is unable to write them, so you'll know.

And foobar2000 (http://www.foobar2000.org/) normal installer includes Wavpack support and the Masstagger which will allow tagging (only APEv2 for Wavpack, to my knowledge).

Personally, I suggest using APEv2 tags, and if ID3 is necessary, use ID3v1.1 additionally for compatibility.

Hope this makes things easier, tec
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-07 21:35:57
The modified sources that work both under Win32 and Linux can be found on my website (http://mukoli.free.fr/wavpack/).

The Linux version has only one drawback, you can't use wildcards (yet). I may fix that tomorrow and hopefully make it work under OS X too.
Title: WavPack 4.0 Beta Release 2
Post by: rjamorim on 2004-05-07 22:25:17
Wonderful. Thank-you very much

@xmixahlx: Where is the Debian package?
Title: WavPack 4.0 Beta Release 2
Post by: naturfreak on 2004-05-07 22:44:24
Bug in Wavpack4 beta2 (win32 executable)?

Hello,

I did some test encodes on my PC with the new beta version. I discovered probably a bug.

After processing the program remains in the memory.

I had several instances of wavpack in the memory after encoding. Processor load stayed at 100%. I had to shutdown the tasks of wavpack manually using the taskmanager.

I'm using OS Windows2000 SP4 German.


Sorry for bad english. It's not my native language, but I'll try to improve my language skills.

Regards
naturfreak
Title: WavPack 4.0 Beta Release 2
Post by: tcmjr on 2004-05-07 23:28:11
no problem using windows xp sp1 all patches
Title: WavPack 4.0 Beta Release 2
Post by: kuniklo on 2004-05-07 23:38:12
Quote
The modified sources that work both under Win32 and Linux can be found on my website (http://mukoli.free.fr/wavpack/).

The Linux version has only one drawback, you can't use wildcards (yet). I may fix that tomorrow and hopefully make it work under OS X too.

Thanks for taking the time to get this working.

It's mostly working for me on my debian unstable box, but I have found two problems:

1. Wvunpack segfaults when unpacking a .wv file if it has to ask about overwriting an existing .wav file.

2. Wvunpack segfaults when unpacking a .wvc.
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-08 00:21:48
Now that Wavpack 4 is relatively stable, and the format is more or less locked, I'm cranking up some testing on the lossy modes. I'll come back with some comments in a few days.

Den.

PS: It goes without saying, Thanks a heap David, and to you others who have whipped up the linux version(s). 
Title: WavPack 4.0 Beta Release 2
Post by: xmixahlx on 2004-05-08 07:16:25
Quote
@xmixahlx: Where is the Debian package?

i actually had it packaged moments after he posted the sources (14:00:03 -0700) but had to leave in a hurry before i could upload them

they are there now (i'm assuming these will be test/preliminary packages so expect them to be modified/updated several times) -- the packaging itself is complete

a few notes on the *nix port (usage debian sid)

* segfaults when overwriting
* doesn't exit gracefully
* still has win32 header
* i'd like to see a library + frontend duo (i.e. frontend does encode/decode)
--> library allows for ease of plugins/etc.

GREAT WORK ROBUX4! Thanx for your efforts! *cough*monkeysaudio*cough*


later
Title: WavPack 4.0 Beta Release 2
Post by: Pamel on 2004-05-08 07:29:27
Quote
First of all, the new WavPack format is block oriented, which facilitates fast seeking. Also, since each block is independently decodable, the format is
streamable and inherently error-resistant ...... In fact, the blocks can be separatedand embedded into another container format and still be decoded transparently

In other words, the Matroska support can start.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-08 09:12:15
Quote
a few notes on the *nix port (usage debian sid)

* segfaults when overwriting
* doesn't exit gracefully
* still has win32 header
* i'd like to see a library + frontend duo (i.e. frontend does encode/decode)
--> library allows for ease of plugins/etc.

GREAT WORK ROBUX4! Thanx for your efforts! *cough*monkeysaudio*cough*


later

You know what ? I'm already running my main compiter with Debian and I'm going to investigate on this.

What is this "win32 header thing" ?

About the library, I'll work on it under Windows first to make room for a DirectShow filter (for decoding from Matroska). The linux version will come afterward.

What about MonkeyAudio ? The linux support doesn't exist ? I can have a look too. And at OptimFrog too. That would make the best 4 lossless codec available which is great. Also note that TTA is now hosted on CoreCodec (maybe WavPack could be hosted there too for the CVS) and so I can probably port that too...
Title: WavPack 4.0 Beta Release 2
Post by: FireStarter on 2004-05-08 12:39:10
Maybe i am blind and it have already been posted, but my files
from the new wavepack doesn`t play in foobar.
am running 0.81.
Is there a new foobar plugin made.?
Title: WavPack 4.0 Beta Release 2
Post by: tcmjr on 2004-05-08 13:18:16
No foobar plugin for wavpack 4 yet.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-08 15:00:46
I fixed all the known bugs in Linux. You can find the updated sources in the same place (http://mukoli.free.fr/wavpack/).
Title: WavPack 4.0 Beta Release 2
Post by: xmixahlx on 2004-05-08 15:01:06
optimfrog is closed source, florin just hasn't produced linux binaries for the latest version (he's given me permission to distribute in debian packages, too, btw...)

the win32 header is just simple editing: (local variable storage in wavpack.c/wvunpack.c)
Code: [Select]
 WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.0b2  5-6-04
Copyright (c) 1998 - 2004 Conifer Software.  All Rights Reserved.


(Note: since i presume there won't be seperate source trees for win32/nix, since/if the porting does not raise issues with win32 -- perhaps just drop the "win32 version" ?

imho, things needing porting:

Case's Tag
Monkey's Audio 3.99

frank klemm ported 3.96b8, so it is in need of re-porting for 3.99's compatibility - also, matt has stated that he doesn't give a **** about the porting process so we are on our own


later
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-08 15:05:07
What's the license of Monkey's Audio ? I was told by the GStreamer guys that they have to ship their version separately because of license issues.

(It Linux it now displays "Linux Version 4.0b2  08-05-04" )
Title: WavPack 4.0 Beta Release 2
Post by: Peter on 2004-05-08 15:38:02
I see WavPack author has yet to discover the idea of file reader callbacks - for reference, Monkey, Flac and OptimFrog all support them.
There will be no updated foobar2000 component (at least not from us) because making new WavPack decoder that isn't broken (no unicode, no streaming, no archive support) would require entire library to be modified to use file access callbacks instead of filenames and I have better things to do in my life than hacking wvunpack source once again.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-08 15:57:02
With David's permission I'll work on a libwv library to encode/decode from a buffer (needed for container integration). So from that point you probably can use it for your player.
Title: WavPack 4.0 Beta Release 2
Post by: glauco on 2004-05-08 20:05:33
TEST MACHINE

Intel Pentium 4 2,4 GHz. 512 MB DDR RAM (266). HDD Maxtor 80 GB 5400 rpm.


TEST FILES

40 files of 1:40 each, fragments of popular songs by Aerosmith, Babyface, Dire Straits, Eric Clapton, Metallica, Mike Oldfield, Phil Collin, Queen, Santana, The Cranberries, U2 and many more.


TEST NOTES

Note that, as the fragments are from the middle of the songs, they are quite loud, without the quieter parts of the beginNing and the end. Thus, the compression ratio is worse than what can be reached with the whole file; or, if you prefer, representative of the "worst case" scenario.

Also note that for the fastest compression and decompression modes the HDD can be the speed limitation factor. In this test a virtual RAM disk was created, but in some modes it's not enough.


WAV

size: 705601760 bytes ; play time: 66 min 40 seg


APE 3.97

extra high

size: 461848484 bytes ;      compress ratio: 65,45 % ;      compress time: 281 seg ;      speed: 14,23 x Real Time ;      decompress time: 281 seg

 
normal
   
size: 467814038 bytes ;      compress ratio: 66,30 % ;      compress time: 132 seg ;      speed: 30,30 x Real Time ;      decompress time: 132 seg


APE 3.99

extra high   
   
size: 461140873  bytes ;      ompress ratio: 65,35 % ;      compress time: 287 seg ;      speed: 13,39 x Real Time ;      decompress time: 287 seg
           
normal       
                 
size: 467440393 bytes ;      compress ratio: 66,24 % ;      compress time: 114 seg ;      speed: 35,08 x Real Time ;      decompress time: 114 seg

(oddly, this mode my build is noticebly slower when there is actual printing in the shell)


FLAC 1.10

-5         
   
size: 483974150 bytes ;      compress ratio: 68,59 % ;      compress time: 100 seg ;      speed: 40 x Real Time ;      decompress time: 56 seg ;      speed: 71,42 x Real Time
           

Wavpack 3.97

-h
   
size: 469534294 bytes ;      ompress ratio: 66,54 % ;      compress time: 157 seg ;      speed: 25,47 x Real Time ;      decompress time: 157 seg

(default)
   
size: 479243959 bytes ;      compress ratio: 67,92 % ;      compress time: 68 seg ;      speed: 58,8 x Real Time ;      decompress time: 68 seg 
       
-f
   
size: 503378455 bytes ;      compress ratio: 71,34 % ;      compress time: 36 seg ;      speed: 111 x Real Time ;      decompress time: 36 seg


Wavpack 4.0 beta 2

-h
   
size: 469887121 bytes ;      compress ratio: 66,59 % ;      compress time: 152 seg ;      speed: 26,31 x Real Time ;      decompress time: 120 seg ;    speed: 33,33 x Real Time

(default)
   
size: 479514963 bytes ;      compress ratio: 67,95 % ;      compress time: 85 seg ;      speed: 47,05 x Real Time ;      decompress time: 67 seg           

New assymetric modes

-hx4
   
size: 469180661 bytes ;      compress ratio: 66,49 % ;      compress time: 2130 seg ;      speed: 1,88 x Real Time ;      decompress time: 120 seg ;    speed: 33,33 x Real Time

-x4
   
size: 475361364 bytes ;      compress ratio: 67,37 % ;      compress time: 1399 seg ;      speed: 2,86 x Real Time ;      decompress time: 67 seg ;      speed: 59,7 x Real Time

-fx6
   
size: 485107697 bytes ;      compress ratio: 68,75 % ;      compress time: 704 seg ;      speed: 5,68 x Real Time ;      decompress time: 51 seg ;      speed: 78,46 x Real Time


SOME CONCLUSIONS

Wavpack 4 combines all the good points of MonkeyAudio AND Flac and much more:

· Good compression ratios
· Fast compression and decompression
· Fast seeking
· Lossless and hybrid modes
· Symmetric and asymmetric modes
· Public source
· Quality based VBR modes (in the near future, I hope).

If you have a fast CPU, you system is probably HDD limited. Then the fast modes are not any faster for you.

Asymmetric -x4 has the same decoding speed of flac, but more compression. Asymmetric -fx6 has the more decoding speed of flac, with roughly the same compression.
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-10 03:20:31
OK, as promised some Wavpack lossy listening test results for those who care.

Just to be sure, I grabbed the latest version linked on HA, ie beta2.zip, and got the following results.

First, I took the kraftwerk1, Waiting, queen - another one bites the dust, rushing and porcelain samples from ff123's site (thanks ff123!), decoded the flacs into wavs, and then encoded them with the beta using -hb256, -hb256x6, -b320, -hb320, -hb320x6. I didn't record times, but each encode was lightning quick except the x6 ones, which were painfully slow. (ie the non x settings took a matter of seconds for all the samples, where as each x6 encode took minutes)

I chose the above samples as I felt like a change from the samples I've used in the past with Wavpack 3.97.

kraftwerk1:
hb256 - not bad quality, but easy to ABX 10/10. Slight change detectable in the background fuzz. Also slight distortion in the three notes that come in 2.4-3.8 secs. Not really noticeable except in an ABX situation.
hb256x6 - very little difference to hb256 case. ABX 10/10
b320 - no real difference in background fuzz problem compared to hb256. Distortion on the three notes in 2.4 - 3.8 secs gone. ABX 10/10
hb320 - can not ABX consistently. Sometimes I think I can hear a hint of the fuzz, but can't consistently pick it so it is statistically transparent. ABX scores were ever better than 7/10 and were usually 5/10.

waiting:
hb256 - some slight noise around the vocals in the opening, but damn it's hard to pick every time. I can ABX it, but only consistently getting 8/10.
hb256x6 - can't ABX. Transparent. Blah!
Relatively noisy or busy samples like this one are good for Wavpack lossy to hide its sins within. It's when you have solo instruments and gaps in the music that any added noise can become more obvious.

Another one bites the dust:
hb256 - can ABX 10/10, but must concentrate, slight change in background noise in the recording, plus a hint of "dustiness" around the percussion.
hb256x6 - can still ABX, but it is much harder, and failed first attempt (6/10), but then got it the next couple trials in a row. (10/10 and 10/10)
b320 - can not ABX consistently. Sometimes I think I can hear a slight change in the b/g noise, but not consistently. Effectively transparent.
hb320 - transparent.

porcelain:
hb256 - Can ABX (10/10), slight changes in the noise/distortion that is part of the opening samples within the music.
b320 - still there, much much more subtle.
hb320 - got me, it's transparent.

rushing:
hb256 - at 4.5 secs in where some chords kick in, there is a slight but noticeable change in noise around the chords. (10/10)
hb256x6 - no change or improvement from hb256. (10/10)
b320 - bugger, it's transparent. (6/10, 6/10 and 5/10)

So in summary? hb256 is not normally going to be transparent, but it is still very good. None of these samples were disasters at 256 kbit. I wonder if Sony's new ATRAC 256kbit is this good? (I have my doubts, but I haven't tested it yet.)

hb256x6 sometimes makes some difference, but it is not consistent, and should not be counted on.

b320 is damn good and lightning quick to encode/decode. I personally would not use it as my default, as I prefer the extra security of hb320, but b320 will be transparent a lot of the time for most samples I believe.

hb320 is my choice for now. It is still quite quick, and seems to work very well at removing those little niggly changes in the noise to my ears. I can't comment on the benefits of hb320x6, as the hb320 has been transparent on the samples I have played with so far.

From the results above, you can see that I didn't get to even listen to the hb320x6 samples in this test, as transparency was reached in each case. Besides, life is too short! 

I haven't extensively tested the new Wavpack 4 lossy beta for transcoding performance, but I can not think of any reason to suspect it will have changed from the previous versions. I have started transpferring some parts of my collection to Wavpack 4 beta 2, and have not stumbled across any problem transcodes to ATRAC on my minidisc yet. 

Later,

Den.
Title: WavPack 4.0 Beta Release 2
Post by: The_Cisco_Kid on 2004-05-10 03:50:46
Played with it briefly, saw it was no joy in FB2k 0.8 and dropped it from my radar again for the moment. I did try to play a test file in WA 5.03 on the crashbox and got no joy there either even after copying the .DLL to the appropiate diectory; that must have been some snafu on my part or just due to my use of WA as a player for less than 5 minutes a month.
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-05-10 05:44:53
First of all, thanks to everyone who has tried out the new WavPack; especially those who posted results! I really appreciate it... 

robUx4:
Wow! Thanks for the quick turnaround on the Linux port! I am interested if the big-endian stuff goes as easily...

You don't need my permission to work on a libwv library, but if there's something I can do to help let me know. Almost everything does already happen in memory (except the legacy stuff which obviously comes out), so it should be pretty straightforward. I am going to reorganize the way packing works to use a library interface the way unpacking works now. Also, I need to make unpacking more robust, but that should not affect the interface.

naturfreak:
I think there is a problem with termination (although I'm using Win2K sp4 also and haven't seen it). I got a report from Jason (of shntools) that he is seeing this also in some situations and I will be looking into it. Thanks.

glauco:
Thanks, but you forgot to mention the multichannel and floating-point support! 

BTW, the "quality" mode won't be back real fast, but I have not given up on it. Also, all the hooks for it are in there so I probably won't have to break decoders when I have something.

FireStarter, etc.:
I am putting together a foorbar plugin now, should be just a few days away...

NRAninja, Tec9SD:
To tell you the truth, I haven't really studied the cuesheet issue enough to know what I want to do yet. I do have one question though. What is the primary purpose/advantage of using a cuesheet with a single compressed audio file for a whole album? Is it the convenience of a single file, or is just the ability to exactly restore (and burn) the album image? What if the exact album image could be ensured even though the tracks were in separate files? Just trying to get my head around this issue...

anyone:
If you have any hardware "connections" this is the time to start. I think that lossless hardware playback is fine, but I believe that WavPack's hybrid mode and portable playback could be killer combo. (I'd buy one, anyway).

Thanks, again...
Title: WavPack 4.0 Beta Release 2
Post by: Cerebus on 2004-05-10 21:12:57
I, too, would like a way to perform the replaygain calculations using the encoder, rather than through the matroska container.  I automate a lot of encoding and transcoding processes in Perl, and without this sort of functionality, I don't know how I'll be able to use the format as much as I'd like to.

The cuesheet and single file is a combination of convenience and being able to recreate the original layout of the cd.  There's really two schools of thought in the single file vs. multiple file issue.  Personally, I like separate files, but that doesn't mean that single file has no merit.  On the contrary, single file is cleaner, but has the issue of being able to index into that file to any track position.  APL functionality in WAVPACK would allow you to satisfy both schools.
Title: WavPack 4.0 Beta Release 2
Post by: NRAninja on 2004-05-10 21:20:56
The single file image and separate tracks issue is more of a personal preference rather than one way being 'better' than the other. It only makes a real difference when a disc has one of those hidden tracks before track 1. Ripping to an image will extract the hidden track. If you rip to separate tracks, the hidden part has to be ripped with a separate step. Single file ripping is less convenient for things like tagging since you can't really get track # and track title tags, but that doesn't make a difference if you use the cue in foobar2000 or if you have APL links like monkey's audio.
Title: WavPack 4.0 Beta Release 2
Post by: ghido on 2004-05-11 00:41:01
Hello,

Here it is a little summary of WavPack 4.0b2 using hb256. According to what den reported earlier, hb256 (around 256 Kb, high compression) is not generally transparent (at least for his ears). As a curiosity, I was working again now at some abandoned branch of OFS - OFSX (the OFS compressed files can be downloaded from http://losslessaudiocompression.com/audiotest (http://losslessaudiocompression.com/audiotest)).

The interesting fact is that the experimental files are *decodable* with any currently available OFS decoder.

Den: If you can ABX them, it would be great, so I can enhance the encoder if it works well, or throw it back into "trash"  [after I finish my diploma thesis ].

For each file, the effective bitrate was shown also. OFSX was used with --bitrate 256, exactly like the 4.509 encoder


kraftwerk1:
264 Kb WV  hb256 - ABX 10/10
259 Kb OFSX b256 - ABX  ?/10

waiting:
270 Kb WV  hb256 - ABX  8/10
256 Kb OFSX b256 - ABX  ?/10

Another one bites the dust:
259 Kb WV  hb256 - ABX 10/10
265 Kb OFSX b256 - ABX  ?/10

porcelain:
267 Kb WV  hb256 - ABX 10/10
256 Kb OFSX b256 - ABX  ?/10

rushing:
261 Kb WV  hb256 - ABX 10/10
260 Kb OFSX b256 - ABX  ?/10
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-11 02:14:15
Quote
Hello,

Here it is a little summary of WavPack 4.0b2 using hb256. According to what den reported earlier, hb256 (around 256 Kb, high compression) is not generally transparent (at least for his ears). As a curiosity, I was working again now at some abandoned branch of OFS - OFSX (the OFS compressed files can be downloaded from http://losslessaudiocompression.com/audiotest) (http://losslessaudiocompression.com/audiotest)).

The interesting fact is that the experimental files are *decodable* with any currently available OFS decoder.


I'll give it a go. I've downloaded your samples already (after removing the extra bracket in your link above), but when I go to your downloads page, and click on the decoder to download, Internet Exploder tries to download the .php file as html rather than the decoder itself. 

I'll grab the decoder again when I get back home and try the samples. Please bear with me as I have a few other things to get out of the way first, so it will probably happen later this week.

Edit: Got that decoder now, and the files. Will get back on this later this week.

Den.
Title: WavPack 4.0 Beta Release 2
Post by: Pamel on 2004-05-11 04:05:43
Quote
The single file image and separate tracks issue is more of a personal preference rather than one way being 'better' than the other.

I largely agree.  Although, for organizational issues, and data transfer, it is much more convenient to have single file.  For instance, if you have 100 albums on your harddrive.  Using the multi-file approach, if each CD had 10 tracks, and then you also had the booklet scanned in, you could easily have 2000 files to deal with.  This makes it difficult when trying to copy albums around to different locations or locate information.  Whereas the single file approach would give you 100 files.

On the flip side, if you only want to copy a single track, the single file approach means you must re-encode that track.
Quote
Single file ripping is less convenient for things like tagging since you can't really get track # and track title tags,
This works fine in Matroska.
Quote
single file is cleaner, but has the issue of being able to index into that file to any track position.
I'm not sure I understand what this means.
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-12 11:52:45
Ok, you asked for it...

kraftwerk1:
264 Kb WV hb256 - ABX 10/10
259 Kb OFSX b256 - ABX 10/10
In 2.4 - 3.4 seconds there are three tones (which I used to ABX Wavpack) and a "bwarp" type tone before. With the OFSX file, the edges of the "bwarp" sound are slightly different.

waiting:
270 Kb WV hb256 - ABX 8/10
256 Kb OFSX b256 - ABX 10/10
In 11.1 - 16.2 some of the edges to the noise are not quite the same.  The slight difference I could hear around the vocals in hb256 Wavpack are not present here. They disappear with hb256x6 also if you read above.

Another one bites the dust:
259 Kb WV hb256 - ABX 10/10
265 Kb OFSX b256 - ABX 10/10
Slight changes in the noise in the percussion. "Dustiness" is not so noticeable here.

porcelain:
267 Kb WV hb256 - ABX 10/10
256 Kb OFSX b256 - ABX 10/10
Again, the noise in the samples that come in is not quite the same, but damn close.

rushing:
261 Kb WV hb256 - ABX 10/10
260 Kb OFSX b256 - ABX ?/10
Haven't played with this one too closely yet, but a quick listen sounds transparent.

OK, the above might read like a negative set of results, but it shouldn't be read this way. I had to really pore over each sample to find differences to ABX, and it took more time to find something compared to the Wavpack equivalent hb256 samples. I haven't conducted a close comparison between OFSX and Wavpack 4, but the OFSX samples were generally "closer to transparency". I achieved the 10/10 ABX results more because I knew what to listen for after playing with Wavpack 4. If hb256x6 is used with Wavpack 4 instead, there is still some difference between the two, but the gap is often closer.

The "artifacts" I'm hearing are barely there, and are best described as minor changes in noise in the background in most cases. If you were to listen to the above OFSX versions by themselves, you would probably miss it. It only becomes vaguely noticeable in a focussed ABX situation with short samples.

If I had to pick one of these encoders at this bitrate based on these samples, purely for quality it would be OFSX, but we don't know how long these samples took to encode. If Wavpack is given plenty of time to encode (ie hb256x6) it gets quite close.

I wouldn't trash your encoder Florin. 

I also think that both you and David need to be congratulated with these latest efforts. At 256ish kbit, these encoders are now seriously in the same league as the other popular lossy encoders. 

Hope this helps.

Den.
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-12 13:59:14
Just to make sure that all is clear:

Quote
waiting:
270 Kb WV hb256 - ABX 8/10
256 Kb OFSX b256 - ABX 10/10
In 11.1 - 16.2 some of the edges to the noise are not quite the same. The slight difference I could hear around the vocals in hb256 Wavpack are not present here. They disappear with hb256x6 also if you read above.


...does not mean that Wavpack was better than OFSX for this sample. The lower score for Wavpack is just a repeat of my first trial results. If I was to listen to Waiting again now with Wavpack it would also be 10/10 as I know what to listen for.

Den.
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-05-14 08:00:47
My first attempt at an updated Foobar2000 plugin has now been added to the beta2 zip package (link above). It seems to work pretty well and plays all the new WavPack formats including multichannel and 32-bit floats. It also reads the .wvc file when present and plays all old WavPack files.

Many thanks to Peter and Case (and anyone else who previously worked on the WavPack Foobar plugin). I didn't realize how much work was involved until I "hacked" it myself. 

updated foobar plugin source code (http://wavpack.com/foo_wavpack.zip)
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-14 08:47:46
 

Thanks David. If there was anything holding Wavpack 4 back, this was it.

Thanks also for the work done by Peter and Case previously. You don't how good something is, until it's gone.

Den.
Title: WavPack 4.0 Beta Release 2
Post by: john33 on 2004-05-14 09:05:47
New 4.0b2 foobar2k plugin binary now at Rarewares.
Title: WavPack 4.0 Beta Release 2
Post by: FireStarter on 2004-05-14 10:12:52
Other then using foobar for transcode wavepack,
is there avabiable some other alternatives.?
Title: WavPack 4.0 Beta Release 2
Post by: Speek on 2004-05-14 11:25:04
Thanks for the foobar component. It works fine (so far...). Just one suggestion: maybe there should be a warning/error report in the console when a decoding error occurs (with a corrupt Wavpack file).

I like it very much that Wavpack 4 can keep decoding when errors occur. But could you make it so that the sound is muted when playing the corrupt samples? The noise I hear now is bad for my ears and my speakers 
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-14 13:13:33
Maybe that should be an option, with a third possibility : skip corrupted content.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-05-14 14:09:00
The latest sources are now uploaded on the CVS of CoreCodec (http://corecodec.org/projects/wavpack/). I haven't uploaded the foobar sources yet because I would like to merge them with the sources I have.
Title: WavPack 4.0 Beta Release 2
Post by: glauco on 2004-05-14 15:27:17
WOW!!!

Linux version, foobar plugin, sources in CVS... Good news keep comming.

Nice work everyone.
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-05-15 20:12:49
Quote
After processing the program remains in the memory.

I had several instances of wavpack in the memory after encoding. Processor load stayed at 100%. I had to shutdown the tasks of wavpack manually using the taskmanager.

I have created and uploaded an experimental wavpack+wvunpack package to hopefully address the termination problem (which I cannot reproduce, but which I think is related to a bug in Cygwin). Please let me know if this does not fix the problem (or if you are not using Cygwin). If this works we'll put it in the next release. Thanks again.

experimental version (http://wavpack.com/beta2x.zip)

Quote
Thanks for the foobar component. It works fine (so far...). Just one suggestion: maybe there should be a warning/error report in the console when a decoding error occurs (with a corrupt Wavpack file).
I like it very much that Wavpack 4 can keep decoding when errors occur. But could you make it so that the sound is muted when playing the corrupt samples? The noise I hear now is bad for my ears and my speakers 

Yes, one of my next projects is to make playback and decoding more robust, and part of this is to mute (and report) errors. I am also considering making a utility that could do in-place "repair" of WavPack files. This would allow time to do a more thorough repair, including a crossfading of material before and after the error.
Title: WavPack 4.0 Beta Release 2
Post by: Pamel on 2004-05-17 22:49:44
Quote
Yes, one of my next projects is to make playback and decoding more robust, and part of this is to mute (and report) errors.

Matroska already has support for adding CRC32 data to Blocks it contains.  Using this may be a little easier...
Title: WavPack 4.0 Beta Release 2
Post by: HansHeijden on 2004-05-19 19:33:27
For those interested, just updated the compression/speed webpage (see www button below) with some more WavPack -x levels. Although, the slowest ones will have to wait until some future PC...
Title: WavPack 4.0 Beta Release 2
Post by: SometimesWarrior on 2004-05-20 07:47:51
Quote
For those interested, just updated the compression/speed webpage (see www button below) with some more WavPack -x levels. Although, the slowest ones will have to wait until some future PC...

Thanks for the update, HansHeijden!
Title: WavPack 4.0 Beta Release 2
Post by: den on 2004-05-20 10:07:17
@FireStarter

Sorry I didn't answer you before, but yes you can use other tools to transcode to and from Wavpack4. If you stick to the 3.97 options, you can use any of the other multifrontends/transcoders without changing anything apart from copying over the latest wavpack encoder and decoder files.

If you want to use the new modes though, you need to either modify the scripts that usually sit behind these tools to make them work, or simply add what you need in the custom command section.

eg, I used Unifront 1.1 Beta today to transcode to and from Wavpack 4. If I used the old modes, I didn't have to change anything apart from copy the new files in. I wanted to encode into -hb320x3 though so I simply chose Wavpack encoder, and then turned off the built in options, and entered -hb320x3 into the "Add additional options" box. Worked a treat.

Hope this helps.

Den. 
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-06-01 21:38:11
For those interrested, I've tuned the Wavpack beta2 code to compile and run on OS X.

The modified sources can be found here (http://mukoli.free.fr/wavpack/). The same source compile for Win32, Linux and OS X.
Title: WavPack 4.0 Beta Release 2
Post by: rjamorim on 2004-06-01 21:54:14
Elite! Thanks
Title: WavPack 4.0 Beta Release 2
Post by: MyAdviceIha on 2004-06-18 16:26:26
It has been a while since any updates have been to Wavpack 4.0, so I was just seeing how development was coming along. I am very excited this release and plan to archive all my CDs using Wavpack 4.0 once it is final. Thanks for any info anyone can give.
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-06-18 16:54:46
I guess it's quite stable.
Unfortunately CoreCodec is down so we can't really work in team.
Last I heard of David, he was working on a library version of his code.
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-06-19 18:26:46
Quote
It has been a while since any updates have been to Wavpack 4.0, so I was just seeing how development was coming along. I am very excited this release and plan to archive all my CDs using Wavpack 4.0 once it is final. Thanks for any info anyone can give.

Thanks for the interest.  The third (and probably last) beta is almost ready and should be posted next week. Like robUx4 said, this version will include a library interface to the encoding routines and an updated Cool Edit / Audition filter (which will now support its native 32-bit floats). I have also made the decoding more robust to errors and added error reporting to the foobar plugin. Despite the lack of CVS, I have incorporated all of robUx4's linux/apple mods, so hopefully it will compile elsewhere with a minimum number of tweaks. Oh, I also improved the noise shaping in the hybrid mode.
Title: WavPack 4.0 Beta Release 2
Post by: Tec9SD on 2004-06-20 09:08:34
Nice to hear, thank you all for your time and effort.

Has MD5 support been created already?

Thanks, tec
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-06-21 05:28:42
Quote
Has MD5 support been created already?

MD5 has not been available in any release up to now, but it will be included in the new beta.
Title: WavPack 4.0 Beta Release 2
Post by: dzy on 2004-06-21 07:59:25
is the md5 going to be the md5 of decoded raw data or md5 of compressed data like monkey's audio?
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-06-21 18:40:23
Quote
is the md5 going to be the md5 of decoded raw data or md5 of compressed data like monkey's audio?

I chose to calculate the MD5 signature on the raw original uncompressed audio (not including headers). This seems to be the most logical to me for the purpose of verifying the integrity (and version) of the original audio track. This seems to also be the method used by Shnutil and OptimFROG (and I verified my values against those programs).

The disadvantage is that these will not be useful in checking hybrid lossy WavPack files, but WavPack's regular error checking will detect any errors in those. However, the user can still identify the original source by the stored signature even if they didn't create (or download) the correction file.

Please let me know if I made the correct decision (it's not too late to change my mind)...
Title: WavPack 4.0 Beta Release 2
Post by: guruboolez on 2004-06-21 18:45:58
Does it mean that files need to be decoded in order to check md5 validity?
I like Monkey's Audio md5 hashing, because I could check the integrity of my library very, very quickly. It's really nice, especially for slow computer like mine.

I good compromise might be two MD5 signature. Is it possible?
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-06-21 19:13:11
Quote
Does it mean that files need to be decoded in order to check md5 validity?
I like Monkey's Audio md5 hashing, because I could check the integrity of my library very, very quickly. It's really nice, especially for slow computer like mine.

I good compromise might be two MD5 signature. Is it possible?

Hmm, that's a good point. Of course, WavPack files verify a lot faster than some others (especially if you avoid using "high" mode), but I'll look into the diffculty of storing a compressed sum as well.

Aren't there stand-alone programs that provide that kind of functionality (with arbitrary file types)? They would certainly be faster and more efficient than anything I could provide for just checking the integrity of the compressed files.
Title: WavPack 4.0 Beta Release 2
Post by: guruboolez on 2004-06-21 19:34:55
Quote
Aren't there stand-alone programs that provide that kind of functionality (with arbitrary file types)? They would certainly be faster and more efficient than anything I could provide for just checking the integrity of the compressed files.

Changing tags -> modified md5.
Monkey's MD5 checking is not affected by any tag modification.
Title: WavPack 4.0 Beta Release 2
Post by: bryant on 2004-06-21 19:49:27
Quote
Changing tags -> modified md5.
Monkey's MD5 checking is not affected by any tag modification.

Hmm, good point #2... 
Title: WavPack 4.0 Beta Release 2
Post by: robUx4 on 2004-06-21 21:49:45
IMO it's good to compute it on the encoded data.
#1) there are less data to compute
#2) in normal mode the data are purely equivalent
#3) MD5 also applies to hybrid mode

Also does the MD5 applies to the whole file or just parts ? (and therefore many MD5s)