Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK 2.2.0 development (Read 36111 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

TAK 2.2.0 development

Initially i thought, the next release would be 2.1.1.

I implemented

  - up to 10 percent faster encoding
  - up to 20 percent faster decoding
  - support for wave format extensible.

The latter was a preparation for multi channel audio support which i intended to implement in a later TAK version. But somehow i coudn't stop at this point. I was too curious to find out, what i could achieve. Now that i have a first working implementation, i also have a lot of questions.

I myself don't use any multi channel audio and my knowledge about it's practical application is very limited. More precise: I don't know, what kind of multi channel files files TAK users would like to compress. I have to know this to be able to tune TAK for the most likely application. It's easy to store the channels independently with TAK's codec, but i also want to exploit channel correlations to apply an extended version of TAK's joint stereo algorithms.

My evaluations seem to show, that the results depend to a high degree on the source material. Since i don't have the time to perform tunings for any possible format at once, i want to start with the formats users would like to compress.

What would they be?

Currently i am only testing 5.1 formats. Currently i am using the following files for tuning:

- HiRes-sample-files from 2L. Mostly 96 KHz converted from a DXD source.
- A 96 KHz version of Hotel California/ Eagles, DVD-A Audio.
- Several albums of CD-DTS-Audio (44 KHz) converted with foobar to wave. (Feeling a bit strange when converting lossy to lossless...)

I really have no idea, if those samples refelect by any means the possible applications of TAK users.

And therefore i have opened this thread. Please tell, what kind of multi channel audio you would like to compress with TAK.

I could have made a poll, but currently i simply don't know enough to ask the right questions.

TAK 2.2.0 development

Reply #1
Hi Thomas, congrats for your codec!
I still use FLAC and some WavPack, however I'm always quick peeping on TAK.

All my music is Stereo. I even don't have mono files.

I am yet to see the point of multi-channel audio in music consumer market and I myself never bought any SACD or DVD-A. The movie market uses it a lot. The only thing I could think of using it was if I would encode a Blu-Ray using h.264 and 5.1 TAK audio. That would be the only scenario really, in which I would encode 5.1

IMO, multi-channel audio should not be a priority now. I see that you have improved even more TAK performance and that makes me want more and more a Linux version. Sorry if I bring this up again, I just did it because you're feeling unsure about multi-channel. Of course there are other users who will want multi-channel, so let's hear them too.

TAK 2.2.0 development

Reply #2
Hi TBeck,
I think almost the same as krafty, I still use Flac but I always have a look at Tak's thread because it is so impressive. Like him, I only use stereo right now but as he said, IMHO, the main use for 5.1 is to encode DTS-HD Master Audio & Dolby TrueHD from blu-ray with eac3to in matroska container.
The use for multichannel with music is IMHO a niche market for highly experimented users doing unusual rips.

Unlike krafty, I think multi-channel should be moderately high on your TODO list, because it opens TAK to the the video world which is a good thing because many skilled developers from Doom9 could have a look at your code & criticize your work.

EDIT: ... forgive me, I forgot TAK was closed source. [Sorry, I couldn't resist teasing Greynol & his colored warnings  Just Kidding]

The DTS Master sample from Dances With Wolves that I personnaly use when I test 5.1 is 24bits per sample & 48Khz, but I think blu-ray supports many scenari, have a look at the DTS-HD Master Audio & Dolby TrueHD links that I posted above to have a clue of the variety, I have no clue which bit-depth/sample rate is the most widely used as I don't rip blu-ray regulary (I still have a Sempron 3000+ so I don't even try).

Have a look at this Blu-Ray audio codecs table for a summary.

TAK 2.2.0 development

Reply #3
Thomas,

During the development of lossyWAV, I looked to accommodate the upper capabilities of the first lossless codec to which the method was applicable, namely FLAC. This resulted in 8 channel support and up to 24 bit integer support. I limited the samplerate support to 384kHz due to memory considerations and availability of samples - although this can be changed relatively simply.

As there are 7.1 setups out in the wild, I would suggest 8 channel support.

Have fun in the development!

Nick.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

TAK 2.2.0 development

Reply #4
I would guess a majority of interest in multichannel lossless would be in current and next-generation movie discs that use lossless formats. DTS could also be of interest in "old" discs like CD and DVD. I, too, feel the creepy weirdness of a lossy format handled by a lossless compressor, but then I think of it as "data preserved in its entirety and accuracy without a widely available lossless source," then it seems slightly less spooky. Or not?

Seems DVD-A is largely ignored and I personally don't know of that many collectors. Does this standard implement loudness standards similar to the standard set by the motion picture industry? If not, then IMO the format seems even more worthless. Myself (and probably many readers here) would be in favor of loudness standard in the next-gen music format. As it turned out, seems MP3/AAC became the masses' format of choice and not DVD-A. But I digress, I just have the opinion DVD-A may not be as high interest for this multichannel endeavor.

I'm out of my league though, most of the material I compress losslessly are mono tracks. Also I have no experience with extracting multichannel audio from disc. I imagine there are some music vendors to download from but are there enough to give TAK a full variety of test material?

Will be happy to see the speed-ups, though.
"Something bothering you, Mister Spock?"

TAK 2.2.0 development

Reply #5
I personally don't see much point for a multichannel lossless encoder. If I am using multichannel for film copies etc, I will either keep the AC3 or DTS track if I am going for quality. If size is my concern, It'll be compressed with a lossy encoder such as AAC tp get the BR right down. The middle ground seems of little use to me.

Each to their own though  but thats my view.

TAK 2.2.0 development

Reply #6
Hi Thomas

First of all, congratulations on your amazing work.
I am not a TAK user yet, but I do follow it's development here with a lot of interest...

Regarding your question, perhaps one interesting use for multichannel audio would be as an intermediate/storage codec in videography, seeing that many cameras capture 5.1 audio, and the correlation between the channels would be very high...

By the way, can I take this opportunity to ask you a couple of things about TAK?

1. How suitable is TAK to be implemented in hardware?

2. What error correction / checksum features are implemented in TAK's file format?
(FLAC, if I'm not mistaken, checksums every frame and does an MD5 for the whole stream. Does TAK do something similar?)

TAK 2.2.0 development

Reply #7
IMO, multi-channel audio should not be a priority now. I see that you have improved even more TAK performance and that makes me want more and more a Linux version. Sorry if I bring this up again, I just did it because you're feeling unsure about multi-channel. Of course there are other users who will want multi-channel, so let's hear them too.

To me it's perfectly ok if someone asks for linux suport. This is likely to have an influence on my priority list. 

What should be avoided are discussions about linux support and going open source, because such discussions got quite nasty in the past. Furthermore they would be fruitless because i have deceided not to talk about those topics unless i am already working on those features.

Unlike krafty, I think multi-channel should be moderately high on your TODO list, because it opens TAK to the the video world which is a good thing because many skilled developers from Doom9 could have a look at your code & criticize your work.

EDIT: ... forgive me, I forgot TAK was closed source. [Sorry, I couldn't resist teasing Greynol & his colored warnings  Just Kidding]

Thank you for reminding me...  And also for the links.

During the development of lossyWAV, I looked to accommodate the upper capabilities of the first lossless codec to which the method was applicable, namely FLAC. This resulted in 8 channel support and up to 24 bit integer support. I limited the samplerate support to 384kHz due to memory considerations and availability of samples - although this can be changed relatively simply.

As there are 7.1 setups out in the wild, I would suggest 8 channel support.

Have fun in the development!

Thank you! 

TAK's stream format now supports up to 16 channels. Initially it was designed for 32 channels, but i think that would be overkill. Ok, while looking for info about multichannel audio i read over an article about an 22 channel format specification, but i doubt, many people would install so many speakers.

16 channels is nice, because it provides some headroom for moderate extensions of the existing formats (7.1).

While the stream supports up to 16 channels, the first encoder version may be limited to 6 channels because i tend to only unlock support for formats the codec already is tuned for.

I would guess a majority of interest in multichannel lossless would be in current and next-generation movie discs that use lossless formats. DTS could also be of interest in "old" discs like CD and DVD. I, too, feel the creepy weirdness of a lossy format handled by a lossless compressor, but then I think of it as "data preserved in its entirety and accuracy without a widely available lossless source," then it seems slightly less spooky. Or not?

Good point!

I'm out of my league though, most of the material I compress losslessly are mono tracks. Also I have no experience with extracting multichannel audio from disc. I imagine there are some music vendors to download from but are there enough to give TAK a full variety of test material?

That's the problem and possibly also part of the answer...

I personally don't see much point for a multichannel lossless encoder. If I am using multichannel for film copies etc, I will either keep the AC3 or DTS track if I am going for quality. If size is my concern, It'll be compressed with a lossy encoder such as AAC tp get the BR right down. The middle ground seems of little use to me.

Each to their own though  but thats my view.

Perfectly understandable.

1. How suitable is TAK to be implemented in hardware?

TAK's decoder complexity is basically quite similar to FLAC's, as long as it isn't using more predictors for the linear prediction filter. The predictor count depends on the preset:

-p0x: 4 predictors. This is less than FLAC -3 is using (6).
-p1x: 12 predictors. This is the same as for FLAC -8.
-p2x: 32 predictors. The maximum FLAC supports, but outside of it's restricted subset. To my knowledge the higher presets of FLAKE are using up to 32 predictors.
-p3x: 80 predictors.
-p4x: 160 predictors.

It doesn't make a difference, if you use TAK's higher evaluation levels like -p1e or -p1m. They will only affect the encoding speed and compression ratio, but not the decoding complexity.

Since TAK is using a reduced precision for it's predictor filter, it may be implemented more efficently than FLAC on some hardware platforms, if optimized code is beeing generated. That's especially true for 24 bit audio.

2. What error correction / checksum features are implemented in TAK's file format?
(FLAC, if I'm not mistaken, checksums every frame and does an MD5 for the whole stream. Does TAK do something similar?)

Frame header checksum:  TAK: 24 bits, FLAC: 8 bits.
Frame data checksum:  TAK: 24 bits, FLAC: 16 bits.
Meta data item checksum: TAK: 24 bits, FLAC: i don't know.

MD5 of the raw audio data: TAK: has to be enabled by -md5, FLAC: is enabled by default.

TAK 2.2.0 development

Reply #8
Thanks for the info
With all your constant optimizations, how x86-specific is the code, if I may ask...

About the -md5 switch:
Is the MD5 info always written on encode, but only checked with -md5 on decode?
Or is it only written on encode with -md5?
And if the MD5 info is present in the file, is it automatically checked, or does it need -md5?

 

TAK 2.2.0 development

Reply #9
Initially i thought, the next release would be 2.1.1.

I implemented

  - up to 10 percent faster encoding
  - up to 20 percent faster decoding
  - support for wave format extensible.

The  latter was a preparation for multi channel audio support which i  intended to implement in a later TAK version. But somehow i coudn't  stop at this point. I was too curious to find out, what i could  achieve. Now that i have a first working implementation, i also have a  lot of questions.

I myself don't use any multi channel audio and  my knowledge about it's practical application is very limited. More  precise: I don't know, what kind of multi channel files files TAK users  would like to compress. I have to know this to be able to tune TAK for  the most likely application. It's easy to store the channels  independently with TAK's codec, but i also want to exploit channel  correlations to apply an extended version of TAK's joint stereo  algorithms.

My evaluations seem to show, that the results depend  to a high degree on the source material. Since i don't have the time to  perform tunings for any possible format at once, i want to start with  the formats users would like to compress.

What would they be?

Currently i am only testing 5.1 formats. Currently i am using the following files for tuning:

- HiRes-sample-files from 2L. Mostly 96 KHz converted from a DXD source.
- A 96 KHz version of Hotel California/ Eagles, DVD-A Audio.
  - Several albums of CD-DTS-Audio (44 KHz) converted with foobar to  wave. (Feeling a bit strange when converting lossy to lossless...)

I really have no idea, if those samples refelect by any means the possible applications of TAK users.

And therefore i have opened this thread. Please tell, what kind of multi channel audio you would like to compress with TAK.

I could have made a poll, but currently i simply don't know enough to ask the right questions.


Sounds great.
I have a couple of DVD-As, mostly 24-96, but I remember there was at least one 24-48.
Also, I got some 24-96 Quad rips.
IMO, multi-channel  audio should not be a priority now. I see that you have improved even  more TAK performance and that makes me want more and more a Linux  version. Sorry if I bring this up again, I just did it because you're  feeling unsure about multi-channel. Of course there are other users who  will want multi-channel, so let's hear them too.

To me it's perfectly ok if someone asks for linux suport. This is likely to have an influence on my priority list. 

Good.
Because, while I have personal interest in multichannel compressor that's better than FLAC, I actually agree with krafty that it's more important for TAK right now.

TAK 2.2.0 development

Reply #10
Hello Thomas,

On the Hydrogenaudio KB 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!

TAK 2.2.0 development

Reply #11
TAK's stream format now supports up to 16 channels. Initially it was designed for 32 channels, but i think that would be overkill. Ok, while looking for info about multichannel audio i read over an article about an 22 channel format specification, but i doubt, many people would install so many speakers.

16 channels is nice, because it provides some headroom for moderate extensions of the existing formats (7.1).

While the stream supports up to 16 channels, the first encoder version may be limited to 6 channels because i tend to only unlock support for formats the codec already is tuned for.

I don't think 32 channels is overkill.
Maybe you are focusing too much on end-user media consumption.
TAK could also be VERY useful in intermediate media production and EXTREMELY useful in final storage.

For example in music production, where all the instruments have their own separate channels.
In a stereo setup, every instrument would take up two channels.
With 16 channels, you'd be limited to 8 voices/instruments...

Or like the example i gave before about the 5.1 audio in videography.
Videography is one of my hobbies, and the subject of intermediate codecs is still a hot debated topic.
There is hardly a good defacto intermediate lossless codec for video that works accross all workflows, and for audio, everyone just uses WAV.
What I mean is, while there are solutions that work, there is still a lot of room for improvement, and the players are not yet set...

Perhaps you shouldn't limit yourself to say X channels, but apply compression to groups of channels?
Like in that music production example, you could apply compression to every pair of stereo channels - since I don't think there would be much point trying to find correlation between voice and drums for example
Or in the 5.1 example, you could compress the 5 channels as a group, and the .1 as another group.
That way you don't have to limit yourself to say X channels, and maybe you could even support 65536 channels as WAV does
65536 of course is overkill, but why not 128 or 1024?

I found the following quote from FLAC's website:

FLAC is designed as a consumer audio format. It trades ease of editing for a featureful, robust transport layer more suited for playback, and encoding speed for more compression and faster decompression.

Maybe TAK can differentiate itself as a more professional audio format? Just some food for thought

By the way, what's the maximum file size TAK supports?

TAK 2.2.0 development

Reply #12
Professional audio format that no professional programs/devices support?

TAK 2.2.0 development

Reply #13
Thomas, if your looking voor common multi channel configuration (for consumer playback), I'll give it a try.
All combinations from 2 to 8 channels are possible.
Most common are 5.1 (surround sound like on DVD-A) and 4.0 (Quadraphonic).

Then there is 5.0 (no separate Low Frequenty channel) that is sometimes used for surround music (not movie related). Some programs/formats confuse this and the rarer 4.1 (quadraphonic with (derived) sub channel) as the number of channels is the same.
Then there is 7.1 that can be configured is multiple configurations (normally with sides and surround backs, but nowadays one of those pairs can be used for height or front wide alternatively).
There do exist some 3 channel SACDs, where the 3 original studio tracks each get their own channel (L-C-R).

bit depth and sample rate are the same range as used in stereo.

Maybe this helps to get a bit of the picture.
In theory, there is no difference between theory and practice. In practice there is.


TAK 2.2.0 development

Reply #15
I have made great progress in the last two weeks. Therefore i am now able to present some first compression results for multi channel audio.

It wasn't easy to obtain appropriate test files for the codec tuning. And since multichannel audio files are quite big, each test run took a lot of time. That's quite annoying if you know you have to repeat this procedure for many other codec variations you want to try. It remined me of my very first attempts in lossless audio compression when i owned a i486...

Here comes the comparison:

Code: [Select]
           TAK             FLAC    WavPack 
Mode       -p2m    -p4m    -8      -hhx
-------------------------------------------------------------------------------
DXD (mostly): 24 bit, 96 khz, 6 channels (5.1)          
-------------------------------------------------------------------------------
m6_96_a    41.69   41.40   43.96   44.11    Samples from 2L - the Nordic Sound    
-------------------------------------------------------------------------------
DVD-A (PCM): 24 bit, 96 khz, 6 channels (5.1)          
-------------------------------------------------------------------------------
m6_96_b    53.77   53.61   55.85   56.56    Eagles - Hotel California
-------------------------------------------------------------------------------          
DTS: 16 bit, 44 khz, 6 channels (5.1)
-------------------------------------------------------------------------------          
m6_44_a    30.22   29.38   33.17   32.42    Al Di Meola - Consequence Of Chaos
m6_44_b    41.69   41.41   45.04   44.35    Pink Floyd - The Dark Side Of The Moon
m6_44_c    41.28   41.06   42.69   42.18    Roxy Music - Avalon
m6_44_d    40.18   39.76   43.23   42.09    The Police - Every Breath You Take
-------------------------------------------------------------------------------
Vinyl-Rip: 24 bit, 96 khz, 4 channels (quadro), denoised and decklicked          
-------------------------------------------------------------------------------          
m4_a       65.46   65.36   67.19   66.84    Pink Floyd - Wish you were here
m4_b       62.30   62.22   63.94   63.42    Santana - Caravanserai

Compression ratio expressed as percentage of the original file size. Each data row represents a complete album or a collection of files.

I couldn't test Monkey's Audio or Optimfrog, because both seem to have no support for multichannel audio. I didn't try a stronger mode for WavPack, beacuse this would have taken too long (4-5 hours were enough...).

I have tested only TAK -p2m and -p4m, because all other presets still have to be constructed (from the many internal encoder options) for optimum performance, what will require a lot of further testing.

I have some more ideas to further improve the compression. Some of them already have been tried and seem to work well. But this is getting very complex and time consuming. I have deceided, to stop the evaluation for now and to start to work on a release. Ok, some minor tuning might take place...

I am quite happy with the current results.

Maybe this helps to get a bit of the picture.

This was very helpful! Thank you.

TAK 2.2.0 development

Reply #16
Could you test it against flake and (especially) als?

TAK 2.2.0 development

Reply #17
Could you test it against flake and (especially) als?

No, at least not now, because

a) The Mpeg4Als binary is not well documented. I would have to look at the source code to determine the optimum parameters for multi-channel-decorrelation. Well, i did, but it's not a matter of just 5 or 10 minutes and currently i don't have more time. Furthermore the encoder was really slow when i tested it in the past and the addition of multi-channel-decorrelation will make things even worse.

b) The  latest official windows binary of Flake seems to be 0.11. Given the later development reported here at hydrogen, i would call it rather outdated. And when i tested 0.11 in the past, the results were quite variable, not seldom worse than with FLAC. The results reported on it's home page seemed to indicate something else, but i couldn't reproduce them on my test corpus and some users at hydrogen reported the same. I think, 0.11 had been tuned with files from lossy sources. That because 1.) i have downloaded the test files which were avaiable in the past and they seemed to be low-passed, and 2.) because i could reproduce it's quite good results compared with TAK 1.0.4 only for lossy processed sources. This does make sense, because TAK 1.0.4 had a severe weakness when compressing such files. I am sure, later development of Flake has removed this tuning-bias against lossy sources.

c) If i am right, later FLAC versions have adopted some of Flake's improvements (the most prominent exception might be variable block size switching), therefore i wouldn't expect to see large differences.

Out of interest i additionally tested "FLAC -8 -L 32 --lax" on some of my test files. That means "-8', but with 32 (maximum possible) instead of 12 predictors. Because this is outside of FLAC's restricted subset, you have to add "--lax".

Code: [Select]
           TAK             FLAC    FLAC    WavPack 
Mode       -p2m    -p4m    -8      -8 -l32 -hhx
---------------------------------------------------------------------------------------
DXD (mostly): 24 bit, 96 khz, 6 channels (5.1)          
---------------------------------------------------------------------------------------
m6_96_a    41.69   41.40   43.96   --.--   44.11    Samples from 2L - the Nordic Sound    
---------------------------------------------------------------------------------------
DVD-A (PCM): 24 bit, 96 khz, 6 channels (5.1)          
---------------------------------------------------------------------------------------
m6_96_b    53.77   53.61   55.85   --.--   56.56    Eagles - Hotel California
---------------------------------------------------------------------------------------          
DTS: 16 bit, 44 khz, 6 channels (5.1)
---------------------------------------------------------------------------------------          
m6_44_a    30.22   29.38   33.17   33.01   32.42    Al Di Meola - Consequence Of Chaos
m6_44_b    41.69   41.41   45.04   45.00   44.35    Pink Floyd - The Dark Side Of The Moon
m6_44_c    41.28   41.06   42.69   42.66   42.18    Roxy Music - Avalon
m6_44_d    40.18   39.76   43.23   43.16   42.09    The Police - Every Breath You Take
---------------------------------------------------------------------------------------
Vinyl-Rip: 24 bit, 96 khz, 4 channels (quadro), denoised and decklicked          
---------------------------------------------------------------------------------------          
m4_a       65.46   65.36   67.19   67.19   66.84    Pink Floyd - Wish you were here
m4_b       62.30   62.22   63.94   63.93   63.42    Santana - Caravanserai
---------------------------------------------------------------------------------------


edit: Somehow messed up the table...

TAK 2.2.0 development

Reply #18
Could you test it against flake and (especially) als?

No, at least not now, because

a) The Mpeg4Als binary is not well documented. I would have to look at the source code to determine the optimum parameters for multi-channel-decorrelation. Well, i did, but it's not a matter of just 5 or 10 minutes and currently i don't have more time. Furthermore the encoder was really slow when i tested it in the past and the addition of multi-channel-decorrelation will make things even worse.

b) The  latest official windows binary of Flake seems to be 0.11. Given the later development reported here at hydrogen, i would call it rather outdated. And when i tested 0.11 in the past, the results were quite variable, not seldom worse than with FLAC. The results reported on it's home page seemed to indicate something else, but i couldn't reproduce them on my test corpus and some users at hydrogen reported the same. I think, 0.11 had been tuned with files from lossy sources. That because 1.) i have downloaded the test files which were avaiable in the past and they seemed to be low-passed, and 2.) because i could reproduce it's quite good results compared with TAK 1.0.4 only for lossy processed sources. This does make sense, because TAK 1.0.4 had a severe weakness when compressing such files. I am sure, later development of Flake has removed this tuning-bias against lossy sources.

c) If i am right, later FLAC versions have adopted some of Flake's improvements (the most prominent exception might be variable block size switching), therefore i wouldn't expect to see large differences.

Out of interest i additionally tested "FLAC -8 -L 32 --lax" on some of my test files. That means "-8', but with 32 (maximum possible) instead of 12 predictors. Because this is outside of FLAC's restricted subset, you have to add "--lax".

Code: [Select]
           TAK             FLAC    FLAC    WavPack 
Mode       -p2m    -p4m    -8      -8 -l32 -hhx
---------------------------------------------------------------------------------------
DXD (mostly): 24 bit, 96 khz, 6 channels (5.1)          
---------------------------------------------------------------------------------------
m6_96_a    41.69   41.40   43.96   --.--   44.11    Samples from 2L - the Nordic Sound    
---------------------------------------------------------------------------------------
DVD-A (PCM): 24 bit, 96 khz, 6 channels (5.1)          
---------------------------------------------------------------------------------------
m6_96_b    53.77   53.61   55.85   --.--   56.56    Eagles - Hotel California
---------------------------------------------------------------------------------------          
DTS: 16 bit, 44 khz, 6 channels (5.1)
---------------------------------------------------------------------------------------          
m6_44_a    30.22   29.38   33.17   33.01   32.42    Al Di Meola - Consequence Of Chaos
m6_44_b    41.69   41.41   45.04   45.00   44.35    Pink Floyd - The Dark Side Of The Moon
m6_44_c    41.28   41.06   42.69   42.66   42.18    Roxy Music - Avalon
m6_44_d    40.18   39.76   43.23   43.16   42.09    The Police - Every Breath You Take
---------------------------------------------------------------------------------------
Vinyl-Rip: 24 bit, 96 khz, 4 channels (quadro), denoised and decklicked          
---------------------------------------------------------------------------------------          
m4_a       65.46   65.36   67.19   67.19   66.84    Pink Floyd - Wish you were here
m4_b       62.30   62.22   63.94   63.93   63.42    Santana - Caravanserai
---------------------------------------------------------------------------------------


edit: Somehow messed up the table...


Some time ago I did multichannel tests of flake svn and it was significantly better than both flac and wavpack. Honestly, I can't tell how much was it though.
ADDED:
And AFAIK als is the multichannel leader. What's the point of comparing to laggards?

TAK 2.2.0 development

Reply #19
Some time ago I did multichannel tests of flake svn and it was significantly better than both flac and wavpack. Honestly, I can't tell how much was it though.

If you send me a binary, i will test it...

TAK 2.2.0 development

Reply #20
And AFAIK als is the multichannel leader. What's the point of comparing to laggards?

References? Suggestions for command line parameters? Time to help me out by testing it yourself with the sample files from 2L i used?

TAK 2.2.0 development

Reply #21
And AFAIK als is the multichannel leader. What's the point of comparing to laggards?

References? Suggestions for command line parameters? Time to help me out by testing it yourself with the sample files from 2L i used?

For now, I can only point you to this old thread.
Maybe tomorrow, when I'm back home I'll do some quick tests.

TAK 2.2.0 development

Reply #22
For now, I can only point you to this old thread.
Maybe tomorrow, when I'm back home I'll do some quick tests.

I know this thread. Unfortunately it doesn't help with the multi-channel-options. I think, MCC (Multi-Channel Coding) has been implemented later.

It would be helpful, if you would evaluate the best options for multi-channel-audio. Then i could use them for my own test. Well, as soon as i have some more time to work on it.

Just to be sure: You know, that mpeg4als includes both an asymmetric and a symmetric codec? The latter is selected by the -z option.

In the past i only tested the asymmetric codec, because the other was too slow.

BTW: This wasn't meant as a comprehensive comparison, which probably will have to wait until the release of V2.2.0.

TAK 2.2.0 development

Reply #23
For now, I can only point you to this old thread.
Maybe tomorrow, when I'm back home I'll do some quick tests.

I know this thread. Unfortunately it doesn't help with the multi-channel-options. I think, MCC (Multi-Channel Coding) has been implemented later.

It would be helpful, if you would evaluate the best options for multi-channel-audio. Then i could use them for my own test. Well, as soon as i have some more time to work on it.

Just to be sure: You know, that mpeg4als includes both an asymmetric and a symmetric codec? The latter is selected by the -z option.

In the past i only tested the asymmetric codec, because the other was too slow.

BTW: This wasn't meant as a comprehensive comparison, which probably will have to wait until the release of V2.2.0.

I found some multichannel Floyds on HDD, I'm doing some quick and dirty testing. Sadly, from preliminary results I already know that the track is not a representative one. I may do another one today (same album though) and maybe another later.
I'd like to do a serious multichannel audio test, but probably not before Christmas, as I will be picking a multichannel encoder when I'm done with compressing my stereo audio to OptimFROG.

And as to multichannel, there's only one switch about it unless you want to rearrange channels -s#. From my memory I can tell that the optimum value is either 2 or 3 for 5.1 audio, varying from track to track, IIRC 2 wins most often.

TAK 2.2.0 development

Reply #24
So here it is, results on some arbitrary file:
Pigs on the wing, 5.1, said to come from a SQ tape, though the fact that it's 5.1 instead of 4.0 makes me suspicious.
Code: [Select]
uncompressed              147571268
flac -8                    65494985
wavpack -hhx6              54864294
als -a -e -p -g5 -s2 -o60  49472082
als -a -e -p -g5 -s1 -o100 49969480
als -a -e -p -g5 -s2 -o100 49311074
als -a -e -p -g5 -s3 -o100 49062431
als -a -e -p -g5 -s6 -o100 48774241
als -z3                    48744061

I chose o100 because I remembered that I liked it.
I'm trying a different file now.