* segfaults when overwriting* doesn't exit gracefully* still has win32 header* i'd like to see a library + frontend duo (i.e. frontend does encode/decode)--> library allows for ease of plugins/etc.

GREAT WORK ROBUX4! Thanx for your efforts! *cough*monkeysaudio*cough*

later

You know what ? I'm already running my main compiter with Debian and I'm going to investigate on this.

What is this "win32 header thing" ?

About the library, I'll work on it under Windows first to make room for a DirectShow filter (for decoding from Matroska). The linux version will come afterward.

What about MonkeyAudio ? The linux support doesn't exist ? I can have a look too. And at OptimFrog too. That would make the best 4 lossless codec available which is great. Also note that TTA is now hosted on CoreCodec (maybe WavPack could be hosted there too for the CVS) and so I can probably port that too...

I see WavPack author has yet to discover the idea of file reader callbacks - for reference, Monkey, Flac and OptimFrog all support them.There will be no updated foobar2000 component (at least not from us) because making new WavPack decoder that isn't broken (no unicode, no streaming, no archive support) would require entire library to be modified to use file access callbacks instead of filenames and I have better things to do in my life than hacking wvunpack source once again.

Note that, as the fragments are from the middle of the songs, they are quite loud, without the quieter parts of the beginNing and the end. Thus, the compression ratio is worse than what can be reached with the whole file; or, if you prefer, representative of the "worst case" scenario.

Also note that for the fastest compression and decompression modes the HDD can be the speed limitation factor. In this test a virtual RAM disk was created, but in some modes it's not enough.

OK, as promised some Wavpack lossy listening test results for those who care.

Just to be sure, I grabbed the latest version linked on HA, ie beta2.zip, and got the following results.

First, I took the kraftwerk1, Waiting, queen - another one bites the dust, rushing and porcelain samples from ff123's site (thanks ff123!), decoded the flacs into wavs, and then encoded them with the beta using -hb256, -hb256x6, -b320, -hb320, -hb320x6. I didn't record times, but each encode was lightning quick except the x6 ones, which were painfully slow. (ie the non x settings took a matter of seconds for all the samples, where as each x6 encode took minutes)

I chose the above samples as I felt like a change from the samples I've used in the past with Wavpack 3.97.

kraftwerk1:hb256 - not bad quality, but easy to ABX 10/10. Slight change detectable in the background fuzz. Also slight distortion in the three notes that come in 2.4-3.8 secs. Not really noticeable except in an ABX situation.hb256x6 - very little difference to hb256 case. ABX 10/10b320 - no real difference in background fuzz problem compared to hb256. Distortion on the three notes in 2.4 - 3.8 secs gone. ABX 10/10hb320 - can not ABX consistently. Sometimes I think I can hear a hint of the fuzz, but can't consistently pick it so it is statistically transparent. ABX scores were ever better than 7/10 and were usually 5/10.

waiting:hb256 - some slight noise around the vocals in the opening, but damn it's hard to pick every time. I can ABX it, but only consistently getting 8/10.hb256x6 - can't ABX. Transparent. Blah!Relatively noisy or busy samples like this one are good for Wavpack lossy to hide its sins within. It's when you have solo instruments and gaps in the music that any added noise can become more obvious.

Another one bites the dust:hb256 - can ABX 10/10, but must concentrate, slight change in background noise in the recording, plus a hint of "dustiness" around the percussion.hb256x6 - can still ABX, but it is much harder, and failed first attempt (6/10), but then got it the next couple trials in a row. (10/10 and 10/10)b320 - can not ABX consistently. Sometimes I think I can hear a slight change in the b/g noise, but not consistently. Effectively transparent. hb320 - transparent.

porcelain:hb256 - Can ABX (10/10), slight changes in the noise/distortion that is part of the opening samples within the music.b320 - still there, much much more subtle.hb320 - got me, it's transparent.

rushing:hb256 - at 4.5 secs in where some chords kick in, there is a slight but noticeable change in noise around the chords. (10/10)hb256x6 - no change or improvement from hb256. (10/10)b320 - bugger, it's transparent. (6/10, 6/10 and 5/10)

So in summary? hb256 is not normally going to be transparent, but it is still very good. None of these samples were disasters at 256 kbit. I wonder if Sony's new ATRAC 256kbit is this good? (I have my doubts, but I haven't tested it yet.)

hb256x6 sometimes makes some difference, but it is not consistent, and should not be counted on.

b320 is damn good and lightning quick to encode/decode. I personally would not use it as my default, as I prefer the extra security of hb320, but b320 will be transparent a lot of the time for most samples I believe.

hb320 is my choice for now. It is still quite quick, and seems to work very well at removing those little niggly changes in the noise to my ears. I can't comment on the benefits of hb320x6, as the hb320 has been transparent on the samples I have played with so far.

From the results above, you can see that I didn't get to even listen to the hb320x6 samples in this test, as transparency was reached in each case. Besides, life is too short!

I haven't extensively tested the new Wavpack 4 lossy beta for transcoding performance, but I can not think of any reason to suspect it will have changed from the previous versions. I have started transpferring some parts of my collection to Wavpack 4 beta 2, and have not stumbled across any problem transcodes to ATRAC on my minidisc yet.

Played with it briefly, saw it was no joy in FB2k 0.8 and dropped it from my radar again for the moment. I did try to play a test file in WA 5.03 on the crashbox and got no joy there either even after copying the .DLL to the appropiate diectory; that must have been some snafu on my part or just due to my use of WA as a player for less than 5 minutes a month.

First of all, thanks to everyone who has tried out the new WavPack; especially those who posted results! I really appreciate it...

robUx4:Wow! Thanks for the quick turnaround on the Linux port! I am interested if the big-endian stuff goes as easily...

You don't need my permission to work on a libwv library, but if there's something I can do to help let me know. Almost everything does already happen in memory (except the legacy stuff which obviously comes out), so it should be pretty straightforward. I am going to reorganize the way packing works to use a library interface the way unpacking works now. Also, I need to make unpacking more robust, but that should not affect the interface.

naturfreak:I think there is a problem with termination (although I'm using Win2K sp4 also and haven't seen it). I got a report from Jason (of shntools) that he is seeing this also in some situations and I will be looking into it. Thanks.

glauco:Thanks, but you forgot to mention the multichannel and floating-point support!

BTW, the "quality" mode won't be back real fast, but I have not given up on it. Also, all the hooks for it are in there so I probably won't have to break decoders when I have something.

FireStarter, etc.:I am putting together a foorbar plugin now, should be just a few days away...

NRAninja, Tec9SD:To tell you the truth, I haven't really studied the cuesheet issue enough to know what I want to do yet. I do have one question though. What is the primary purpose/advantage of using a cuesheet with a single compressed audio file for a whole album? Is it the convenience of a single file, or is just the ability to exactly restore (and burn) the album image? What if the exact album image could be ensured even though the tracks were in separate files? Just trying to get my head around this issue...

anyone:If you have any hardware "connections" this is the time to start. I think that lossless hardware playback is fine, but I believe that WavPack's hybrid mode and portable playback could be killer combo. (I'd buy one, anyway).

I, too, would like a way to perform the replaygain calculations using the encoder, rather than through the matroska container. I automate a lot of encoding and transcoding processes in Perl, and without this sort of functionality, I don't know how I'll be able to use the format as much as I'd like to.

The cuesheet and single file is a combination of convenience and being able to recreate the original layout of the cd. There's really two schools of thought in the single file vs. multiple file issue. Personally, I like separate files, but that doesn't mean that single file has no merit. On the contrary, single file is cleaner, but has the issue of being able to index into that file to any track position. APL functionality in WAVPACK would allow you to satisfy both schools.

The single file image and separate tracks issue is more of a personal preference rather than one way being 'better' than the other. It only makes a real difference when a disc has one of those hidden tracks before track 1. Ripping to an image will extract the hidden track. If you rip to separate tracks, the hidden part has to be ripped with a separate step. Single file ripping is less convenient for things like tagging since you can't really get track # and track title tags, but that doesn't make a difference if you use the cue in foobar2000 or if you have APL links like monkey's audio.

Here it is a little summary of WavPack 4.0b2 using hb256. According to what den reported earlier, hb256 (around 256 Kb, high compression) is not generally transparent (at least for his ears). As a curiosity, I was working again now at some abandoned branch of OFS - OFSX (the OFS compressed files can be downloaded from http://losslessaudiocompression.com/audiotest).

The interesting fact is that the experimental files are *decodable* with any currently available OFS decoder.

Den: If you can ABX them, it would be great, so I can enhance the encoder if it works well, or throw it back into "trash" [after I finish my diploma thesis ].

For each file, the effective bitrate was shown also. OFSX was used with --bitrate 256, exactly like the 4.509 encoder

Here it is a little summary of WavPack 4.0b2 using hb256. According to what den reported earlier, hb256 (around 256 Kb, high compression) is not generally transparent (at least for his ears). As a curiosity, I was working again now at some abandoned branch of OFS - OFSX (the OFS compressed files can be downloaded from http://losslessaudiocompression.com/audiotest).

The interesting fact is that the experimental files are *decodable* with any currently available OFS decoder.

I'll give it a go. I've downloaded your samples already (after removing the extra bracket in your link above), but when I go to your downloads page, and click on the decoder to download, Internet Exploder tries to download the .php file as html rather than the decoder itself.

I'll grab the decoder again when I get back home and try the samples. Please bear with me as I have a few other things to get out of the way first, so it will probably happen later this week.

Edit: Got that decoder now, and the files. Will get back on this later this week.

The single file image and separate tracks issue is more of a personal preference rather than one way being 'better' than the other.

I largely agree. Although, for organizational issues, and data transfer, it is much more convenient to have single file. For instance, if you have 100 albums on your harddrive. Using the multi-file approach, if each CD had 10 tracks, and then you also had the booklet scanned in, you could easily have 2000 files to deal with. This makes it difficult when trying to copy albums around to different locations or locate information. Whereas the single file approach would give you 100 files.

On the flip side, if you only want to copy a single track, the single file approach means you must re-encode that track.

QUOTE

Single file ripping is less convenient for things like tagging since you can't really get track # and track title tags,

This works fine in Matroska.

QUOTE (Cerebus @ May 10 2004, 03:12 PM)

single file is cleaner, but has the issue of being able to index into that file to any track position.

kraftwerk1:264 Kb WV hb256 - ABX 10/10259 Kb OFSX b256 - ABX 10/10In 2.4 - 3.4 seconds there are three tones (which I used to ABX Wavpack) and a "bwarp" type tone before. With the OFSX file, the edges of the "bwarp" sound are slightly different.

waiting:270 Kb WV hb256 - ABX 8/10256 Kb OFSX b256 - ABX 10/10In 11.1 - 16.2 some of the edges to the noise are not quite the same. The slight difference I could hear around the vocals in hb256 Wavpack are not present here. They disappear with hb256x6 also if you read above.

Another one bites the dust:259 Kb WV hb256 - ABX 10/10265 Kb OFSX b256 - ABX 10/10Slight changes in the noise in the percussion. "Dustiness" is not so noticeable here.

porcelain:267 Kb WV hb256 - ABX 10/10256 Kb OFSX b256 - ABX 10/10Again, the noise in the samples that come in is not quite the same, but damn close.

OK, the above might read like a negative set of results, but it shouldn't be read this way. I had to really pore over each sample to find differences to ABX, and it took more time to find something compared to the Wavpack equivalent hb256 samples. I haven't conducted a close comparison between OFSX and Wavpack 4, but the OFSX samples were generally "closer to transparency". I achieved the 10/10 ABX results more because I knew what to listen for after playing with Wavpack 4. If hb256x6 is used with Wavpack 4 instead, there is still some difference between the two, but the gap is often closer.

The "artifacts" I'm hearing are barely there, and are best described as minor changes in noise in the background in most cases. If you were to listen to the above OFSX versions by themselves, you would probably miss it. It only becomes vaguely noticeable in a focussed ABX situation with short samples.

If I had to pick one of these encoders at this bitrate based on these samples, purely for quality it would be OFSX, but we don't know how long these samples took to encode. If Wavpack is given plenty of time to encode (ie hb256x6) it gets quite close.

I wouldn't trash your encoder Florin.

I also think that both you and David need to be congratulated with these latest efforts. At 256ish kbit, these encoders are now seriously in the same league as the other popular lossy encoders.

waiting:270 Kb WV hb256 - ABX 8/10256 Kb OFSX b256 - ABX 10/10In 11.1 - 16.2 some of the edges to the noise are not quite the same. The slight difference I could hear around the vocals in hb256 Wavpack are not present here. They disappear with hb256x6 also if you read above.

...does not mean that Wavpack was better than OFSX for this sample. The lower score for Wavpack is just a repeat of my first trial results. If I was to listen to Waiting again now with Wavpack it would also be 10/10 as I know what to listen for.

My first attempt at an updated Foobar2000 plugin has now been added to the beta2 zip package (link above). It seems to work pretty well and plays all the new WavPack formats including multichannel and 32-bit floats. It also reads the .wvc file when present and plays all old WavPack files.

Many thanks to Peter and Case (and anyone else who previously worked on the WavPack Foobar plugin). I didn't realize how much work was involved until I "hacked" it myself.

Thanks for the foobar component. It works fine (so far...). Just one suggestion: maybe there should be a warning/error report in the console when a decoding error occurs (with a corrupt Wavpack file).

I like it very much that Wavpack 4 can keep decoding when errors occur. But could you make it so that the sound is muted when playing the corrupt samples? The noise I hear now is bad for my ears and my speakers