Tom's Audio Support

Submitted by icceland on Wed, 2019-08-21 08:14

Forums:

MOC version: 
2.5.2

Please add a TAK audio support, as it can be currently done with ONE LINE OF CODE in ffmpeg.c.
I created even a "branch":

https://github.com/icceland/mocp

I'm tired to compile my favorite music player on every new system to have *.tak support and I believe, some other users will be happy to have it too.

As mentioned in the "branch", seeking is a bit inaccurate, but works fine since months. Compiled on AMD and ARM and no bugs were noticed, so why don't have it in the stable release?

Kind regards!

jcf

Wed, 2019-08-21 21:57

Thanks for that suggestion.

I've been looking (unsuccessfully) for TAK audio files on which I can test; even my usual source of test files has let me down on this one. But I'm sure you can provide a few links for me. (I don't like testing on locally generated files if possible because some encoding diversity is preferred.)

The FFmpeg libraries do have a wide range of formats and codecs from which they can decode, and provides a function so the client application can obtain a list... but they don't always work. That's why MOC limits those for which it can use FFmpeg to a subset of those known to work. I'm happy to add any which are missing from that subset as users request them (and providing they do actually work).

Some time ago I thought about externalising that subset of MOC-supported FFmpeg/LibAV codecs so users could add to it (at their own risk) in a configuration option. Your post has brought that back to mind and I shall revisit my ideas from that time.

icceland

Thu, 2019-08-22 23:08

Currently the one and only encoder I know is the one published by the author:
http://www.thbeck.de/Download/TAK_2.3.0.zip
It's Windows build and under Linux WineHQ is required to run it (although it runs it without any problems) and requires *.WAV files as input.

So all the files I have I compressed by myself with probably the only available encoder. Not, that I'm lazy, but I think you will get exactly this same result compressing anything on your own. There's GUI version in ZIP archive, so will cost no effort.
But I found one music album, which was released for free, so I believe not to brake any law.

https://drive.google.com/open?id=1LlF1qvkCefDfS9HXvrAc0xGhVC3UKbHQ

jcf

Fri, 2019-08-23 01:49

First, neither of those two routes are available to me as I don't have access to an MS-Windows machine and trying to access the album you pointed to requires a Google login... which ain't going to happen.

Second, I think what I'm reading between the lines is that TAK is a fairly niche format/codec and hasn't yet gained a critical mass.

So, I think the way to proceed is to place it into the "use at your own risk" category and users can make it available via an appropriate option setting in their own configuration.

I currently have in mind two syntaxes for doing that. The first requires little work but is a little clumsy. The second is more flexible but would require some intrastructural support which isn't in place yet. I'm reluctant to introduce a syntax which will change when that support does become available; there will be enough such changes when the time comes for already existing options and I don't want to add to that.

So I'll keep thinking about it and maybe bring that intrastructural change forward to accomodate.

Fortunately, you can apply that patch locally and it might be easier if you recast it as a binary patch with 'tak' replacing one of the other, unused (by you) extensions.