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 codec (Any news, seems silent for some time) (Read 61926 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK codec (Any news, seems silent for some time)

Reply #50
The code of the decoder looks tidy. I can't wait to give it a try...

TAK codec (Any news, seems silent for some time)

Reply #51
Nice! A few quirks though:
  • decoding fails when there's an APE tag (non lossless result)
  • ffmpeg segfaults when trying to decode a large(ish) TAK file (469 MiB)
  • the ffmpeg plugin in deadbeef refuses to load TAK files

TAK codec (Any news, seems silent for some time)

Reply #52
First two issues should be resolved in latest version - available on github - until merged with FFmpeg. Please report any issues found with this version.
Last issue is probably because deadbeef(and bunch of other lavc users) does not support/recognize planar sample formats - this one have nothing to do with this decoder.

TAK codec (Any news, seems silent for some time)

Reply #53
First two issues should be resolved in latest version - available on github - until merged with FFmpeg.


I see it has been merged into ffmpeg. Those issues are indeed solved

Last issue is probably because deadbeef(and bunch of other lavc users) does not support/recognize planar sample formats - this one have nothing to do with this decoder.


What are planar sample formats? How does the TAK decoder differ from, say, the ALAC decoder (which works with deadbeef's ffmpeg plugin)?

TAK codec (Any news, seems silent for some time)

Reply #54
What are planar sample formats?

I also came across this recently. AFAICT, it's a term used by (invented by?) ffmpeg to describe when multi-channel data is stored/transported one channel per buffer/stream, as opposed to being interleaved in a single buffer/stream.

TAK codec (Any news, seems silent for some time)

Reply #55
New version of ffmpeg (1.1) officially supports TAK decoding. I checked on a couple of files - don't see any problems in decoding.

TAK codec (Any news, seems silent for some time)

Reply #56
There's one major problem though: as far as I can tell, ffmpeg only outputs 16 bit audio.

TAK codec (Any news, seems silent for some time)

Reply #57
That is just untrue.

TAK codec (Any news, seems silent for some time)

Reply #58
Decoding a 24 bit TAK file with ffmpeg git:

Code: [Select]
ffmpeg -i foo.tak bar.wav
ffmpeg version git-2013-01-08-ff6b340 Copyright © 2000-2013 the FFmpeg developers
  built on Jan  8 2013 14:04:24 with gcc 4.7.2 (GCC)
  configuration: --prefix=/usr --enable-gpl --enable-libass --enable-libfaac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-nonfree --enable-x11grab
  libavutil      52. 13.100 / 52. 13.100
  libavcodec    54. 86.100 / 54. 86.100
  libavformat    54. 59.106 / 54. 59.106
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter    3. 32.100 /  3. 32.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample  0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[tak @ 0x1807740] max_analyze_duration 5000000 reached at 5124535
Guessed Channel Layout for  Input Stream #0.0 : stereo
Input #0, tak, from 'foo.tak':
  Duration: 00:00:28.33, start: 0.000000, bitrate: 891 kb/s
    Stream #0:0: Audio: tak, 44100 Hz, stereo, s32p
Output #0, wav, to 'bar.wav':
  Metadata:
    ISFT            : Lavf54.59.106
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (tak -> pcm_s16le)
Press [q] to stop, [?] for help
size=    4881kB time=00:00:28.33 bitrate=1411.2kbits/s   
video:0kB audio:4881kB subtitle:0 global headers:0kB muxing overhead 0.001601%

The result is a 16 bit WAV file. The same used to be true with their FLAC decoder in ffmpeg version 1.0.

TAK codec (Any news, seems silent for some time)

Reply #59
Yes and that is normal, default codec for wav is 16 bit pcm. You need to add -acodec pcm_s24le.

The link you mentioned have nothing with this "issue", because flac encoder in FFmpeg got 24 bit support recently, and decoder supported 24 bit for ages.


TAK codec (Any news, seems silent for some time)

Reply #60
I see. One shouldn't need to manually select the output format though, the default here is just wrong.

TAK codec (Any news, seems silent for some time)

Reply #61

Quote
http://ffmpeg.org/pipermail/ffmpeg-devel/2...ber/131785.html


Is this all (sufficient to decode all TAK files) ?

Quote
It feels a bit strange to see source code implementing my ideas with a foreign copyright notice not even mentioning me.


Indeed. Can't they add "This implements a decoder of the TAK audio codec by Thomas Becker" ??? They don't even write what the code is supposed to do :-\

Quote
don't want users to get into trouble with not-compliant implementations. I know myself: There are a lot of applications where i am the I-simply-want-it-to-work-guy... Therefore i feel forced to do anything to facilitate compliant implementations.
Quote


Did a short test: encode with TAK 1.1.1, decode with FFMPEG 1.1.1 - Result:



Red uncomprehensive complains 1'000'000'000'000 times :-(
/\/\/\/\/\/\

TAK codec (Any news, seems silent for some time)

Reply #62
Quote
Did a short test: encode with TAK 1.1.1, decode with FFMPEG 1.1.1 - Result:

Red uncomprehensive complains 1'000'000'000'000 times


Retest with TAK 2.2.0:

FFMPEG is able to decode it :-) But size is bad ... extra junk in the WAV header ... removing it ... audio PCM data is identical :-) Conclusion: FFMPEG is a not-compliant implementation as it fails to decode TAK 1.1.1 and fails to brew a useful message ... and the limitations are nowhere documented (should say "only TAK 2.xx").
/\/\/\/\/\/\

TAK codec (Any news, seems silent for some time)

Reply #63
I think in the worst case you would have to transcode your files from TAK to another format. If i would quit the work on TAK and new operating systems would  drop support for the latest release (for instance if windows would no longer support 32-bit-applications), you probably would have years left to perform the transition. But ok, this would mean a lot of work.

This might sound a bit harsh, but if you have traced the TAK development threads a couple of years ago, you possibly will understand.
aa
I made promisese regarding an open source release, which i first could not and -at some point- did not want to keep. My biggest fault. I surely deserved critic, but there have also been a lot of inappropriate insults. And some members seemed to jump at any chance to attack me over and over again.

I don't want to make the same mistakes again. Therefore no promisese. I only can tell you my current attitude:

I would like to release an open source decoder. If i could snap with the fingers and it was there, i would do it. But unless someone donates me a magic wand, a lot of (not very exciting) work is required. And i don't know, when i will able to do it.

That's all i can say. Nothing more to add.

Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.

TAK codec (Any news, seems silent for some time)

Reply #64
Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.

That's a lot of work too. Given my limited time, i will first concentrate on an open source decoder.

TAK codec (Any news, seems silent for some time)

Reply #65
Not sure how these things work, but meanwhile wouldn't a format specification suffice? With that people could make decoders or encoders if they desire.

That's a lot of work too. Given my limited time, i will first concentrate on an open source decoder.


People tend to underestimate just how hard writing a decoder specification is.  I've seen a certain major software company release a specification that covered 2/3s of the format and then ended with 'for the rest look at the decoder source'

Were you planning to write a new decoder, or to work on the ffmpeg one?  FWIW, the ffmpeg one seemed to be of fairly high quality although maybe you had other opinions.

 

TAK codec (Any news, seems silent for some time)

Reply #66
Thomas, just FYI, I can't link to your official web page because it's in german only. So for now, I'm going to link to the HA wiki entry: http://wiki.hydrogenaudio.org/index.php?title=TAK

TAK codec (Any news, seems silent for some time)

Reply #67
People tend to underestimate just how hard writing a decoder specification is.  I've seen a certain major software company release a specification that covered 2/3s of the format and then ended with 'for the rest look at the decoder source'

Yeah. And there will nearly always be ambiguities in the specification which make you want to look at the source code.

Were you planning to write a new decoder, or to work on the ffmpeg one?  FWIW, the ffmpeg one seemed to be of fairly high quality although maybe you had other opinions.

I haven't examined the ffmpeg decoder, but i am sure the ffmpeg people are very talented and i have little doubt that their decoder is of high quality. And BTW: Finally i really have to thank them for pushing me in the right direction (regarding an open source decoder release)... 

But i think, i will take the easiest and most safe way and base the decoder on my implementation. Even if it's probably a less suitable base for portability.

Thomas, just FYI, I can't link to your official web page because it's in german only. So for now, I'm going to link to the HA wiki entry: http://wiki.hydrogenaudio.org/index.php?title=TAK

Thank you!

TAK codec (Any news, seems silent for some time)

Reply #68
Thomas, I've recently found a few classical recordings that, compared to what I'm used to (a maximum difference of about 1% compression between p4m and monkey's audio extra high), compress quite badly with tak. (30kbps higher bitrate where the difference is usually between 1-4kbps.)
Would you like me to send you one or more of these files so you can have a look at why? The performances are of Brahms's first piano concerto and variations on a theme by Haydn, both orchestral works. Some hiss in the recording because of it being older (1955), and probably recorded live, or sub-par recording equipment, but I've seen recordings with much more hiss compress much better.

TAK codec (Any news, seems silent for some time)

Reply #69
Thank you for providing the test file.

Some hiss in the recording because of it being older (1955), and probably recorded live, or sub-par recording equipment, but I've seen recordings with much more hiss compress much better.

I will look at it, but i can't promise that i will be able to improve the compression. Anyhow a nice addition to my pool of special files, that i use to test new ideas for improvements.