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 45861 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

why isn't wavpack more popular?

Reply #50 –
David rocks 

why isn't wavpack more popular?

Reply #51 –
More detailed testing is to follow, but so far in casual listening, I am not picking up any obvious noise/hiss using the default q setting. I even did some stuff at -q-5 which dropped the bitrate down to 250 kbits or less in many cases. I can hear some hiss albeit at still quite low levels considering the bitrate.

Very cool, and yes, it's official. David does seriously rock.  This is EXACTLY what I have been looking for. My wishlist for Wavpack is now nearly complete, apart from foobar support with 4.

 

We just now need to do a few checks to see if anything can fool this puppy!

Den.

why isn't wavpack more popular?

Reply #52 –
Woah! Excellent work, David! I'm really looking forward to fb2k support for it! Given the current state of things we are not too far away from a beta, are we?

A couple of small requests, both for the encoder and the decoder:
1. Decoder: A umm... decoding speed ratio indicator (if that is how it is called ) e.g. 52.2x, 22.3x, etc. It's much more comfortable to have it automatically than to divide the track length by the decoding time. I must say I am quite impressed with the decoding speeds of the -ffq modes reaching ~50x (on my Mobile AthlonXP 1700+)! Keep it up and it will very likely replace MPC insane as my quasi-lossless-for-transcoding-and-archival format of choice!
2. Encoder: Average bitrate display. While the % lossy compression does provide what is needed to get it (100 - % * 1411), again for convenience's sake it would be nifty to have it automatically.

On another issue, the -x appears not to work as explained on the readme for the quality modes. Using -ffq9x6 and -ffq9 for one test song (3:06) yields exactly the same file size with 55s vs 36s encoding time, respectively. Decoding time are also practically the same: 4.07 vs. 4.13. Whether there are quality differences, I don't know (certainly inaudible to me), but if I understood correctly there shouldn't be any, only an impact on bitrate, which stays the same (around 460 kbps). Where is the extra encoding time going? A bug, perhaps?

why isn't wavpack more popular?

Reply #53 –
ChristianHJW:
After we communicated last I created a document describing (in general terms) how the future API would look, and that file is also now included in the alpha package. I believe that this is a more useful picture of the Matroska integration issues than the source code because there is no API in the source code. If your devs look over that document and have questions or suggestions then we can go back and forth and they can influence how the API might look. If they still want to see the source after that I can provide something, but it's still kind of a mess and I really don't think they could find anything useful in there.

I do want to make sure that I don't do anything that makes Matroska difficult...

glauco:
Thanks for the testing! The model I used was from a 1988 paper, so there's nothing really new in there. The only real modification I made was having the ATH (absolute threshold of hearing) float relative to the audio level rather than be absolute so that when Den turns the volume way up in a quite part he still won't be able to hear hiss (I say with fingers crossed)! Anyway, when the bitrate came out to about the level I expected, I left it alone. We'll see whether people can find any problem samples...

As for tuning, there's probably not a lot to do because the model is so simple. But I think I will be able to reduce the bitrate some while staying within the model, but not until I finalize the format. My goal here was not to get transparent sound at the lowest possible bitrate, but to work toward a codec that is transparent in all circumstances.

Dologan:
I believe that I mentioned somewhere in the readme that the -x option works best with the default and the -f mode, and not so good with the -ff and -h modes (or maybe I thought about putting that in there). Anyway, the problem is that the -ff mode is so simple there's not much for the -x switch to do; it looks but can't find any improvement unless the signal is very atypical. I actually considered not including that mode at all. I recommend using the -f mode if decode speed is important because it will definitely benefit from -x and decodes almost as fast. Also note that some disk handling optimizations should speed up the "fast" modes somewhat on some systems (on one computer I tested "fast" was actually slower than normal!).

I agree that having average bitrate displayed would be good, maybe even the default for lossy modes? As for encoding/decoding speed as a realtime ratio...well, we'll see what I can do. 

My plan is to have a beta towards the end of this month, although it could easily slip into February as I have some paying work I need to get out of the way...    Anyway, thanks for the testing and suggestions!

rjamorim & den:
Thanks to you guys also! 

why isn't wavpack more popular?

Reply #54 –
Hi,
After a few quick tests, I just have a quick bug report. When I answered to not overwrite an existing file using wvunpack, it deleted the file instead.

Code: [Select]
D:\wavpack>wvunpack.exe "01-Love Me Do.wv"

 WVUNPACK  Hybrid Lossless Wavefile Decompressor  Win32 Version 4.0a1  11-6-03
 Copyright (c) 1998 - 2003 Conifer Software.  All Rights Reserved.

overwrite 01-Love Me Do.wav (yes/no/all)? n


I'll report more when I get a chance to do some proper testing.

Thanks David,
rinseaid.
Uh oh, you bwoke it.

why isn't wavpack more popular?

Reply #55 –
Still early days, but I have now encoded a couple of CDs through it and spent some time doing close attentitive listening, not ABX style though. The CDs I listened to were Seal IV and Street Fighting Years - Simple Minds. The latter one is particularly suitable for picking up hiss in the quiet sections with Wavpack 3.97.

I used the bog standard -q, no x, no f, no h, no nothing.

Very impressive. The bitrates for each track are in the 300 to 320 kbit range, and even at extreme volumes I am not hearing obvious hiss. -hb320 with 3.97 results in files where I can easily hear some hiss even at only moderate high volumes.

I am yet to try some decent ABX testing, but this lossy quality mode seems very reasonable so far.

After an email from David, I added x4 to the command line, just to see how much this squeezes the bitrate. (Quality doesn't change, it justs uses a few less bits.) So far, for the noticeable slowdown in encoding speed, I am only noticing a 5 kbit saving in most cases, so not enough to convince me, but for others where every bit counts, or if you can leave it encoding overnight. I'm trying it again with x6, just to see what happens, and now it is very slow encoding wise as you'd expect.

I have also done a couple of quick listens at -q5 and -q-5, and although -q-5 was hissy, it wasn't as bad as I was expecting, and it did shave another 20-25 kbits off in the couple of tracks I tested.

This is looking better and better everytime I play with it. 

Quote
rjamorim & den:
Thanks to you guys also!


No worries David. Me and rjamorim are just a couple of fanboys...

Later,

Den.

why isn't wavpack more popular?

Reply #56 –
Den, do you plan to do another transcoding test and/or a new comparison with Optimfrog Dualstram in the near future? It would be great to see the results of these tests.
Over thinking, over analyzing separates the body from the mind.

why isn't wavpack more popular?

Reply #57 –
Yes and yes PoisonDan.

I don't wish to pre-empt any such tests, but I don't expect the model that David has introduced to cause any significant problems with transcoding. I guess some will be worried that now that a model is involved, it could potentially cause problems, but if my understanding is correct, the model is more focused on using more or less bits in order to ensure that the level of quantisation noise(hiss) is perceptible, rather than deciding which frequencies in a signal will be missed if they are not encoded, etc. Alpha 2 still keeps all the frequencies, etc. The difference is it uses a model to determine whether the hiss can be detected, and if yes, use more bits, and if not, perhaps try a few less.

I'm certainly impressed with how it handles known problem samples from Wavpack 3.97. Where as before you had to make decisions as to whether to use joint stereo or not, or to use a higher bitrate when required for difficult samples, the quality mode just uses more bits when required, without the need for changing your command line. It even goes near lossless to resolve problem areas from what I've seen so far.

Sweet. This is just what I was after.

Anyway, I am still enjoying the last few days of holidays with my family, but after that, I am planning to do some reasonably serious tests and document them here.

Also, while I haven't posted much about alpha 1 on HA, it certainly achieves transparency at lower bit rates than 3.97 in my experience, and is now closer to Dualstream in terms of bitrate to get a given level of perceptible noise or lack thereof.

Later,

Den.

why isn't wavpack more popular?

Reply #58 –
Quote
Hi,
After a few quick tests, I just have a quick bug report. When I answered to not overwrite an existing file using wvunpack, it deleted the file instead.

Code: [Select]
D:\wavpack>wvunpack.exe "01-Love Me Do.wv"

 WVUNPACK  Hybrid Lossless Wavefile Decompressor  Win32 Version 4.0a1  11-6-03
 Copyright (c) 1998 - 2003 Conifer Software.  All Rights Reserved.

overwrite 01-Love Me Do.wav (yes/no/all)? n


I'll report more when I get a chance to do some proper testing.

Thanks David,
rinseaid.


That was definitely not the intended behavior, although it did not actually overwrite the file! 

I have uploaded a new alpha2 with that fixed; hope there was no damage done.

Thanks a lot for letting me know! 

why isn't wavpack more popular?

Reply #59 –
Quote
If you look at the FLAC comparison page, http://flac.sourceforge.net/comparison.html, you'll see that wavpack normal compresses a few MB better than FLAC maximum, encodes in half the time, and decodes not much slower...

Wavpack is also free and open-source, just like FLAC... and it has an excellent feature that FLAC lacks: hybrid mode ("lossy" + correction file).

FLAC's advantages are that it is stream able, is more well-known (under the xiph umbrella now as well) and has better support (on a few hardware players as well).

Now there isn't perhaps that much between them, but surely wavpack deserves more recognition than it gets?

I'm new to the whole lossless thing (but I know I don't care for WMA), and from what I see a lot here in HA, it seem people put speed before quality. I could care less for the speed of what I'm encoding, my "first" priority would be quality.
So I see a lot of people recommending FLAC or Monkey, etc. How come there aren't any forum listings on these formats? I know that MP3's, Ogg, and AAC are popular, but maybe if there were a little more emphasis on these, maybe, just maybe they can get a little more boost in popularity.
Again, I digress. From what I've been reading I think Flac would be a good choice, plus it seems like more are also jumping on the bandwagon(including me).
As for Wavepak, that's totally in left field and i have to continue may quest for knowledge of these lossless codecs.
I see "Deaf" people! d(-_-)b

why isn't wavpack more popular?

Reply #60 –
Quote
I could care less for the speed of what I'm encoding, my "first" priority would be quality.

Then any lossless compressor should interest you.

However, if you are looking for quality features (since all lossless compressors are 100% [digital] audio quality) then you will need to read up on them since I won't give you an unbiased opinion.

WAVPack seems to have better speed vs. size efficiency than other's recent versions of encoders. Hybrid mode should be interesting for those looking to have both a lossless backup and a PC-machine music collection with lossy without as much space reuqirements compared to something else like lossless + MP3. COol!

edit: much gooder rewording
"Something bothering you, Mister Spock?"

why isn't wavpack more popular?

Reply #61 –
Quote
I'm new to the whole lossless thing (but I know I don't care for WMA), and from what I see a lot here in HA, it seem people put speed before quality. I could care less for the speed of what I'm encoding, my "first" priority would be quality.
So I see a lot of people recommending FLAC or Monkey, etc. How come there aren't any forum listings on these formats? I know that MP3's, Ogg, and AAC are popular, but maybe if there were a little more emphasis on these, maybe, just maybe they can get a little more boost in popularity.
Again, I digress. From what I've been reading I think Flac would be a good choice, plus it seems like more are also jumping on the bandwagon(including me).
As for Wavepak, that's totally in left field and i have to continue may quest for knowledge of these lossless codecs.

I don't know what you've been reading, pal, but most people here don't put speed before quality by any means. Proof of that would be that the --alt-preset standard is still the recommended setting for LAME, despite the fact that the fast variation of it yields almost the same quality and is significantly faster. On the other hand, why are you talking about quality if these are lossless codecs? They are all "perfect".
FLAC, Monkey, WavPack and the other lossless codecs have their place in the Lossless category. They don't have their own forums simply because there isn't so much to talk about each of them as there is for lossy codecs. Lossless codecs don't have problem samples and can't be tuned but for speed and a little extra compression. Lossless codecs also only come in one flavour, the original one, unlike AAC or MP3 for instance, which have several implementations each.
Anyway, all this is a little off-topic, since the topic has long wandered to another direction.

why isn't wavpack more popular?

Reply #62 –
This encoder is exciting. I suppose that this new VBR/quality mode is able to keep plain transparency, and restitute noise free encoding, even with classical music.
I’ve played some hours with the –q mode with samples of mine. I’ve tried to find some flaws, and to make things easier, I’ve began to encode with –q-9 in order to select the most noisier sample. I’ve noticed that tonal instruments (organ, strings, wind...) suffers a lot at this low quality setting. But for most of them, the default setting (-q) was not strong enough, and the slight remaining noise was still ABXable. I have even ABXed some samples at -q5, and one at -q9. This last one is a part of an organ sample (bruhns.wav), and the funniest thing is that some lossless encoders are more efficient than the -q9 lossy mode (488 kbps vs 431 kbps for optimFROG -extranew).


Then, I’ve tried to compare wavpack4 alpha (WV) with the other hybrid encoder (dualstream or DS), which is for my very limited experience better than wavpack 3.9 lossy. DS -q3 gave me approx. the same size than WV -q mode. I’ve compared both format with three samples :

- Bruhns.wav (organ)
- Candide.wav (orchestral, strings part)
- Corelli.wav (chamber, strings)




BRUHNS.WAV (organ)

Whereas DS -q3 was smaller than WV -q, the quality was better. With noise shaping, DS outperform WV VBR... More surprising, DS -q1 was similar to WV -q (on some parts noiser, on some other cleaner), with a big difference in bitrate (DS -q1 = 240 kbps // WV -q = 350 kbps). Wavpack -q suffered a lot from unstable noise. Maybe flaws in noise estimation model?
I noticed than noise shaping (DS) was very efficient with -q3, but lowered the quality at -q1
I’ve compared in the same test WV -q-8 and WV -hb230, and quality was really poor (blizzard noise) compared to DS at similar bitrate (-q1 and -q1 ans).




CANDIDE.WAV (orchestral)

This time, DS -q3 was clearly bigger than WV -q. I’ve therefore tested DS -q2 and DS -q3, and WS -q and -q2. I’ve introduced in the same test WV in -b mode (-hb340), in order to compare -q and -b at the same bitrate.

Again, DS -q3 ans was better than anything else (even better than reference: I’ve rated 4.7/5 the reference file...). Second one was WV -hb340, not so transparent. Last one (on 7 files) was WV -q !!! WV -q2 was inferior to DS -q3 (with and without noise shaping).
Again, I’ve noticed that noise shaping (DS) is a real advantage at -q3, but lowered the quality at -q2...
For this sample, WV -q and -q2 mode were clearly worse than -b340




CORELLI.WAV (chamber)

I’ve restricted the test for this sample, which is more difficult to ABX than the two previous one. I’ve tested WV -q and WV -hb320 to DS -q3 and -q3 ans.

Two groups appeared:
- close to transparency, DS -q3 ans and WV -hb320. I gave the best note to DS, though I didn’t tried to ABX the existing difference with WV.
- audible noise : DS -q3 without noise shaping and WV -q. For the first time, WV was superior to DS (but difference is very limited)




CONCLUSIONS

• I can’t say if WV is superior or inferior to DS. For two reasons. First reason: I’ve just tested three samples... Second reason: I used three samples with specific problems for WV4 -q mode.
• VBR or quality mode is not always better than CBR or -b mode. On the three samples, comparison between -b and -q at the same average bitrate was each time in favor of -b mode...
• If all hybrid encoders are suffering from noise, WV VBR is the one to generate unatural (fluctuant) noise, which is really annoying (but maybe very rare).
• (From Wavpack alpha2 readme.txt:) In the default version (-q) the psycho-acoustic model is used directly and should provide transparent operation with virtually all samples and listeners. This is not the case for the moment. Some kind of samples are really noisy with the -q setting (limited noise, but not acceptable IMO for 350 kbps encodings).
• DualStream with noise shaping (and sometimes without) was each time better than Wavpack -q. I suppose that progress are possible for WV4 final )
• DualStream noise shaping seems to have problems with -q1 and -q2 settings, but provide a very impressive quality jump with -q3 (at least, on these three samples).
• Last one : at this bitrate (>300 kbps), it seems to be easier to find problem samples for hybrid encoders than for traditionnal lossy encoders, so I’m not sure that this kind of encoder is really useful (except maybe in the case of correction files stored on CD/DVD or perhaps for loud mastered music).





OTHER SMALL TESTS

• MENDELSSOHN.wav
DS –q3--ans  >  WV –hb340  >  WV –q

• BINIOU.wav
DS –q3--ans > WV –q & WV –hb340 > WV –hb340-s-1



EDIT: samples are uploaded here:
http://www.hydrogenaudio.org/forums/index....ndpost&p=170894
 

why isn't wavpack more popular?

Reply #63 –
Thanks for the post guru. Facinating reading. I haven't checked out your samples yet and in fact I'm yet to do detailed ABX tests with Wavpack 4 a 2, but will be later next week.

It's interesting that you mention the fluctuating noise. I actually find the noise shaping in Dualstream quite annoying in some of the samples I have reported previously. I find I can hear subtle changes in the background moving around the notes, and while the volume needs to be high for me to hear it, it bugs me.

I don't think that it is easier or harder to find problem samples for these or the more traditional lossy encoders. They are simply different. If you put fatboy, castanets or some of the other well known problem samples through Wavpack or Dualstream, they handle them quite well. But then something that LAME or Vorbis finds easy to encode, can produce background hiss in Wavpack/DS. I think what is more important is what bugs you. Noticeable artifacts such as pre/post echo, smearing, etc or slight changes in the background hiss.

Also, with regards to your comments about how useful these codecs are, it depends on your needs. I still believe that the lossy files from Wavpack/DS leave vorbis/LAME/mpc/AAC for dead when it comes to transcoding.  My latest music storage system is to have all of my CDs, (~250) on my harddisks as Wavpack lossless as split wv+wvc files. When I am travelling, I take a cut down version of my favourites as the lossy files on a few DVD+RWs, which I can transcode to ATRAC3 and into my MD from my laptop when required with minimal (nil) transcoding artifacts. If I do this with mpc for example, I can clearly hear transcoding problems with some of my files. Not everytime, but enough to bug me.

I suspect that Wavpack 4 still has some work to do to match Dualstream in the quality:bitrate ratio stakes, but the gap is closing.

Den.

why isn't wavpack more popular?

Reply #64 –
guruboolez:
Thanks so much for your (as usual) thorough testing! I have downloaded your samples and will be trying to duplicate some of your results and figure out what is going on. BTW, when I used the phrase "virtually...all listeners", I had you (and some aussie dude) in mind. 

There is one thing I would like to clarify about comparisons between WavPack hybrid and OptimFROG Dualstream. Using the command lines that you used and decoding on my 1.7 GHz P4, I measured a 4:1 difference in speed (in WavPack's favor). Even using OptimFROG's fastest mode and WavPack's slowest resulted in a difference of almost 2:1. Now, there is a direct relationship between the complexity of an algorithm and the compression performance in can achieve, and WavPack and DualStream are definitely at opposite sides of the spectrum. If quality at a given average bitrate is the only criteria, then WavPack will almost certainly never match DualStream. However, my emphasis has been on decoding simplicity and the possibility of hardware (portable?) playback.

Changing your WavPack command lines from -q to -qx4 reduced the bitrates on those 4 files by a little over 5 kbps, and switching DualStream to "fast" mode increased its bitrate by about 10 kbps, so there's 15 kbps that might narrow the quality difference somewhat.

Also with respect to bitrate, the current WavPack alpha does not perform optimally, mostly so I could stay compatible with the existing decoders. My emphasis was on finding out whether I had the quality right and then let the bitrate fall somewhat as I went to the beta version. Also, the "fluctuating" noise that you heard may be an artifact of trying to fit into the existing format (especially at negative q settings) and will go away in the beta.

However, this brings up the point that you can still hear noise at -q0. Since the psychoacoustic model I used is pretty old and well established, I can only think of two possibilities. One is that I have implemented something incorrectly, or the problem may be a binaural problem which is not covered by the model. Could I ask you to try an experiment? I would be very interested if you still hear the noise if both the reference and test files are converted into mono just before the ABX test:

A: original file ---> mix to mono
B: original file ---> encode ---> decode ---> mix to mono

If this eliminates the audibility of the noise then I have a very good idea of how to proceed. If not, then I'll quickly come up with another plausible explanation... 

Anyway, thanks again for taking the time to report your results.

why isn't wavpack more popular?

Reply #65 –
Hello David, and thanks for your positive comments.

On my Duron 800, optimFROG DualStream --quality 3 --ans is really fast compared to wavepack -q (it's faster fast than Vorbis, or Lame preset abr/cbr). In comparison, wv4 -q is painfull (I havn't checked speed, but I can remember that I was bored).

I have compared average bitrate with 20 classical tracks (from 20 different discs), for 2 hours of music. Here are results :

Code: [Select]
           WVq  ofsQ3 mpc10 GT3q9 AACTr

track 01 : 367   345   349   330  +324+
track 02 : 328   346   355   319   292
track 03 : 353   339   388   334   312
track 04 : 316   343  -313-  254  -265-
track 05 : 345  +360+  320   279   306
track 06 : 336  -304-  344   277   289
track 07 :-304-  327   365   321   289
track 08 :+453+ +360+  331   286   303
track 09 : 324   344   328   288   284
track 10 : 348   336   374   304   295
track 11 : 354   352   334   297   308
track 12 : 329   335  +409+ +372+  290
track 13 : 322   353   341   305   298
track 14 : 326   343   347   345   310
Dixit    : 312   348   322   298   310
Wagner   : 332   341   340   296   308
Bayle    :+443+  350   320  +353+ +324+
Beethoven: 357   350   355  -284-  300
Rinaldo  : 352   351   330   298   315
Requiem  : 326   342  -314- -284-  311
---------------
1h'56'55"
7015 sec

wavpack -q..................  289 Mo (303 832 170 octets)   ~337 kbps
DualStream -q 3 --ans.......  287 Mo (301 479 022 octets)   ~335 kbps
musepack -q10...............  289 Mo (303 764 860 octets)   ~337 kbps
vorbis GT3b1 q9.............  250 Mo (262 740 196 octets)   ~292 kbps
AAC Nero ::transcoding::....  253 Mo (265 975 691 octets)   ~295 kbps

14 first tracks are extracted from an anthology (14 different CD, all stereo with one old/noisy piano track [tr#5]).
Track#8 is a two-hand piano, and I can't explain the blow for WV4 (453 kbps - OptimFROG lossless max is 436 kbps).
"Bayle" is electronic music, with micro-impulse, and bitrate explosion is easy to understand.


As you can see, for my purpose (I have only tried classical), both hybrid encoders are close to 335 kbps (with a small advantage for DualStream), and DualStream is much faster and really usable.



EDIT: I can test downix this wek-end, but probably not post results before some days.
EDIT2 : just a precision to avoid confusion, wv4 -qis really good, and I can hear noise on some samples only. The organ sample is the most annoying, because noise level is different for each note (and particulary audible for one - that's why I'm tempted to consider it as a problem sample)

why isn't wavpack more popular?

Reply #66 –
guruboolez:

I played around with the organ sample and I agree that it's a problem (I ABX'd it at -q-3 and probably could have at -q if it hadn't been for my new computer's many noisey fans and open headphones). It is very tonal and the part of my model that estimates tonality does not seem to be registering it high enough. I'll have to figure out if it's a bad implementation or whether I need to go to a multi-frame tonal estimator.

I think there's no longer a need for the downmix test if you haven't already done it, although if you have done it I would still be interested in the general results.

BTW, when I mentioned speed I was refering to decode speed, not encode speed (which is done only once). The encode speed of the new -q mode is slower than OptimFROG, although there is probably some room for improvement once I settle on an algorithm.

Thanks again...

why isn't wavpack more popular?

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

Code: [Select]
typedef struct {
    char ckID [4];  // "wvpk"
    long ckSize;  // size of entire frame (minus 8, of course)
    short version;  // 0x400 for now
    uchar track_no;  // track number (just an idea now)
    uchar index_no;  // remember these? (just an idea now)
    ulong total_samples;    // for entire file (-1 if unknown)
    ulong block_index;  // index of first sample in block (to file begin)
    ulong block_samples;    // # samples in this block
    ulong flags;  // various flags for id and decoding
    ulong crc;      // crc for actual decoded data
} WavpackHeader;


Does the CRC contain this header too ?

Otherwise from a Matroska point of view it all looks good to me. We'll probably strip some unnecessary data from this header when muxing in Matroska and reconstitute it on playback (if that's needed by the decoder).

BTW, can you mix mono and stereo (or more) packets in the same file (for the same stream) ? I guess not, as it's supposed to be lossless and there are no such source material, but I just want to make sure it's OK (not to have this).

why isn't wavpack more popular?

Reply #68 –
robUx4:
The header is not included in the CRC; it is for the decoded audio samples only.

The only fields required to be correct by the decoder are the data size, version, block_samples, flags, and crc. I'm not too sure of the advantage of not just leaving the block alone considering how large they generally are (unless you are planning on really short blocks).

Each of these packets are completely stand-alone. They can be decoded back to mono or stereo audio without anything else. So I don't see any reason that you could not mix as many mono and stereo streams as you wanted as long as Matroska was keeping track of them.

The only issue about consecutive blocks is that during encoding it is more efficient if the encoder can start where it left off in the previous block. However, I have written code to encode a block without that (i.e. stand-alone) but it's a little slower because it has to scan the block to set some encoding parameters.

If you would like to discuss this more offline, feel free to e-mail me at the address on the WavPack website.

why isn't wavpack more popular?

Reply #69 –
While you are free to require a certain bitstream always be returned to the decoder, it would be nice if the headers could be stripped. 

As a high level container, the idea is to store only the RAW data inside of the Blocks and store all other information at the container level.  This way tools can be written that can read and manipulate a variety of information on any type of format. 

A good example of this would be subtitles.  For storage in Matroska, the display time and duration are stripped out of the data stored in the Block and stored at the container level.  Because of this it is possible to remove, move, and change the duration of subtitles no matter the format they are stored it (SRT, SSA, VobSub, etc), without the program needing to understand the format. 

Things like the CRC can be stored at the container level, allowing applications to instantly spot a Block with bad data.  Then you can decide exactly what you want to do with that Block.

why isn't wavpack more popular?

Reply #70 –
Quote
If you would like to discuss this more offline, feel free to e-mail me at the address on the WavPack website.

I tried to email to you but my personal SMTP server was blocked...

You can find a copy of the email here.

why isn't wavpack more popular?

Reply #71 –
I figured out what was going on with my tonality estimation and fixed it. Unfortunately, this resulted in an unacceptable increase in average bitrate, so I biased up the noise threshold to get the average back to about 360 kbps. I am happier with this version than the previous (and it does much better on the organ sample from guruboolez), but I realize that this will have to wait for the beta version to really work well at reasonable bitrates.

The latest (and probably last) alpha is here:

http://wavpack.com/alpha3.zip

Thanks to everyone who tried it out!

robUx4 and Pamel:
I have responded by e-mail (to robUx4) regarding these issues. Please let me know if you don't receive something.

why isn't wavpack more popular?

Reply #72 –
Nice.

Quality is, for me, far more important than bitrate.

And I was not so wrong about the tuning stuff 

Great work.
Just a thought...

why isn't wavpack more popular?

Reply #73 –
@bryant

Please consider adding the md5sum [of the datapart of the WAVE file] to the header. Just like FLAC and the newest OptimFROG.

why isn't wavpack more popular?

Reply #74 –
Quote
@bryant

Please consider adding the md5sum [of the datapart of the WAVE file] to the header. Just like FLAC and the newest OptimFROG.

an md5sum of the wav file would make me feel a lot more comfortable archiving with wavpack, so i always know my decompressed files are not corrupt.

Also, is there any APL-like feature for wavpack in sight any time soon?