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 1.0.4 - Development (Read 84911 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0.4 - Development

Reply #50 –
I forgot to mention an easy way to get the total sample size to go along with --skip and --until (same as metaflac --show-total-samples).

Thanks Thomas!

TAK 1.0.4 - Development

Reply #51 –
Although TAK's decoding speed is already very high in V1.0.3b and probably limited by the IO-speed on most systems, i again have spent some time on tuning.

Here a comparison of the current version with V1.0.3b:

Code: [Select]
 Preset    1.0.3b    1.0.4     Improvement
-------------------------------------------
 -p0       105.64    118.09      12 %
 -p1        98.24    109.03      11 %
 -p2        91.73    100.76      10 %
 -p3        80.97     87.93       9 % 
 -p4        74.57     80.33       8 %
 -p5        66.15     70.78       7 %
-------------------------------------------

Speed data expressed as multiple of real time on a Pentium 3 with 1000 MHz.

And that's not the end of the line...

TAK 1.0.4 - Development

Reply #52 –
I switched lossless format from ape extreme high to TAK -p4.
Though Monkey extreme high is still a little bit better as far as compression ratio is concerned it's not essential to me and I prefer the improved decoding speed compared to Monkey's.

With my collection there's no significant bitrate improvement when going from -p4 to -p5, but real improvement is there when going from -p2 to -p3 to -p4. These settings are very well balanced IMO, and as -p4's encoding speed is still very good for me I use -p4.

Very good work, Thomas.

Any plans to build a rockbox port together with the Rockbox people?
At the moment most of my music on my DAP is compressed via lossyWav+FLAC.
For music with few instruments and/or quiet music however going purely lossless yields the smaller bitrate.
It would be great if I could use TAK on my rockbox armed DAP. At the moment wavPack normal -x5 is the best solution for me (FLAC is a pretty bad performer in many of these cases), but TAK is even better.
Moreover I'd prefer to use lossyWav together with TAK instead of FLAC.

So it would be great to have TAK with Rockbox.
Any plans?
lame3995o -Q1.7 --lowpass 17

TAK 1.0.4 - Development

Reply #53 –
Quote
So it would be great to have TAK with Rockbox.
Any plans?
I'm also looking forward to having TAK in Rockbox!
If age or weaknes doe prohibyte bloudletting you must use boxing

TAK 1.0.4 - Development

Reply #54 –
Erm, let's have a linux/Unix port first, please...

TAK 1.0.4 - Development

Reply #55 –
Quote from: TBeck on
Although TAK's decoding speed is already very high in V1.0.3b and probably limited by the IO-speed on most systems, i again have spent some time on tuning.

Although true for p0 - p2 (or p3), it is still welcome for the higher modes.
Besides it would make it more viable for hardware platforms (if the optimisations are portable).
In theory, there is no difference between theory and practice. In practice there is.

TAK 1.0.4 - Development

Reply #56 –
Quote from: halb27 on
With my collection there's no significant bitrate improvement when going from -p4 to -p5, but real improvement is there when going from -p2 to -p3 to -p4. These settings are very well balanced IMO, and as -p4's encoding speed is still very good for me I use -p4.

Now and then i am thinking about dropping -p5... On big representative file sets the advantage over -p4 is usually less than 0.20 percent. But on the other hand some particular files gain up to 2 percent.

Quote from: halb27 on
Any plans to build a rockbox port together with the Rockbox people?
At the moment most of my music on my DAP is compressed via lossyWav+FLAC.
For music with few instruments and/or quiet music however going purely lossless yields the smaller bitrate.
It would be great if I could use TAK on my rockbox armed DAP. At the moment wavPack normal -x5 is the best solution for me (FLAC is a pretty bad performer in many of these cases), but TAK is even better.
Moreover I'd prefer to use lossyWav together with TAK instead of FLAC.

Quote from: eevan on
Quote
So it would be great to have TAK with Rockbox.
Any plans?
I'm also looking forward to having TAK in Rockbox!

There has been a contact with one rockbox developer but it was (and is) too early...

I still have to prepare a source code release in Standard C (at least of the decoder). I am doing it step by step. For TAK 1.0.4 i have replaced some DELPHI specific runtime libraries with portable code. Next step may be the conversion of the code from object orientation to a pure procedural design.

Simultaneously i am working on a slighltly improved codec (a bit faster, a bit stronger and simplier code) which will involve a (small) format change. I have to evaluate some new ideas before i can deceide, if the improvements justify a format change. This has to be done before thinking about a source code release because this should be the first and last format change.

Quote from: skamp on
Erm, let's have a linux/Unix port first, please...

This could happen earlier.

Quote from: GeSomeone on
Quote from: TBeck on

Although TAK's decoding speed is already very high in V1.0.3b and probably limited by the IO-speed on most systems, i again have spent some time on tuning.

Although true for p0 - p2 (or p3), it is still welcome for the higher modes.
Besides it would make it more viable for hardware platforms (if the optimisations are portable).

Some are definitely portable, others maybe. But it's difficult to predict the effect on the speed of hardware player implementations.

Thanks to anyone for commenting. It's always very motivating to receive some feedback!

TAK 1.0.4 - Development

Reply #57 –
I am thinking about a new preset configuration for -p0 and -p1.

The compression efficiency of new -p1 will lie between old -p0 and -p1.

More important: -p0 will compress much worse than before!

Am i joking?

No.

Welcome in the wonderful world of marketing...

New -p0 is intended to compete with FLAC's -0 to -2. The goal is to make it encode and decode faster than those FLAC settings and -as you would expect from TAK- compression should nevertheless be better (about 0.5 percent) than FLAC.

I doubt, that anyone would use this weak preset, but if want to make TAK the fastest codec, it should also compete well at this low level.

What do you think?

TAK 1.0.4 - Development

Reply #58 –
Quote
Now and then i am thinking about dropping -p5... On big representative file sets the advantage over -p4 is usually less than 0.20 percent. But on the other hand some particular files gain up to 2 percent.

I once use -p4 but some test show me that.. I have a lot of these "particular files (album)" that -p5 offer somewhat noticeable better compression rate than -p4. But if this happen, decoding rate will noticeable slower too. (which is not a big deal) Most of these is quiet music.

TAK is very good with quiet music. Today I find some album that TAK have better compression than the APE "Extra high" 

On the another hand.. Sometime (Once.. maybe.. I can't remember), There are another type of "particular files" that made TAK -p3 have better compression rate than -p5  weird eh? And I'm not talking about white noise & some weird stuff too.

And good news on decoding speed up. Any chance to hope about encoding speed up?

About -0,-1 Isn't it fast enough?

Thanks for your hard work TBeck 

TAK 1.0.4 - Development

Reply #59 –
Quote from: TBeck on
... -p0 will compress much worse than before!

Am i joking?

No.

Welcome in the wonderful world of marketing...

New -p0 is intended to compete with FLAC's -0 to -2. The goal is to make it encode and decode faster than those FLAC settings ....


Well, if you do want to be the encoding speed champion: go ahead.
In a practical sense I can't see how FLAC -0 to -2 can be attractive to anybody. It's hard to imagine that FLAC -5 isn't fast enough while providing a significantly better compression ratio.
Same goes for TAK's -p0 and -p1 attractiveness so it won't hurt if you go this way.
lame3995o -Q1.7 --lowpass 17

TAK 1.0.4 - Development

Reply #60 –
Quote from: TBeck on
I am thinking about a new preset configuration for -p0 and -p1.

The compression efficiency of new -p1 will lie between old -p0 and -p1.

More important: -p0 will compress much worse than before!

Am i joking?

No.

Welcome in the wonderful world of marketing...

[skipped]

What do you think?


It depends on what goal do you want to reach.

If you want to get first places (or at least beat FLAC -0) in speed tests, then ultrafast presets will be useful. If you plan to get hardware support from some vendor who produce portable players, then you may need these ultrafast presets as well.

But I see no reason to change -p0 and -p1 presets. You may simply add something like -p00 and -p01 presets with faster speed.


But if we're talking about 'real life' usage on PC, then compression means a lot. Personally I use TAK and WavPack with maximum level of compression. And that's the main reason why I prefer these codecs over FLAC.

Encoding speed in this case means not much at all, cause I encode my music only once. As about decoding speed... OK, let's say FLAC -0 has on my PC decoding speed 210x, TAK -p0 has 175x. So what ? How can I see this difference during playback when I have ~0% CPU usage in both cases ?

Once again, it depends on your goals, so you decide. And thanks for great codec btw 

TAK 1.0.4 - Development

Reply #61 –
Quote from: SokilOff on
Encoding speed in this case means not much at all, cause I encode my music only once. As about decoding speed... OK, let's say FLAC -0 has on my PC decoding speed 210x, TAK -p0 has 175x. So what ? How can I see this difference during playback when I have ~0% CPU usage in both cases ?


On what CPU/RAM? What version of TAK/FLAC libraries? It's interesting that the new FLAC libraries in foobar0.9.4.5.(?) got much faster, now they reach 480-600x decode rate on 44.1/16 stereo music - sometimes they get over 650x (especially on classical music - unaffected by loudness war?)
TAK 1.03 (with foobar 0.9.5 and up) 2 max reaches ~330x-340x on the same machine - about on par or somewhat (~10%) faster than high-bitrate mp3, and definitely faster than wavpack normal (~250x-260x on the same config, same foobar). I don't have any APE files ATM, but AFAIK it's also much slower than TAK.

So the proportions look very different here (FLAC -8 typically leads by ~70% opposed to your ~20%), my system (as a whole hw+sw combined) seems to like FLAC a lot better  I dunno how much FLAC settings matter (TAK settings don't change decoding speed very much) but if they do, the difference can be even bigger.
But it doesn't matter anyway, TAK is still very fast and I won't stop supporting it

Specs: core2 duo (conroe 4M core) @3.33GHz, (dual) DDR2 RAM@832MHz/cl4; intel P965 chipset.
Pity that I'm not very familiar with the actual strength of hardware players, but my uneducated guess is that current TAK is no problem, though optimization is always welcome as it increases battery life for sure

TAK 1.0.4 - Development

Reply #62 –
Quote from: TBeck on
I still have to prepare a source code release in Standard C (at least of the decoder). I am doing it step by step. For TAK 1.0.4 i have replaced some DELPHI specific runtime libraries with portable code. Next step may be the conversion of the code from object orientation to a pure procedural design.
If the current code is OO, wouldn't C++ make more sense? Open source doesn't need to be plain C.

Quote from: TBeck on
I am thinking about a new preset configuration for -p0 and -p1.

The compression efficiency of new -p1 will lie between old -p0 and -p1.
More important: -p0 will compress much worse than before!

What do you think?

I don't think it matters much, (lossless) compression is usually a tradeoff between speed and compression, what you suggest is merely a (small?) shift towards more speed and less compression for p0 p1.  I myself use only -p3 and -p4, the compression factor with the achieved decoding speeds is the selling point of TAK (IMO).
In theory, there is no difference between theory and practice. In practice there is.

TAK 1.0.4 - Development

Reply #63 –
Quote from: alvaro84 on
On what CPU/RAM? What version of TAK/FLAC libraries? It's interesting that the new FLAC libraries in foobar0.9.4.5.(?) got much faster, now they reach 480-600x decode rate on 44.1/16 stereo music - sometimes they get over 650x (especially on classical music - unaffected by loudness war?)
TAK 1.03 (with foobar 0.9.5 and up) 2 max reaches ~330x-340x on the same machine - about on par or somewhat (~10%) faster than high-bitrate mp3, and definitely faster than wavpack normal (~250x-260x on the same config, same foobar). I don't have any APE files ATM, but AFAIK it's also much slower than TAK.


Sorry, I was probably a bit too abstract.

My config: Athlon64 3800+ @2.4 GHz, 1 Gb RAM. I got latest foobar v0.9.5.1 beta2 (hope it uses latest FLAC), foo_input_tak dated 9.nov.2007 (is it latest one ?) and foo_benchmark plugin.

Same wav file was compressed with FLAC v1.2.1 using -0 preset and with TAK 1.0.3 using -p0 preset. Decopression speed benchmark is:

FLAC: 352x
TAK: 212x

So yes, latest FLAC is ~1.66x faster than TAK on their fastest presets.

But there is another question: what advantage do I get from this ? Even if some codec decodes @ 1000x, what does it change ? I listen all music @ 1x anyway  I get ~0% CPU load with both these codecs. So is there some REAL advantage except nice benchmark results ?

Imo the place where decoding speed is really very important is portable hardware device. Less decoding complexity = work on slower processors and longer playback time. That really makes sense.

But speaking about playback on PC I see no advantages at all: 200x, 400x or even 1000x. It changes nothing.

TAK 1.0.4 - Development

Reply #64 –
Quote from: SokilOff on
Imo the place where decoding speed is really very important is portable hardware device. Less decoding complexity = work on slower processors and longer playback time. That really makes sense.

But speaking about playback on PC I see no advantages at all: 200x, 400x or even 1000x. It changes nothing.

Except that lossless audio makes little sense on portable devices. It even makes little sense for plain playback on any device, portable or not, unless it serves an alternate purpose at the same time, such as transcoding, archiving, etc (not much point taking up an additional 20 gigs for a lossy archive when a lossless archive is already available)...
The only advantage to fast decoding speeds that I can think of, is in the case of transcoding (less decoding time means more processing power for encoding).

TAK 1.0.4 - Development

Reply #65 –
Quote from: alvaro84 on
So the proportions look very different here (FLAC -8 typically leads by ~70% opposed to your ~20%), my system (as a whole hw+sw combined) seems to like FLAC a lot better  I dunno how much FLAC settings matter (TAK settings don't change decoding speed very much) but if they do, the difference can be even bigger.
But it doesn't matter anyway, TAK is still very fast and I won't stop supporting it

Do you mean FLAC -8 is decoding 70 percent faster than TAK -p2?

Please be aware, that you are not only testing codecs but also how well foobar and the codec are interacting. There have been reports that decoding of TAK files with the foobar plugin is significantly slower than when performed with the TAK application.

Some data comparing the decoding speed of TAK -p2 and FLAC -8 (with md5 turned of):

Josh Coalson's FLAC comparison: 197.84 / 156.47 = 1.26 (FLAC is decoding 26 percent faster)
Synthetic Soul's comparison: 143 / 124 = 1.15 (FLAC is decoding 15 percent faster)

TAK 1.0.4 - Development

Reply #66 –
I have my doubts that the level of compression used with TAK will make any difference when it comes to proper playback on a portable.

TAK 1.0.4 - Development

Reply #67 –
Quote from: halb27 on
Well, if you do want to be the encoding speed champion: go ahead.
In a practical sense I can't see how FLAC -0 to -2 can be attractive to anybody.

not many people here use it: http://www.hydrogenaudio.org/forums/index....showtopic=58731
for flac it can be useful for real-time transcoding from unsupported formats (e.g. slimserver->squeezebox).

if it were really that important I could make -0 faster.

TAK 1.0.4 - Development

Reply #68 –
Quote from: TBeck on
1. I still have to prepare a source code release in Standard C (at least of the decoder).
I am doing it step by step.
2. For TAK 1.0.4 i have replaced some DELPHI specific runtime libraries with portable code.
3. Next step may be the conversion of the code from object orientation to a pure procedural design.


3 very good ideas

Quote
If the current code is OO, wouldn't C++ make more sense? Open source doesn't need to be plain C.


"plain" C is ways more portable ... go "plain" , please
/\/\/\/\/\/\

TAK 1.0.4 - Development

Reply #69 –
Quote from: SokilOff on
But speaking about playback on PC I see no advantages at all: 200x, 400x or even 1000x. It changes nothing.

And transcoding scenario? It's important. It's only CPU results.
I think those benchmark didn't count with real I/O and other conditions. (RAM's and HDD's speed.)

While uncompressed *.wav  has a higher CPU speed, TAK and FLAC have smaller data rate (less data to read from HDD). That's why it takes less (real) time to transcode from TAK, FLAC to LAME MP3 (in foobar) than from uncompressed *.wav to same MP3 on some systems. So CPU isn't bottleneck before some limit.

Is it really important to worry about very high decoding speed comparable to  FLAC -0 ... -2? When each generation (each 2 years) of CMOS(-like) transistors have a lower power consumption that benefit longer battery life. Current hardware supports FLAC -5 -8 and TAK 1.0.4 -p0 -p1 has the same decoding speed. I wouldn't talk about cuantic electronic revolution that will permits to low power consumption at least hundreds time because someone would hit me. But there are some thoughts that it just the matter of time. 
In other hand  the consumption of LED display mostly is higher than of decoding itself.
Maybe  there is no need to loose compression of -p0 at cost of higher decoding speed.

TAK 1.0.4 - Development

Reply #70 –
Quote from: DOS386 on
"plain" C is ways more portable ... go "plain" , please


Agree.

Plain 'C' is better for reading and porting to other language, such as assembly.
Hong Kong - International Joke Center (after 1997-06-30)

TAK 1.0.4 - Development

Reply #71 –
Quote from: IgorC on
And transcoding scenario? It's important. It's only CPU results.

It maybe important only for those people who do transcode very big amount of music (20-30 Gb) rather often. Actually I know noone who does so.

For common user, who can transcode 2-3 new albums a time just to put 'em to portable player, there will be no big time win anyway.


Edit: typo

TAK 1.0.4 - Development

Reply #72 –
Quote
Quote from: SokilOff on
And transcoding scenario? It's important. It's only CPU results.

It maybe important only for those people who do transcode very big amount of music (20-30 Gb) rather often. Actually I know noone who does so.
Decoding speed and transcoding: IMO transcoding cannot be the bottleneck there, if the encoder is slower than the decoder. I've seen decoding speed as a bottleneck only in a replaygain scanning scenario...

TAK 1.0.4 - Development

Reply #73 –
It's not a question of decoding being a bottleneck. Decoding takes processing power, no matter what, and 5% of the CPU is better than 10%: it leaves 95% for the encoding process, vs. 90%.
Granted, that's irrelevant if you have more than one CPU/core and run only one transcoding process (i.e. only one decoding process and one encoding process), but then you're wasting the other core(s). It becomes relevant again when you run multiple transcoding processes at once.

TAK 1.0.4 - Development

Reply #74 –
Personally i think a new preset p0 has faster decode speed and lower compression ratio is good idea,its mean that when system use CPU process power 99% (likely run transcoding or some error process blocked system) my music playback wouldn't be easier to delay especially with ASIO audio driver.