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.4 alpha 2 for Windows (Read 170110 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.4 alpha 2 for Windows

Reply #50 –
Quote from: DARcode on
24-7 Spyz - Gumbo Millennium is just ~220 kb bigger too  .

Any new alphas to play with yet ?
Can't wait to test -hx4 (x4 = old v4.31 -x mode), maybe MMX/SSEx optimized too.

Unfortunately I have not got a chance to work on -x4 yet (and I'm not even thinking about MMX). I have added commands to wvunpack to automate the extraction of embedded cuesheets, but that's just in SVN for now. Thanks for your (and everyone's) testing so far (and thanks for your patience)... 

I did finish up a first pass at a test suite that should be a useful resource for developers including WavPack support in their applications (and is important for acceptance of WavPack in the Linux community). It also has some samples at various lossy bitrates that provide a demo of WavPack's capabilies outside pure lossless. Anyway, if anyone would like to check it out, it can be found here:

http://www.rarewares.org/wavpack/

BTW, many thanks to Roberto for the hosting! 

WavPack 4.4 alpha 2 for Windows

Reply #51 –
Quote from: bryant on
I have added commands to wvunpack to automate the extraction of embedded cuesheets, but that's just in SVN for now.
Yow beauwty!

Looks like I may have to get SVN setup to play...

Thanks for listening David.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #52 –
Quote from: Synthetic Soul on
Looks like I may have to get SVN setup to play...

Thanks for listening David.

Actually, it's not too fancy. It doesn't edit the cuesheet or anything like that, but it does get it out without having to jump through hoops.

I could easily post another alpha if you're not set up to compile it and would like to beat on it... 

WavPack 4.4 alpha 2 for Windows

Reply #53 –
Great to see you're able to allocate time to WV these days and things are progessing quite a bit, thank you David, being patient is the least we can do, such a brilliant product and free to boot, I'd like to help more (tho ain't no coder) or being able to donate at least.

P.S.
I'm a Kubuntu user too, albeit a total noob.

EDIT: Grammar grammar grammar.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.4 alpha 2 for Windows

Reply #54 –
Quote from: bryant on
I could easily post another alpha if you're not set up to compile it and would like to beat on it... 
I'm not currently setup for it, but I wouldn't want you to waste your time; that was not my intention.

Thanks for the offer.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #55 –
SVN works over HTTP, so any web-downloader will work if you're in a pinch; just do a recursive download and you'll get the current revision of the mainline trunk.

(The WavPack SVN server doesn't seem to use trunks or branches, though.)

WavPack 4.4 alpha 2 for Windows

Reply #56 –
Here is a build from the source this morning:

http://www.4shared.com/file/3518984/727cc0...k_20060906.html

It was built with MSVC++ 2006 Express Edition, with the default project settings.  If there are any problems, please let me know.

Thanks Bryant!  Great software!

WavPack 4.4 alpha 2 for Windows

Reply #57 –
Quote from: Synthetic Soul on
Quote from: bryant on
I could easily post another alpha if you're not set up to compile it and would like to beat on it... 
I'm not currently setup for it, but I wouldn't want you to waste your time; that was not my intention.

Thanks for the offer.

Well, it certainly would not be a waste of time (and probably wouldn't have taken 5 minutes) but lantern did it while I was sleeping (thanks!) and I checked his version and it seems to be fine. I would be interested to know if this meets at least some of the desired utility, although I know you are busy...

WavPack 4.4 alpha 2 for Windows

Reply #58 –
I actually managed to beat lantern to it, but didn't think to post my builds.  I had TortoiseSVN here at work already, and installed Visual C++ 2005 Express with little trouble.  It's more fun with a little effort.

What can I say, it does exactly what it says on the tin!  I like the options to both output to STDOUT and to file on extraction.  It's great that WVUNPACK asks for confirmation before overwriting an existing cuesheet, as it does for the WAV file.

I tested with a self-extracting file which I believe I successfully added a cuesheet to on encoding, but on extraction the cuesheet was not extracted.  I may need to test again to be sure; it may be safer to encode to WV, check the cuesheet is there (-c switch ), and then prepend the wvselfx.exe file, before I test.

IMHO, if a self-extracting file has a cuesheet it will be required, and it would be great if it could be automatically extracted when the EXE is double-clicked.  Is that achievable?  There's something nice about the idea of giving someone an EXE and saying "double click that and you have everything you need to burn to CD in Nero". (If someone knew about EAC, foobar, or Burrrn they could handle the WV themselves).

I can't really think what else to test... the cuesheet is simply a piece of text (in this instance) so WVUNPACK has no concerns about compliancy, etc.  I can't think how I could trip it over... it either extracts or it doesn't.  Is there anything specific you would like tested?

Thanks again David.

Edit: OK, tested self-extract again using method above, and no cuesheet.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #60 –
Quote from: Synthetic Soul on
IMHO, if a self-extracting file has a cuesheet it will be required, and it would be great if it could be automatically extracted when the EXE is double-clicked.  Is that achievable?  There's something nice about the idea of giving someone an EXE and saying "double click that and you have everything you need to burn to CD in Nero". (If someone knew about EAC, foobar, or Burrrn they could handle the WV themselves).
The wvselfx header is due for an update and that's where the logic needs to go to self-extract a cuesheet. My plan was to simply have it extract the cuesheet if there's one there; I can't imagine a scenario where that would be a problem.


Quote from: Synthetic Soul on
I can't really think what else to test... the cuesheet is simply a piece of text (in this instance) so WVUNPACK has no concerns about compliancy, etc.  I can't think how I could trip it over... it either extracts or it doesn't.  Is there anything specific you would like tested?
Actually, the fact that you ran it on a different machine with a different image and cuesheet is a good test. I was mostly concerned whether this was enough functionality and that the options made sense. It turns out that it is a little more complicated than it seems because the cuesheet is stored as UTF-8 in the tag and needs to be converted to ANSI, and I had a bug where newlines were not being handled correctly, but I think it's all sorted out now.

Thanks for the feedback! 

WavPack 4.4 alpha 2 for Windows

Reply #61 –
Quote from: bryant on
The wvselfx header is due for an update and that's where the logic needs to go to self-extract a cuesheet. My plan was to simply have it extract the cuesheet if there's one there; I can't imagine a scenario where that would be a problem.
Superb.  That would be ideal.

Quote from: bryant on
I was mostly concerned whether this was enough functionality and that the options made sense.
Well, we still have the idea of editing the cuesheet upon extraction to ensure that it points to the WAVE file, but I realise that this is a lot more effort, and possibly should simply be bounced back to the embedder's responsibility to ensure that the cuesheet points to a WAVE of the same name before embedding.

Unfortunately mine don't, and I guess EAC doesn't do that if you rip compressed.  However, again, I suppose you could say that the embedder should have the skills to edit the cuesheet.  It's all down to making it as easy as possible for the decrypter, not the encrypter.

Both would be good though.

Quote from: bryant on
It turns out that it is a little more complicated than it seems because the cuesheet is stored as UTF-8 in the tag and needs to be converted to ANSI, and I had a bug where newlines were not being handled correctly, but I think it's all sorted out now.
When I made my changes to Tag I had to mess about to get new lines coming out OK in STDOUT.  Hmmm... I wonder whether it barfs with non-ASCII characters.

That's why you do what I do, and I just stick my oar in.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #62 –
David, I've been using your nice little proggy copytags a lot lately, it's definitely pretty handy, any intention of integrating its functionality into wavpack.exe?
If not in the near future what about when all executables will be merged into one?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.4 alpha 2 for Windows

Reply #63 –
Quote from: DARcode on
David, I've been using your nice little proggy copytags a lot lately, it's definitely pretty handy, any intention of integrating its functionality into wavpack.exe?
If not in the near future what about when all executables will be merged into one?

Oops, sorry, for some reason I missed this post...

Glad you can use copytags. Just don't use it on anything important! 

Yes, once wavpack.exe can accept wv files as input (for transcoding) then it would also copy any tags found.

WavPack 4.4 alpha 2 for Windows

Reply #64 –
As part of my Yalac testing I have just completed some tests with 4.4a3.  For the full results, please see this post on the Yalac thread for info.

Here are the WavPack-related results though, settings in compression order.

REMOVED, please see post #68 below.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #65 –
Thanks Synthetic Soul for adding the new WavPack version, I really appreciate all your work on this!

The results fit my expectations pretty much, however I think there's one error. I find it unlikely that "4.4a3" and "4.4a3 -f" would get exactly the same compression ratio. I think they must be both "-f". If that's the case then it's also interesting that the two decode speeds differ by almost 3% when they should be identical! I suspect that this indicates that your test method has a higher level of measurement error than your 4 significant digits suggest and that perhaps rounding to the nearest integer would be more appropriate.

Finally, a request. If I could add a single option combination it would be "-fx". I think this is significant because it offers faster decoding and better compression than "-f" alone, and with a fairly small increase in encode time. For those users who might consider WavPack as a FLAC replacement it is certainly the most logical choice. I would even be willing to give up the other -x2 options for this because they really don't offer too much over -x alone. But, of course, this is all up to your descretion. 

Thanks again for the results.

WavPack 4.4 alpha 2 for Windows

Reply #66 –
Argh!  I have just checked the scripts and both runs were using -f.  I do try to check my results when I publish, as I am very concerned about spreading misinformation, but this obviously slipped my net.  Many apologies.

Personally, I'm not suprised that the speeds vary slightly.  My reports currently list TIMER's global speed which includes CPU and IO time.  I suspect that the IO process, which in my case slows the process down, introduces some variables.  Your point about using integer values only is extremely valid, and not something I had previously considered.  I had a brief discussion about significant bits a while back; not being a math wiz I don't really consider the fact that the decimal places shown indicate the precision.  I will change it ASAP.  FYI: My scripts are now recording both CPU+IO and CPU only times, but I need time to update my report system to be able to display both/either.  I would be a lot happier displaying CPU-only results.

Of course I will run -fx and add that in to the report.

Thanks for the feedback David, and again, apologies for the false info.

BTW, although it was posted in another thread, I have to say:

Quote from: bryant on
It's kind of like poking someone with a stick; most of the time you'd get them in the leg or the arm, but if you were really lucky you would get them in the eye and cause real trouble.
... has got to be the best analogy I have ever seen!
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #67 –
OK, I've updated the default figures immediately, as they were wrong.  I'll run the -fx (and probably -fx2 and -fx3) tests today and get them up as soon as I can.

Here's the correct data:

Code: [Select]
Encoder Setting    Compression    Encode    Decode
==================================================
WavPack -hx            64.337%        1x       46x
WavPack 4.4a3 -hhx3    64.382%        4x       45x
WavPack 4.4a3 -hhx2    64.396%        8x       45x
WavPack 4.4a3 -hhx     64.423%       13x       45x
WavPack -h             64.487%       28x       46x
WavPack 4.4a3 -hh      64.500%       28x       46x
WavPack 4.4a3 -hx3     64.679%        6x       53x
WavPack 4.4a3 -hx2     64.708%       11x       53x
WavPack 4.4a3 -hx      64.764%       18x       53x
WavPack 4.4a3 -h       64.877%       33x       53x
WavPack -x             65.144%        3x       66x
WavPack 4.4a3 -x3      65.285%        9x       65x
WavPack 4.4a3 -x2      65.312%       17x       65x
WavPack 4.4a3 -x       65.371%       25x       64x
WavPack 4.4a3          65.582%       43x       62x
WavPack                65.750%       46x       67x
WavPack 4.4a3 -f       66.741%       49x       66x
WavPack -f             67.095%       49x       69x
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #68 –
And now with -fx(2/3):

Code: [Select]
Encoder Setting    Compression    Encode    Decode
==================================================
WavPack -hx            64.337%        1x       46x
WavPack 4.4a3 -hhx3    64.382%        4x       45x
WavPack 4.4a3 -hhx2    64.396%        8x       45x
WavPack 4.4a3 -hhx     64.423%       13x       45x
WavPack -h             64.487%       28x       46x
WavPack 4.4a3 -hh      64.500%       28x       46x
WavPack 4.4a3 -hx3     64.679%        6x       53x
WavPack 4.4a3 -hx2     64.708%       11x       53x
WavPack 4.4a3 -hx      64.764%       18x       53x
WavPack 4.4a3 -h       64.877%       33x       53x
WavPack -x             65.144%        3x       66x
WavPack 4.4a3 -x3      65.285%        9x       65x
WavPack 4.4a3 -x2      65.312%       17x       65x
WavPack 4.4a3 -x       65.371%       25x       64x
WavPack 4.4a3          65.582%       43x       62x
WavPack                65.750%       46x       67x
WavPack 4.4a3 -fx3     66.386%       15x       67x
WavPack 4.4a3 -fx2     66.445%       25x       67x
WavPack 4.4a3 -fx      66.536%       33x       66x
WavPack 4.4a3 -f       66.741%       49x       66x
WavPack -f             67.095%       49x       69x
Code: [Select]
Encoder Setting    Compression    Encode    Decode
==================================================
WavPack 4.4a3          65.582%       43x       62x
FLAC (-5)              66.279%       38x       72x
WavPack 4.4a3 -fx      66.536%       33x       66x
Code: [Select]
Encoder Setting    Compression    Encode    Decode
==================================================
Flake -12              65.368%        7x       69x
WavPack 4.4a3 -x       65.371%       25x       64x

http://synthetic-soul.co.uk/comparison/lossless/?All=1

I made reference in the Yalac thread when I posted my initial results that I had never previously considered WavPack's- -f option, and was surprised at the speed and compression.  It's impressive that WavPack can compete with FLAC -5 in speed, and still surpass Flake in compression.

I also find it interesting that the changes in 4.4 are geared toward faster, less processor-intensive decoding, and that has come at a small cost in compression.  I must admit, I think I may be sticking with -h (-hh), but it's very possible that I may switch to the new -h for a little faster decoding at the cost of a few MiB, as it seems the difference to me would only be around 4MiB per GiB encoded, which really is negligable.

Edit: David, can you see the presets changing at all for the release version, or will I be able to rename to 4.4 and leave the results as is?
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #69 –
Ah yes, those results make more sense now! Thanks for updating them so quickly and adding the -f results also.

Yeah, I find that this speed measurement business can be a real nightmare trying to get results that are consistent and make sense. There are enough variations between CPU's and OS's and I/O devices and compilers to make your head spin around! Anyway, I think having those numbers rounded to ints makes sense and doesn't convey more accuracy than is actually there.

I don't know if you originally encoded your files with -h or -hx, but in my corpus the new -hx3 actually compresses better than the old -h (i.e. new -hh). I notice that for some reason the -x mode achieves a lot less extra compression on your corpus than on mine. Probably that's because my corpus was designed to have a wide and varying range of material, which is exactly what the -x mode is trying to take advantage of.

I'm not really sure what I'm going to finally do with the presets. I am going to try to add a -x4 setting to work more like the old -x mode, but this is really only for special cases and certainly wouldn't make sense for your corpus. I would also like to see if I can make some quick performance tweaks while still staying in pure C, but time will tell whether that happens. Basically, I reserve the right to improve everything dramatically!

Oh, BTW, glad you liked the analogy...   

WavPack 4.4 alpha 2 for Windows

Reply #70 –
Quote from: bryant on
Yeah, I find that this speed measurement business can be a real nightmare trying to get results that are consistent and make sense. There are enough variations between CPU's and OS's and I/O devices and compilers to make your head spin around! Anyway, I think having those numbers rounded to ints makes sense and doesn't convey more accuracy than is actually there.
I don't really like posting my "IO-infected" rates, but it's how I started reporting and I would need some time to switch totally to CPU-only.  I am also still undecided as to how irrelevant IO+CPU times are, as this is what I would see.  I've never meant my tests to be the definitive figures for each encoder, but it concerns me that people may think that is what I am trying to portray.  Thanks for the suggestion to report integer values; it makes a lot of sense.

Quote from: bryant on
I don't know if you originally encoded your files with -h or -hx, but in my corpus the new -hx3 actually compresses better than the old -h (i.e. new -hh). I notice that for some reason the -x mode achieves a lot less extra compression on your corpus than on mine. Probably that's because my corpus was designed to have a wide and varying range of material, which is exactly what the -x mode is trying to take advantage of.
I use -hm at the moment.  I assumed that -x must perform better with other corpuses than mine.  A lot of people seem to use -x.  The fact that it is not nearly such a performance hit as the old -x is great anyway, and does mean I may consider using it, in case my music taste gets a little more varied.

Quote from: bryant on
I'm not really sure what I'm going to finally do with the presets. I am going to try to add a -x4 setting to work more like the old -x mode, but this is really only for special cases and certainly wouldn't make sense for your corpus. I would also like to see if I can make some quick performance tweaks while still staying in pure C, but time will tell whether that happens. Basically, I reserve the right to improve everything dramatically!
Hey, fine by me.  I will re-test when you release 4.4; it may be interesting to compare the two results anyway, to ensure they match where they should.

Thanks David.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #71 –
Out of interest, here's the results for my "Yalac" corpus in a different format.

Firstly, the speeds are CPU-only, so they are not affected by my hard drive.  Bear in mind that, if you decode to file, you may not attain these speeds, even if using the same equipment, as writing to disc may introduce some further delay (refer to my results listed above to see the difference my hard drive makes, or take a look at the graph on this unfinished page).

Secondly, I have grouped the switches, and I think the result quite neatly demonstrates the effect of using -x in addition to a core setting, so I thought I would share.

Code: [Select]
Mode    Encoding    Decoding    Compression
===========================================
-hh          32x         53x        64.500%
  x          15x                    64.423%
  x2          8x                    64.396%
  x3          4x                    64.382%
   
-h           41x         64x        64.877%
  x          20x                    64.764%
  x2         12x                    64.708%
  x3          6x                    64.679%
  
Default      59x         78x        65.582%
  x          29x                    65.371%
  x2         18x                    65.312%
  x3         10x                    65.285%

-f           69x         91x        66.741%
  x          36x                    66.536%
  x2         27x                    66.445%
  x3         16x                    66.386%

 
I am currently running the same scripts on my "FLAC" corpus.  When I have the results (around a day's time) I'll post them in this same format.  I'm hoping the greater (although probably still not great) variety in my "FLAC" corpus may demonstrate -x's benefits more.
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #72 –
Synthetic Soul the build you're using doesn't have any MMX/SSEx optimizations right?
Allegari nihil et allegatum non probare, paria sunt.

WavPack 4.4 alpha 2 for Windows

Reply #73 –
No, it doesn't.  It's the version from post #30 in this thread.

I'm not overly interested in optimised versions until David applies them himself (at which point I will become very interested).
I'm on a horse.

WavPack 4.4 alpha 2 for Windows

Reply #74 –
I am very interested in optimised versions since my PC isn't the fastest.