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.40.0 beta available (Read 49826 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.40.0 beta available

Reply #25 –
Quote from: Mangix on
i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.

http://www.microsoft.com/downloads/details...;displaylang=en

Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

WavPack 4.40.0 beta available

Reply #26 –
those runtimes are only needed if WavPack or anything else is compiled using Visual C++ 2005(As far as i'm aware). if one were to compile it with another compiler like Intel C++ or MinGW, then the plugin won't use those runtimes.

but in the end, it might result in a bigger dll. it also might be possible to not use those runtimes when compiling with VC++ but i don't currently know how.

WavPack 4.40.0 beta available

Reply #27 –
Quote from: DARcode on
Quote from: Mangix on

i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.

http://www.microsoft.com/downloads/details...;displaylang=en

Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?

Sorry you had trouble with this (although that's what a beta is for)... 

Anyway, I'm glad you're going now, and thanks for bringing it to my attention.

It is possible to build the DLL to not require MSVCR80.DLL, but then it grows to 200K (which I think is a little absurd for a stupid winamp plugin). I thought that the way I did it would be okay, but I didn't try it on enough systems. I could just point people to the Microsoft link and have people install it, but I would prefer that it work out-of-the-box. I expect that at some point all systems will have MSVCR80.DLL just like they all have MSVCRT.DLL now.

Another solution would be to build the winamp plugin on VC 6.0 using the library I build on VC 2005 (I'll probably have to do this for the Nero plugin also). I assume that will work, but with Microsoft one never knows since they claim VC 6.0 is not supported (like Windows 95).

I'm almost sorry I upgraded to VC 2005. What were the advantages again...? 

WavPack 4.40.0 beta available

Reply #28 –
using new runtimes  j/k

it could also be possible to compile WavPack using Intel C or even GCC(i personally want to build WavPack under GCC 4.1.1 but stupid MinGW doesn't want to compile it )

btw, is there a Makefile in the SVN? i can only find a Makefile.am which links to a "Makefile" which does not get downloaded.

edit: as for VC++ 2005, i think the only advantages that you can get are in C++(not C). last time i tried C++ with it, it used a "_tmain" function instead of a regular main and the compiler was also complaining about a few things when i was compiling WavPack(fileno in particular).

WavPack 4.40.0 beta available

Reply #29 –
Quote from: Mangix on
i personally want to build WavPack under GCC 4.1.1 but stupid MinGW doesn't want to compile it

No problem here...

Quote from: Mangix on
btw, is there a Makefile in the SVN? i can only find a Makefile.am which links to a "Makefile" which does not get downloaded.

You have to run autogen.sh first (autoconf, automake, libtool needed) to generate the appropriate files. Then configure, make.

WavPack 4.40.0 beta available

Reply #30 –
I have tested the new version by encoding 124 different files (my FLAC corpus (28), TAK corpus (50) and the RW corpus (46)) using 28 different compression settings.  I have compared the MD5 hash of the source WAVE with the hash of the decoded file and all have matched.

I have also tested the new WVSELFX.EXE with embedded cuesheets, and it works as expected (although I would still like to see the cuesheet FILE command corrected upon extraction, at some point in the future  ).

Thanks for your continuing hard work David.
I'm on a horse.

WavPack 4.40.0 beta available

Reply #31 –
Correct as in point to the new [filename].wav?

WavPack 4.40.0 beta available

Reply #32 –
Quote from: dv1989 on
Correct as in point to the new [filename].wav?
Yes.  This has been discussed before when the idea was first raised; I believe that it is on David's todo list, but I think there are higher priorities at the moment.  I'm just keeping him on his toes. 

Edit: I should point out that for many people it will not need amending.  It has also previously been raised that perhaps it should just be the responsibility of the encoder (user) to ensure that the cuesheet points to a WAVE of the same name before embedding, which makes a lot of sense.  If it's a real headache to check and amend the cuesheet upon extraction then I would rather Mr Bryant spent his time on more important things.
I'm on a horse.

WavPack 4.40.0 beta available

Reply #33 –
Quote from: bryant on
Quote from: DARcode on

Quote from: Mangix on

i believe that the C++ 8 Runtimes are installed by default when you install the .NET Framework 2.0(and maybe even 3.0). otherwise, you can get them here.

http://www.microsoft.com/downloads/details...;displaylang=en

Thanks buddy, it worked, tho Winamp takes a little bit more time to load now.
Pardon my ignorance, I'm no dev, but isn't there a way to embed those libraries into the plug-in?
Finally, should't those runtimes be listed as system requirements or are they really common in normal WinXP SP2 installs?

Sorry you had trouble with this (although that's what a beta is for)... 

Anyway, I'm glad you're going now, and thanks for bringing it to my attention.

It is possible to build the DLL to not require MSVCR80.DLL, but then it grows to 200K (which I think is a little absurd for a stupid winamp plugin). I thought that the way I did it would be okay, but I didn't try it on enough systems. I could just point people to the Microsoft link and have people install it, but I would prefer that it work out-of-the-box. I expect that at some point all systems will have MSVCR80.DLL just like they all have MSVCRT.DLL now.

Another solution would be to build the winamp plugin on VC 6.0 using the library I build on VC 2005 (I'll probably have to do this for the Nero plugin also). I assume that will work, but with Microsoft one never knows since they claim VC 6.0 is not supported (like Windows 95).

I'm almost sorry I upgraded to VC 2005. What were the advantages again...? 

And that's what beta testers/Guinea pigs are for  !
Your work is superb, I'm glad if I can help a little.
Outta curiosity, what about the missing MSJAVA.DLL reported by both WA plug-in versions? Does that belong to the discontinued MS Java VM?
Once you get to work on the Nero plug-in I'd like to test the dependency free WA one too if you ever allocate time to that, thanks.

P.S.
There ain't nuffin' stoopid 'bout a Winamp plug-in  !

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

WavPack 4.40.0 beta available

Reply #34 –
Quote from: nyarlathotep on
Thank you for your work bryant.
You converted me to lossless. 

I've always thought San Francisco could only produce cool things.

Thanks. I believe that FLAC was written in this area also, so you may be right! 

Quote from: Synthetic Soul on
I have tested the new version by encoding 124 different files (my FLAC corpus (28), TAK corpus (50) and the RW corpus (46)) using 28 different compression settings.  I have compared the MD5 hash of the source WAVE with the hash of the decoded file and all have matched.

I have also tested the new WVSELFX.EXE with embedded cuesheets, and it works as expected (although I would still like to see the cuesheet FILE command corrected upon extraction, at some point in the future  ).

Wow, that's almost 3500 files! I think that's probably more than I've done... 

Thanks, Synthetic Soul, and thanks for testing out the self-extraction also. Yes, I remember about the filename stuff... 



Quote from: DARcode on
Outta curiosity, what about the missing MSJAVA.DLL reported by both WA plug-in versions? Does that belong to the discontinued MS Java VM?
Once you get to work on the Nero plug-in I'd like to test the dependency free WA one too if you ever allocate time to that, thanks.

P.S.
There ain't nuffin' stoopid 'bout a Winamp plug-in  !

I have no idea what that MSJAVA thing is; there's certainly no Java in my plugin. Also, since it doesn't show up when I run Dependency Walker, and you see it with the previous plugin also, I think I'll not worry about it. That is, unless someone has a clue what it might mean.

I didn't mean to imply that winamp plugins are stupid in general. Just my winamp plugin! 

WavPack 4.40.0 beta available

Reply #35 –
Hello mates.
until now i was using Easy Cd-Da Extractor to encode my cds in Wavpack.
Today i have DL Wavpack frontend and i'll use that one.
Now, excuse me if this is a stupid question, but please tell me what "extra options" should i use. Or, should i use some? If yes, pls tell me what. I want to encode my cds in WavPack.
Also, should i use this beta version for my encodings?
Thank you

WavPack 4.40.0 beta available

Reply #36 –
this beta should be pretty safe. WavPack also stores an MD5 checksum inside to make sure that the data inside is not corrupted.

as for the extra modes, why bother using them? the only thing they do is increase encoding time(quite drastically at x4-6) and they lower the filesize by about maybe 1 or 2 percent. IMO, x2 or x3 should be sufficient for you since Mr. Bryant recently made them fast enough to actually be usable

i personally use x6 on my comp due to the fact that i mostly use WavPack for storage.

WavPack 4.40.0 beta available

Reply #37 –
ok. then i will only start Wavpack frontend, add the tracks and click Go!
 
Thanx

WavPack 4.40.0 beta available

Reply #38 –
Quote from: Mangix on
this beta should be pretty safe. WavPack also stores an MD5 checksum inside to make sure that the data inside is not corrupted.
Isn't the -m switch required to compute and store the MD5?  If so I would recommend adding that to the command line.

Quote from: Mangix on
as  for the extra modes, why bother using them?
...
IMO, x2 or x3 should be sufficient for you
...
i personally use x6 on my comp due to the fact that i mostly use WavPack for storage.
  Confusing.

I would probably recommend -hxm, which is probably the switches I will be using.
I'm on a horse.

WavPack 4.40.0 beta available

Reply #39 –
-x modes ( even 4~5) have huge compression gains on some samples like extreme artificial. The gains are less when using the high modes, but are still there.

WavPack 4.40.0 beta available

Reply #40 –
ok, in conclusion: should i use some switches?
witch one? why?
thank you very much. i'm not into wavpack. i'm just starting

WavPack 4.40.0 beta available

Reply #41 –
Quote
Isn't the -m switch required to compute and store the MD5? If so I would recommend adding that to the command line.
yeah i believe it is. right now, i don't even understand why there even is a switch like that. WavPack should always store an MD5 by default

WavPack 4.40.0 beta available

Reply #42 –
Guess you are out for lossless encoding for archiving purposes on a pc.
In this case try hx3 to hx5 and use the maximum setting that is done with tolerable speed for you. hx6 is real pain, and I'd avoid it with lossless encoding.

I am personally into lossy encoding and did use hx6 so far. Don't care too much about the extreme time as I don't encode very much. But I reconsider it and I'm not sure myself yet what to do in the future (thinking of hx3 so far, but also considering normal mode x5 for the sake of my DAP's battery drain. Guess I'll do some tests when final comes out).
lame3995o -Q1.7 --lowpass 17

WavPack 4.40.0 beta available

Reply #43 –
Could somebody explain me in a few words what hx means.
what the switches are doing? is there any difference in quality (like Lame presets for example)?
any difference in quantity, time?
yes i wanna encod for archiving purposes. i had around 30 dvds with wavs and yesterday i have tested one of them (princo  ) and they have a lot of errors. so i won't burn them again as wavs, i have choosed to kill you guys with my stupid questions 
cheers

WavPack 4.40.0 beta available

Reply #45 –
@yulyo!: I was a total WavPack noob a while ago, but these amazing forums gave me a hand, just browse this thread: http://www.hydrogenaudio.org/forums/index....showtopic=40055

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

WavPack 4.40.0 beta available

Reply #46 –
Quote from: halb27 on
In this case try hx3 to hx5

As advise for someone new to WavPack, beside the link Synthetic Soul posted, I would keep it simple.
Try options:
Code: [Select]
-m      (normal)
-m -h   (high)
(-m -hh  very high in >4.4)


In CDex and foobar2000 add -i (for compatibility reasons).

If you like to try the "extra" modes, just add -x  as that gives the optimal number of extra processing.
Forget about -xn (n=number) as that will change in 4.4 (soon to be expected).
In theory, there is no difference between theory and practice. In practice there is.
 

WavPack 4.40.0 beta available

Reply #48 –
I'll be a dissonant voice in this: why not sticking with the default for a start? try the default mode or -h or even -hh

WavPack 4.40.0 beta available

Reply #49 –
i guess people love their compression ratios

as for -h vs -hh, i've heard that -hh gives only a few bits more compression than -h at the cost of longer decoding time. i personally use -hx6 in my command line since i like big compression but not a big fan of slow decoding.