Should i release an alpha version of the WinAmp plugin?

As i wrote earlier, a WinAmp plugin is already done. I wanted to wait with a release until the finalization of my SDK, because the plugin shall use the SDK library. But the testing of the SDK will possibly take a bit more time and i really would like TAK users to be able to playback TAK files as soon as possible. For me it was very much fun to hear my first TAK file...

I am thinking about an alpha release within the next days. Well, i haven't had any severe trouble with the plugin, therefore i could also call it a beta release. But i want to wait, until the SDK is done. Then i will compile a new version of the plugin and call it beta...

Any reason why i shouldn't release an alpha now? (For the user it's totally easy to switch to the later beta and final.)

No,

Release it ASAP! Hehehe, I've been checking the forum daily to give it a try . Can't wait Thomas!

I would also love an alpha and Thomas can prove that he actually got it working ;-)

i say release it. TAK right now is almost completely useless unless there is something that can actually play the audio.

I rarely play my WavPack archive files.

That said, I think you should release it Thomas.

Yup, many users simply keep the lossless files as an archive and usually listen to the music transcoded to their favorite lossy format on DAPs/mobiles or stereos, but not all: me I listen to PC playback a lot, and therefore a WA plugin would be welcome even im alpha state, it'd also push the format even further I think.

I wouldn't release a winamp plugin, instead focus on a C library and API. But i'm biased, since i have no use for a winamp plugin.

Another vote for yes release the alpha plugin. Like I said earlier it would be cool to hear a TAK file.

Well, i just released the first alpha of my Winamp plugin. More info here: TAK Winamp Plugin: Alpha and beta releases

@Thomas

I was using the -l2 option in takc (version 1), and noticed two things:

1. The results are in German... (Nein, Ja). You might want to change it to English.

2. More pressing, It seems that TAK is not using SSE in my computer. Is it disabled at the moment or am i the only one suffering from this? I'd love to see how fast TAK would go if SSE were enabled.

Thanks for your work on TAK and for releasing the plugin. I'm in the process of converting all my lossless to TAK.

You are right. Currently i am using one of my standard libraries (also used in other projects) to create the protocol file. I didn't want to touch this well tested code. But i will change it sooner or later.


Currently TAK isn't using any SSE optimizations. Because of it's speed oriented design, nearly any calculation is beeing performed in 16-bit integer arithmetic. I doubt that SSE's floating point arithmetic could be any faster. Only the core calculation routine of the predictor coefficients is using floating point. Early Yalac evaluation versions contained a SSE implementation of this code, but the speed advantage wasn't significant (maybe 1 percent...). It's possible, that future TAK versions will use the 128-bit MMX-implemenation (instead of the good old 64-bit MMX) of SSE3 and then you will see a 'Ja', sorry, 'Yes' in the SSE field. But first i will have to buy a new PC which supports SSE3...


Wow, that's great news for me! I wasn't sure if someone is really using TAK!

Thomas

The pleasure is mine. I'm saving about 7 mb per album (previously compressed using wavpack -hh). Now all i need is a plugin in foobar and replaygain support, and i'm all set!

Out of curiousity: Which preset are you using?

Possibly you will not have to wait too long for a foobar plugin, but damn... i always had the feeling, i have forgotten something... "replaygain support"! That it was!

-4. I tried -4m but the space savings vs -4m wasn't enough to justify the slower encode speed.

Love tak.

Just as a side note...
Is there actually interest in a foobar2000 0.8.3 decoder plugin?

I think still someone using 0.8.x because some 3rd party plugin not working in 0.9.

Foobar2000 is one of the best and serious player/converter/processor, can't imagine doing batch job or simple scripting without it, using other tools works but take a much longer time.

Even so, I think developing for an older, non-supported, version of foobar is a waste of time that could be spent better elsewhere.

Perhaps a 3rd party can choose to do so when the SDK is released, if they see fit.

NB: I dig foobar too, but that's pretty 'TOS #5'.

Yessssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss!!!!!!!!!!!!!!!!!!!!!!!

yes.

A foobar2000 decoder + winamp decoder is the only thing that's been keeping me from converting my current lossless files over.

Though I'm willing to wait for an API to come out so that others can work on plugins/conversion tools if necessary.

A Winamp playback plugin is already available and it looks, as if an experienced developer will soon start the work on a foobar plugin. I myself will not provide a plugin for older foobar versions. I can't do all on my own...

i need help with the parameters when using foobar to encode to TAK.

after looking at the readme, i came up with the following chains:
-e -p4 %d
-e -extra %d

and neither work. i'm not sure what i'm doing wrong, as far as i can tell those chains should work. can anyone help me out?

since piping is not supported, you need to do this:

takc -e -p4 %s %d

%d is the destination name. You are not specifying a source. Therefore:


Edit: Beaten to it. That's what comes of lining up a load of tabs in Firefox before reading.

that works, thanks!

now it's saying:


EDIT: apparently TAK doesn't like 32BPS

TAK shows some interesting results - some data I thought I'd share

Got some good results for 24bit files - ALL presets beat FLAC
i.e. TAK @ 0 compression beats FLAC @ -8 compression.

Did anyone else find any pleasant irregularities like the following?


Tones are usually hard for lossless codecs. Optimal settings seem to be 'high' preset.




Moderation: Amended inline images to linked thumbs

I'm confused. Are you referring to the fact that TAK Turbo compresses better than FLAC -8?

yup

I wouldn't call it an irregularity, as I think everyone saw similar results.

In my comparison TAK Turbo easily beats FLAC -8 using two apodisation switches as well. I'm not sure that any number of apodisation switches could provide the same compression as TAK Turbo.

There is a lot of talk about the speed comparison between TAK and FLAC, but if you take compression into account there is no comparison - FLAC simply cannot compete in the same arena.

Of course, I still find the speed comparisons interesting, especially given the swift release of FLAC 1.1.4 following 1.1.3, and FLAC's resurgence as the faster decoder. I look forward to further streamlining from both quarters (hmm... 'both'... 'quarters'... ermm...).

Maybe I'm misunderstanding, but it looks like the irregularities he's talking about are the fact that increasing the compression level did not always result in a smaller file. In the pure tones, Tak High compressed better than Tak Extra, which is certainly unexpected.

Yes, that's why I checked before answering, because that really is an irregularity. However, wildnewt has already answered contrary to that.

I remember seeing a similar thing with FLAC in one of the tests I've been involved in, where (for sake of argument) -5 and -6 compressed worse that -4. I guess it just depends on the individual sample and the settings the presets are using... and whether the sample finds a 'loophole' in the normal situation.

Absolutely yes.

TAK 1.0 has been tested by Ultimate Command Line Compressors: Comparison