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

[jido]

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

[skamp]

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

[mycroft]

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.

[skamp]

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)?

[bandpass]

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.

[Zergen]

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

[skamp]

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

[mycroft]

That is just untrue.

[skamp]

Decoding a 24 bit TAK file with ffmpeg git:

CODE

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.

[mycroft]

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.



This post has been edited by mycroft: Jan 8 2013, 15:40

[skamp]

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

[DOS386]

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

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

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 :-(

[DOS386]

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").