Has anyone done a comparison of lossless codecs' performance on 24-bit audio?
I'm used to all lossless codecs performing about the same, but for 24-bit, this clearly isn't so; WavPack seems to work a lot better than FLAC, even though they're basically tied on CD audio.
Has anyone done a comparison of lossless codecs' performance on 24-bit audio?
No, please go ahead
I suspect that TBeck has some figures, following his TAK development and testing.
I'm not sure how large the corpus is.
Any ideas for test material? I produce music, and nearly all of my 24-bit files are mixes-in-progress and stuff... very little "end product" in 24-bit. I could download some lossless DVD-A rips and 24/96 vinyl recordings, I suppose.
If the source was recorded, then it passed through an ADC, and ADCs generally record noise in many/most of the last 8 bits anyway, so I don't think the choice of source is all that important. Though purely electronic music may be a bit different, since you wouldn't have thermal noise mixed in.
I may be missing something, but if the lower 8 bits are noise (i.e., incompressible), won't every codec perform the same on that part, thus making the comparison dependent on what's in the top 16 bits?
I may be missing something, but if the lower 8 bits are noise (i.e., incompressible), won't every codec perform the same on that part, thus making the comparison dependent on what's in the top 16 bits?
That's how it should be, but it turns out that it's not always the case.
With FLAC there is a limitation in the size of the values that can be represented in the Rice coder, so when the residuals get too large the encoder starts storing values without any compression. I also seem to remember that Monkey's Audio also has some limitation with large magnitude samples because of its MMX usage, although this may have been fixed in newer versions.
So, when testing 24-bit capabilities it would be good to have some loud samples and some with lots of high frequencies to make sure the codecs are exercised fully.
I would actually like to test out some of the lossless codecs to post here as I have some 24-bit rips. Before I do, I wanna make sure I have everything I need...
I plan on testing: WavPack, FLAC, Monkey's Audio, and TAK. Time permitting, OptimFROG and LA.
As far as I understand, I just need to use the tool timethis.exe to get encoding time? Do I need anything else? If not, I'm going to start working on this very soon.
I plan on testing: WavPack, FLAC, Monkey's Audio, and TAK. Time permitting, OptimFROG and LA.
LA doesn't support 24-bits, so you can take that off your list. You might consider replacing it with TTA because it handles 24-bits, and it also handles 32-bit floats in case you considered testing that also.
I look forward to seeing your results!
As far as I understand, I just need to use the tool timethis.exe to get encoding time? Do I need anything else? If not, I'm going to start working on this very soon.
I would recommend TIMER.EXE (http://www.7-zip.org/igor.html), rather than TIMETHIS.EXE. TIMER.EXE allows you to report CPU-only times, rather than CPU+IO times, which TIMETHIS.EXE will only report. TIMER.EXE reports both ("Global Time" = CPU+IO; "Process Time" = CPU-only).
This thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=50954) may provide some further considerations.
Any ideas for test material? I produce music, and nearly all of my 24-bit files are mixes-in-progress and stuff... very little "end product" in 24-bit. I could download some lossless DVD-A rips and 24/96 vinyl recordings, I suppose.
Well, there is a lot of 24 bit material available from live recording crowd. Especially on archive.org in the live music section. Most of it audience records made on 722's. But a few bands allow soundboard 24 bit plugins. If you goto archive.org check you can find 24bit soundboards from Younder Mountain String Band, Dark Star Orchestra or Ryan Adams(plus a few others here and there). You can find some good 24 bit audience recordings from Bela Fleck, String Cheese Incident plus quite a few others.
This thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=50954) may provide some further considerations.
Thank you, I really appreciate that Synthetic Soul! You're guide will help me out a lot
This thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=50954) may provide some further considerations.
Thank you, I really appreciate that Synthetic Soul! You're guide will help me out a lot
No problem. It's just one way of doing things, but I hope there will be some information that may help.
If you have any further questions reagarding my processes I would suggest posting to that thread (I am tracking it) so that everyone can benefit from my infinite wisdom. Feel free to PM concerning subjects that may not be relevant to that thread though.
I have also noticed this myself.
One day last week I was comparing the decode speeds (and file sizes) of FLAC (-0), TAK (turbo), and WavPack (fast) in Foobar. When I used a 16/44.1 file, obviously FLAC had the fastest decode speed (but much larger file), followed by TAK, and finally came WavPack (which had a slightly smaller file size than TAK, but was fairly slower on the decode speed). I started to consider converting all my whole audio collection from WavPack to TAK even though I knew this would take a few hours of encoding time.
But then I started to test some of my 24/96 files. To my great surprise, WavPack not only had the smallest file size, but it also had the fastest decoding speed (by a pretty decent margin). FLAC (which I thought would come in first) was runner up (again with the largest file size), with TAK coming in dead last (although much better file size compared to FLAC, though still bigger than WavPack).
Even though I would like to see better decode speeds at 16/44.1, I decided to stick with WavPack as my codec of choice (besides, David is a stand up guy ). I was very impressed with how well WavPack scales, and conversely disappointed with how bad FLAC/TAK scales. Is this bad scaling just an inherit flaw in the FLAC/TAK algorithm or does this just happen to be one of WavPack's strengths (or maybe a mix both)?
Now if David would just suck it up for the team and sleep with some of the iAudio engineers, we could possibly get official WavPack support on the upcoming Cowon A3. Then life would be great!
But then I started to test some of my 24/96 files. To my great surprise, WavPack not only had the smallest file size, but it also had the fastest decoding speed (by a pretty decent margin). FLAC (which I thought would come in first) was runner up (again with the largest file size), with TAK coming in dead last (although much better file size compared to FLAC, though still bigger than WavPack).
Even though I would like to see better decode speeds at 16/44.1, I decided to stick with WavPack as my codec of choice (besides, David is a stand up guy ). I was very impressed with how well WavPack scales, and conversely disappointed with how bad FLAC/TAK scales. Is this bad scaling just an inherit flaw in the FLAC/TAK algorithm or does this just happen to be one of WavPack's strengths (or maybe a mix both)?
It's always a bit dangerous to draw conclusions regarding compression performance from limited file sets. These are the results of my 24 Bit /96 Khz test corpus:
WavPack -f 58,08 %
TAK Turbo 54,52 %
Here TAK is performing 3,5 % better than WavPack. Possibly your files are something special. I would be interested to analyze a snippet (10 to 30 seconds) of one of your files to check what is going on. Could you please send me one via email?
For the speed: Those fast modes are usually limited by the speed of the io system (unless you have a really ultra fast hard disk array). I doubt, that TAK's codec is encoding or decoding slower than WavPack on those settings, but it's possible that TAK's io system is responsible for worse results. With 24 Bit /96 Khz TAK 1.0.1 is using quite large io buffers which can considerably decrease the speed. Funny, but i am just working on a new io sub system for TAK 1.0.2 which will use considerably smaller buffer and at least on my system achieves significantly higher speeds than V1.0.1 on high resolution audio.
Thomas
Here TAK is performing 3,5 % better than WavPack. Possibly your files are something special. I would be interested to analyze a snippet (10 to 30 seconds) of one of your files to check what is going on. Could you please send me one via email?
There is one case where i would expect Wavpack to perform better than TAK: Possibly the files are not really 24 bit. If audio data with less bits (possibly because the ADC is only generating for instance 20 bit) is converted to 24 bit, the lower bits will contain constant patterns. If those patterns are beeing detected by the encoder, about 6 percent per bit can be saved. Currently TAK detects only the most common case where the low bits are all zero, while WavPack can also take advantage of other patterns. This can also result in a speed advantage.
I thought such files ("pseudo 24-Bit") are too rare to put much effort into their handling. But i may add support for other constant bit patterns to one of the next versions. It's very easy to do and very fast.
Ah I'm sorry I should have mentioned that since I don't care about encoding time (I always encode while I'm at work), I use the -fx6 switch for WavPack since it has no impact on decoding speed. Perhaps that's why we are seeing different results (it was ever so slight, I believe the bit-rate difference was like 3000k vs 3005k). So I'm guessing the default -f switch probably would produce a larger file. Sorry for the confusion.
To be honest though Tom the different file sizes between codecs doesn't bother me as much as the different decoding speeds between codecs (as long as the file sizes are close). I can stomach the slight increased size of the TAK file (vs the WavPack file), but I couldn't stomach a ~15% drop in decoding speed (example: 75x real-time vs 64x real-time for Bohemian Rhapsody). The new IO system in TAK 1.0.2 does sound very interesting. I will make sure that when TAK 1.0.2 is released, I will retest and reevaluate my codec options.
Also I can also assure you it is indeed a 24/96 file (not a 20-bit file). I ripped the 24/96 PCM Stereo files from my "Queen: A Night at the Opera" DVD-Audio disc. I'm fairly sure they are true 24/96 files (though if I'm wrong please correct me).
I'm sorry Tom if I came off as being critical of the TAK codec (or FLAC for that matter), but I was so impressed by TAK's performance with 16/44.1 files, I was really expecting similiar results with 24/96 files too. So you can imagine the disappointment I had when I ran my higher resolution tests for TAK. I wouldn't worry about it though since I'm sure the overwhelming majority of files out there are 16/44.1, not 24/96. It's really exciting to see the TAK codec develop; I wish you the best of luck.
Now if David would just suck it up for the team and sleep with some of the iAudio engineers, we could possibly get official WavPack support on the upcoming Cowon A3. Then life would be great!
I have a suggestion for a file base. It's not perfect but it has some advantages. First, its a native 24/96 recording. Second, its readily available to everyone. Finally, it comes with the original md5 and ffp signatures so that we all know that we are dealing with the same files:
Original 24bit
http://www.archive.org/details/paf2007-06-...41v.m222.flac24 (http://www.archive.org/details/paf2007-06-03.mk41v.m222.flac24)
download site:
ftp://ia350640.us.archive.org/0/items/paf...41v.m222.flac24 (http://ftp://ia350640.us.archive.org/0/items/paf2007-06-03.mk41v.m222.flac24)
16bit version of same:
http://www.archive.org/details/paf2007-06-...41v.m222.flac16 (http://www.archive.org/details/paf2007-06-03.mk41v.m222.flac16)
download site
ftp://ia350630.us.archive.org/0/items/paf...41v.m222.flac16 (http://ftp://ia350630.us.archive.org/0/items/paf2007-06-03.mk41v.m222.flac16)
Here is a different recording, of the same show but in 24/48:
http://www.archive.org/details/phil2007-06...k21.nbox.flac24 (http://www.archive.org/details/phil2007-06-03.mk21.nbox.flac24)
download site:
ftp://ia301321.us.archive.org/2/items/phi...k21.nbox.flac24 (http://ftp://ia301321.us.archive.org/2/items/phil2007-06-03.mk21.nbox.flac24)
Like wise there is a 16bit version of the above mentioned 24/48 recording:
http://www.archive.org/details/phil2007-06...k21.nbox.flac16 (http://www.archive.org/details/phil2007-06-03.mk21.nbox.flac16)
download:
ftp://ia350624.us.archive.org/2/items/phi...k21.nbox.flac16 (http://ftp://ia350624.us.archive.org/2/items/phil2007-06-03.mk21.nbox.flac16)
Please note that these are all LEGAL FILES. Also, the ftp download locations are very fast, I average about 700k/s from my cable modem.
I'm doing an informal file size comparison of flac, wavpack, tak and ape at max compression. I'll post it in a few days.
I can stomach the slight increased size of the TAK file (vs the WavPack file), but I couldn't stomach a ~15% drop in decoding speed (example: 75x real-time vs 64x real-time for Bohemian Rhapsody).
Just out of curiosity, what is the practical difference between a 75x and 64x real-time decoding speed that you find so difficult to stomach?
Has anyone done a comparison of lossless codecs' performance on 24-bit audio?
I'm used to all lossless codecs performing about the same, but for 24-bit, this clearly isn't so; WavPack seems to work a lot better than FLAC, even though they're basically tied on CD audio.
I can whole heartedly agree with that. I recently digitally ripped all my DVD-Audio disks and found that wavpack was much better than FLAC, sometimes I was looking at 10% extra compression. Also Wavpack could do 88200Hz and 19200hz files, FLAC just fell over.
I use wavpack -hhx6 for everything now, it may be incredibly slow, but it gives great compression ratios.
Ah I'm sorry I should have mentioned that since I don't care about encoding time (I always encode while I'm at work), I use the -fx6 switch for WavPack since it has no impact on decoding speed. Perhaps that's why we are seeing different results (it was ever so slight, I believe the bit-rate difference was like 3000k vs 3005k). So I'm guessing the default -f switch probably would produce a larger file. Sorry for the confusion.
Thanks for the info! I will try this on my file sets. I have to admit, that i am not very familar with the effect of WavPack's options.
BTW: There is a similar switch for TAK: -p0e or p0m will select extra or maximum evaluation and shouldn't affect the decoding speed.
To be honest though Tom the different file sizes between codecs doesn't bother me as much as the different decoding speeds between codecs (as long as the file sizes are close). I can stomach the slight increased size of the TAK file (vs the WavPack file), but I couldn't stomach a ~15% drop in decoding speed (example: 75x real-time vs 64x real-time for Bohemian Rhapsody). The new IO system in TAK 1.0.2 does sound very interesting. I will make sure that when TAK 1.0.2 is released, I will retest and reevaluate my codec options.
I hope it will help a bit. I forgot, that the speed also depends on the cpu type. TAK is for instance performing less well on a P4.
Also I can also assure you it is indeed a 24/96 file (not a 20-bit file). I ripped the 24/96 PCM Stereo files from my "Queen: A Night at the Opera" DVD-Audio disc. I'm fairly sure they are true 24/96 files (though if I'm wrong please correct me).
This helps to rule out the constant bits hypothesis...
I'm sorry Tom if I came off as being critical of the TAK codec (or FLAC for that matter), but I was so impressed by TAK's performance with 16/44.1 files, I was really expecting similiar results with 24/96 files too. So you can imagine the disappointment I had when I ran my higher resolution tests for TAK. I wouldn't worry about it though since I'm sure the overwhelming majority of files out there are 16/44.1, not 24/96. It's really exciting to see the TAK codec develop; I wish you the best of luck.
Please don't take me wrong. I am always very excited if someone posts such results contrary to my expectations because it shows me, that i may have missed something and may have to improve TAK. I already have a nice collection of extraordinary behaving 16-bit files, but my high resolution corpus is still quite small. It's always possible that i have missed somthing.
Could you please try one of those files with -p0e, -p0m and p1m? This could help me to find the reason for the unexpected results.
Thomas
Just out of curiosity, what is the practical difference between a 75x and 64x real-time decoding speed that you find so difficult to stomach?
Well my 24/96 files already reach up to a max of five cpu usage in foobar; I really don't want to go any higher than that. But when I said "couldn't stomach" I was really talking about transcoding (remember all my files are already WavPack). Since the files are about the same in size, why would I spend a few hours transcoding my high resolution files just to lose 15% in decoding speed? That's what I can't stomach right now.
Could you please try one of those files with -p0e, -p0m and p1m? This could help me to find the reason for the unexpected results.
Yes I could. I'll post back later today with results.
[EDIT]Ah sorry guys went out and saw Die Hard 4 tonight, I'll delay the testing till tomorrow.[/EDIT]
I use wavpack -hhx6 for everything now, it may be incredibly slow, but it gives great compression ratios.
Hmm, are you sure it's better than -hx6?
I abandoned the idea of ever using -hh a while back when I compared -hhx6 and -hx6 on some files, and found that -hhx6 was never much better, and was often a little bit worse. Those were 16-bit files, however.
Also Wavpack could do 88200Hz and 19200hz files, FLAC just fell over.
FLAC handles any sample rate up to 655350Hz. probably the problem was that 88.2kHz and 19.2kHz are not in the subset so you have to use the --lax switch when encoding with flac.exe.
FLAC performance on 24bit is not tuned but will improve. some things are already done but not released yet.
Here is the data from my quick 24/96 lossless compression comparision:
Name Ext Size Type Created Modified Accessed Attr
The wav files:
paf2007-06-03s1t01.wav wav 473088000 Audio File (WAV) 7/8/2007 08:56:49 7/8/2007 01:55:57 7/8/2007 01:41:36 ----A----
paf2007-06-03s1t02.wav wav 447606784 Audio File (WAV) 7/8/2007 08:57:34 7/8/2007 01:49:00 7/8/2007 01:23:56 ----A----
paf2007-06-03s1t03.wav wav 360878080 Audio File (WAV) 7/8/2007 08:58:16 7/8/2007 01:41:36 7/8/2007 01:20:17 ----A----
paf2007-06-03s1t04.wav wav 644939776 Audio File (WAV) 7/8/2007 08:55:43 7/8/2007 01:53:39 7/8/2007 01:20:11 ----A----
Monkey's Audio 4.01 "insane"
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03s1t01.ape ape 220217344 Audio File (APE) 7/8/2007 09:21:35 7/8/2007 09:34:42 7/8/2007 09:21:35 ----A----
paf2007-06-03s1t02.ape ape 208175104 Audio File (APE) 7/8/2007 09:34:42 7/8/2007 09:47:55 7/8/2007 09:34:42 ----A----
paf2007-06-03s1t03.ape ape 170258432 Audio File (APE) 7/8/2007 09:39:19 7/8/2007 09:48:59 7/8/2007 09:39:19 ----A----
paf2007-06-03s1t04.ape ape 301494272 Audio File (APE) 7/8/2007 09:21:35 7/8/2007 09:39:18 7/8/2007 09:21:35 ----A----
Flac 1.1.4b using compression level -8
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03s1t01.flac flac 245911552 Audio File (FLAC) 7/8/2007 09:05:10 7/8/2007 01:55:57 7/8/2007 01:41:36 ----A----
paf2007-06-03s1t02.flac flac 232583168 Audio File (FLAC) 7/8/2007 09:07:30 7/8/2007 01:49:00 7/8/2007 01:23:56 ----A----
paf2007-06-03s1t03.flac flac 187633664 Audio File (FLAC) 7/8/2007 09:10:00 7/8/2007 01:41:36 7/8/2007 01:20:17 ----A----
paf2007-06-03s1t04.flac flac 335106048 Audio File (FLAC) 7/8/2007 09:12:17 7/8/2007 01:53:39 7/8/2007 01:20:11 ----A----
WavPack release 4.41 using -hhx6
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03s1t01.wv wv 232615936 Audio File (WV) 7/8/2007 11:12:12 7/8/2007 12:14:07 7/8/2007 11:12:12 ----A----
paf2007-06-03s1t02.wv wv 220196864 Audio File (WV) 7/8/2007 12:14:07 7/8/2007 13:14:25 7/8/2007 12:14:07 ----A----
paf2007-06-03s1t03.wv wv 179040256 Audio File (WV) 7/8/2007 13:14:25 7/8/2007 14:01:21 7/8/2007 13:14:25 ----A----
paf2007-06-03s1t04.wv wv 317763584 Audio File (WV) 7/8/2007 09:50:00 7/8/2007 11:12:12 7/8/2007 09:50:00 ----A----
TAK 1.01 using -p4m
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03s1t01.tak tak 222396416 TAK File 7/8/2007 19:29:22 7/8/2007 19:31:58 7/8/2007 19:29:22 ----A----
paf2007-06-03s1t02.tak tak 210464768 TAK File 7/8/2007 19:32:32 7/8/2007 19:35:21 7/8/2007 19:32:32 ----A----
paf2007-06-03s1t03.tak tak 171737088 TAK File 7/8/2007 19:35:41 7/8/2007 19:38:04 7/8/2007 19:35:41 ----A----
paf2007-06-03s1t04.tak tak 304373760 TAK File 7/8/2007 19:38:23 7/8/2007 19:42:50 7/8/2007 19:38:23 ----A----
Some informal observations:
WavPack took longest to encode, nothing else came close.
TAK was the quickest to encode.
However...
WavPack decompressed very quickly, and eventhough my hard drive was very busy writing 2 gigs of wav files, the cpu wasn't flooded at all.
TAK on the other hand was much slower than WavPack in decoding and flooded my CPU
Here is the shntool info output of the original wav files that I decompressed from the original flac files. The original recording comes packed in flac 1.1.2:
-------------------------------------------------------------------------------
File name: paf2007-06-03s1t01.wav
Handled by: wav format module
Length: 13:41.332
WAVE format: 0x0001 (Microsoft PCM)
Channels: 2
Bits/sample: 24
Samples/sec: 96000
Average bytes/sec: 576000
Rate (calculated): 576000
Block align: 6
Header size: 44 bytes
Data size: 473087160 bytes
Chunk size: 473087196 bytes
Total size (chunk size + 8): 473087204 bytes
Actual file size: 473087204
File is compressed: no
Compression ratio: 1.0000
CD-quality properties:
CD quality: no
Cut on sector boundary: n/a
Sector misalignment: n/a
Long enough to be burned: n/a
WAVE properties:
Non-canonical header: no
Extra RIFF chunks: no
Possible problems:
File contains ID3v2 tag: no
Data chunk block-aligned: yes
Inconsistent header: no
File probably truncated: no
Junk appended to file: no
Odd data size has pad byte: n/a
-------------------------------------------------------------------------------
File name: paf2007-06-03s1t02.wav
Handled by: wav format module
Length: 12:57.091
WAVE format: 0x0001 (Microsoft PCM)
Channels: 2
Bits/sample: 24
Samples/sec: 96000
Average bytes/sec: 576000
Rate (calculated): 576000
Block align: 6
Header size: 44 bytes
Data size: 447604416 bytes
Chunk size: 447604452 bytes
Total size (chunk size + 8): 447604460 bytes
Actual file size: 447604460
File is compressed: no
Compression ratio: 1.0000
CD-quality properties:
CD quality: no
Cut on sector boundary: n/a
Sector misalignment: n/a
Long enough to be burned: n/a
WAVE properties:
Non-canonical header: no
Extra RIFF chunks: no
Possible problems:
File contains ID3v2 tag: no
Data chunk block-aligned: yes
Inconsistent header: no
File probably truncated: no
Junk appended to file: no
Odd data size has pad byte: n/a
-------------------------------------------------------------------------------
File name: paf2007-06-03s1t03.wav
Handled by: wav format module
Length: 10:26.520
WAVE format: 0x0001 (Microsoft PCM)
Channels: 2
Bits/sample: 24
Samples/sec: 96000
Average bytes/sec: 576000
Rate (calculated): 576000
Block align: 6
Header size: 44 bytes
Data size: 360875592 bytes
Chunk size: 360875628 bytes
Total size (chunk size + 8): 360875636 bytes
Actual file size: 360875636
File is compressed: no
Compression ratio: 1.0000
CD-quality properties:
CD quality: no
Cut on sector boundary: n/a
Sector misalignment: n/a
Long enough to be burned: n/a
WAVE properties:
Non-canonical header: no
Extra RIFF chunks: no
Possible problems:
File contains ID3v2 tag: no
Data chunk block-aligned: yes
Inconsistent header: no
File probably truncated: no
Junk appended to file: no
Odd data size has pad byte: n/a
-------------------------------------------------------------------------------
File name: paf2007-06-03s1t04.wav
Handled by: wav format module
Length: 18:39.687
WAVE format: 0x0001 (Microsoft PCM)
Channels: 2
Bits/sample: 24
Samples/sec: 96000
Average bytes/sec: 576000
Rate (calculated): 576000
Block align: 6
Header size: 44 bytes
Data size: 644939568 bytes
Chunk size: 644939604 bytes
Total size (chunk size + 8): 644939612 bytes
Actual file size: 644939612
File is compressed: no
Compression ratio: 1.0000
CD-quality properties:
CD quality: no
Cut on sector boundary: n/a
Sector misalignment: n/a
Long enough to be burned: n/a
WAVE properties:
Non-canonical header: no
Extra RIFF chunks: no
Possible problems:
File contains ID3v2 tag: no
Data chunk block-aligned: yes
Inconsistent header: no
File probably truncated: no
Junk appended to file: no
Odd data size has pad byte: n/a
Tkanks for the data!
Some informal observations:
WavPack took longest to encode, nothing else came close.
TAK was the quickest to encode.
However...
WavPack decompressed very quickly, and eventhough my hard drive was very busy writing 2 gigs of wav files, the cpu wasn't flooded at all.
TAK on the other hand was much slower than WavPack in decoding and flooded my CPU
Can you please explain what exactly "flooded my CPU" means?
Your observation regarding TAK's decoding speed on high resolution audio is very interesting for me. TAK seems to behave significantly different than with 16 bit audio. It's a bit surprising, because the audio data is beeing sent trough exactly the same filters for 16 and 24 bit audio. It only has to be shifted down for TAK's reduced precision arithmetic. This operation is very fast; much faster than the filter operations which are equal for 16 and 24 bit audio. Therefore this can't explain the lower decoding speed.
Currently i see two possible reasons for the speed penality:
1) TAK 1.0.1 is using very large io buffers for high resolution audio. This is likely to affect the disk io speed.
2) The ram usage is much higher than neccessary. Possibly the data will not fit into the cpu's level 2 cache.
Fortunately TAK 1.0.2 will improve both aspects. The io buffer size will be reduced to about one quarter, the ram usage is already down to about one third. Probably this will significantly improve the decoding speed for high resolution audio.
Funny: I have already put much work into those optimizations but was not sure, how much sense this makes. Now i know...
Thomas
I just performed a decoding speed test on my high resolution sample set. To test my hypothesis that your results may depend on disk io issues i performed a test without disk access: The compressed data was already in the file cache and both codecs had been configured to create no decoded output file (-t option for TAK, -v for WavPack). The files had been encoded with the strongest settings (-p4m for TAK, -hhx6 for WavPack).
Result: Decoding took 17.5 seconds for WavPack, 9.3 seconds for TAK.
Looks as if the disk io is a very important factor.
Unfortunately i can not provide results with disk io, because my hard disk is far too slow. Both codecs are decoding much faster than my hard disk can read and write data.
Tkanks for the data!
Can you please explain what exactly "flooded my CPU" means?
I was "watching" the process in Process Explorer, the free utility that was originally developed by Sysinternals and is now at M$crosoft. It puts a cpu usage graph in the lower right corner of the tool bar. Like I said, it was an "informal" observation.
The point I was trying to make was that WavPack, despite being incredibly slow to encode, was astoundingly fast decoding and appeared to take up less cpu resources. The upshot of all this is that WavPack appears to be astoundingly asymmetric at 24/96, much more than I expected.
I did not mean to imply that TAK was inadequate at decoding, just that it roughly appeared to be more symmetrical at 24/96 than wavpak(and probably flac). The reading from the TAK gui for decompression was a little over 14x if I remember correctly... That's not bad, especially considering the insane amount of data that's being processed.
I would be interested in seeing data on optimum frog for this file set, but it would take a very long time to process this file set with OFR at it's highest setting. I certainly don't have that much time...
WavPack in it's most recent incarnation states in the changelog:
added: MMX intrinsics for 24-bit (and higher) stereo encoding (thanks to
Joachim Henke)
Could that also partly account for the "differences" I observed(I do have Intel Processor with MMX, SSE 1,2 and 3 etc...)?
I understand that TAK is a newer lossless codec, and thus hasn't had as much opportunity for optimizations etc... Heck, the most popular lossless codec out there(whose name I shall not mention) has been around for quite some time and only recently got the speed & compression optimizations it really needed at 16 bits. It still needs compression optimizations at 24 bits(according to the developer).
Here is an interesting question: What would the results be if I repeated the above test with a 24/48 fileset? There are a lot of recordings out there in this oddball format.
If I have time this week I might dither(and nothing else!) the fileset to 16/44 and repeat the tests. That might also be interesting...
Some informal observations:
WavPack took longest to encode, nothing else came close.
This is due to the x6 setting. IMHO the -x settings above 3 are not of practical use (maybe with the exception of the combination with the fast setting -f). -hhx2 would be a lot more reasonable, encoding timewise.
..WavPack appears to be astoundingly asymmetric at 24/96
The -x setting is causing this "asymetric" effect, it let's WavPack spend eXtra time on encoding, while decoding stays the same.
But maybe encoding time was not what you wanted to test...
I did not mean to imply that TAK was inadequate at decoding, just that it roughly appeared to be more symmetrical at 24/96 than wavpak(and probably flac). The reading from the TAK gui for decompression was a little over 14x if I remember correctly... That's not bad, especially considering the insane amount of data that's being processed.
...
added: MMX intrinsics for 24-bit (and higher) stereo encoding (thanks to
Joachim Henke)
Could that also partly account for the "differences" I observed(I do have Intel Processor with MMX, SSE 1,2 and 3 etc...)?
As i wrote above i am convinced that TAK's slow decoding is only beeing caused by it's sub optimal disk io interface. Your system seems to be much faster than mine and you are achieving only 14x realtime. Well, on my good old Pentium 3 with 1 GHz the decoding speed for this audio format is already more than 25x... Something is really going wrong here.
Here is an interesting question: What would the results be if I repeated the above test with a 24/48 fileset? There are a lot of recordings out there in this oddball format.
Regarding TAK's speed: If the large io buffer is responsible for it's slow decoding on your system, this effect should be considerably smaller with this format.
I definitely would like to find the reason for TAK's bad behaviour on your system (possibly this is not limited to your system). Would you be interested to repeat the decoding test with the current evaluation version of TAK 1.0.2? It alreday implements the new io interface with the smaller io buffers and should perform much better if the large buffers of 1.0.1 are responsible for the bad performance. Unfortunately i can't perform such testing by myself because my hard disk is much too slow.
Thomas
[quote name='GeSomeone' date='Jul 9 2007, 04:43' post='503531']
This is due to the x6 setting. IMHO the -x settings above 3 are not of practical use (maybe with the exception of the combination with the fast setting -f). -hhx2 would be a lot more reasonable, encoding timewise.
[/quote]It was just an "informal observation." Also, I do not find the x6 settings to be impractical. Even though I haven't been using the x6 setting for a long period of time, I've already encoded lots of 24/96 recordings with it. I just script it and start the script before I goto work/bed. I do this with recordings about ~180 minutes length(~3.6gigs raw wav file size).
..WavPack appears to be astoundingly asymmetric at 24/96
The -x setting is causing this "asymetric" effect, it let's WavPack spend eXtra time on encoding, while decoding stays the same.
But maybe encoding time was not what you wanted to test...
[/quote]
No, I was strictly testing the encoded file size. In general I do not place a lot of emphasis on encoding speed, except in the case of OFR which is just too much.
Some math that I didn't have time to do originally:
[code]Name Ext Size Type Created Modified Accessed Attr Compressed
paf2007-06-03s1t01.wav wav "473,088,000" Audio File (WAV) 7/8/2007 8:56 7/8/2007 1:55 7/8/2007 1:41 ----A----
paf2007-06-03s1t02.wav wav "447,606,784" Audio File (WAV) 7/8/2007 8:57 7/8/2007 1:49 7/8/2007 1:23 ----A----
paf2007-06-03s1t03.wav wav "360,878,080" Audio File (WAV) 7/8/2007 8:58 7/8/2007 1:41 7/8/2007 1:20 ----A----
paf2007-06-03s1t04.wav wav "644,939,776" Audio File (WAV) 7/8/2007 8:55 7/8/2007 1:53 7/8/2007 1:20 ----A----
paf2007-06-03s1t01.ape ape "220,217,344" Audio File (APE) 7/8/2007 9:21 7/8/2007 9:34 7/8/2007 9:21 ----A---- 0.465489177
paf2007-06-03s1t02.ape ape "208,175,104" Audio File (APE) 7/8/2007 9:34 7/8/2007 9:47 7/8/2007 9:34 ----A---- 0.465084783
paf2007-06-03s1t03.ape ape "170,258,432" Audio File (APE) 7/8/2007 9:39 7/8/2007 9:48 7/8/2007 9:39 ----A---- 0.471789342
paf2007-06-03s1t04.ape ape "301,494,272" Audio File (APE) 7/8/2007 9:21 7/8/2007 9:39 7/8/2007 9:21 ----A---- 0.467476628
paf2007-06-03s1t01.flac flac "245,911,552" Audio File (FLAC) 7/8/2007 9:05 7/8/2007 1:55 7/8/2007 1:41 ----A---- 0.519800866
paf2007-06-03s1t02.flac flac "232,583,168" Audio File (FLAC) 7/8/2007 9:07 7/8/2007 1:49 7/8/2007 1:23 ----A---- 0.519614931
paf2007-06-03s1t03.flac flac "187,633,664" Audio File (FLAC) 7/8/2007 9:10 7/8/2007 1:41 7/8/2007 1:20 ----A---- 0.519936439
paf2007-06-03s1t04.flac flac "335,106,048" Audio File (FLAC) 7/8/2007 9:12 7/8/2007 1:53 7/8/2007 1:20 ----A---- 0.519592775
paf2007-06-03s1t01.wv wv "232,615,936" Audio File (WV) 7/8/2007 11:12 7/8/2007 12:14 7/8/2007 11:12 ----A---- 0.491696970
paf2007-06-03s1t02.wv wv "220,196,864" Audio File (WV) 7/8/2007 12:14 7/8/2007 13:14 7/8/2007 12:14 ----A---- 0.491942642
paf2007-06-03s1t03.wv wv "179,040,256" Audio File (WV) 7/8/2007 13:14 7/8/2007 14:01 7/8/2007 13:14 ----A---- 0.496123943
paf2007-06-03s1t04.wv wv "317,763,584" Audio File (WV) 7/8/2007 9:50 7/8/2007 11:12 7/8/2007 9:50 ----A---- 0.492702723
paf2007-06-03s1t01.tak tak "222,396,416" TAK File 7/8/2007 19:29 7/8/2007 19:31 7/8/2007 19:29 ----A---- 0.470095238
paf2007-06-03s1t02.tak tak "210,464,768" TAK File 7/8/2007 19:32 7/8/2007 19:35 7/8/2007 19:32 ----A---- 0.470200130
paf2007-06-03s1t03.tak tak "171,737,088" TAK File 7/8/2007 19:35 7/8/2007 19:38 7/8/2007 19:35 ----A---- 0.475886726
paf2007-06-03s1t04.tak tak "304,373,760" TAK File 7/8/2007 19:38 7/8/2007 19:42 7/8/2007 19:38 ----A---- 0.471941368
I can possibly provide further samples from my DVDA discs, I've ripped out all the hires data and stored them on DVDRs in Wavpack. It wouldn't take much time to recompress them using Foobar Converter, although, all samples are likely in totally different format (44,1k, 48k, 88,2k, 96k, stereo and 5.1, in all manners of combinations.).
Ok, I final did the same comparison after dithering the files down to 16bit.
Dithered files using ssrc_hp.exe --rate 44100 --bits 16 --normalize --twopass --dither 3 --pdf 1
Name Ext Size Type Created Modified Accessed
paf2007-06-03-dithereds1t01.wav wav 144883712 Audio File (WAV) 7/24/2007 21:58:21 7/24/2007 22:01:12 7/24/2007 21:58:21
paf2007-06-03-dithereds1t02.wav wav 137080832 Audio File (WAV) 7/24/2007 22:01:12 7/24/2007 22:04:26 7/24/2007 22:01:12
paf2007-06-03-dithereds1t03.wav wav 110518272 Audio File (WAV) 7/24/2007 22:04:26 7/24/2007 22:06:48 7/24/2007 22:04:26
paf2007-06-03-dithereds1t04.wav wav 197513216 Audio File (WAV) 7/24/2007 22:06:48 7/24/2007 22:11:22 7/24/2007 22:06:48
Ape using insane compression
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03-dithereds1t01.ape ape 67575808 Audio File (APE) 7/24/2007 22:17:37 7/24/2007 22:24:02 7/24/2007 22:17:37
paf2007-06-03-dithereds1t02.ape ape 65622016 Audio File (APE) 7/24/2007 22:24:02 7/24/2007 22:30:33 7/24/2007 22:24:02
paf2007-06-03-dithereds1t03.ape ape 52113408 Audio File (APE) 7/24/2007 22:26:14 7/24/2007 22:31:18 7/24/2007 22:26:14
paf2007-06-03-dithereds1t04.ape ape 92811264 Audio File (APE) 7/24/2007 22:17:37 7/24/2007 22:26:14 7/24/2007 22:17:37
TAK -p4m
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03-dithereds1t01.tak tak 68730880 TAK File 7/24/2007 22:33:43 7/24/2007 22:35:54 7/24/2007 22:33:43
paf2007-06-03-dithereds1t02.tak tak 66908160 TAK File 7/24/2007 22:35:54 7/24/2007 22:38:23 7/24/2007 22:35:54
paf2007-06-03-dithereds1t03.tak tak 52965376 TAK File 7/24/2007 22:38:23 7/24/2007 22:40:21 7/24/2007 22:38:23
paf2007-06-03-dithereds1t04.tak tak 94511104 TAK File 7/24/2007 22:40:21 7/24/2007 22:44:07 7/24/2007 22:40:21
Flac version 1.2 using -8 (note:somewhere between this week and last week I deleated flac 1.1.4b from my computer)
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03-dithereds1t01.flac flac 70725632 Audio File (FLAC) 7/24/2007 22:13:48 7/24/2007 22:01:12 7/24/2007 21:58:21
paf2007-06-03-dithereds1t02.flac flac 68730880 Audio File (FLAC) 7/24/2007 22:14:35 7/24/2007 22:04:26 7/24/2007 22:01:12
paf2007-06-03-dithereds1t03.flac flac 54243328 Audio File (FLAC) 7/24/2007 22:15:18 7/24/2007 22:06:48 7/24/2007 22:04:26
paf2007-06-03-dithereds1t04.flac flac 97140736 Audio File (FLAC) 7/24/2007 22:12:52 7/24/2007 22:11:22 7/24/2007 22:06:48
Flac version 1.2 using -8 on the orginal 24/96 wav files from previous posts
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03s1t01.flac flac 245911552 Audio File (FLAC) 7/25/2007 00:11:52 7/8/2007 01:55:57 7/8/2007 01:41:36
paf2007-06-03s1t02.flac flac 232583168 Audio File (FLAC) 7/25/2007 00:14:41 7/8/2007 01:49:00 7/8/2007 01:23:56
paf2007-06-03s1t03.flac flac 187633664 Audio File (FLAC) 7/25/2007 00:17:36 7/8/2007 01:41:36 7/8/2007 01:20:17
paf2007-06-03s1t04.flac flac 335106048 Audio File (FLAC) 7/25/2007 00:08:15 7/8/2007 01:53:39 7/8/2007 01:20:11
WavPack using -hhx6
Name Ext Size Type Created Modified Accessed Attr
paf2007-06-03-dithereds1t01.wv wv 69427200 Audio File (WV) 7/25/2007 12:04:35 7/25/2007 12:21:41 7/25/2007 12:04:35
paf2007-06-03-dithereds1t02.wv wv 67506176 Audio File (WV) 7/25/2007 12:21:41 7/25/2007 12:38:03 7/25/2007 12:21:41
paf2007-06-03-dithereds1t03.wv wv 53407744 Audio File (WV) 7/25/2007 12:38:03 7/25/2007 12:50:47 7/25/2007 12:38:03
paf2007-06-03-dithereds1t04.wv wv 95612928 Audio File (WV) 7/25/2007 11:43:03 7/25/2007 12:04:35 7/25/2007 11:43:03
I've done most of the "data generation legwork" if someone wants to do analysis please feel free to help. We all have time constraints in our lives, by splitting this up we can get some useful data by x-mas...