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

TAK 2.0 Development

Reply #50
Excuse me, but that is off-topic.

Recording industry is already using higher sampling rates and eventually they all will, not much different from the HDTV transition. I suppose my great grandchildren will take it for granted they have home stereos with Dolby Lossless 15.1 at 192KHz
"Something bothering you, Mister Spock?"

TAK 2.0 Development

Reply #51
can human really differentiate between 44.1kHz and 192khz? This is pointless to the industry when they people cant actually feel the difference. Moreover, this will cost a lot of fortunes.

TAK 2.0 Development

Reply #52
I can't even hear a difference between 44.1kHz and 48kHz. I think it's a bit optimistic to think that listeners will get much benefit out of 192kHz or even 96kHz.

Producers, on the other hand, could definitely take advantage of that... but for the purpose of released tracks for public consumption, 48kHz should be just fine.

For that matter, do we even need 15 spatial channels? Where would you put the speakers?

TAK 2.0 Development

Reply #53
Good questions, I'll have to consult consumer-gurus.

As for lossless, I think I'm right in saying there are no boundaries of what is "good enough," especially from the stance of audio production (something that would be suicidal if using lossy schemes). I think of lossy is the by-product of consumer-ism.

Anyways, 192KHz is currently the new bar for excellence in digital audio production, something for the studio management to brag about. Having lossless is the only choice in that environment, so obviously the best contender will see fairly high savings for such an extreme sampling rate.
"Something bothering you, Mister Spock?"

TAK 2.0 Development

Reply #54
Well, the highest standard is DXD @ 384 kHz, 24bit. Supposed to be used in audio production.
BTW can TAK encode it? FLAC can't.

TAK 2.0 Development

Reply #55
IIRC DXD has samplerate 44.1*8 = 352.8 kHz. Also, FLAC can encode 352.8 kHz/24bit WAV file.


TAK 2.0 Development

Reply #57
The 192KHz is a strange one, it is poised to predict the future of digital audio.

let's see some evidence of that.  192kHz might have some advantages as an intermediate format but for final distribution anything over 48kHz is overkill because no one will hear it.

Well, the highest standard is DXD @ 384 kHz, 24bit. Supposed to be used in audio production.
BTW can TAK encode it? FLAC can't.

yes it can, the max flac sample rate is 655350Hz and is not even really practically limited to that.

TAK 2.0 Development

Reply #58
In the meantime i have to deceide, if i want to add another optimization which improves the compression of 192 KHz files by about 0.25 percent but unfortunately has no significant effect on files with lower sample rates. There are good reasons against this optimization:

- It will either make the encoder slower (for any sampling rate!) or require a higher code compexity to avoid this speed penality.
- TAK's compression efficiency for 192 KHz files is already on top, only beaten by OptimFrog in my tests, therefore it's not really neccessary to add a bit more, especially because 192 KHz files are a bit exotic.

So it's very likely that we will see a first release within the next days.

And i was about to release V2.0 Beta on last saturday...

But then i deceided to dig a bit deeper into the said optimization. Fortunately!

- The compression of my 192 KHz test files improved by 0.45 percent. If i exclude files converted from DSD-Sources from my test set, the advantage is more than 1 percent. That's because the extreme high frequency noise of the DSD files kills nearly any attempt to improve the signal prediction.

- The new optimization can also help some CD-Audio files a bit, but this will require further tuning of the encoder in later releases.

- As a side effect the encoding speed of 16 bit audio is again a bit higher for some presets.

Now i again have to perform a lot of testing to prepare the release.

TAK 2.0 Development

Reply #59
Excellent gains there, Thomas. It also reminds me of a dilemma I frequently run into with projects: "Is it done yet, or should I keep fine-tuning it?" I have only to thank exterior deadlines for simplifying the decision.

192kHz might have some advantages as an intermediate format but for final distribution anything over 48kHz is overkill because no one will hear it.
Yes, I omitted a lot in that claim. I keep forgetting a majority of end-users deal with 44.1 and 48 KHz material. To clarify, the studio (where lossless is a must) would use such high sampling rates for production, and that is where I meant that there are no boundaries (practically speaking and audibility aside). Given the idea that higher sampling rates are yet to become more popular later on (not sure how much or how soon), I was addressing Thomas' question if leaving out better 192KHz compression in version 2.0 release might encumber the codec later (a format/container change).
"Something bothering you, Mister Spock?"

TAK 2.0 Development

Reply #60
Excellent gains there, Thomas. It also reminds me of a dilemma I frequently run into with projects: "Is it done yet, or should I keep fine-tuning it?" I have only to thank exterior deadlines for simplifying the decision.

How true...

The said optimizations may provide opportunities for further improvements, which would not be compatible with the current file format. If i could yet specify the necessary modifications of the format, i could prepare the decoder for it and then later optimize the encoder to take advantage of it. Unfortunately i can't exactly specify the modifications without writing the encoder part and performing a lot of evaluations first. Since this means much work and i still want to release at least a beta before christmas, i will not implement it now.

TAK 2.0 Development

Reply #61
Excellent gains there, Thomas. It also reminds me of a dilemma I frequently run into with projects: "Is it done yet, or should I keep fine-tuning it?" I have only to thank exterior deadlines for simplifying the decision.

How true...

The said optimizations may provide opportunities for further improvements, which would not be compatible with the current file format. If i could yet specify the necessary modifications of the format, i could prepare the decoder for it and then later optimize the encoder to take advantage of it. Unfortunately i can't exactly specify the modifications without writing the encoder part and performing a lot of evaluations first. Since this means much work and i still want to release at least a beta before christmas, i will not implement it now.


Well, one can make a really future-proof decoder the way zpaq did - by specifying an interepreted language for writing (de)compressors and attaching algorithms to the files. However implementing it efficiently (JIT compiling?) would take a lot of time....I guess it's not an idea for TAK, but for some future project.

 

TAK 2.0 Development

Reply #62
Well, one can make a really future-proof decoder the way zpaq did - by specifying an interepreted language for writing (de)compressors and attaching algorithms to the files. However implementing it efficiently (JIT compiling?) would take a lot of time....I guess it's not an idea for TAK, but for some future project.

That could be interesting for a codec focussing only on optimum compression. But it would be too slow for TAK. Maybe i will play a bit with symmetric compression, when i am done with TAK's high efficiency codec... There such an approach could fit. Well, you have to try it to be sure.

BTW: Now i am definitely preparing a beta release. Execution of my validation scripts started some hours ago, but they will take some more hours to complete.