Comparison : 24bit/192KHz/stereo FLAC vs. APE, How can it be ? Options

[foorious]

Hi everybody,

I've just made a small comparison between Monkey's Audio 3.99 (Extra High Compression) and FLAC 1.21 (Compression level 8 ), using 24bit/192KHz/stereo files (the files were generated from a vinyl rip).

Of course I expected APE to perform slightly better than FLAC, like it usually does for 16bit/44KHz/stereo files (2-3%, maybe even 5%)... but I didn't really expect this !



Take a look at all the file sizes : we're talking about 20% difference here ! The total file size is 1,53 Go for APE vs. 1,88 Go for FLAC.

So I don't understand. I'm a genuine FLAC enthusiast (all my files are FLAC), but... how can it be ? Is there something wrong here ? Can we do something to improve all the FLAC file sizes ?

Thanks in advance for your explanation.

[viniciusferrao]

MonkeyAudio do not support 192kHz! :confused:

Moderation: Removed unnecessary quote.

This post has been edited by greynol: Jul 26 2008, 03:04

[Axon]

My understanding is that the lowest 8-12 bits of a 24-bit recording are pretty much white noise (as LossyWAV has so handily illustrated). Every lossless codec handles pure white noise equally bad, but they handle low-level white noise considerably differently. APE's encoding tends to do considerably better.

[Curtor]

MonkeyAudio do not support 192kHz! :confused:

From the Monkey's Audio FAQ:

Exactly what kind of files does MAC support?
For now, the list goes like this: (but it'll hopefully grow as time goes on)
Format: PCM WAVE (standard windows .wav file)
Sample Rate: anything
Bit depth: 8 or 16 or 24
Channels: 1 or 2
As a note, MAC has been tuned primarily for 44khz, 16-bit stereo music, since this is what today's CDs are.

192kHz fits into the "anything" category.

[TBeck]

Take a look at all the file sizes : we're talking about 20% difference here ! The total file size is 1,53 Go for APE vs. 1,88 Go for FLAC.

Not really surprising for me...

From earlier evaluations of some 44 Khz files i knew, that FLAC has some weaknesses when it has to deal with low passed files. Well, because 192 Khz audio recordings usually don't contain much frequencies above 20 Khz, they could also be considered as low passed. Therefore i expected to see FLAC perform worse on 192 KHz samples.

Out of interest i unlocked TAK support for 192 KHz files (the last official release only supports up to 96 KHz). Since i don't have any 192 KHz recordings i upsampled the 13 files of my 24-bit/96 KHz test corpus (Cooledit with maximum quality settings).

Results:

CODE

FLAC 1.2.1
  -8               46.20
  
Monkey's Audio 3.99
  High             38.09
  Extra            35.52
  Insane           35.76

OptimFrog 4.600ex
  --ExtraNew       29.98

TAK 1.0.4 (with 192 Khz support unlocked )
  -p0              45.15
  -p1              37.93
  -p3m             34.91
  
TAK 2.0 (Developer version)
  -p3m             31.94
  
TTA 3.4
  Default          39.41
    
WavPack 4.41
  -hhx3            44.84
  -hhx4            34.01
  -hhx6            33.40

Quite similar to your findings...

So I don't understand. I'm a genuine FLAC enthusiast (all my files are FLAC), but... how can it be ? Is there something wrong here ? Can we do something to improve all the FLAC file sizes ?

I think the resolution/accuracy of FLAC's predictor coefficients isn't sufficient to deal with such files. I don't know, if it's possible to increase the accuracy without breaking the FLAC format.

Thomas

edit: Results for Monkey's Audio added.
edit 2: Updated the results for TAK -p0 to -p2. Better compression because of a quick optimization of some parameter estimation in the encoder.
edit 3: Results for WavPack -hhx3 added.
edit 4: Results for WavPack -hhx4 and -hhx6 added.
edit 5: Results for TAK 2.0 (Alpha, unreleased!) added.
edit 6: Results for TTA added.
edit 7: Results for OptimFrog added. Results for TAK 2.0 updated.

This post has been edited by TBeck: Jul 31 2008, 12:57

[foorious]

Thanks everyone for all your interesting answers.

Well, so it looks that FLAC isn't really well-suited at the moment for low-passed files, thus for 96 and 192 KHz files. Considering the results, I think it will be better for me to stick with FLAC for 16/44 files, but to switch to another format for 24/96 and 24/192 files. I don't like the idea of handling two different lossless formats in my collection, but the gap is huge, and I don't see any reason for losing almost 350 MB of disk space for a single album.

I secretly hope Josh Coalson has some ideas in store for improving FLAC's handling of HD audio files. We'll see !

Oh, one last question : in your opinion, is this issue related only to the frequency (96, 192 KHz) or also to the bits per sample ? In other words, would FLAC perform much better with 24bit/48KHz files than it does with 24bit/192KHz files ?

This post has been edited by foorious: Jul 27 2008, 16:41

[Nick.C]

My understanding is that the lowest 8-12 bits of a 24-bit recording are pretty much white noise (as LossyWAV has so handily illustrated). Every lossless codec handles pure white noise equally bad, but they handle low-level white noise considerably differently. APE's encoding tends to do considerably better.

Using two of the freely available Nine Inch Nails - The Slip downloads, 16/44.1 and 24/96, it is interesting to note the following:

24/96 lossless (FLAC -5) : 2954 kbit/s (926MiB); lossyWAV --standard|FLAC -5: 787 kbit/s (247MiB)
16/44.1 lossless (FLAC -5) : 637 kbit/s (200MiB); lossyWAV --standard|FLAC -5: 476 kbit/s (149MiB)

This post has been edited by Nick.C: Jul 27 2008, 17:23

[Dynamic]

Oh, one last question : in your opinion, is this issue related only to the frequency (96, 192 KHz) or also to the bits per sample ? In other words, would FLAC perform much better with 24bit/48KHz files than it does with 24bit/192KHz files ?

In conjunction with NickC's results, perhaps resampling (fb2k/Resampler) to 44.1 kHz and/or 48 kHz in the Convert DSP while retaining 24-bit output would answer that, and offer comparison between 16/44.1 and 24/44.1 when processed through lossyWAV (though it isn't certain the 16/44.1 is the same as a straight downconversion from the 24/96 files)

[TBeck]

Oh, one last question : in your opinion, is this issue related only to the frequency (96, 192 KHz) or also to the bits per sample ? In other words, would FLAC perform much better with 24bit/48KHz files than it does with 24bit/192KHz files ?

Yes, it does. The problem with the limted predictor coefficients accuracy is rarely an issue up to 96 KHz.

[Nick.C]

In conjunction with NickC's results, perhaps resampling (fb2k/Resampler) to 44.1 kHz and/or 48 kHz in the Convert DSP while retaining 24-bit output would answer that, and offer comparison between 16/44.1 and 24/44.1 when processed through lossyWAV (though it isn't certain the 16/44.1 is the same as a straight downconversion from the 24/96 files)

Taking onboard your comment regarding whether the 16/44.1 is a straight downconversion of the 24/96, I used the SSRC dsp plugin (ultra mode) in foobar2000 to resample the 24/96 version down to 48kHz and 44.1kHz and got the following:

24/96 lossless FLAC -5: 2954 kbit/s (926MiB); lossyWAV --standard|FLAC -5: 787 kbit/s (246MiB);
24/48 lossless FLAC -5: 1598 kbit/s (501MiB); lossyWAV --standard|FLAC -5: 517 kbit/s (162MiB);
24/44.1 lossless FLAC -5: 1489 kbit/s (466MiB); lossyWAV --standard|FLAC -5: 498 kbit/s (156MiB);

Also, I changed the bitdepth in foobar2000 and dithered the 24/96 version to 16/96 and got:

16/96 lossless FLAC -5: 1421 kbit/s (445MiB); lossyWAV --standard|FLAC -5: 776 kbit/s (243MiB);

This post has been edited by Nick.C: Jul 27 2008, 20:40

[GeSomeone]

24/44.1 lossless FLAC -5: 1489 kbit/s (466MiB); lossyWAV --standard|FLAC -5: 498 kbit/s (156MiB);

16/96 lossless FLAC -5: 1421 kbit/s (445MiB); lossyWAV --standard|FLAC -5: 776 kbit/s (243MiB);

Seems to me that FLAC has a "weakness" with compressing 24bit files (though I never have bothered with 192kHz). If you're looking for another codec (besides the mentioned Monkey or TAK), wavPack does better with 24bit files than FLAC too.

This post has been edited by GeSomeone: Aug 11 2008, 22:15

[DARcode]

24/44.1 lossless FLAC -5: 1489 kbit/s (466MiB); lossyWAV --standard|FLAC -5: 498 kbit/s (156MiB);

16/96 lossless FLAC -5: 1421 kbit/s (445MiB); lossyWAV --standard|FLAC -5: 776 kbit/s (243MiB);

Seems to me that FLAC has a "weakness" with compressing 24bit files (though I never have bothered with 192kHz). If you're looking for another codec (besides the mentioned Monkey or TAK), wavPack does better with 24bit files then FLAC too.

Yup, from the features listed on the WavPack main page:

• Compatible with virtually all PCM audio formats including 8, 16, 24, and 32-bit ints; 32-bit floats; mono, stereo, and multichannel; sampling rates from 6 to 192 kHz (and non-standard rates)

[pawelq]

From the Monkey's Audio FAQ:


Sample Rate: anything

This must be a lie. You can't have "anything" in a digital computer with finite memory.

[Enig123]

I think "anything" here just means no particular restrictions.

[pdq]

If you treat the data as simply a series of values and compress them accordingly then it makes no difference at what sample rate you play them back. It only matters that the desired platback sample rate can be expressed to the playing device. I assume the limitation here is how this value is encoded in a WAV file.

[TBeck]

If you're looking for another codec (besides the mentioned Monkey or TAK), wavPack does better with 24bit files then FLAC too.

Well, i have added the result for WavPack -hhx3 to my comparison above. It too seems to be less efficient with 192 KHz/ 24 Bit, only slightly better than FLAC. At least with my sample set.

This post has been edited by TBeck: Jul 28 2008, 18:04

[SebastianG]

This is in response to the original question.

FLAC's problem (not the format's but the current reference encoder's problem) might be the suboptimal quantization of LP coefficients. In case of such high sampling rates and signals where there's almost nothing above 20 kHz the optimal LP filter's magnitude response is pretty far from being flat which implies that simple per-sample quantization of the LP coefficients may lead to large spectral distortions (= large discrepancy between calculated and quantized filter).

Whether choosing a better quantization method really makes a big difference needs to be tested. If anyone is willing to try here's what needs to be done:

• Instead of the Levinson-Durbin algorithm (which solves a linear equation system A x = y with A being a Toeplitz and positive definite matrix) use a Cholesky factorization of A: A = L L^T where L is a lower triangular matrix.
• solve for 'b' in L b = y in high accuracy (preferably floating point). Solving triangular systems is fairly easy: you can compute each component after another.
• solve for 'x' in L^T x = scale * b where 'scale' is the LP coefficient scaling and the coefficients of 'x' are rounded to the nearest integer immediately after such a coefficient has been computed so this quantized coefficient is used during computation of the remaining coefficients.

'x' will contain the quantized LP coefficients. Merging quantization with the last "triangular solver" will reduce the spectral distortions. To go one step further (optimal set of quantized coefficients for a given filter order and 'scale' value) find 'x' with integer coefficients that minimizes ||1/scale*L^T*x-b||. This is not trivial but possible (lattice vector quantization). How quantization is done currently in FLAC is equivalent to the partition 'C' in the following picture. The one I described is equivalent to partition 'B' and partition 'A' is the one that leads to the optimal solution -- the more sphere-like the better.

(image taken from this paper, the hexagonal lattice is just an example for the lattice defined by the matrix L.)

Also, it might be a good idea to check whether the current heuristic for choosing the LP coefficient accuracy (scale) could be improved for the case "24 bit + high sampling rate". In this regard I'd like to mention that the Levinson-Durbin algorithm has the advantage that it estimates the sum of squared prediction errors. LP coefficient quantization simply adds ||1/scale*L^T*x-b||^2 to this estimate which could help choosing the right scale factor for the LP coefficients.

Cheers,
SG

edit: fixed bug in above paragraphs (I mixed up L and L^T)

This post has been edited by SebastianG: Jul 30 2008, 10:54

[Dynamic]

Seems to me that FLAC has a "weakness" with compressing 24bit files (though I never have bothered with 192kHz). If you're looking for another codec (besides the mentioned Monkey or TAK), wavPack does better with 24bit files then FLAC too.

I happened to have conducted some tests yesterday, as yet unpublished, with reference to lossyWAV and clipping. Here's a preview of some tests of a fairly loudly mastered 2005 album, Keane's Hopes And Fears (Album Gain -9.87 dB) with all metadata stripped away (encoded with wavpack -hm or the recommended -hm --block-size 512 --merge-blocks in the case of lossyWAV processed files)

Duration: 50:37.120 (133936992 samples)

Filesize Filename
361,738,994 16bitlossless.wv (952kbps)
361,756,956 24bitpadded.wv (952kbps)

which shows Wavpack handles the same 16-bit data marginally better when padded with zeroes to 24-bit, surprisingly, but essentially the same overall bitrate.

180,156,448 16bitStd.lossy.wv (474kbps)
179,583,978 24bitStd.lossy.wv (473kbps)
179,472,308 24bitStdScale0.5.lossy.wv (472kbps)

This shows the same with lossyWAV -standard processing, and the --scale 0.5 version eliminates any potential clipping without losing any original data (because when scaled it originally occupied only bits 7 to 22, with bit 23 as headroom), thus allowing lossyWAV to reduce bit-depth unimpeded by clipping prevention.

[bryant]

If you're looking for another codec (besides the mentioned Monkey or TAK), wavPack does better with 24bit files then FLAC too.

Well, i have added the result for WavPack -hhx3 to my comparison above. It too seems to be less efficient with 192 KHz/ 24 Bit, only slightly better than FLAC. At least with my sample set.

Thanks for trying out WavPack! Since we're talking about non-standard files here, I think that -hhx4 (or higher) would be a much better choice (even though it's much slower). The -x values from 1-3 use pre-calculated filters while values from 4-6 generate custom filters.

[TBeck]

Thanks for trying out WavPack! Since we're talking about non-standard files here, I think that -hhx4 (or higher) would be a much better choice (even though it's much slower). The -x values from 1-3 use pre-calculated filters while values from 4-6 generate custom filters.

I have added the results for -hhx4 and -hhx6 to my comparison above. And the winner is... WavPack!

Seems as if i have to tune TAK still a bit more for 192 Khz.

This post has been edited by TBeck: Jul 29 2008, 20:02

[TBeck]

Seems as if i have to tune TAK still a bit more for 192 Khz.

Results for TAK 2.0 Alpha added to the comparison.

It's far away from a release, but already performing quite well.

[bryant]

Thanks for trying out WavPack! Since we're talking about non-standard files here, I think that -hhx4 (or higher) would be a much better choice (even though it's much slower). The -x values from 1-3 use pre-calculated filters while values from 4-6 generate custom filters.

I have added the results for -hhx4 and -hhx6 to my comparison above. And the winner is... WavPack!

Seems as if i have to tune TAK still a bit more for 192 Khz.

Wow! I expected an improvement, but I sure didn't expect over 10%!

So, for almost 2 hours WavPack beat TAK ... hehe, that's cool.

[vpa]

Could you test TTA too?
It's very quick but gives usually better results than FLAC -8 (at least with 44.1 and 48 kHz material).

[TBeck]

Could you test TTA too?
It's very quick but gives usually better results than FLAC -8 (at least with 44.1 and 48 kHz material).

Done.

But please, i don't want to make this look like an exhaustive or representative codec comparison. I would need more and especially real 192 KHz files for this purpose.

[TBeck]

So, for almost 2 hours WavPack beat TAK ... hehe, that's cool.

And for almost one day TAK 2.0 was on the top: Optimfrog added to the comparison above.