IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
TAK codec (Any news, seems silent for some time)
jido
post Oct 5 2012, 17:52
Post #51





Group: Members
Posts: 246
Joined: 10-February 04
From: London
Member No.: 11923



The code of the decoder looks tidy. I can't wait to give it a try...
Go to the top of the page
+Quote Post
skamp
post Oct 5 2012, 18:17
Post #52





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
mycroft
post Oct 6 2012, 01:33
Post #53





Group: Members
Posts: 3
Joined: 6-October 12
Member No.: 103657



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.
Go to the top of the page
+Quote Post
skamp
post Oct 11 2012, 10:37
Post #54





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (mycroft @ Oct 6 2012, 02:33) *
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 smile.gif

QUOTE (mycroft @ Oct 6 2012, 02:33) *
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)?


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
bandpass
post Oct 11 2012, 11:01
Post #55





Group: Members
Posts: 327
Joined: 3-August 08
From: UK
Member No.: 56644



QUOTE (skamp @ Oct 11 2012, 10:37) *
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.
Go to the top of the page
+Quote Post
Zergen
post Jan 7 2013, 22:57
Post #56





Group: Members
Posts: 24
Joined: 7-February 05
Member No.: 19656



New version of ffmpeg (1.1) officially supports TAK decoding. I checked on a couple of files - don't see any problems in decoding.
Go to the top of the page
+Quote Post
skamp
post Jan 8 2013, 09:18
Post #57





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
mycroft
post Jan 8 2013, 13:29
Post #58





Group: Members
Posts: 3
Joined: 6-October 12
Member No.: 103657



That is just untrue.
Go to the top of the page
+Quote Post
skamp
post Jan 8 2013, 14:08
Post #59





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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.


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
mycroft
post Jan 8 2013, 15:37
Post #60





Group: Members
Posts: 3
Joined: 6-October 12
Member No.: 103657



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
Go to the top of the page
+Quote Post
skamp
post Jan 8 2013, 15:44
Post #61





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
DOS386
post Feb 4 2013, 15:00
Post #62





Group: Members
Posts: 64
Joined: 16-June 07
Member No.: 44412




QUOTE


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


--------------------
/\/\/\/\/\/\
Go to the top of the page
+Quote Post
DOS386
post Feb 4 2013, 16:17
Post #63





Group: Members
Posts: 64
Joined: 16-June 07
Member No.: 44412



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


--------------------
/\/\/\/\/\/\
Go to the top of the page
+Quote Post
mzso
post Jun 23 2013, 22:18
Post #64





Group: Members
Posts: 185
Joined: 2-May 07
Member No.: 43131



QUOTE (TBeck @ Jun 18 2013, 10:31) *
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.
Go to the top of the page
+Quote Post
TBeck
post Jun 25 2013, 11:14
Post #65


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (mzso @ Jun 23 2013, 23:18) *
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.
Go to the top of the page
+Quote Post
saratoga
post Jun 25 2013, 19:16
Post #66





Group: Members
Posts: 5039
Joined: 2-September 02
Member No.: 3264



QUOTE (TBeck @ Jun 25 2013, 06:14) *
QUOTE (mzso @ Jun 23 2013, 23:18) *
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' smile.gif

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.
Go to the top of the page
+Quote Post
skamp
post Jun 26 2013, 13:06
Post #67





Group: Developer
Posts: 1450
Joined: 4-May 04
From: France
Member No.: 13875



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


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
TBeck
post Jun 27 2013, 11:05
Post #68


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



QUOTE (saratoga @ Jun 25 2013, 20:16) *
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' smile.gif

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

QUOTE (saratoga @ Jun 25 2013, 20:16) *
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)... wink.gif

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.

QUOTE (skamp @ Jun 26 2013, 14:06) *
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!
Go to the top of the page
+Quote Post
boombaard
post Jun 27 2013, 20:32
Post #69





Group: Members
Posts: 337
Joined: 7-February 05
From: Local Cluster
Member No.: 19647



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.
Go to the top of the page
+Quote Post
TBeck
post Jun 30 2013, 21:47
Post #70


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



Thank you for providing the test file.

QUOTE (boombaard @ Jun 27 2013, 21:32) *
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.
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st October 2014 - 08:37