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.2 released (Read 70484 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack 4.2 released

Reply #50
Quote
You might have to set CFLAGS to look in /usr/local for the iconv stuff on bsd, like so:

export CFLAGS="-I/usr/local/include -L/usr/local/lib"
sh autogen.sh
./configure
[a href="index.php?act=findpost&pid=290056"][{POST_SNAPBACK}][/a]


Thanks. I'll try that. I'm using the SourceForge Compile Farm, so I can't install iconv myself...

WavPack 4.2 released

Reply #51
NetBSD compiles work if you use the --with-iconv argument to configure (I didn't notice that the first time). Free/OpenBSD will probably need that too.

$ bash configure --with-iconv=/usr/pkg

So, no real problems with either Solaris or NetBSD - all user error. I'm going back under my rock for now. 

WavPack 4.2 released

Reply #52
rjamorim: You're welcome; the changes look great.

One other thing I noticed:
"Comparisions" <-- second "i" is erroneous.

WavPack 4.2 released

Reply #53
Quote
rjamorim: You're welcome; the changes look great.

One other thing I noticed:
"Comparisions" <-- second "i" is erroneous.
[a href="index.php?act=findpost&pid=290164"][{POST_SNAPBACK}][/a]

Okay, thanks, I updated the links page. And the help with the various *nix ports is great! I'm sure we'll get them all straightened out in no time.

I deeply appreciate the encouraging words from everyone; I hope I continue to live up to them. 

WavPack 4.2 released

Reply #54
just adding some more encouraging words ...
even some people that don't actually use wavpack as default, like me, are seriously following its evolution since instant seeking version 4 ...

Why I still use Flac C5:
1: Xiph
2: Vorbis Comment
3: Not Hybrid
4: Portable Support

Why at each new wavpack version I consider switching nowadays:
1: Around 10 meg saved by album
(Actually I lose 4gigs of HD with flac C5 over wavpack high)
2: Better "Speed Vs Compression" Settings
3: Stores the Compression Setting

after 100+gig of flac C8 encodes I switched to C5 as the -e option is too greedy,
after one year of flac using, flac has became a "one setting only codec", C5 default ...

when wavpack 4 came out, I have seriously considered using wavpack because its highest compression setting "Speed Vs Compression", wavpack -high, is much better than flac C8, but finally I only switched to flac C5 ...

why I didn't switch to wavpack ? because I don't need space actually, I don't actually need these 4gigs I could save ... furthermore due to the clean way my collection is sorted all it takes me to convert all my flac to wavpack is 3 clicks in frontah + 200 free gigs ...

I don't use wavpack as default actually ... but when I will buy a new empty 200gigs HD I will most likely do the step & convert all to wavpack high in one night ... & re-convert wavpack to flac when I will need portable playback ...

Wavpack+Flac is becoming a single codec for me ...

like other people use lossless for backup & lossy for portable ...

I use:
1: Wavpack High for HD backup
2: Flac C5 for portable playback if I ever need it (I want iRiver Support !!!)
3: Vorbis Q5 for all lossy use ...

Xiph may need two lossless codecs afterall ... why ? :
1: one codec that never breaks hardware portable compatibility, despite compression freeze: flac
2: one codec that always increase compression despite breaking hardware compatibility: wavpack

... you may disagree with me as I know many people here don't like Xiph & would do everything to avoid Xiph ...

but that's how I use Wavpack+Flac ... & as wavpack is open source it's already an unofficial Xiph codec in my heart ... in the same way Xiph is an unofficial part of Gnome in my heart ...

there is two types of lossless codecs: Compression Oriented: Ape & Hardware Support Oriented Support: Flac ...

wavpack may be the actual perfect compromise between ape & flac,
if wavpack start getting hardware support its compression will most likely freeze like  flac ... & a new codec breaking hardware compatibility with better compression will rise & then power-users will ask portable hardware support for it like they will soon ask for wavpack portable support ... it's an endless game ...

so we need either 2 codecs for 2 uses (compression/portable) or 2 settings for these 2 uses in the same codec ... something like a non-portable friendly mode for flac to compete with wavpack for pure compression)
... that's why I use (or actually plan to use ...) both flac for hardware & wavpack for backup ...

my 2 main problems with wavpack actually are:
1: lossless newbies are scared by the word "hybrid", so spliting hybrid encoder from the lossless one may be clever  (losslesswpack.exe vs hybridwpack.exe) & joining wavpack encoder/decoder (wavpack.exe+wvunpack.exe) so that in the end we have only 2 encoder/decoder one for lossy, one for hybrid might be clever ... specially as many wavpack lossless user favors lossy over hybrid ... so they would have the choice of not downloading hybridwpack.exe at all ...

2: Vorbis Comment, as a Vorbis User I feel home with vorbis comments, with ape tags I fell like I am using MPC & I dislike it much ;( lol

but maybe that's just my personnal taste ...
anyway congratulations for this great lossless codec

WavPack 4.2 released

Reply #55
I'm suprised about the rapid progress (not just in technical terms) of wavpack recently. I wouldn't have expected that with FLAC becoming almost the de-facto lossless standard. But i guess, it shows that its never too late :) I can understand very well that bryant will now focus on hardware support and compatibility in general - that priority makes sense.

BTW: i disagree with the previous poster on the hybrid-topic....... some recent threads have shown, that the hybrid-mode may after all be one of wavpacks biggest strenghts...... because it can be interesting when lossless is too big, yet you still want a HQ-source for transcoding.

- Lyx
I am arrogant and I can afford it because I deliver.

WavPack 4.2 released

Reply #56
Quote
2: one codec that always increase compression despite breaking hardware compatibility: wavpack[a href="index.php?act=findpost&pid=290207"][{POST_SNAPBACK}][/a]


I strongly believe Bryant isn't interested in breaking hardware compatibility

WavPack 4.2 released

Reply #57
Thanks bryant
Too bad that I can't download it currently in order to update my comparison. Were there changes (in speed) since beta 4?

WavPack 4.2 released

Reply #58
Roberto:
yes, ... once a lossless codec gets a small user database & the dev judges his codec "mature" he freezes the codec compression for hardware compatibility ... it happened to flac ... it will happen to wavpack if we all switch to wavpack ... that's why I didn't make the step yet ... so far I favor waiting for Josh to break portable compatibility like Monty will do with Vorbis II over switching to wavpack ...

Instead of fast-standard-high compression settings, it would be better IMHO to have 2 setting one for with frozen specification for compatibility with portable player ... & one freelance for pure compression backup ...

I know several guys that used to do ape image+cue for backup while they favor flac+splitted for playback ... the paradox is not new ...

the battle between top-compression & frozen-codecs-for-hardware will never ends if dev don't split their codec in 2 uses from within ...

flac 1.11 & 1.12 have bring nothing new for me ... like vorbis 1.01 have bring nothing new to me ... it's bugfix release, bugfixing is enought as long as you're the best ...

if Josh doesn't come to parity with wavpack 4 I will switch to wavpack ... sorry but flac portable hardware support is not so big that flac is the de-facto standard ...

the problem is that if we switch to each new codec with better compression, no lossless codec will never have a big enougth user database so that hardware compagny like iRiver & co will seriously consider supporting it ...

so it's to codec developper to break their holy portable compatibility when their codec is not state-of-the-art anymore ... it's not to end-user to switch to new codec for better compression each 2 years ...

actually I dunno what to do ... using wavpack for compression or flac for portable ...
I think that I will switch to wavpack but I push that time to "the later possible the better" because I wanna push iRiver to support Flac the more I can ...

lossless codec dev thinking portable support is the holy grail are wrong ... because even a lossless user like me would use lossy if I would have the choice between Flac & Vorbis for my iRiver portable ...

most user want portable hardware support for flac-wavpack because they want to have the possibility to do this ... it's a question of freeness ... it's not an absolute need ...

When I see I can save 4gigs with wavpack righ now, & flac iRiver support is non-existant ... at some point I will be realistic ... I will switch ...

... if flac is zip & wavpack is 7z ... then sorry but I use 7z ...

the countdown to wavpack has begun for me ...

WavPack 4.2 released

Reply #59
I'm sorry, OggZealot, I don't see how breaking FLAC's backward compatibility will improve its compression. The latest flac release might have not given you anything new, but that doesn't mean the developers are not actively trying to implement new compression schemes because they're afraid of breaking backwards and hardware compatibility. I believe FLAC developers value backwards compatibility, streaming, and stability more than highest compression levels.
As for wavpack4, it is fully backward compatible to WavPack 1.0, as every release so far, and new compression algorithms and features were added in every release. This probably means the codec is robust enough to handle such changes without breaking backwards compatibility and hardware support.
In my opinion, what Monty's doing with Vorbis hardware support is not a good thing, like you seem to believe. Breaking backwards compatibility is not mandatory to improve a codec.

WavPack 4.2 released

Reply #60
emtee:
yes maybe flac reached its wall ... I prefer not even think about it because then it's a wide open door to wavpack ...

Quote:
I believe FLAC developers value backwards compatibility, streaming, and stability more than highest compression levels.

I favor general features over compression too ... the problem is that wavpack does almost all that flac does ... & it does it with better compression ... wavpack is not ape, it doesn't miss any major features ...

I favor flac 1.10 over wavpack 3.97 or any ape version ... due to better general features ... but I favor wavpack 4 over flac 1.10

The problem is that wavpack 4 is a ape/flac killer joining the strenght of both world without any major flaws ... you cannot be blind to this eternally

I still use flac C5 in the same way people use zip over 7z or mp3 over vorbis ... lazyness ... not because I am convinced it's the best overall lossless codec ...

Like many flac users I don't consider switching at every new "last fashion" codec is a good thing ... but wavpack is here since a long time ... the only reason flac 1.10 was more popular than wavpack was wavpack 3.97 missing instant seeking feature ...

I don't happily break my Flac C5-Vorbis Q5 couple ... but following xiph for more than a year I know for sure Xiph skeleton rely on the Vorbis+Theora in ogg couple much more than Speex+Vorbis+Flac trio ... see how Ogg-Flac is a joke so far & how Josh is often in xiphmeet ... each month I hear: Rillian "Flac News: Is Josh Here ?" -Big Silence Rillian: "It seems not ... next topic" ...

sorry but the link between Flac & Xiph is not as close as it first seems ... flac was a perfect replacement for shorten when wavpack was not ready ... it's popularity came from there ...

now that wavpack is ready it's really hard to still use flac ... unless you're really a flaczealot ... which I am not ... or have a lot of free HD space ... which I actually have that's why I still use flac C5 so far ... but space goes down day by day making me look toward wavpack more & more ...

Finally yes I think Monty breaking Vorbis backward compability is a wonderfull thing ... for Vorbis I updates we have aoyumi ... I almost consider aoyumi as the official Vorbis I developper nowadays ... I wait his beta 4 final ... Monty himself also mainly rely on aoyumi for vorbis I updates now ... it's obvious if you read last xiphmeet logs & I like it that way ... 2 vorbis dev for 2 vorbis codec is better than 1 dev for 1 vorbis codec no ? ... it was obvious Monty wasn't really interested in tuning vorbis I  for high bitrate so it's better that he codes a new codec which willl potentially be natively better on high bitrates than that he only updates vorbis I once by year ... see how 1.01 was interesting ...

Monty had a problem with vorbis I as with experience he realized there were misstake in the vorbis design he couldn't fix ... instead of slowly losing interest Monty decided to code vorbis II so that nobody ever complaint portable player battery  have a longer life with mp3 than vorbis ... you should be happy of it ...
plz start complaining about Vorbis II if it ends in vaporware like bitrate peeling ... or if it ends to be worst in ABX test than vorbis I ... not just because it's new ...

WavPack 4.2 released

Reply #61
I decided to try out the excellent new WavPack 4.2 release to day with the new options.  Here are my encoding speed/size comparisons this morning, for those who may be interested.  Not sure if I should have posted this as a separate topic but it isn't a "listening" test, so here it is: 

Equipment:  WinXP P4 3.0 GHZ HT w/512 DDR RAM

Clips: 

Green Day - American Idiot -- Chosen because it is short and loud (not acoustic by any means).  2 minutes 54 seconds - WAV is 30,030 kb (29.3 MB)
Tom Waits "I Hope That I Don't Fall in Love With You" (quiet and should compress well) - 3 minutes 54 seconds - WAV is 40, 403 kb (39.4 MB)


I used the following options:

-h

Code: [Select]
 WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 7.67 secs (lossless, 24.89%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 14.58 secs (lossless, 47.68%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.0 MB
Waits: 20.6[/color]

========================================

-x1

Code: [Select]
WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 5.71 secs (lossless, 23.97%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 12.76 secs (lossles
s, 46.68%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.2 MB
Waits: 21.0[/color]

==============================

-x6

Code: [Select]
WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 127.62 secs (lossless, 24.41%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 164.17 secs (lossle
ss, 47.20%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.1 MB
Waits: 20.8[/color]

=====================================

-hx1

Code: [Select]
WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 24.76 secs (lossless, 24.89%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 19.97 secs (lossles
s, 47.89%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.0 MB
Waits: 20.5[/color]

==========================================

-hx3

Code: [Select]
WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 96.82 secs (lossless, 24.93%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 122.24 secs (lossle
ss, 48.00%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.0 MB
Waits: 20.5[/color]

==========================================

-hx6

Code: [Select]
WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 01 - American Idiot.wv in 516.29 secs (lossless, 24.95%)
-------------------------------------------------------------------------------

WAVPACK  Hybrid Lossless Wavefile Compressor  Win32 Version 4.2  2005-04-02
Copyright (c) 1998 - 2005 Conifer Software.  All Rights Reserved.

created 02 - I Hope That I Don't Fall in Love With You.wv in 683.51 secs (lossle
ss, 48.02%)
-------------------------------------------------------------------------------
Press any key to continue . . .


Resulting sizes:

Green Day: 22.0 MB
Waits: 20.5[/color]

So, the sizes didn't change much, but as stated in the documentation, the encoding time here shows that it is much higher.  I wonder if I am using the right settings?  The file sizes are sometimes larger than the -h standard....

Scott

WavPack 4.2 released

Reply #62
oggzealot, no need to stir the pot.  there is no "battle" among open codecs.  we put everything out there and users decide what to use.

are users going to switch because of a couple percent difference in file size?  a few, but not many.  mp3 is far from state-of-the-art but is the most used because is plays everywhere, is reasonably good and has been around longer.  wma and aac are only even noteworthy seconds because of big companies with big infrastructures behind them.

unless a lossless codec comes around that has a significant size advantage (I think at least 15-20%), codec usefulness will be the dominant factor.  one useful thing is the variety of software/devices on which it plays, availability of material, etc.  another may be a hybrid mode, I don't know.

getting support for an open codec is a long process of slow adoption.  for FLAC it has taken years (1.0 was almost 4 years ago), even though it had the advantage of filling a void.  now there is no void, now it's like unseating an incumbent.  it has to be blown away on features.  it can be partially shut out by apple+alac+itunes or ms+wmalossless+drm but there will always be a niche for something non-proprietary.  somehow I doubt that mpeg4-als will emerge unencumbered despite the best efforts of Tilman.

all that stuff you said about xiph, I can't make any sense of it.

and there's nothing 'holy' about portable hardware compatibility.  but to break backward compatibility and totally disrupt and piss-off users, you had better be getting more than a couple % extra compression.  it's not just about portables.  it's about home stereo equipment, car stereo, anything outside the PC.  no current codecs that get more than a few extra % can play outside the PC.

none of this is disparaging wavpack, which I think is a great codec.  for windows-PC-centric lossless I think it is the top right now.  but I don't think you are connected with the reality of what's beyond that.

Josh

WavPack 4.2 released

Reply #63
Quote
unless a lossless codec comes around that has a significant size advantage (I think at least 15-20%), codec usefulness will be the dominant factor.  one useful thing is the variety of software/devices on which it plays, availability of material, etc.  another may be a hybrid mode, I don't know.
[a href="index.php?act=findpost&pid=290355"][{POST_SNAPBACK}][/a]


hybrid mode, embedded cue sheets, asymmetrical compression/decompression are all usefulness factors that drew me to wavpack...

a windows-free, linux user since 1/31/06.

WavPack 4.2 released

Reply #64
Quote
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
[a href="index.php?act=findpost&pid=289620"][{POST_SNAPBACK}][/a]

would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd?  and then when i transcode to mp3 w/ foobar2000, id still have the original replaygain values?

if so, that would be awsome!  it would eliminate the extra step of replaygaining in fb2k.
a windows-free, linux user since 1/31/06.

 

WavPack 4.2 released

Reply #65
Quote
would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd?
[a href="index.php?act=findpost&pid=290373"][{POST_SNAPBACK}][/a]


Yes, except that in that case you would only have album gain, not track gain...

WavPack 4.2 released

Reply #66
Quote
Thanks bryant
Too bad that I can't download it currently in order to update my comparison. Were there changes (in speed) since beta 4?
[a href="index.php?act=findpost&pid=290243"][{POST_SNAPBACK}][/a]

No, the only difference between beta 4 and the release was the 2 gig fix.

On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in fast, 15% in normal, 30% in high, and 15% in all the extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance degradation in the beta 3 compared to the 4.1 release (except in the extra mode).

WavPack 4.2 released

Reply #67
Quote
Quote
Any plans for a commandline replaygain scanner for Wavpack? A wvgain or wavpackgain or something?
[a href="index.php?act=findpost&pid=289620"][{POST_SNAPBACK}][/a]

would this make it so when i ripped my cd's w/ eac to a wavpack image, i could have it automatically replaygain my cd?  and then when i transcode to mp3 w/ foobar2000, id still have the original replaygain values?

if so, that would be awsome!  it would eliminate the extra step of replaygaining in fb2k.
[a href="index.php?act=findpost&pid=290373"][{POST_SNAPBACK}][/a]

My thinking on the ReplayGain scanner would be that it would not handle the embedded cuesheets because foobar2000 is the only program that can currently play the image files as individual tracks and it has a fine ReplayGain scanner. When something else can handle cuesheets (I don't know how to make my winamp or nero plugins do it) then maybe I would add that.

For now I am imagining a command-line utility called WvGain that would accept a wildcard specification of WavPack files (just like WvUnpack does) and apply track gain to each one and album gain to the whole list. ID3v1 tags would be converted to APEv2. Is that enough for most people?

It won't be right away, but I think I think it's easy enough that I could squeeze it in with other stuff sometime soon.

WavPack 4.2 released

Reply #68
Quote
For now I am imagining a command-line utility called WvGain that would accept a wildcard specification of WavPack files (just like WvUnpack does) and apply track gain to each one and album gain to the whole list. ID3v1 tags would be converted to APEv2. Is that enough for most people?

It won't be right away, but I think I think it's easy enough that I could squeeze it in with other stuff sometime soon.
[a href="index.php?act=findpost&pid=290683"][{POST_SNAPBACK}][/a]

That would be awesome! 
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

WavPack 4.2 released

Reply #69
Thank you, bryant!  WavPack is just what I need for Adobe Audition.

I do have a question, though:

Using the plug-in for Audition, I have the option to "Normalize" the 32-bit float file.  I know that in the accompanying text file it states:
Quote
This does not affect the file's usability in either Audition or other WavPack compatible programs.

What is the difference made to the file by normalizing?  If the decompressed files are identical, what is the reason for the option?  Why wouldn't one use the "Normalize" option?

Sorry if this is a silly question...
I'm just wondering if there's some benefit in not using the "Normalize" option.

Thanks, again!

~esa

WavPack 4.2 released

Reply #70
Quote
On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in fast, 15% in normal, 30% in high, and 15% in all the extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance degradation in the beta 3 compared to the 4.1 release (except in the extra mode).
[a href="index.php?act=findpost&pid=290682"][{POST_SNAPBACK}][/a]

I don't know what beta version I used for my wavpack test. I've tried yesterday the beta 4 and compared the speed with the value currently present on my comparison, and there were no changes (tested with -fx5 and with defaulted mode). Are the modifications dependant on a CPU? Mine is old (Duron 800), and it maybe expain the lack of changes.

Anyway, I'll wait to download 4.2 final before updating my comparison.

WavPack 4.2 released

Reply #71
Quote
Thank you, bryant!  WavPack is just what I need for Adobe Audition.

I do have a question, though:

Using the plug-in for Audition, I have the option to "Normalize" the 32-bit float file.  I know that in the accompanying text file it states:
Quote
This does not affect the file's usability in either Audition or other WavPack compatible programs.

What is the difference made to the file by normalizing?  If the decompressed files are identical, what is the reason for the option?  Why wouldn't one use the "Normalize" option?

Sorry if this is a silly question...
I'm just wondering if there's some benefit in not using the "Normalize" option.

Thanks, again!

~esa
[a href="index.php?act=findpost&pid=290763"][{POST_SNAPBACK}][/a]


First of all, it's not a silly question at all. It is however, somewhat difficult to clearly explain. 

The reference in the Audition filter settings to "type 1" or "type 3 normalized" refers only to the type of wav file you will get if you unpack the resulting WavPack file with the command-line program. The WavPack files themselves are basically identical, except for the information on what kind of wav file to make if unpacked.

The type 1 files are non-standard because the float data ranges +/- 32768 and the type tag of 1 indicates integers. These were natively created by CoolEdit, and can generally only be loaded by CoolEdit or Audition. I suspect that they got lots of complaints about this and so decided to switch Audition's native format to type 3 (float) files which have the correct range of +/- 1.0 (i.e. normalized) and so can be correctly recognized by other programs.

So, basically this means that if you select type 1 files, the wav file that will result from unpacking will be native to CoolEdit and the type 3 files will be native to Audition. Although either program will load and save in either format, they work faster with their native format (I imagine because they must do a lot of internal conversions). The type 3 files are compatible outside of CoolEdit and Audition, so that's a big advantage.

So, to answer your central question, the only disadvantage to using the type 3 normalized option would be if you unpacked the resulting files back to wavs and then used them in CoolEdit they would operate slower than if you saved in type 1. Now that I think about it, that should probably be the default behavior. 

Glad the filter is working out for you!

WavPack 4.2 released

Reply #72
Quote
Quote
On your tables you give the WavPack version as 4.2, so I assume that it was beta 3. The encoding speed improvement from beta 3 that I am measuring here is 11% in fast, 15% in normal, 30% in high, and 15% in all the extra modes. Unfortunately the improvement from 4.1 is less because there was actually a performance degradation in the beta 3 compared to the 4.1 release (except in the extra mode).
[a href="index.php?act=findpost&pid=290682"][{POST_SNAPBACK}][/a]

I don't know what beta version I used for my wavpack test. I've tried yesterday the beta 4 and compared the speed with the value currently present on my comparison, and there were no changes (tested with -fx5 and with defaulted mode). Are the modifications dependant on a CPU? Mine is old (Duron 800), and it maybe expain the lack of changes.

Anyway, I'll wait to download 4.2 final before updating my comparison.
[a href="index.php?act=findpost&pid=290802"][{POST_SNAPBACK}][/a]

Well, I just did the comparison on another system and got different results, so I guess it is somewhat system dependent. In this case there was nice improvement from 4.1 to 4.2b3, but then no change from 4.2b3 to 4.2, and the extra option wasn't improved at all.

Let's just say that 4.2 is as fast or faster than any previous version. 

edit: added a missing word

WavPack 4.2 released

Reply #73
Quote
The reference in the Audition filter settings to "type 1" or "type 3 normalized" refers only to the type of wav file you will get if you unpack the resulting WavPack file with the command-line program. The WavPack files themselves are basically identical, except for the information on what kind of wav file to make if unpacked.

The type 1 files are non-standard because the float data ranges +/- 32768 and the type tag of 1 indicates integers. These were natively created by CoolEdit, and can generally only be loaded by CoolEdit or Audition. I suspect that they got lots of complaints about this and so decided to switch Audition's native format to type 3 (float) files which have the correct range of +/- 1.0 (i.e. normalized) and so can be correctly recognized by other programs.

So, basically this means that if you select type 1 files, the wav file that will result from unpacking will be native to CoolEdit and the type 3 files will be native to Audition. Although either program will load and save in either format, they work faster with their native format (I imagine because they must do a lot of internal conversions). The type 3 files are compatible outside of CoolEdit and Audition, so that's a big advantage.

So, to answer your central question, the only disadvantage to using the type 3 normalized option would be if you unpacked the resulting files back to wavs and then used them in CoolEdit they would operate slower than if you saved in type 1.
Thank you, bryant!
That makes perfect sense.
 
...and thanks again for WavPack!



:edit:
One more question:

Is the command-line parameter "-a" the same as "Normalize (type 3)" in Audition?

TIA!

WavPack 4.2 released

Reply #74
Quote
One more question:

Is the command-line parameter "-a" the same as "Normalize (type 3)" in Audition?

TIA!
[a href="index.php?act=findpost&pid=291043"][{POST_SNAPBACK}][/a]

It's related to it. That option just causes WavPack to properly recognize those non-standard wav files generated by CoolEdit that indicate in the header that they're integers but are actually floats. If you don't use this then the resulting WavPack might be unusable, and will definitely be unplayable. Since you use Audition (not CoolEdit), you should never need this unless you save your wav file in one of the non-standard formats (which you shouldn't).