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: FLAC to TAK ? (Read 24721 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC to TAK ?

Reply #25
No real disadvantage of TAK, due to foobar2000 creating an excessive amount of seeking points via piping anyway. At least that's what I read somewhere around here a couple of times. Haven't encountered this issue myself so far, because I compress to FLAC through EAC+REACT2 instead, updating the archive is done using the script mentioned above.

This seems to happen only when you transcode from FLAC to FLAC with piping within foobar. When you use an intermediate WAV file or Synthetic Soul's script no additional seek points are added. (IIRC this has no negative effect other than being ugly to look at  )

Frankly, if you think about recompressing your archive, why not take some albums and convert them with some recent codecs? If you select your albums well you can estimate how big your gain will be. Might help making a decision...

FLAC to TAK ?

Reply #26
No real disadvantage of TAK, due to foobar2000 creating an excessive amount of seeking points via piping anyway. At least that's what I read somewhere around here a couple of times.
Yes.  IIRC it is recommended to use a temporary WAVE file when converting to FLAC with foobar, as a conflict between the way that Peter and Josh see STDIN working means that piping to FLAC results in an inordinate number of seek points being created.
I'm on a horse.

FLAC to TAK ?

Reply #27
Premature? Depends on which features you are focussing. As a general statement i consider this as wrong.

Format change? Yes. To make it even better. It's a vivid format.

TBeck, don't take it as a criticism, he is just saying what you are replying, it is changing for the better, and because it is too new, is a good moment to do "non-backwards-compatible" changes.

If you're waiting for the next update you'll be waiting forever... Because every format gets better with every update, and with lossless formats as competitively close to each other as they are today every format seems to get slightly ahead of the others for every new update.

I think again, that he is asking for short term changes that would render the previous format not-compatible.

FLAC to TAK ?

Reply #28

Premature? Depends on which features you are focussing. As a general statement i consider this as wrong.

Format change? Yes. To make it even better. It's a vivid format.

TBeck, don't take it as a criticism, he is just saying what you are replying, it is changing for the better, and because it is too new, is a good moment to do "non-backwards-compatible" changes.

Well, possibly i am a bit too sensitive here. I tend to associate "premature" with "unreliable" and "not trustworthy". I never would deny the fact, that TAK is missing some features, which are important for some people.

Honestly, i don't like to have to perform a bit as a marketing guy ("My dingeling is longer than your dingeling").  But since the publication of TAK i have to. Well, others are doing the same, but possibly a bit more decent. But now stopping whining....

  Thomas

FLAC to TAK ?

Reply #29
Thomas, how often will you update TAK, is it worth waiting for the next version?

The next version will not change the format, but add some tiny compatible improvements and some new functionality. On average you will not experience a significant compression advantage.

I can not tell you, when i will perform a format change, because i want to collect all new format-breaking ideas and then release them at once. The optimization of those new methods will take some time, therefore it's quite possible to take maybe 3 to 6 months.

But expect nothing ground breaking compression wise. The expected advantage will be quite small compared to the advantage TAK already has compared to FLAC.

One improvement is intended for high sampling rate files (96 Khz and more) and will not affect the efficiency of CD audio compression at all.

  Thomas

FLAC to TAK ?

Reply #30
I would venture to say that the flac, tak, and wavpack decoders are all getting very close to fundamental limits determined by their inherent algorithmic complexity.
Could you please elaborate this (or provide reading links)? What are the limits for lossless compression of audio?
I meant the decoding speed.  once 2 different algorithms are completely optimized (cannot be made any faster) then the runtime will reflect fundamental differences in complexity.  I think these 3 codecs approaching that point for decoding.

> Also, i wish TAK and FLAC somehow merge one day.

I don't think this is possible ... it would kill existing FLAC standard
it's possible to add things to FLAC in a backward-compatible way.  the difficulty is getting it to the hardware makers in a way that doesn't cause problems for users, but this has already been done twice for FLAC.

once TAK is open source, all the other codecs will be free to pick and choose techniques that can improve them.

I think apples to apples comparisons are very difficult to ascertain when using completely different enc/decoders.  For example, a test could time encoders encoding and tagging a file, or even encoding, tagging and verifying.  None of them do the same thing in any situation.  Of course, timing decompression speed for playback is one useful test, which I will be interested to see - I wouldn't say that it was the only test though.  If I wished to compare 'apples to apples' considering compression rate it would be impossible with my corpus, as even FLAC -8 Ax2 does not surpass TAK Turbo.  'Apples to apples' seems to me to be subjective.
ok, I'm just saying if a comparison is only showing one decoding time as "the" decoding time for a codec, the most representative one is the one I described.  that doesn't preclude a comparison showing more than one that includes tagging or verifying or something else.

BTW for comparison-testing purposes, to disable md5sum checking for flac decoding you can run "metaflac --set-md5sum=00000000000000000000000000000000 file.flac" on the file after it is encoded.  that will clear the md5 and the decoder will not do md5 checking on the file.

After some recent WavPack testing, where my PC showed very little improvement even though newer PCs showed dramatic improvement, I have considered removing my comparison, as I have realised that showing results for one system is a little misleading.  I think your point is just more proof of this.
this is due to all comparisons being done on x86 where there is so much variation in the hardware and optimizations.  that's partly why I do my comparison on a primitive machine.

on modern PCs, where all the time variation is, decoding time is almost a moot point since most codecs are already decoding at high multiples of realtime.

FLAC to TAK ?

Reply #31
Well, possibly i am a bit too sensitive here. I tend to associate "premature" with "unreliable" and "not trustworthy". Honestly, i don't like to have to perform a bit as a marketing guy ("My dingeling is longer than your dingeling").  But since the publication of TAK i have to. Well, others are doing the same, but possibly a bit more decent. But now stopping whining....

Thomas, you don't have to, your codec is well regarded here. The prove is all the topics/questions/etc. And people asking to open it (either the sources or the specification) are prove to it.

FLAC to TAK ?

Reply #32
Quote
it's possible to add things to FLAC in a backward-compatible way. the difficulty is getting it to the hardware makers


YES. But then existing "old" players won't play "new" TAK-FLAC 

Quote
Premature? Depends on which features you are focussing. As a general statement i consider this as wrong.


Format stability. This is not criticism, it's because TAK is NEW

Quote
Let's see if FLAC will continue without a format change when 24 Bit audio is more often beeing used and FLAC's 24-bit compression limitation caused by a design flaw becomes obvious.


Did not know ... then FLAC should either keep the format ... or change AND add TAK algorithm at this occasion
/\/\/\/\/\/\

FLAC to TAK ?

Reply #33
Quote
it's possible to add things to FLAC in a backward-compatible way. the difficulty is getting it to the hardware makers
YES. But then existing "old" players won't play "new" TAK-FLAC
no worries, I have a good relationship with the various hardware makers and we make sure that doesn't happen.


 

FLAC to TAK ?

Reply #35
humm... the standard format should stay FLAC, cuz there is already more hardware and software support than any other lossless format. So, if it's possible, the different developers of the codecs, especially TAK and WavPack (when I'm thinking of hybrid and lossy mode), should work together with FLAC developers or get their technologies together. Developing his own format will result in the end to a confusing format world for users! TAK is a the moment a strong codec, but I think it won't survive or will be the standard... well, we will see what the future will bring us!
FB2K,APE&LAME

FLAC to TAK ?

Reply #36
Let's see if FLAC will continue without a format change when 24 Bit audio is more often beeing used and FLAC's 24-bit compression limitation caused by a design flaw becomes obvious.

What "design flaw" would that be?

FLAC to TAK ?

Reply #37

Let's see if FLAC will continue without a format change when 24 Bit audio is more often beeing used and FLAC's 24-bit compression limitation caused by a design flaw becomes obvious.

What "design flaw" would that be?

The allowed range of rice parameters is too limited. Big residuals can not be compressed efficiently. Josh told, that this may be cured by a later format change. It's less an issue on 24 bit samples with high sampling rates but the effect can be very obvious at for instance 24-Bit / 48 K.

Nobody is immune against such failures. I for example found some rare samples were TAK would benefit from a higher resolution of the filter coefficients as is supported by the current format.

  Thomas

FLAC to TAK ?

Reply #38
humm... the standard format should stay FLAC, cuz there is already more hardware and software support than any other lossless format. So, if it's possible, the different developers of the codecs, especially TAK and WavPack (when I'm thinking of hybrid and lossy mode), should work together with FLAC developers or get their technologies together. Developing his own format will result in the end to a confusing format world for users! TAK is a the moment a strong codec, but I think it won't survive or will be the standard... well, we will see what the future will bring us!


Totally disagree. The advantages of having a plurality of choices cannot be discounted. Since the audio IS lossless, we CAN always jump ships if another codec comes up with features more suited to our purposes. Each lossless codec is fulfilling a "niche" (e.g. LA/OptimFrog for ultra high compression, FLAC for hardware/software support, TAK for high compression w/o compromising decompression and so on). I hope that developers work towards making their codecs better performers in their niche than working to make some bland "standard" codec that attempts to be everything to everybody.

FLAC to TAK ?

Reply #39
I know that feeling... I have like 300-400GB of lossless in various versions of FLAC between 1.1.0 and 1.1.4, just converting it all to 1.1.4 would probably be a huge improvement... but somehow it just feels like too much work.

Using Synthetic Soul's script it's an automatic, painless job: http://www.synthetic-soul.co.uk/files/flac-113.bat

Despite its name this batch file also works flawlessly in conjunction with FLAC 1.1.4. I used it myself to update a 80 GB archive overnight, without encountering any problems. Of course, in your case the conversion would take a lot more time, but since the script kept doing its job in the background, this shouldn't be much of a hindrance in practice. In conjunction with gharris999's FLACGetV script it even skips the already 1.1.4-compressed data, saving some time.
Hmm... Looks pretty handy. I'll take a look at it, thanks.

FLAC to TAK ?

Reply #40
Here's what I did:

Instead of converting with foobar or any script, I choose to rename all my files and later convert to wav.
Some time ago when I converted from mixed lossless formats to latest FLAC I got 1 error on 4000 files.
So this time I choose to convert to wav, to be on the safe side.

I renamed all my lossless files to
Artist - Album [Year] Tracknumber Trackname
example:
Dark Empire - Distant Tides [2006] 03 A Soul Divided.tak

I used Rename Master
http://www.joejoesoft.com/vcms/108/
perfect

So no more need for folders when converting, just one plain simple folder.

I'm happy now, all TAK files.

FLAC to TAK ?

Reply #41

I know that feeling... I have like 300-400GB of lossless in various versions of FLAC between 1.1.0 and 1.1.4, just converting it all to 1.1.4 would probably be a huge improvement... but somehow it just feels like too much work.

Using Synthetic Soul's script it's an automatic, painless job: http://www.synthetic-soul.co.uk/files/flac-113.bat

Despite its name this batch file also works flawlessly in conjunction with FLAC 1.1.4. I used it myself to update a 80 GB archive overnight, without encountering any problems. Of course, in your case the conversion would take a lot more time, but since the script kept doing its job in the background, this shouldn't be much of a hindrance in practice. In conjunction with gharris999's FLACGetV script it even skips the already 1.1.4-compressed data, saving some time.
Hmm... Looks pretty handy. I'll take a look at it, thanks.



And it keeps all the tags! It keeps all the tags! Oh that made me so happy when I saw that script when the new FLAC came out!

FLAC to TAK ?

Reply #42
And it keeps all the tags! It keeps all the tags! Oh that made me so happy when I saw that script when the new FLAC came out!
Thank FLAC 1.1.4 for that BTW, not my script; it's native to FLAC.EXE, when using a source FLAC.
I'm on a horse.