Alpha release 1 of TAK 2.2.0 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Applications 2.2.0 Alpha 1 b in "\Applications".
- TAK Winamp plugin 2.2.0 Alpha 1 in "\WinAmp".
- TAK Decoding library 2.2.0 Alpha 1 in "\Deco_Lib".
The final release will additionally contain the SDK.
Download:
Download link removed. TAK 2.2.0 Final (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89610&view=findpost&p=762614) has been released.
What's new
This release brings support for multi-channel audio and speed optimizations for encoder and decoder.
New features:
- Support for multi-channel audio. While the stream format supports up to 16 channels, the codec currently is restricted to a maximum of 6 channels.
- Support for the "Wave Format Extensible" file format.
Improvements:
- Encoding speed improvements of up to 10 percent for my primary file set. Most of it is achieved by a modification of the algorithm which selects the optimal predictor order for each subframe. It will now often use less predictors than before, what may on average result in about 0.01 percent worse compression. You will only notice an speed advantage, if your files benefit from high predictor orders.
- Decoding speed improvements of up to 18 percent for my primary file set. Some of it is attributed to the above-noted modification of the encoder's predictor order selection algorithm. Therefore it will only take effect when decoding files encoded with this version and only, if they benefit from high predictor orders. Additionally SSSE3-instructions can be used for predictor counts of 32 and more. This affects the presets p3, p4 and sometimes p2, but only, if a particular file benefits from high predictor orders.
Known issues:
- If you use pipe decoding and the application reading the pipe is beeing terminated before the whole file has been read, TAKC may get into an endless loop and has to be manually killed with the task manager. I don't think this is a big issue but i will try to fix it in one of the next versions. BTW: Big thanks to shnutils for testing the pipe decoding!
- There seem to be some compatibility issues with pipe decoding to some other applications ("crc1632.exe" has been reported). I will try to fix it in the next release.
Alpha testing
This alpha release has already gone through extensive testing performed by my automatic scripts. Nevertheless there may be bugs left. Especially because i had to write a lot of new code for the support of multi-channel audio. This also involved a lot of minor modifications of the existing code. Therefore i would like you to verify the proper function of the codec: Compress -> Decompress -> Compare resulting wave with the original file, either by a binary compare or by the use MD5-check sums.
Certainly i am very interested into efficiency comparisons of the new multi-channel audio codec and other compressors.
Some remarks:
The most time consuming part of the new codec is it's channel decorrelation mechanism. The strongest presets sometimes check any possible channel combination. Principially you have n * (n - 1) (n = channel count) possible combinations, if you count "A predicts B" and "B predicts A" as two combinations.
Some figures:
2 channels -> 2 combinations
4 channels -> 12 combinations
5 channels -> 20 combinations
6 channels -> 30 combinations
8 channels -> 56 combinations
This rapid increase is the reason, why the codec currently is restricted to a maximum of 6 channels. I have to find and evaluate more heuristics for a fast estimation of optimal pairings which doesn't require a full evaluation of all possibilities.
Some are alreaday working. Most of them rely on the presence of a speaker assignment mask in the source wave file. If present, some faster presets will only test those combinations, which were most useful in my evaluations. A low frequency channel will never be evaluated.
But this only works, if the speaker assignment is known. Therefore the encoding time of the same audio data may differ considerably dependent on the presence of a speaker mask in the original wave file.
Im my evaluations the new codec often did beat Mpeg4Als -7 compressionwise, if a particular file provided good opportunities for channel decorrelation. Unfortunately for some files there are zero opportunities. My test corpus is still too small to make any generalized statement regarding the new codecs efficiency.
Therefore i am very interested into compression results and comparisons with other codecs.
Thanks for testing and have fun
Thomas
I get "Wave file not supported" on all files.
Sample:
http://www.hydrogenaudio.org/forums/index....showtopic=88969 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88969)
BTW flood protection sucks.
Come on, what a problem with users writing 2 simple posts within a minute?
I get "Wave file not supported" on all files.
Sample:
http://www.hydrogenaudio.org/forums/index....showtopic=88969 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88969)
Hm, works for me. I tried encoding with both Tak and Takc and decoding with Tak. Binary compare of the resulting wave file is also ok.
edit: Here is TAK's file info result:
=== d2.tak ====================================================
File size: 2.37 MB
Header size: 0.13 KB
Unused: 0.00 KB
Compression: 36.01 %
Samples per channel: 384000
File duration: 8.00 sec
Frame duration: 125 ms
Seek table: Not available
Audio format: PCM, 48000 Hz, 24 Bits, 6 Channels
Encoder: V 2.2.0, -p2
Codec: 4 Integer 24 bit MC (TAK 2.2)
Wave file meta data: Header 68, Footer 0 Bytes
MD5: Not available
APEv2-Tag: No
Status: Ok
Hm, works for me.
Works here too.
Although there is no hint, i just looked at my wave file reader and found some unfortunate limitation. It seems to insist on the wValidBitsPerSample value to be zero or equal to wBitsPerSample. That's not how it is meant to work. This could be a source of your problem. Maybe the editor you are using to create the sample file is modifying this field in the way TAK expects.
edit: Addendum
I can post a quick fix for you to try.
The file was created with sox. I just tried Tak instead of Takc with the same result. I use Windows XP x64 if that matters.
I can only repeat my suggestion from long ago:
Make Takc more verbose. "Wave file not supported" is not really helpful.
The file was created with sox.
What version? 14.3.2 or earlier?
Added: sox 14.3.1 and earlier writes dwChannelMask = 0.
The file was created with sox. I just tried Tak instead of Takc with the same result. I use Windows XP x64 if that matters.
Can you please try this TAK.exe:
Attachment removed
I can only repeat my suggestion from long ago:
Make Takc more verbose. "Wave file not supported" is not really helpful.
Well, since this is possibly a bug, i am not sure if a more informative message would have been created.
Nevertheless i will think about it. I don't want to break the current design of the internal error handling, but maybe i can add a function to request extended error info.
The file was created with sox.
Added: sox 14.3.1 and earlier writes dwChannelMask = 0.
Thanks for the hint. But this should(!) be no problem.
I decoded d2.flac to 2 wav files with SoX 14.3.1 and 14.3.2.
They have different RIFF chunk sizes: 0x0069783c for 14.3.1 and 0x00697848 for 14.3.2.
takc.exe can encode the latter file, but not the former.
I decoded d2.flac to 2 wav files with SoX 14.3.1 and 14.3.2.
They have different RIFF chunk sizes: 0x0069783c for 14.3.1 and 0x00697848 for 14.3.2.
takc.exe can encode the latter file, but not the former.
A difference of 12 bytes? I am having some difficulties to interpret this. Well, i am really not the master of sound file formats...
Could you please send me the maybe first 512 bytes of both files?
--
I decoded d2.flac to 2 wav files with SoX 14.3.1 and 14.3.2.
They have different RIFF chunk sizes: 0x0069783c for 14.3.1 and 0x00697848 for 14.3.2.
takc.exe can encode the latter file, but not the former.
A difference of 12 bytes? I am having some difficulties to interpret this. Well, i am really not the master of sound file formats...
Could you please send me the maybe first 512 bytes of both files?
Sorry, no longer needed! I had some trouble downloading 14.3.1 from sourceforge, but finally it worked. Now i can reproduce the failure.
edit: I was too slow! Thank you.
Sorry, my bad, seems to be a flake bug, the flac doesn't decompress correctly!
I'm going to replace it in a minute with a wavpack file which I just verified to be OK. The latest build shows the same problem.
Sox 14.3.2 BTW.
ADDED: I can confirm that both versions of tak compress the decompressed flac correctly.
ADDED: The wavpack compressed file is uploaded. Same place as before, http://www.hydrogenaudio.org/forums/index....showtopic=88969 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88969)
Sorry, my bad, seems to be a flake bug, the flac doesn't decompress correctly!
I'm going to replace it in a minute with a wavpack file which I just verified to be OK. The latest build shows the same problem.
Sox 14.3.2 BTW.
ADDED: I can confirm that both versions of tak compress the decompressed flac correctly.
ADDED: The wavpack compressed file is uploaded. Same place as before, http://www.hydrogenaudio.org/forums/index....showtopic=88969 (http://www.hydrogenaudio.org/forums/index.php?showtopic=88969)
Thank you. I can reproduce the failure.
They have different RIFF chunk sizes: 0x0069783c for 14.3.1 and 0x00697848 for 14.3.2.
takc.exe can encode the latter file, but not the former.
Often i may be a bit too restrictive when reading foreign file formats...
My wave reader starts like this:
if not FFile.Seek (0) then begin
Result := frr_IoError;
EXIT;
end;
if FFile.Length < SizeOf (Chunk) then begin
Result := frr_InvalidType;
EXIT;
end;
if not FFile.ReadBuffer (Chunk, SizeOf (Chunk)) then begin
Result := frr_IoError;
EXIT;
end;
if Chunk.Id <> WaveRiffId then begin
Result := frr_InvalidType;
EXIT;
end;
if Chunk.nBytes <> FFile.Length - SizeOf (Chunk) then begin
Result := frr_StructError;
EXIT;
end;
It's the last check which is causing the trouble. The reader insits, that nothing comes after the RIFF-chunk and it's data. Could it be that Sox is adding some meta data? I am a bit irritated, because i never before received a report about such a failure.
From SoX changelog:
"Fix bug where FACT chunk was not accounted for in RIFF length calculation. Patch by David Bryant."
Probably that's why SoX 14.3.2 works fine but 14.3.1 doesn't.
From SoX changelog:
"Fix bug where FACT chunk was not accounted for in RIFF length calculation. Patch by David Bryant."
Probably that's why SoX 14.3.2 works fine but 14.3.1 doesn't.
Thank you so much! This explains everything. After inspecting the file with a hex editor, i just wanted to post the suspicion, that the file is invalid.
Then everything is ok (for now...).
Thank you all for helping me to resolve this issue.
Indeed, that last check shouldn't be made.
Microsoft's Wave format is a RIFF based format, and the RIFF format is just a union of labeled chunks of data.
I don't know if it is usual nowadays, but wave editors used to add an INFO FACT chunk adding their name to the files. This is just one of many things that can be also in the file. And then, there is the people that insist in adding tags to wave files...
You have to assert that the chunk's size of the "data" chunk is not bigger than the current position minus file length, but only that. Read up to chunk size, and if you are not at the file end, then there's something else that you don't care.
So:
Open
Read 8 bytes-> 4bytes Id and 4 bytes size (in little endian, in the case of RIFF files). Verify that it's RIFF and the chunk size is smaller than the file size.
Read next 4 bytes if it's WAVE, continue.
Read 8 byes -> 4 bytes ID and 4 bytes size. Verify that the ID is "fmt " (there's a space in there, yes). The chunk size can also be an indication of which waveformat you have. Read up to fmt's chunk size.
Read 8 bytes -> 4 bytes ID and 4 byte size. loop while this chunk ID isn't "data", skipping the chunk size.
Read wave data up to this chunk size.
Close.
This is a basic Wave file reader. Something simpler is not a wave reader, just a reader that happens to read most wave files.
Read up to chunk size, and if you are not at the file end, then there's something else that you don't care.
...but please don't break
-ihs switch
Indeed, that last check shouldn't be made.
Microsoft's Wave format is a RIFF based format, and the RIFF format is just a union of labeled chunks of data.
I don't know if it is usual nowadays, but wave editors used to add an INFO chunk adding their name to the files. This is just one of many things that can be also in the file. And then, there is the people that insist in adding tags to wave files...
You are right.
I think my motivation for including this check was that i wanted to make sure, that i don't unintentionally ignore additional wave data chunks possibly added by applications trying to circumvent the file formats size limitations. Maybe this is a non-issue, but as i wrote above, i am (obviously) not an expert for audio file formats.
I will modify the wave reader for the next release.
Read up to chunk size, and if you are not at the file end, then there's something else that you don't care.
...but please don't break -ihs switch
How can you say something so horrible?! I never would (intentionally...)!
I managed to finish a preview of a TAK benchmark due to a conversion issue.* This short test only covers TAK and not other multichannel encoders. The end result is that TAK 2.2.0 completed the test successfully without any errors, also noted encoding speed-ups with stereo material. Machine used: Athlon XP 3000+, 2GB, WD1.5GB SATA, WinXP SP3, NTFS.*
Source files:
DTS source 6ch 16bit 48KHz 3.29GB 102:19.125 RG -5.61dB
CD audio 1 2ch 16bit 44.1KHz 297MB 29:26.392 RG -9.75dB
CD audio 2 2ch 16bit 44.1KHz 304MB 30:07.258 RG -10.71dB
encoder / file enc timer301.exe (enc / dec)
(-p2 setting) ratio enc / dec speed (Kernel) (User) (Process)
-------------- ------ ----------------- ----------------------------------
TAK 2.2.0 DTS 40.30% 15.49x / 59.00x (2% / 13%) (95% / 75%) (98% / 88%)
TAK 2.2.0 CD 1 67.12% 115.10x / 197.68x (6% / 14%) (85% / 83%) (91% / 98%)
TAK 2.2.0 CD 2 68.96% 114.53x / 191.90x (5% / 12%) (86% / 84%) (91% / 96%)
TAK 2.1.0 CD 1 67.12% 110.49x / 192.62x (5% / 14%) (86% / 80%) (91% / 94%)
TAK 2.1.0 CD 2 68.96% 106.71x / 191.48x (5% / 12%) (84% / 83%) (90% / 95%)
bitcompared decoded TAK files with original WAV files = No differences.
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]*conversion issue: TAK reports Wave file not supported on WAV files with durations >02:04:16 (converted DTS->WAV using FB2K v1.1.6, foo_input_dts.dll v0.3.0 & specs above). Sizes of resulting WAV files are shown to be 4.04GB and 4.10GB even though every media player reports a durations of 02:04:16 for both those files. Anyone give me hint at fixing this (possibly) WAV header issue?[/size]
Anyone give me hint at fixing this (possibly) WAV header issue?
1) Convert DTS to W64.
2) Convert W64 to WAV, encode to TAK with (the above-mentioned) -ihs switch.
3) Compare W64 and TAK.
Added: according to takc help, -ihs works only in pipe mode...
takc.exe -e -ihs -p2 - out.tak < in.wav
I managed to finish a preview of a TAK benchmark due to a conversion issue.* This short test only covers TAK and not other multichannel encoders. The end result is that TAK 2.2.0 completed the test successfully without any errors, also noted encoding speed-ups with stereo material. Machine used: Athlon XP 3000+, 2GB, WD1.5GB SATA, WinXP SP3, NTFS.*
...
bitcompared decoded TAK files with original WAV files = No differences.
Thank you! That's good news.
*conversion issue: TAK reports Wave file not supported on WAV files with durations >02:04:16 (converted DTS->WAV using FB2K v1.1.6, foo_input_dts.dll v0.3.0 & specs above). Sizes of resulting WAV files are shown to be 4.04GB and 4.10GB even though every media player reports a durations of 02:04:16 for both those files. Anyone give me hint at fixing this (possibly) WAV header issue?
Well, add about half a second to 02:04:16 and your files exceed the 4 GB limit of the wave file format. There is little i can do besides adding support for something like the Wave64-Format.
takc.exe -e -ihs -p2 - out.tak < in.wav
Good idea! Currently i have no time to look at the source to check if this works for files larger than 4 GB. TAK's stream functions definitely support more than 4 GB, but i am not sure, if i have somewhere coded some restriction. Anyway, you will not be able to decode such a file while TAK only supports the standard wave format as output format...
Well, add about half a second to 02:04:16 and your files exceed the 4 GB limit of the wave file format. There is little i can do besides adding support for something like the Wave64-Format.
Ok, that makes sense. Those large WAV files were a DTS conversion of a concert DVD where all the channels were in one single WAV.
An intermediate step to the "RF64" option might be two different options: a) for the user, divide the concert into chapters; b) the program maybe could accommodate the 6-WAV approach (multiple WAV files of the the different channels) since it's likely each channel is less than 4GB by itself...
Good idea! Currently i have no time to look at the source to check if this works for files larger than 4 GB. TAK's stream functions definitely support more than 4 GB, but i am not sure, if i have somewhere coded some restriction. Anyway, you will not be able to decode such a file while TAK only supports the standard wave format as output format...
What can I say...
a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.
Resulting .w64 file is identical to the source.
What can I say...
a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.
Resulting .w64 file is identical to the source.
Thank you! I am surprised. Really nice.
Didn't have doubt about data integrity of TAK, I just can't benchmark with TAK converting via FB2K piped and get CPU% numbers to account for HDD bottlenecks. Also not really sure why FB2K writes a WAV that it can't read to-the-end correctly when converting from DTS, but the AC3filter utils' "valdec.exe" managed to do so.
This multichannel TAK implementation seems highly successful and since I will be looking to bench with chapter-split files I can run tests to compare the performance vs. ALAC-derived and have results before xmas
Great work, Thomas!
And here's some test results
Not sure exactly what settings to use with MP4ALS I ended up supplying using no arguments at all. Comparing that with -p0 TAK came up a little less compressed in every file. I re-ran with -p1 and TAK edged out every MP3ALS file, so I'm guessing the closet TAK setting to default MP4ALS for compression ratio is either -p0e or -p0m.
6ch 48KHz 16bit TAK 2.2.0alpha -p1 MP4alsRM23
WAV filesize ratio enc dec ratio enc dec
----- --------- ------ ------ ------ ------ ------ ------
D1-02 106.15 MB 44.95% 42.80x 81.36x 45.68% 13.00x 34.16x
D1-03 228.73 MB 41.33% 44.94x 87.38x 42.10% 13.15x 35.49x
D1-05 407.76 MB 33.35% 48.04x 97.76x 34.04% 13.66x 36.94x
D1-08 506.63 MB 42.42% 44.79x 86.55x 43.47% 13.00x 36.78x
D1-10 140.89 MB 45.28% 44.01x 87.80x 46.21% 13.12x 36.81x
D2-05 153.60 MB 43.40% 44.08x 81.35x 43.98% 12.95x 34.61x
D2-09 201.40 MB 36.35% 47.12x 90.26x 37.13% 13.45x 37.67x
D2-10 378.39 MB 42.43% 44.40x 87.83x 43.04% 12.88x 37.27x
D2-11 296.93 MB 45.78% 42.19x 84.29x 46.29% 12.79x 36.19x
D2-18 340.04 MB 45.58% 43.54x 85.02x 46.55% 12.84x 36.79x
D3-02 87.80 MB 49.94% 42.81x 76.37x 51.55% 12.87x 37.89x
D3-05 184.21 MB 48.95% 43.27x 81.93x 50.45% 12.91x 36.44x
D3-09 211.97 MB 45.15% 44.26x 86.97x 46.62% 12.86x 35.85x
D3-11 501.20 MB 44.19% 44.04x 84.76x 45.54% 12.90x 36.61x
D3-12 191.09 MB 46.88% 44.00x 83.70x 48.29% 12.91x 36.56x
I did try the settings from the TAK 2.2.0 development thread but MP4ALS encoder was so incredibly slow I abandoned the test early on, but here's what I got:
6ch 48KHz 16bit TAK 2.2.0alpha -p2m MP4alsRM23 -7 -o160 -t6
WAV filesize ratio enc dec ratio enc dec
----- --------- ------ ------ ------ ------ ------ ------
D1-02 106.15 MB 43.72% 4.184x 76.83x 43.12% 0.206x 7.12x
D1-03 228.73 MB 40.38% 4.231x 74.86x 39.58% 0.209x 7.55x
D1-05 407.76 MB 32.70% 4.357x 84.39x 32.40% 0.220x 8.41x
D1-08 506.63 MB 41.07% 4.087x 75.10x 40.66% 0.211x 9.07x
D1-10 140.89 MB 44.11% 4.134x 79.31x 43.30% 0.209x 7.09x
Didn't have doubt about data integrity of TAK, I just can't benchmark with TAK converting via FB2K piped and get CPU% numbers to account for HDD bottlenecks.
Doubts wouldn't be totally unjustified. There must be a reason, why i call it an alpha release...
Not sure exactly what settings to use with MP4ALS I ended up supplying using no arguments at all. Comparing that with -p0 TAK came up a little less compressed in every file. I re-ran with -p1 and TAK edged out every MP3ALS file, so I'm guessing the closet TAK setting to default MP4ALS for compression ratio is either -p0e or -p0m.
Usually a -p1x setting is comparable to the default mode of Mpeg4Als. Then both are using 12 predictors (like FLAC -8). The significantly better performance of -p1 provides an indication, that your files provide good opportunities for TAK's channel decorrelation algorithms. And those seem to be more efficient than Mpeg4Als' ones. This advantage may compensate for the lower predictor count (4) of -p0x.
I am really glad to see an advantage of TAK's channel decorrelation algorithms on your files, because most of the work has gone into them. Since my multi channel test file corpus is still small, i really couldn't be sure if the advantage would also manifest in other comparisons.
I did try the settings from the TAK 2.2.0 development thread but MP4ALS encoder was so incredibly slow I abandoned the test early on, but here's what I got:
More nice results.
Could you please test those 5 files with -p4m?
You really made my day. Thank you!
The -p4m results:
6ch 48KHz 16bit TAK 2.2.0alpha -p2m TAK 2.2.0alpha -p4m MP4alsRM23 -7 -o160 -t6
WAV filesize ratio enc dec ratio enc dec ratio enc dec
----- --------- ------ ------ ------ ------ ------ ------ ------ ------ ------
D1-02 106.15 MB 44.00% 4.184x 76.83x 43.85% 3.079x 62.78x 43.12% 0.206x 7.12x
D1-03 228.73 MB 40.38% 4.231x 74.86x 40.18% 3.121x 60.16x 39.58% 0.209x 7.55x
D1-05 407.76 MB 32.70% 4.357x 84.39x 32.49% 3.312x 61.38x 32.40% 0.220x 8.41x
D1-08 506.63 MB 41.07% 4.087x 75.10x 40.94% 3.018x 68.00x 40.66% 0.211x 9.07x
D1-10 140.89 MB 44.11% 4.134x 79.31x 43.91% 3.159x 62.90% 43.30% 0.209x 7.09x
Note: I initially noticed for the file D1-02 the ratio of -p2m was better than -p4m and found it was a error in calculation or a typo, so it's fixed. I double-checked the other files' ratios for -p2m and there were no further errors/typos.
Speaking of 'no errors,' all my tests with -p0, -p1, p2m and -p4m were decompressed and bit-compared, still no errors found
The -p4m results:
...
Speaking of 'no errors,' all my tests with -p0, -p1, p2m and -p4m were decompressed and bit-compared, still no errors found
This was fast!
Ok, nevertheless Mpeg4Als here compresses better, although at the price of about 15 times slower encoding and about 9 times slower decoding. Not to mention, that it's using bigger frames which also are not independent, so that you for instance would loose much more audio data in case of a single bit error.
That's not meant as an excuse. It simply illustrates, why i don't want to modify TAK in a similar way to improve it's compression. I really like high speeds and small, independent frames of audio data.
And thank you again!
Ok, nevertheless Mpeg4Als here compresses better, although at the price of about 15 times slower encoding and about 9 times slower decoding. Not to mention, that it's using bigger frames which also are not independent, so that you for instance would loose much more audio data in case of a single bit error.
That price of roughtly 0.5% for the speed isn't worth it, IMO. Although this ALS is unoptimized I have yet to seen any optimizations from this lossless format.
This was fast!
You can thank TAK for that, and the fact I didn't re-run the ALS tests. Actually, once I get my initial test script written it's really easy to change the settings. It was the first run of testing where that error of the -p2m compression ratio came from (sorry about that) and I got the script errors fixed after.
What can I say...
a) 12.7GB .W64 file was converted to 12.7GB .WAV
b) This .WAV file was converted to 5.56 GB .TAK file (takc.exe -e -ihs -p2 - out.tak < in.wav).
c) Then .TAK file was decoded back to .W64 with foobar2000.
Resulting .w64 file is identical to the source.
Thank you! I am surprised. Really nice.
I somehow overlooked lvqcl using pipe input off redirect instead of using FB2K. Now I should start saving up for glasses, apologies.
I also wanted to inquire: would there be interest for other testing 24-bit DTS->WAV files? I can see one point of interest (to measure TAK's ability on that bit-depth) as well as a point of non-interest (persons don't much convert DTS->WAV anyway, much less at 24-bit since there nearly zero audible advantages). At any rate, the DTS decoder gave me the option of 16 or 24 bits. I suppose it's more interesting to test on 24/48 or even 24/96 multichannel material but I have no such material.
I also wanted to inquire: would there be interest for other testing 24-bit DTS->WAV files? I can see one point of interest (to measure TAK's ability on that bit-depth) as well as a point of non-interest (persons don't much convert DTS->WAV anyway, much less at 24-bit since there nearly zero audible advantages). At any rate, the DTS decoder gave me the option of 16 or 24 bits. I suppose it's more interesting to test on 24/48 or even 24/96 multichannel material but I have no such material.
I agree. Testing of true 24-bit material would be nice, but testing of an 24-bit version of your DTS files would not really be informative. The results may be similar to the 16-bit results. If not, the difference may be attributed to the output stage of the decoder, whose properties are of little interest for us.
Maybe you could test your files with FLAC and WavPack to obtain a more complete picture?
Well, somehow this release is a bit problematic because it adds a feature only few users will be using and this means even less testers. I am not sure, if i will immediately release a final version or insert a beta release. The latter may be tried by more users who possibly don't want to touch alpha releases. In fact this only means a different label, because only the wave reader has been slightly modified.
Maybe you could test your files with FLAC and WavPack to obtain a more complete picture?
I would be happy if someone included WavPack in the comparison, but I believe that the configuration used in the other testing thread (-hhx) might be suboptimal for multichannel and high sampling rates. The first issue is that multichannel WavPack files will use shorter blocks and those end up being less efficient with the longer headers of the very high mode, so it might even be that the regular high mode (-h) is better (and certainly faster to encode and decode). Also, the -x1 to -x3 options are optimized for regular 44.1 KHz audio, so they are not ideal for the LFE channel of a multichannel stream or 96 KHz sampling rates. The -x4 to -x6 options generate custom decorrelation filters, so they work better (sometimes much better) than the lower ones in these cases.
Maybe a good comparison configuration (that would not be too slow at encoding) would be -hx4 (or even -x4 if that was still too slow). These might improve WavPack's compression a little compared to the other test (especially at 96 or 192 KHz), but I'm sure it still won't get close to the values for this new TAK (which is a great piece of work, Thomas, congratulations!)
David
Tested TAK 2.2.0 Alpha on an HDCD album "Sara Evans - Stronger (2011)" [Peak extension disabled]
Original album size [compressed using Monkey's Audio High (-c3000)]
256 MB
Size of album after decompressing to 24-bit WAV, then compressed with TAK 2.2.0 Alpha (-p4m)
255 MB
Nice to know that you could listen to this type of HDCD album in foobar2000 without having to use the HDCD plugin, save 1 MB an album in the process, and also use ReplayGain with the TAK files as well.
MD5 - CRC Comparison:
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.tak"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.wav"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.tak"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.wav"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.tak"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.wav"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.tak"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.wav"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.tak"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.wav"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.tak"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.wav"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.tak"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.wav"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.tak"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.wav"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.tak"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.wav"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).tak"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).wav"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
All items decoded successfully.
Bit Comparison:
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.tak"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.wav"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.tak"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.wav"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.tak"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.wav"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.tak"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.wav"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.tak"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.wav"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.tak"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.wav"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.tak"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.wav"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.tak"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.wav"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.tak"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.wav"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).tak"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).wav"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
All items decoded successfully.
Ran another test on another HDCD album "Carly Simon - Boys In The Trees (1978)' [Peak extension enabled] This time, though, I decompressed the original album into 24-bit WavPack files (Extra High) and compared it to TAK 2.2.0 Alpha to see how it handled block size
WavPack (Extra High)
254 MB
TAK 2.2.0 Alpha (-p4m)
231 MB
That's a 23 MB difference in file size (in TAK 2.2.0 Alpha's favor)
MD5 - CRC Comparison:
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.tak"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.wav"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.tak"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.wav"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.tak"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.wav"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.tak"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.wav"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.tak"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.wav"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.tak"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.wav"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.tak"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.wav"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.tak"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.wav"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.tak"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.wav"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).tak"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).wav"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
All items decoded successfully.
Bit Comparison:
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.tak"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\01. Desperately.wav"
MD5: EA41B8E89DCF097D78D6F7F7A52F9CC4
CRC32: 99BB3CD7
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.tak"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\02. A Little Bit Stronger.wav"
MD5: F323EB8CC18FA1467A08BD966948A702
CRC32: 5D6CB218
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.tak"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\03. My Heart Can't Tell You No.wav"
MD5: EFBDB2BA5D2CF4090CBBC52CB859BE60
CRC32: FF639028
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.tak"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\04. Anywhere.wav"
MD5: 486998CCBB67C144CE6786019371E036
CRC32: CD82EF1D
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.tak"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\05. Alone.wav"
MD5: 243DE8364D81FFC8FE33107273E65863
CRC32: B7F53113
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.tak"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\06. Ticket To Ride.wav"
MD5: C45F19A945CB72CCA8B81150851A932A
CRC32: 76B7E44F
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.tak"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\07. Life Without Losing.wav"
MD5: B0526DE645D9B10EC1D2B63D1F6DBB3B
CRC32: 3A2723C1
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.tak"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\08. What That Drink Cost Me.wav"
MD5: B9E747A5210E29796CAF720035DF2809
CRC32: A5D464CE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.tak"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\09. Wildfire.wav"
MD5: 045DAAC28BA8FBF5B6F06D84D2C42C5A
CRC32: 5739ECFE
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).tak"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
Item: "C:\Documents and Settings\Default User\My Documents\My Music\Sara Evans\2011 - Stronger (HDCD)\10. Born To Fly (Bluegrass Version).wav"
MD5: 1563D1F2FB08BAE898CDC1B3B3EDCE47
CRC32: 75AFC5AC
No problems found.
All items decoded successfully.
Maybe you could test your files with FLAC and WavPack to obtain a more complete picture?
I would be happy if someone included WavPack in the comparison, but I believe that the configuration used in the other testing thread (-hhx) might be suboptimal for multichannel and high sampling rates. The first issue is that multichannel WavPack files will use shorter blocks and those end up being less efficient with the longer headers of the very high mode, so it might even be that the regular high mode (-h) is better (and certainly faster to encode and decode). Also, the -x1 to -x3 options are optimized for regular 44.1 KHz audio, so they are not ideal for the LFE channel of a multichannel stream or 96 KHz sampling rates. The -x4 to -x6 options generate custom decorrelation filters, so they work better (sometimes much better) than the lower ones in these cases.
Maybe a good comparison configuration (that would not be too slow at encoding) would be -hx4 (or even -x4 if that was still too slow). These might improve WavPack's compression a little compared to the other test (especially at 96 or 192 KHz), but I'm sure it still won't get close to the values for this new TAK (which is a great piece of work, Thomas, congratulations!)
David
I am embarrassed to admit that I did not remember WavPack handled multichannel (nor FLAC). My apologies. I have a good idea why I might have missed knowing so.
At any rate, I am most happy to run some more tests. Here's what I have got to work with: DTS extracted from DVD's, hard rock music at live venues, 5.1 channels, 48KHz. I suppose (unless advised otherwise) WavPack -h and FLAC -8.
I will also use a slightly different test corpus than previous tests. I noticed D1-05 was noticeably different from other files and plan to focus on those (FYI, I recall D1-05 was a solo acoustic guitar performance w/no vocals).
Thanks to all (especially Thomas) for their feedback
Maybe a good comparison configuration (that would not be too slow at encoding) would be -hx4 (or even -x4 if that was still too slow). These might improve WavPack's compression a little compared to the other test (especially at 96 or 192 KHz), but I'm sure it still won't get close to the values for this new TAK (which is a great piece of work, Thomas, congratulations!)
Thank you, this means a lot to me!
Tested TAK 2.2.0 Alpha on an HDCD album "Sara Evans - Stronger (2011)" [Peak extension disabled]
...
All items decoded successfully.
...
Ran another test on another HDCD album "Carly Simon - Boys In The Trees (1978)' [Peak extension enabled] This time, though, I decompressed the original album into 24-bit WavPack files (Extra High) and compared it to TAK 2.2.0 Alpha to see how it handled block size
...
All items decoded successfully.
Great! Thank you.
At any rate, I am most happy to run some more tests. Here's what I have got to work with: DTS extracted from DVD's, hard rock music at live venues, 5.1 channels, 48KHz. I suppose (unless advised otherwise) WavPack -h and FLAC -8.
I will also use a slightly different test corpus than previous tests. I noticed D1-05 was noticeably different from other files and plan to focus on those (FYI, I recall D1-05 was a solo acoustic guitar performance w/no vocals).
And... time for another 'Thank you'.
Ran another test on another HDCD album "Carly Simon - Boys In The Trees (1978)' [Peak extension enabled] This time, though, I decompressed the original album into 24-bit WavPack files (Extra High) and compared it to TAK 2.2.0 Alpha to see how it handled block size
WavPack (Extra High)
254 MB
TAK 2.2.0 Alpha (-p4m)
231 MB
That's a 23 MB difference in file size (in TAK 2.2.0 Alpha's favor)
Thanks for including WavPack in your test!
I'm not sure what command-line options you used, but adding "--blocksize=256 --merge-blocks" can make a huge improvement for decoded HDCD files. WavPack blocks are pretty big by default, and so special options are required to get good results from these files (or lossyWAV files, which have similar kind of redundancy).
The original tests were run using the highest compression levels of both codecs, without modification. Didn't think to add the relative switches for block size control. So I redid the test again with them in the mix.
Carly Simon - Boys In The Trees (1978) [HDCD] (Peak extension enabled)
TAK -p4m -fsl512
220 MB
WavPack -h -x2 --blocksize=256 --merge-blocks
219 MB
This time around, WavPack has a 1 MB edge. Extremely close.
Any chance to play tak format with windows media player ?
Ljubo44: http://liviocavallo.altervista.org/ (http://liviocavallo.altervista.org/)
Tired before, installed from C:/Temp from bat as admin without errors on w7 64. But..
Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file.
Tired to replace newer "tak_deco_lib.dll" in windows/system32. But same message from wmp
Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file.
anyway thanks for help.
I want to prepare a final release.
Therefore, if anyone has encountered any problems with this alpha release, now is a good time to report them.
Currently the only difference between this alpha and the final release consists in a modified wave file reader, which supports meta data located at the end of the wave file. Not enough to initiate an additional beta release.
I dont have any multichannel file, but if any test with standard files is needed I will be happy to help.
*bump*
Hello Thomas,
On the Hydrogenaudio KB (http://wiki.hydrogenaudio.org/index.php?title=TAK#Future_Features) I can see cue sheets and cover art are already on your to-do list, but how much of a priority are they?
Currently I'm using WavPack (-hhx -w "Cuesheet=@*.cue" --write-binary-tag "Cover Art (Front)=@*.png"). I've already been experimenting a little with TAK and of course I can add cue sheets and cover art afterwards with Mp3tag because of the APEtag, but once TAK supports it natively I'm really thinking of switching over.
Keep up the good work!
Therefore, if anyone has encountered any problems with this alpha release, now is a good time to report them.
No problems here, all the TAK files decoded with no differences. Obviously I didn't get my last comparison done, there was desktop computer disaster (an electricity outage in my area made my harddrives disappear from the BIOS, turned out half the power regulating capacitors on the mainboard blew). I'll slate that comparison after final release of 2.2.0.
I dont have any multichannel file, but if any test with standard files is needed I will be happy to help.
Since i have performed a lot of code optimizations which affect standard files as well, i would be happy if you tested the final release.
*bump*
Hello Thomas,
On the Hydrogenaudio KB (http://wiki.hydrogenaudio.org/index.php?title=TAK#Future_Features) I can see cue sheets and cover art are already on your to-do list, but how much of a priority are they?
Currently I'm using WavPack (-hhx -w "Cuesheet=@*.cue" --write-binary-tag "Cover Art (Front)=@*.png"). I've already been experimenting a little with TAK and of course I can add cue sheets and cover art afterwards with Mp3tag because of the APEtag, but once TAK supports it natively I'm really thinking of switching over.
Keep up the good work!
The inclusion of the cuesheet should already work, although not with the '*' placeholder:
-tt # Add textual tag item #, where # is a key/value pair: "key=value",
for instance "TITLE=A nice song". "key=@file" will read the value
from the text(!) file "file" in the source directory.
The support for binary items like pictures is now on my todo list for V2.2.1. If nothing intervenes.
No problems here, all the TAK files decoded with no differences.
Fine!
Obviously I didn't get my last comparison done, there was desktop computer disaster (an electricity outage in my area made my harddrives disappear from the BIOS, turned out half the power regulating capacitors on the mainboard blew). I'll slate that comparison after final release of 2.2.0.
Good idea!
Thomas
TAK 2.2.0 Final (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89610&view=findpost&p=762614)
has been released.
surprisingly!
Very good news!
Thank you!
Therefore i am very interested into compression results and comparisons with other codecs.
I have done some testing:
Chris Rea_test (Driving Home For Christmas sample)
WAV (16bit 44.1KHz, 11.733s) 1411Kbps, 2021.23KB, 100%
FLAC 1.2.1 [-8] 861Kbps, 1233.17KB, 61.01%
TTA 3.4.1 [-e] 852Kbps, 1220.10KB, 60.36%
WavPack 4.60.1 [-hhx] 837Kbps, 1199.49KB, 59.34%
TAK 2.0.0 [-e -p4m] 812Kbps, 1163.19KB, 57.55%
TAK 2.1.0 [-e -p4m] 812Kbps, 1163.02KB, 57.54%
TAK 2.2.0 [-e -p4m] 812Kbps, 1163.10KB, 57.54%
Monkey's Audio 4.10 [-c3000] 819Kbps, 1172.99KB, 58.03%
Monkey's Audio 4.10 [-c4000] 804Kbps, 1151.77KB, 56.98%
Monkey's Audio 4.10 [-c5000] 796Kbps, 1140.78KB, 56.44%
OptimFROG 4.600ex [--encode --mode bestnew --seek min --optimize best] 791Kbps, 1133.00KB, 56.05%
OptimFROG 4.910b [--encode --mode bestnew --seek min --optimize best] 790Kbps, 1131.81KB, 56.00%
OptimFROG 4.600ex [--maximumcompression --experimental] (decode error!) 788Kbps, 1129.07KB, 55.86%
OptimFROG 4.910b [--maximumcompression --experimental] (±55% cpu lol!) 787Kbps, 1127.71KB, 55.79%
LA 0.4b [-high] 790Kbps, 1130.99KB, 55.96%
Gladiator Soundtrack
WAV (16bit 44.1KHz, 1h:01m:38.293s) 1411Kbps, 637088.86KB (622.16MB), 100%
FLAC 1.2.1 [--best] 706Kbps, 318757.12KB (311.29MB), 50.03%
WavPack 4.60.1 [-hhx] 702Kbps, 317369.66KB (309.93MB), 49.82%
TAK 2.1.0 [-e -p4m] 684Kbps, 308839.48KB (301.60MB), 48.48%
TAK 2.2.0 [-e -p4m] 684Kbps, 308865.17KB (301.63MB), 48.48%
Monkey's Audio 4.10 [-c3000] 687Kbps, 310348.86KB (303.08MB), 48.71%
Monkey's Audio 4.10 [-c4000] 680Kbps, 307066.54KB (299.87MB), 48.20%
Monkey's Audio 4.10 [-c5000] 676Kbps, 305098.90KB (297.95MB), 47.89%
Angra - Temple of Shadows
WAV (16bit 44.1KHz, 1h:06m:34.533s) 1411Kbps, 688120.82KB (671.99MB), 100%
FLAC 1.2.1 [--best] 986Kbps, 480797.87KB (469.53MB), 69.87%
WavPack 4.60.1 [-hhx] 971Kbps, 473486.58KB (462.39MB), 68.81%
TAK 2.1.0 [-e -p4m] 957Kbps, 466692.68KB (455.75MB), 67.82%
TAK 2.2.0 [-e -p4m] 957Kbps, 466720.24KB (455.78MB), 67.83%
Monkey's Audio 4.10 [-c3000] 960Kbps, 468348.68KB (457.37MB), 68.06%
Monkey's Audio 4.10 [-c4000] 952Kbps, 464030.97KB (453.16MB), 67.43%
Monkey's Audio 4.10 [-c5000] 948Kbps, 462497.08KB (451.66MB), 67.21%
LA 0.4b [-high] 939Kbps, 457720.45KB (446.99MB), 66.52%
Royal Hunt - Paper Blood
WAV (16bit 44.1KHz, 56m:51.027s) 1411Kbps, 587602.68KB (573.83MB), 100%
FLAC 1.2.1 [--best] 1097Kbps, 456942.46KB (446.23MB), 77.76%
WavPack 4.60.1 [-hhx] 1089Kbps, 453645.32KB (443.01MB), 77.20%
TAK 2.1.0 [-e -p4m] 1082Kbps, 450697.51KB (440.13MB), 76.70%
TAK 2.2.0 [-e -p4m] 1083Kbps, 450738.92KB (440.17MB), 76.71%
Monkey's Audio 4.10 [-c3000] 1081Kbps, 449852.87KB (439.31MB), 76.56%
Monkey's Audio 4.10 [-c4000] 1078Kbps, 448739.60KB (438.22MB), 76.37%
Monkey's Audio 4.10 [-c5000] 1075Kbps, 447681.16KB (437.19MB), 76.19%
...what may on average result in about 0.01 percent worse compression.
I come to the same conclusion, although I would've loved seeing some more compression strength. The codec is already fast enough imho.
One funny detail about about my results; TAK -e -p4m beats Monkey's Audio 'High' in all cases except the last one (1082 vs 1081Kbps). Although my lossless collection is still rather small, Paper Blood appeared to be the hardest to compress.
The inclusion of the cuesheet should already work, although not with the '*' placeholder:
-tt # Add textual tag item #, where # is a key/value pair: "key=value",
for instance "TITLE=A nice song". "key=@file" will read the value
from the text(!) file "file" in the source directory.
Takc.exe -e -p4m -tt "Cuesheet=@filename.cue" <infile> <outfile.tak> doesn't work. Neither when I include the full directory path.
"Command line error: Error reading tag file" is what I get.
Updated my test with TTA, WavPack, TAK.
Generally, TAK looses to ALS, but is rocket fast.
I haven't decided which one do I want to use yet...Really, I expected TAK to do better.
http://www.hydrogenaudio.org/forums/index....showtopic=89649 (http://www.hydrogenaudio.org/forums/index.php?showtopic=89649)
Updated my test with TTA, WavPack, TAK.
I took the freedom to post an excerpt of your data in the final release thread. I hope, that's ok?
I have done some testing:
Thank you!
...what may on average result in about 0.01 percent worse compression.
I come to the same conclusion, although I would've loved seeing some more compression strength. The codec is already fast enough imho.
I don't think i can significantly improve the compression without making decoding slower.
One funny detail about about my results; TAK -e -p4m beats Monkey's Audio 'High' in all cases except the last one (1082 vs 1081Kbps). Although my lossless collection is still rather small, Paper Blood appeared to be the hardest to compress.
As a rule of thumb: The harder files are to compress, the worse TAK will perform compared to MAC. When it comes to highly compressible files, usually dynamically rich and tonal, TAK can do even better than MAC Extra, as can be seen in the FLAC comparison.
The inclusion of the cuesheet should already work, although not with the '*' placeholder:
Takc.exe -e -p4m -tt "Cuesheet=@filename.cue" <infile> <outfile.tak> doesn't work. Neither when I include the full directory path.
"Command line error: Error reading tag file" is what I get.
Strange. Where is the cue file located? In the source directory?
Updated my test with TTA, WavPack, TAK.
I took the freedom to post an excerpt of your data in the final release thread. I hope, that's ok?
Sure
Strange. Where is the cue file located? In the source directory?
Yes, in the source directory. But I think I figured it out. Initially I used the following command line:
wvunpack <infile.wv> - | Takc -e -p4m -tt "Cuesheet=@infile.cue" - <outfile.tak>
Which results in the error I mentioned before.
When I first decode the wv-file and use the wav-file as source it does seem to work. So it appears the TAK encoder can't load the cue-file properly when being used in a pipe.
When I then insert the tak-file in Foobar however, it doesn't load the cuesheet at all. After examining the tak-file in MP3tag there appear to be two cuesheet-entries. A cuesheet-entry with the correct content, but also a blank one (with no content). Manually deleting the blank cuesheet-entry in MP3tag does the trick, but still there appears to be something going wrong in the process.
I don't think i can significantly improve the compression without making decoding slower.
As long as it doesn't become as slow as Monkey's Audio 'Insane' I really don't mind some degeneration. I think a lot more people wouldn't mind either. Someone should hold a poll some time.
Thank you for the info! I will look into it for the next release. Probably very few (if any) users have tried TAK's tagging functionality, what might explain why this bug has not been reported earlier.