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

WavPack 4.4 alpha 1 for Windows

I have posted the first alpha version of WavPack 4.4 here. The most significant change is that I have added an option (--optimize-mono) to check for stereo blocks that are in fact mono and encode them more efficiently than previous versions (see this thread). This option should only be used when you believe you might have mono material because the resulting files (even if they are fully stereo) will not be playable on decoders prior to the 4.3 version. Thanks go to Guruboolez and BoraBora for finding this problem.

The only other changes are that I have started the process of splitting the "help" information into a short and long version (--help) and, of course, added the capability of having long option names.

This should really only be significant to a few members, but more general improvements are hopefully on the way... 

WavPack 4.4 alpha 1 for Windows

Reply #1 –
Seeing as I already had the scripts:

http://synthetic-soul.co.uk/comparison/wavpack/

I can do other settings David, if it would be of interest.  Now I have my core scripts, and I've hacked the Yalac ASP pages, it will only take me a few minutes prep to do some more runs.

Code: [Select]
Encoder          Comp. %    Encode    Decode
==========================================
WAVPACK 4.3      38.260%    53.68x    84.07x
WAVPACK 4.4a1    33.299%    60.92x    96.54x

Should the encode and decode times be improved?  I have actually run it twice now as I didn't trust the first results.

FYI: Previous (Run #1) results:

Code: [Select]
Encoder          Comp. %    Encode    Decode
==========================================
WAVPACK 4.3      38.260%    53.80x    84.05x
WAVPACK 4.4a1    33.299%    61.25x    96.22x
I'm on a horse.

WavPack 4.4 alpha 1 for Windows

Reply #2 –
for %%i in (*.wav) do "C:\Program Files\WavPack\wavpack.exe" --optimize-mono -h -m -d "%%i"

File size: 143,354,514 bytes

for %%i in (*.wav) do "C:\Program Files\WavPack\wavpack.exe" -h -m -d "%%i"

File size: 143,354,514 bytes

There is no size different. I am using The Beatles Rubber Soul Mono.

WavPack 4.4 alpha 1 for Windows

Reply #3 –
Am I understanding this right?  The compression is improved by several percent WHILE increasing encode and decode speed?

[edit]
Ah... obviously this is only applicable to mono files.

By the way, have the new MMX optimizations (I think from he-jo) been incorporated into the new version?

WavPack 4.4 alpha 1 for Windows

Reply #4 –
Quote from: Supacon on
Am I understanding this right?  The compression is improved by several percent WHILE increasing encode and decode speed?

[edit]
Ah... obviously this is only applicable to mono files.
My later assumption is that the rate calculation is improved mainly because of the decreased file size.  There are simply less bytes to process.  Again, this is my assumption.

Quote from: Supacon on
By the way, have the new MMX optimizations (I think from he-jo) been incorporated into the new version?
I don't believe so.
I'm on a horse.

WavPack 4.4 alpha 1 for Windows

Reply #5 –
Synthetic Soul:
Wow! Thanks for the testing. It looks like you're seeing exactly what I suspect with "pure" mono files, almost 5%. (BTW, I really like the style of your site; very clean and classy!)

Yes, I also expected the speed to increase. The reason is that when a block is determined to be identical L/R all the way through, it is collapsed to a single channel and encoded that way, so it's really half as much work. Same thing for playback.

I don't think there's any more need for testing "pure" mono files. What I'm a little more worried about is CDs that go in and out of pure stereo, which I think some do.

One issue I have thought of that I don't have the best solution for yet is lossy files. Right now, if you specify a bitrate for a lossy/hybrid encode with this new switch and the track is mono, you will get 1/2 the bitrate specified. The sort-of makes sense and sort-of doesn't. Without the new switch a mono (or "near" mono) track will encode using some of the bits it saves on the "side" channel to encode the "mid" channel better and I think I should try to copy this behavior with the new mode. Otherwise, if a track is switching back and forth there might be audible fluctuations in the noise.

Bottom line is this might not be ready for critical lossy use (although the hybrid lossless mode should be lossless and get the efficiency boost).

Thanks again! 

keytotime:
You see, this is what happens with all my mono CDs! The problem is that they're not really mono. If you encoded that CD in FLAC it probably wouldn't do any better than WavPack. But on the mono tracks that Guruboolez and BoraBora found, FLAC was sometimes doing 4% better than WavPack. Thanks for testing though, it's nice to know it didn't mess anything up while trying.

Supacon:
I have just started looking at the MMX stuff, so nothing's really in there yet. However, I think that this may end up making a decent speed improvement across the board (decoding too).

WavPack 4.4 alpha 1 for Windows

Reply #6 –
Aw thank you. Also thank's for updating the Rockbox codec.

WavPack 4.4 alpha 1 for Windows

Reply #7 –
I've gathered some tracks showing compression unefficiency with WavPack in order to test them with an improved encoder. Now the encoder is out, I don't have access to my main computer  Anyway, thanks for improving WavPack!

I've just ripped one mono-disc (Sony SMK 52 594 Glenn Gould's Goldberg-Variationen + 2 Fuga  ) to test the alpha encoder, but unfortunately, I discovered that it isn't the kind of mono signal that would be useful to test the new WavPack encoder's performance. Nevertheless, the results:
Code: [Select]
WavPack 4.31    -f                       182 676 Kb     539 kbps
WavPack 4.31    -fx5                     178 528 Kb     527 kbps
WavPack 4.4a    -fx5 --optimize-mono     178 515 Kb¹    527 kbps
FLAC 1.1.2      -5                       173 805 Kb     514 kbps
FLAC 1.1.2.1    -8                       173 057 Kb     511 kbps


¹ the alpha-encoded file doesn't contain the 13 329 bytes [source: frontah] of tag datas present inside the first file; hence the small difference.


WavPack is still significantly unefficient compared to FLAC (especially without asymetric preset) - but it can possibly be an exceptional situation: I learned to not draw any conclusion based on one sample (lossy) / album (lossless). More tests are needed, and I'm impatient to do some on the tracks I amassed in the past.
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

WavPack 4.4 alpha 1 for Windows

Reply #8 –
Quote from: guruboolez on
WavPack is still significantly unefficient compared to FLAC (especially without asymetric preset) - but it can possibly be an exceptional situation: I learned to not draw any conclusion based on one sample (lossy) / album (lossless). More tests are needed, and I'm impatient to do some on the tracks I amassed in the past.

Yeah, that album is not triggering the mono detection. The six you sent me before are all getting 5% improvement.

BTW, one of my other goals is to improve the asymmetric performance of the "fast" mode. I think I can significantly reduce the gap between -f and -fx.

Thanks for your testing, Guru!

WavPack 4.4 alpha 1 for Windows

Reply #9 –
Quote from: bryant on
I have just started looking at the MMX stuff, so nothing's really in there yet. However, I think that this may end up making a decent speed improvement across the board (decoding too).

My patch was just a quick hack with the three most used loops (-x modes) converted to MMX, and I only posted it for testing purposes. These weeks I'm very busy , but now that the speed improvements look very promising, I'll convert the remaining three loops in the decorrelation function to MMX too. It's already in my mind, and I'm sure to find some time to implement, test, and release this stuff next weekend. I don't want to promise too much, but at the end I expect a speedup of about 20%-25%.

Thanks to David for this great codec! It's written in a very portable manner and that's why I like it. And this also means that there is still room for more improvements. 

WavPack 4.4 alpha 1 for Windows

Reply #10 –
Hiya Bryant! I ran a quick & dirty test this morning on some of my old mono tests CD and your work looks very promising! I'm really glad to see my codec of choice improved, thanks a lot! 

You'll find a excel sheet here: http://perso.wanadoo.fr/borabora/mono.xls

As you can see, some compression rates were greatly improved and some were unchanged. I wish I could help more but I'm overwhelmed by work (I'm opening a books/records store on wednesday and working 14h/day 7/7). If you wish to work on some samples of these CDs, I can upload them on my FTP but I can't be sure I'll find the time next week. Anyway, thanks again for your work, it's much appreciated!

WavPack 4.4 alpha 1 for Windows

Reply #11 –
to Bryant:

Thanks for new version...though it has no practical value for me since I do not not have mono discs, i still believe that your work is simply astonishing...

I wish you all the best and good luck!..
 

WavPack 4.4 alpha 1 for Windows

Reply #12 –
Quote from: he-jo on
My patch was just a quick hack with the three most used loops (-x modes) converted to MMX, and I only posted it for testing purposes. These weeks I'm very busy , but now that the speed improvements look very promising, I'll convert the remaining three loops in the decorrelation function to MMX too. It's already in my mind, and I'm sure to find some time to implement, test, and release this stuff next weekend. I don't want to promise too much, but at the end I expect a speedup of about 20%-25%.

Now that I looked at this code I think it's very interesting. I haven't quite figured out how it works, but I can tell it's very clever; I really like the new macro for update_weight()!

I'm not sure that handling the other 3 [negative] term cases will get you too much (although you're obviously free to try). They aren't used very much and you have to be a little careful because the left and right channels are not completely independent like in the postive cases.

I am also interested in how decoding might be improved. One nicer thing about decoding is that the sample history is post-processing, so you can skip the samples_AB buffer altogether and simply get the samples from the data you just processed (once you've processed 8 samples, obviously). I took advantage of this in the Rockbox code (www.rockbox.org).

Thanks again for you and wisodev looking into this; I'm sure this will improve WavPack in the long run.


Quote from: BoraBora on
As you can see, some compression rates were greatly improved and some were unchanged. I wish I could help more but I'm overwhelmed by work (I'm opening a books/records store on wednesday and working 14h/day 7/7). If you wish to work on some samples of these CDs, I can upload them on my FTP but I can't be sure I'll find the time next week. Anyway, thanks again for your work, it's much appreciated!

Thanks for providing the updated results! The interesting one is the Bo Diddley. It is obviously suffering from the mono problem (comparing to FLAC) but the option doesn't do anything. My guess is that maybe it's going in and out of "pure" mono so quickly that every block has some mis-matched samples. Since the default block size in "high" mode is 1 second, it might be interesting to try a smaller block size (like 4096) using the new --blocksize switch (when you have time, of course). If that does anything I may force a smaller blocksize with --optimize-mono to ensure that it's an even bigger hack than it is now! 

Anyway, good luck with your new business!