Hey everyone, I'm completely new to the forums but I do come here semi-regularly to read around when I need help with audio. I'm also a massive geek, so when I saw the news about LossyWAV reaching the 1.0 milestone, I decided to run a test to see how well it performs in conjunction with FLAC.

The album I tested was The Slip by Nine Inch Nails. It's a free download so anyone can check my results if they wish. I tested both the HD (96/24) and CD (44.1/16) quality versions. I downloaded the HD version as WAV and the CD version as FLAC which I converted to WAV before my tests. Yes I know there's a FLAC download for the HD audio now, but there wasn't on the day of the release. I did not use the keep-foreign-metadata flag when encoding to FLAC because I didn't know about it, but since the "FACT" chunk LossyWAV inserts is only about 100 bytes (a little less than 1KB for the whole album), it's of little consequence in a compression comparison.

Sadly I can't attach files to posts, so here's a link to an Excel file on my webspace:
LossyWAV FLAC.xls

Or if you prefer Open Office, here's a Calc file:
LossyWAV FLAC.ods

I included some idealised figures for 320 Kbps and 192 Kbps audio files to represent lossy formats, though I didn't actually compress to MP3 or AAC to find any true figures.

I hope this is of some use, but if not, at least I find it interesting ... because I'm a geek who has a number fetish. If anyone wants me to I can also make a spread sheet that gives a breakdown of the numbers on a song by song basis rather than just for the whole album.

Your lossyWAV + FLAC bitrates are unusally high. It may happen with this specific album (lossyWAV is pure VBR!), but please make sure you use a blocksize of 512 when using FLAC.

Moreover it would be interesting to know what lossyWAV version you used because due to default noiseshaping of the recent versions bitrate grew a little bit.

I downloaded the album (CD-version encoded with FLAC) and encoded it using lossyWAV 1.0.1q (that is: with defaulted noiseshaping) --standard (which is -q 5), followed by FLAC, and the average bitrate of the album is 475 kbps (according to foobar2000) as opposed to the 531 kbps of your result.
My FLAC parameters are -3 -e -m -r 2 -f -b 512, but the difference should be negligible when using -8 -b 512 (which yields a very tiny decrease in bitrate compared to my setting but is a bit slower) or -5 -b 512 (which yields a very tiny increase in bitrate but is a bit faster).

So using -b 512 with FLAC is pretty essential.
Maybe you can't set the FLAC blocksize with the FLAC frontend tool. Encoding to lossyWAV + FLAC in 1 step using foobar2000 and the lossyWAV description given in the Wiki here is an alternative.

I love the moderators! (Edit:So Much!)

Oh be nice!

He gets points in my book for being interested, for having a cool username, and for illustrating the obvious and disasterous mistake that lots of people will probably make.

So, we can learn that this needs to go right at the top of the wiki, instructions, FAQ, download page etc in big writing! "Make sure you set the blocksize in your lossless codec to match that of lossyWAV (instructions below) or the bitrate will increase (but the quality won't!)"

Cheers,
David.

sauvage78, so this is how you welcome a first poster to the forum? Go back to your Counter Strike.

2Bdecided, hail to the hero who stands up to the tyranny that is sauvage! I hear he drinks the blood of children you know. Now what can I spend my points on?

halb27, I wasn't aware of the blocksize used by LossyWAV, nor that the FLAC encoder had to be set to the same value, so thank-you for pointing that out. I have re-encoded all of the test files using a blocksize of 512 from the command line (FLAC Frontend doesn't allow for much tweaking of settings).

For the test files I used -8 -V -b 512 as suggested, I also tried adding -r 8 -l 32. Unfortunately that only saved 600 bytes from the size of the full (HD quality) album while adding significantly to the compression time.

I also tried encoding with Flake, but there was no gain in compression at all, in fact there was actually a loss in compression.

I have uploaded my new results. The sheets are in the same place as last time but here's a re-link all the same. MS Office Excel file and ODF Spreadsheet file.

By using -8 (and therefore -l 12 -r 6), I was able to gain a slight increase in compression over the command you used, just as you said I would, the average bitrate now being 468 Kbps for LossyWAV -5. That works out to be a 2.2 MiB saving over the CD quality album.

Now your results are well in the range of what can be expected.
As for the addtional FLAC parameters besides -b 512: don't care too much about it. If encoding time doesn't hurt you: just use -8. The fact that your bitrate is a little bit lower than mine is due to the fact that you used lossyWAV 1.0.0b which doesn't use default noise shaping IIRC. With the identical lossyWAV version the difference is lower and usually not worth talking about. You may want to try lossyWAV 1.0.1q --standard + FLAC -8. Guess you will save perhaps 2 kbps, if at all, compared to my result.

EDITED: I wrote '--extreme' first (cause that's what I usually do), but here it's about --standard.

Thanks for taking the time to carry out these analyses - the numbers are indeed interesting. One minor point, when compressing losslessly to FLAC I think the fairest thing to do is to leave the "-b 512" part of the command line out as it gives bigger FLAC file sizes for the lossless originals.

That said, it seems that the wiki article does indeed require to be tweaked to make it clear that the optimal lossless encoding will almost certainly be when using a lossless codec blocksize which is the same as that of lossyWAV (default = 512 samples).

[edit] Wiki article duly modified. [/edit]

Yeah, I left the -b 512 out for the original lossless encodings, encoded at the default -b 4096 for those.

Is it possible to manually change the blocksize for LossyWAV? I checked LossyWAV -h and there doesn't seem to be a switch for it, but it would be interesting to see if a bigger blocksize might help towards a more compressed final FLAC file even if the lossy process is more restrained.

At beta 1.0.1o, the -b,--blocksize parameter was (re)introduced with valid values: 512, 1024, 2048 & 4096. This is visible in --longhelp.

There's not much use in it. The lossyWAV blocksize is rather small for a good reason: let the number of bits removed adapt well to the various musical situations of a track.
Look at 2 512 sample blocks A and B, with 8 bits removed in block A and 3 bits removed in block B.
If lossyWAV would use a blocksize of 1024, the 1024 sample block which covers the beforementioned 2*512 samples would only have 3 bits removed. You always get the worse number of bits removed for the larger block.
So you don't make best use of the lossyWAV principle.
The other side is the FLAC efficiency which is best with a larger FLAC blocksize within a comparison situation where lossyWAV bits removed are identical. In cases that lossyWAV's bits removed don't vary much from a 512 sample block to the next a higher FLAC blocksize can yield a better overall compression. It should always be a multiple of 512 however. But it's just the FLAC blocksize which can have an effect - there's no sense in changing the lossyWAV blocksize.

Anyway the situations where a larger FLAC blocksize is favorable are so rare that there's not much use in playing around with it. The rare situations I ran upon where of a kind that lossless encodings were very efficient (especially when using TAK or wvPack instead of FLAC), and in these cases I just used the lossless encodings. The typical musical situation for this is a quiet solo instrument. With pop or rock music of the various genres chance is zero in a practical sense that a larger FLAC blocksize than 512 has an advantage.