First two issues should be resolved in latest version - available on github - until merged with FFmpeg.
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?
ffmpeg -i foo.tak bar.wavffmpeg 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 5124535Guessed Channel Layout for Input Stream #0.0 : stereoInput #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, s32pOutput #0, wav, to 'bar.wav': Metadata: ISFT : Lavf54.59.106 Stream #0:0: Audio: pcm_s16le ( / 0x0001), 44100 Hz, stereo, s16, 1411 kb/sStream mapping: Stream #0:0 -> #0:0 (tak -> pcm_s16le)Press [q] to stop, [?] for helpsize= 4881kB time=00:00:28.33 bitrate=1411.2kbits/s video:0kB audio:4881kB subtitle:0 global headers:0kB muxing overhead 0.001601%
It feels a bit strange to see source code implementing my ideas with a foreign copyright notice not even mentioning me.
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.QuoteDid 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 :-(
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 :-(
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
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.aaI 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.
Quote from: mzso on 23 June, 2013, 05:18:50 PMNot 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.
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
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.