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: why isn't wavpack more popular? (Read 45939 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

why isn't wavpack more popular?

Reply #25 –
Quote
I'm sure Wavpack is not so difficult to port. I'll try to do a complete (how risky sounds that...) Wavpack Linux version as soon as some alpha code gets released. Well, as soon as I have some free time, and that means probably Christmas.


glauco, I would be very interested in helping you with this endevour. Wavpack is a nice tool and I have wanted a Linux version of it for a while. I am fairly experienced in porting stuff (normally the other way - from Linux to Windows).

It would be nice, however, if whatever changes were made to the source made it properly portable (rather than just a Linux version) and were merged with the main tree. This is obviously the call of the wavpack developers though. Even if it doesn't go back in to the main tree, this would be good for wavpack. There are few better ways to find bugs than by porting a piece of code to a different compiler.

I would also be willing to write a simple GTK or KDE (QT) based frontend to replace the windows one in the Linux port.

glauco, contact me at mbrooker at smuts uct ac za if you are interested in getting some help with this project.

why isn't wavpack more popular?

Reply #26 –
I have created a sourceforge account some months ago - nothing very interesting there so far, just some 3.x sources and binaries - and I think that would be the ideal environment to coordinate the porting efforts.

why isn't wavpack more popular?

Reply #27 –
I was also considering doing a Linux port, but seeing as I've only just returned to Linux after a break of three years, and it's about the same time since I last looked at a C program, I think I will leave to you guys. You sound like you know what you are doing. I'll concentrate my time helping in other ways, like listening tests.

I would however suggest that you hang back from bugging David just yet, unless you want to swing Wavpack 3.97/3.98 across to Linux, as I'm guessing that Wavpack4 will remain in alpha for a little while yet. 

It would make sense to ensure everything is sweet before you spend too much time on it.

B)

why isn't wavpack more popular?

Reply #28 –
Quote
I'm guessing that Wavpack4 will remain in alpha for a little while yet. 

As I understood, all that is left to implement to freeze the stream specs is the lossy VBR mode and multichannel support.

Did David tell you something different? (since I expect you also got an alpha  )

quoting from the readme:

Quote
                                4. What's Next
                               --------------

o create VBR "quality-based" version of hybrid compression
o add multichannel support and finalize format specification (with beta)

why isn't wavpack more popular?

Reply #29 –
OK, so as some of you already noticed by my previous post, WavPack4 alpha is already out.

David didn't make this release public yet. His intention is to make it public only once he has a player plugin working, so that users can see for themselves that yes, seeking is now much faster.

Also, he didn't implement yet multichannel coding. So, the only new feature left to be tested in this version is error robustness.  And so I did.

The procedure:

-Encode a song in WavPack4
-Open it in a Hex editor (in my case, WinHex) and delete some bytes, replace others.
-Try to decode with wvunpack

wvunpack decoded OK until the part where I deleted some bytes. The part where I changed some bytes decoded OK, although there was an awful sound coming from my speakers.  Maybe it would be interesting if wvunpack output a message saying that sample #X is corrupt.

When it reached the part where I deleted some bytes, it output the error message "incorrect number of samples!" and exit. Maybe it would be possible to add a -f (orce) switch that would skip the wrong block(s) and resync?


About compression*:

From my small test (one sample, 46.524Kb), wavpack4 high seems quite faster than3, but compresses a little less. That's probably because of the new block-based bitstream (block header overhead, etc.)

WavPack4a - high - 23723Kb - 14.39s
WavPack3  - high - 23624Kb - 18.30s
WavPack4a - normal - 24171Kb - 8.30s
WavPack3  - normal - 24160Kb - 8.07s

WavPack4 features a new improved compression method that does exhaustive compression on each block searching for the best ratio. As I understand it, it's like pngcrush -brute. Of course, encoding is much slower in this mode, but decoding as about just as fast. It is probably useful if you need to compress just those extra few bits to make 2 albums fit one CDr.

I tested the default compression method with -x5 (the assymetrical methods go from x1 to x6)

WavPack4a - default x5 - 23.889Kb - 225.37s

I ran some tests with Flac and Monkey's Audio for comparision.

Flac 1.1.0 - 8 - 24140Kb - 58s
Flac 1.1.0 - 5 - 24198Kb - 12s
Monkey's Audio 3.97 - high - 23390Kb - 12s
Monkey's Audio 3.97 - normal - 23483Kb - 10.2s


Also, according to the readme, the lossy mode got improved, the new minimum bitrate is 192kbps and reasonable quality is obtained with 256kbps. Also, VBR is going to be implemented.

There are two forms of operation in the hybrid mode now: focus on quality (at expense of lossless overall size), or focus on compression (at expense of lossy file quality)

Well, that's about it regarding what I tested and noticed so far.

All in all, things are progressing well and there are some new features that make WavPack stand out from the competition. Looking forward to new alphas/betas...

Best regards;

Roberto.


*AMD XP 1500+, 384Mb RAM, Windows 2000.

why isn't wavpack more popular?

Reply #30 –
Quote
cabbagerat : glauco, I would be very interested in helping you with this endevour


Having help is always better than doing something alone. Thank a lot. 

Quote
It would be nice, however, if whatever changes were made to the source made it properly portable (rather than just a Linux version) and were merged with the main tree


Sure. That was also my idea. It shouldn't be so difficult to do.

Quote
rjamorim :
I have created a sourceforge account some months ago


That would be a great way to coordinate the efforts. Even if I don't think the porting project's going to be big enough to need it, sure it will improve it's popularity.

Quote
den: I was also considering doing a Linux port, but seeing as I've only just returned to Linux after a break of three years, and it's about the same time since I last looked at a C program, I think I will leave to you guys. You sound like you know what you are doing. I'll concentrate my time helping in other ways, like listening tests.


Well, any help will surely be appreciated. Even if you have forgotten your C skills, I'm sure your ears are willing to test the new release.

By the way, you can contact me at gonzalomonte AT eresmas DOT net
Just a thought...

why isn't wavpack more popular?

Reply #31 –
Quote
WavPack4 alpha is already out.


Coooooooool.  B)
Just a thought...

why isn't wavpack more popular?

Reply #32 –
Roberto:

Thanks for trying out the alpha!

On the error robustness issue, the format is resistant to errors, but the alpha version of Wvunpack cannot yet take advantage of it. It currently expects everything to be in place or it fails. Needless to say, it's on my todo list, but is less important than just getting the spec complete.

It looks to me like your test of the -X switch was actually on the default mode rather than the "high" mode. First of all, -X5 in "high" mode would have taken a lot longer than that (I recommend -X3 in high, -X4 in default), and would not have resulted in worse compression than "high" without -X. What I see there is what I've seen myself: that the -X can make the default mode compress almost as well as "high" with very little (if any) affect on the decode speed. (After I wrote this I see you already caught and changed that...)

Thanks again.

why isn't wavpack more popular?

Reply #33 –
@Roberto

I was trying to subtly drop hints without giving away that I have an alpha... 

But now that it's out in the open...

My focus (as you can imagine form my previous Wavpack threads) is on the hybrid and lossy side. My early impressions are that the 256kbit bitrate is very nice indeed, especially compared to Wavpack 3.98 in this bitrate range (or as close to it as it can get).

I'm in the throws of setting up a battery of listening tests once I settle on what quallity settings, bitrates etc I'm interested in. (After I finally get around to completing a certain trancoding test that is still outstanding...)

 

I'm still getting my head around the new extra compression assymetiric encoding options, and whether they deliver sufficient extra bang for the extra wait, but from a placebo point of view, it certainlly feels a lot better. 

This new encode of Blue Monday is taking longer than it takes to play in realtime on my PC, it has to sound better!!!

why isn't wavpack more popular?

Reply #34 –
For anyone interested in playing around with the alpha release of WavPack 4.0, I have now got a winamp2 plugin working (with fast seeking). I also created a document giving a technical overview of the new WavPack format. The whole package is here:

http://www.wavpack.com/alpha1.zip

Note that this is very early and for testing purposes only, so don't archive with it. Also, the wvunpack program and the winamp plugin will not deal with regular WavPack files.

Any testing results, comments or suggestions are very much appreciated.

Happy Thanksgiving to the locals!

why isn't wavpack more popular?

Reply #35 –
Quote
I have created a sourceforge account some months ago

Please allow me to invite you and David to move the project to corecodec.org instead. We are a small family, but we support each other best we can.

Also, on sourceforge wavpack is one project amongst many others, on corecodec its something special. A dedicated webforum, an IRC server and much support from the organization side are additional benefits. Please think about it before going opensource with Wavpack4 ....

why isn't wavpack more popular?

Reply #36 –
Thanks for sharing Bryant!

I did some testing, just to see how the filesize/encoding time compared to each other. Encoding done with a p4 @ 2ghz, 512mb ram. first in the list is the encoding option, then filesize and then encoding time.

Test-track:
The Police - Walking on the moon  52,025 kb (just picked some random track)

No options | 33,478 kb (10.19)

-h | 32,598 kb (13.08)

-x1 | 33,284 kb (16.09)
-x2 | 33,240 kb (29.86)
-x3 | 33,196 kb (49.55)
-x4 | 33,064 kb (106.53)
-x5 | 33,052 kb (158,48)
-x6 | 33,001 kb (326,17)

-fx1 | 34,843 kb (13.89)
-fx2 | 34,821 kb (17.67)
-fx3 | 34,821 kb (18.36)
-fx4 | 34,112 kb (35.14)
-fx5 | 33,982 kb (46.02)
-fx6 | 33,924 kb (55.56)

-ffx1 | 35.010 kb (12.48)
-ffx2 | 34,984 kb (14.59)
-ffx3 | 34,984 kb (14.79)
-ffx4 | 34,699 kb (20.70)
-ffx5 | 34,699 kb (20.78)
-ffx6 | 34,699 kb (20.81)

-hx1 | 32,601 kb (31.55)
-hx2 | 32,585 kb (56.66)
-hx3 | 32,516 kb (230.17)
-hx4 | 32,492 kb (433.58)
-hx5 | 32,492 kb (596.64)
-hx6 | 32,480 kb (1276.63)

All decoding was somewhere between 5 and 10 seconds per track.
Verifying was somewhere between 3 and 4 seconds per track.

I'm on a old and slow hd for the moment, because my main hd crashed on me, so decoding time depended too much on hd writing speed. I could almost hear it choke on writing sometimes, thats why i didn't include the exact decoding times (too flawed IMO).

Seeking is instant with all tracks (nice!).

Below are the results on the same track with monkey's audio v3.97.

Just did these to have some comparison because i use monkey's right now for personal use.

-c1000 | 33,056 kb (7.1)
-c2000 | 32,531 kb (10.5)
-c3000 | 32,364 kb (15.1)
-c4000 | 32,034 kb (25.5)

why isn't wavpack more popular?

Reply #37 –
Quote
WavPack is 100% ANSI C! (wavpack 3 at least, not sure about 4)
So, porting it to other systems and platforms should be quite easy.

I just a peek at code, and I wouldn't say it's ANSI C. Most people mean C89 when they talk about ANSI C, and something as basic as the // comment syntax is invalid in C89. It is, however, a part of C99. Granted, most of the code compiles, but functions like read(), write(), close() (all used in bits.c), tell() & lseek() (used in wavpack.c) aren't part of ANSI C. __fastcall and O_BINARY are Windows-specific and should be defined to nothing and 0, respectively. I guess it wouldn't be difficult to port the code, but that doesn't make it "100% ANSI C".

Sorry for the nitpicking (and the delay in the reply), I just couldn't resist

why isn't wavpack more popular?

Reply #38 –
ChristianHJW:
Thanks, Christian! When the time comes we can discuss this. Roberto has done a pretty good job of selling me on SourceForge (those compile farms sound handy!) but if WavPack is going to wind up in Matroska in some form then corecodec makes sense too.

Benny.X:
Wow, thanks for your patient testing! (Of course, your computer is almost an order of magnitude faster than mine; I can't even think about -hx6!).

Your results pretty much match what I expect, and back up what I recommend in the readme. It's nice to see that the -X switch is able to get WavPack's "high" mode to beat Monkey's "normal" mode in compression (if not encode speed, obviously).

The poor encode and decode speed results that you got (without -X) are probably a result of some missing optimizations as much as your slower hard drive. When I first tested the old WavPack on Win2K I was amazed to see it run much slower than it ran on Win95! I finally figured out that the different flavors of Windows require all sorts of different "tweeks" for disk I/O management to perform optimally, and that in disk intensive applications (like WavPack's faster modes) these tweeks can make a 2:1 (or greater) difference in performance. In fact, on the XP system I tested this alpha version on, the "fast" mode was actually slower than the default mode! I plan on putting the Win2K+XP optimzations in there one of these days (probably the same time as Roberto's error resistance) and this should make 4.0 match the speed of 3.97 in the default and "high" modes because the overall complexity of the algorithms has not changed significantly. However, the optimization for Win95/98 involved multithreading and was so ugly that it will never be seen again...

Thanks again!

danchr:
Okay, okay, it's not 100% ANSI C! 

But read (), write (), open () and close () were described in the first K&R book and are pretty much universally available for non-stream I/O, right!?

why isn't wavpack more popular?

Reply #39 –
Damn ! Why I always miss the best goodies ... 
Testing ... Testing ...

why isn't wavpack more popular?

Reply #40 –
so why isnt optimfrog more popular? 
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

why isn't wavpack more popular?

Reply #41 –
Quote
so why isnt optimfrog more popular? 

Well, it should be. 
Over thinking, over analyzing separates the body from the mind.

why isn't wavpack more popular?

Reply #42 –
Any news on the development of Wavpack 4 in these past two weeks? I am eagerly awaiting a moderately-safe beta of it to try it out on some albums I want to fit into a CDR at high lossy bitrates.  Any gross estimation of when such a beta might be available?
OK, two weeks is probably too short a time to have any interesting news, so I am just checking whether David hasn't been squashed by a piece of masonry yet.

EDIT: Is there any chance we will see any improvement at lossy mode's decoding speed with version 4? A fast decoding speed would be important for transcoding purposes, and a quick test revealed that Wavpack lossy (@500 kbps, -h) decodes around 1/4-1/3 as fast as FLAC...

why isn't wavpack more popular?

Reply #43 –
Quote
OK, two weeks is probably too short a time to have any interesting news, so I am just checking whether David hasn't been squashed by a piece of masonry yet.

He was still alive some days ago when I phoned him


IIRC, he's now working on psychoacoustic for implementation of the lossy VBR mode. Hopefully he'll have another alpha with this feature as christmas gift for you guys
 

why isn't wavpack more popular?

Reply #44 –
Quote
danchr:
Okay, okay, it's not 100% ANSI C! 

But read (), write (), open () and close () were described in the first K&R book and are pretty much universally available for non-stream I/O, right!?

Nope, they are POSIX calls, and as such not related to any of the C standards. fread(), fwrite(), fopen() and fclose() are the ones mentioned in second edition of K&R. I don't know about the first edition of K&R, though, I never saw it

What I have seen of K&R C tells me that it, if possible, should be avoided.

(I seem to be particularly predisposed for missing posts in this thread...)

why isn't wavpack more popular?

Reply #45 –
I have posted a new WavPack 4.0 alpha that includes my first cut at a "quality" mode using psycho-acoustic analysis. The package includes a readme with all the details:

http://www.wavpack.com/alpha2.zip

Any comments or suggestions are (as usual) very much appreciated... 

why isn't wavpack more popular?

Reply #46 –
David you legend...

Will comment in due course...

Den.

why isn't wavpack more popular?

Reply #47 –
David,

dont forget you wanted to ping me if you feel our devs can have a look at your sources, so we can comment about matroska compatibility .....

why isn't wavpack more popular?

Reply #48 –
Cool !!!

Cristmas gift just in time. A new toy to play with... can't wait to test that new VBR stuff.

Great work David. 
Just a thought...

why isn't wavpack more popular?

Reply #49 –
Testing right now ...

WOW !!!

The VBR mode is great.

I have tested a bunch of 100 seconds music clips that i have for, well, testing purposes.

The VBR mode is much slower than the normal mode, but as fast as many other codecs. It's around 6x realtime (10 seconds encoding time/ 1 minute song time) in my 2.4GHz Pentium4, and that's with unoptimized code.

The bitrates, between 263 kbps (Babyface - Change the world) and 353 kbps (Queen - A kind of magic), averaging 297 kbps in 40 music clips tested.

The quality seems very good. For the moment I haven't detected any hissing sound, although I haven't been listening very carefully. I also believe my ears are not as good as Den's 

But what i like most is the idea. No target bitrate, no quality settings. Just an standard quality level and an (optional) offset in dB. Simple and effective. 

It's a great idea David. It's a great work.

Perhaps introducing a psycho-acoustic model has been a risky move. I don't know, maybe it can need some tunning in the future, but that remains to be seen... I believe it's been a wise move. ¿How conservative / aggressive have you been with that ?

Edit : I almost forgot : Seeking is as fast as possible. 
Just a thought...