Skip to main content ↑ ↓
Topic: WavPack 4.0 Beta Release 2 (Read 26306 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.0 Beta Release 2

Reply #25 –
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...

WavPack 4.0 Beta Release 2

Reply #26 –
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.?

WavPack 4.0 Beta Release 2

Reply #27 –
No foobar plugin for wavpack 4 yet.
Kind Regards , Tcmjr

Aka HellSnoopy

WavPack 4.0 Beta Release 2

Reply #29 –
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

WavPack 4.0 Beta Release 2

Reply #30 –
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" )

WavPack 4.0 Beta Release 2

Reply #31 –
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.

WavPack 4.0 Beta Release 2

Reply #32 –
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.

WavPack 4.0 Beta Release 2

Reply #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.
Just a thought...

WavPack 4.0 Beta Release 2

Reply #34 –
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.

WavPack 4.0 Beta Release 2

Reply #35 –
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.

WavPack 4.0 Beta Release 2

Reply #36 –
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...

WavPack 4.0 Beta Release 2

Reply #37 –
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.

WavPack 4.0 Beta Release 2

Reply #38 –
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.

WavPack 4.0 Beta Release 2

Reply #39 –
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).

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

WavPack 4.0 Beta Release 2

Reply #40 –
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).

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.
 

WavPack 4.0 Beta Release 2

Reply #41 –
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.

WavPack 4.0 Beta Release 2

Reply #42 –
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.

WavPack 4.0 Beta Release 2

Reply #43 –
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.

WavPack 4.0 Beta Release 2

Reply #44 –
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

WavPack 4.0 Beta Release 2

Reply #45 –
 

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.

WavPack 4.0 Beta Release 2

Reply #46 –
New 4.0b2 foobar2k plugin binary now at Rarewares.

WavPack 4.0 Beta Release 2

Reply #47 –
Other then using foobar for transcode wavepack,
is there avabiable some other alternatives.?

WavPack 4.0 Beta Release 2

Reply #48 –
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 
 
SimplePortal 1.0.0 RC1 © 2008-2020