Thanks to those who sent in results for the 24 bit FLAC test I created.
Results were received for Windows, Linux, and Intel Mac. All results
showed the identical poor compression ratio with the given test file.
This indicates that the issue is likely not related to a certain
platform/compiler. I also tested FLAC with various other options like
integer only and turning off ASM optimizations (to see if the problem
code path could be narrowed down), which did result in different output
data, but the compression was slightly worse.
At this point I'm assuming that there is certain 24 bit data signals
which are causing poor performance from FLAC.
The next question becomes:
Is there a compression performance issue with the reference encoder in
relation to 24 bit or does the FLAC format itself have trouble
compressing these signals?
My current thought (or rather hope) is that its an issue with the
reference encoder. Below is a set of other tests I performed on various
24 bit stereo audio samples. As you can see, FLAC often has rather
comparable compression as Wavpack (under 7% or so difference). There
are some cases where this difference reaches 20% though, which seems
like possible candidates exhibiting this issue. Analysis of these FLAC
files showed that most chunks were encoded verbatim.
There is of course the possibility that the Wavpack format is able to
handle these problem audio chunks in a way which FLAC cannot.
I'm not knowledgeable enough in the theory, mathematics or code base of
FLAC to debug this issue, and hope that someone else will put some
effort into discovering what the cause of this is.
Best regards,
Josh Green
Other 24 bit stereo samples tested:
File
Size
Flac Size
Wpack Size
Flac %
Wpack %
Diff %
Bees1_clip01.wav
257324
243159
201094
94.50
78.15
16.35
Bees1_clip02.wav
408620
319382
300742
78.16
73.60
4.56
Bees2_clip01.wav
531500
535266
438290
100.71
82.46
18.25
Bees3_clip01.wav
669740
538943
498508
80.47
74.43
6.04
Bees3_clip02.wav
411692
356050
316122
86.48
76.79
9.70
Bees3_clip03.wav
267308
202738
192450
75.84
72.00
3.85
Bees3_clip04.wav
233516
180798
169204
77.42
72.46
4.96
Bees3_clip05.wav
445484
348487
326398
78.23
73.27
4.96
Bees3_clip06.wav
296492
246837
221402
83.25
74.67
8.58
Bees4_clip01.wav
396332
397719
318000
100.35
80.24
20.11
Bees4_clip02.wav
264236
239811
206392
90.76
78.11
12.65
Bees4_clip03.wav
365612
367556
293120
100.53
80.17
20.36
Cricket01.wav
239660
243255
204224
101.50
85.21
16.29
Cricket02.wav
192812
197026
161418
102.19
83.72
18.47
Crow1.wav
123900
86952
82852
70.18
66.87
3.31
Dog_Howling01.wav
2085524
1692320
1516442
81.15
72.71
8.43
Dog_Howling02.wav
1352012
991368
942016
73.33
69.68
3.65
Dog_Howling03.wav
2574530
2001849
1850906
77.76
71.89
5.86
GrassHopper_clip01.wav
768044
768673
669232
100.08
87.13
12.95
GrassHopper_clip02.wav
646700
638097
564734
98.67
87.33
11.34
GrassHopper_clip03.wav
559148
557699
495702
99.74
88.65
11.09
GrassHopper_clip04.wav
565292
568383
499236
100.55
88.31
12.23
GrassHopper_clip05.wav
1544876
1459159
1283262
94.45
83.07
11.39
Schweine01.wav
483372
337195
333246
69.76
68.94
0.82
Schweine02.wav
4326476
2886941
2877448
66.73
66.51
0.22
SeedPod1.wav
257744
259027
217720
100.50
84.47
16.03
SeedPod2.wav
289580
289343
243170
99.92
83.97
15.94
SeedPod3.wav
278060
273867
234554
98.49
84.35
14.14
Josh (Green), Seems like the longest example in your list is a 15-second file. I would like to see the same problem exhibited in a file that is of a normal length. I have been recording full performances lasting hours, and flac always compresses the files below 70% of the original size. Another thing to note is that "--best --no-padding" will not create a file that is larger than the original. Perhaps the only reason you're seeing the file grow when flac-compressed is that you're allowing the default padding to add to the file size. I am not familiar with WavPack, but perhaps it does not add empty padding for metadata. One of the other volunteers looking at this problem produced a 3- minute track that was supposed to have the same problem, but it ended up compressing quite well ... 58% of the original size. He's looking into why he remembered having problems in the past. If we can't reproduce this problem with normal-sized songs, then perhaps the best solution is to recommend that users simply turn off padding if they need to compress extremely short audio samples. Brian Willoughby Sound Consulting On Apr 2, 2007, at 12:02, Josh Green wrote: Thanks to those who sent in results for the 24 bit FLAC test I created. Results were received for Windows, Linux, and Intel Mac. All results showed the identical poor compression ratio with the given test file. This indicates that the issue is likely not related to a certain platform/compiler. I also tested FLAC with various other options like integer only and turning off ASM optimizations (to see if the problem code path could be narrowed down), which did result in different output data, but the compression was slightly worse.
On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote:> Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. > > Another thing to note is that "--best --no-padding" will not create a > file that is larger than the original. Perhaps the only reason > you're seeing the file grow when flac-compressed is that you're > allowing the default padding to add to the file size. I am not > familiar with WavPack, but perhaps it does not add empty padding for > metadata. > > One of the other volunteers looking at this problem produced a 3- > minute track that was supposed to have the same problem, but it ended > up compressing quite well ... 58% of the original size. He's looking > into why he remembered having problems in the past. > > If we can't reproduce this problem with normal-sized songs, then > perhaps the best solution is to recommend that users simply turn off > padding if they need to compress extremely short audio samples. > > Brian Willoughby > Sound Consulting >Yes, it would be nice to have some longer poor test cases, I'll see if I can come up with something. I've got lots of 24 bit samples I've recorded, but a lot of them contain lots of silence, so I'd expect them to compress well. It seems that generally Wavpack does a little better than FLAC at compressing audio. But that is generally within a rather small margin. 20% margin seems a little large to me though. There may indeed be no problem with the FLAC reference implementation in regards to 24 bit and its just having trouble compressing certain types of audio that Wavpack does much better on. But I think its worth having an understanding of what exactly is going on, in case there is something that can be improved in the FLAC reference implementation. I'll see about finding some larger poor compressing examples. Josh Green