Final release of TAK 1.0.1 ((T)om's lossless (A)udio (K)ompressor)
It consists of:
- TAK Applications 1.0.1
- TAK Winamp plugin 1.0.4. Updated 2007-05-15.
- TAK SDK 1.0.3. Updated 2007-04-28.
- TAK Decoding library 1.0.4. Updated 2007-04-25.
Download
The main archive and the tools can be downloaded from the upload section: TAK 1.0.1 Final (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=54159&view=findpost&p=485421)
What's new in the Applications
Features:
- Some speed optimizations of encoder and decoder. Depending on the preset and your cpu you may see improvements of 2 to 10 percent (if your hard disk is fast enough). Most affected: Encoding and decoding of presets Turbo and Fast, decoding of presets High and Extra.
- Removed the access to internal encoder options. Reintroduced the additional evaluation level EXTRA as compensation.
- Added a dynamic comparison table to illustrate the effect of presets and evaluation levels on compression efficiency, encoding and decoding speed.
- Added a meta data structure to hold encoder version, preset and evaluation level used for compression. Because of rounding errors the addition of this handful of bytes can cause 0.01 percent worse compression be reported (compared to TAK 1.0).
- Added a new command to show selected information about a compressed file.
- The command line version now indicates errors via the exit code. I always thought i already had done this...
- Even better error tolerance of the decoder.
Fixed:
- GUI: When compressing/decompressing the selection of a drives root directory as user specified output destination caused an error.
- It was theoretically possible, that when decoding some verify or source io errors had not been reported properly.
- One tester send me a very special file which could not be encoded; the encoder stopped with an error message. The fact, that nobody before reported such problems, confirms, that this file generated a very special conndition. Fortunately TAK still contains much self check code (which is slowing it down a bit), which detected this error condition and throw the error message. This bug affected only the encoder; if your files have been encoded without the encoder reporting an error, they are fine.
What's new in the Winamp plugin and the SDK (compared to 1.0.1)
Modifications:
- The APEv2 tag reading functions are a bit more tolerant when reading invalid tag headers not following the official APEv2 specification.
Fixed:
- When playing high resolution audio, plugin and SDK reported wrong values for the current compressed bitrate.
Thomas
Are there any format changes from 1.0.0 to 1.0.1?
Are there any format changes from 1.0.0 to 1.0.1?
No. V1.0.1 added a medata item to hold information about the encoder, but this will be ignored by V1.0.0, hence it's backwards compatible.
Thomas
When is decoder for foobar2000 expected?
When is decoder for foobar2000 expected?
pffff - foo_input_tak (http://www.hydrogenaudio.org/forums/index.php?showtopic=54087&hl=)
Don't forget to ask mommy for permission
I have a problem with Winamp plugin using last (beta) version 5.34 build 1239.
Shortly, I cannot play any tak file, the Winamp error reporter generates the following:
Winamp client version: 5.34 build 1239 Beta
winamp caused an Access Violation (0xc0000005)
in module winamp.exe at 001b:00000000.
Exception handler called in Winamp.
It seems that it is a Winamp problem, because I don't have it with older versions (2.95 and 5.13).
Unfortunately, I deleted the old version of the plugin before testing the new one so, I could not confirm if this is common behavior with 1.0.1 and 1.0.2.
Does anybody have the same problem? Any hints for overcome it?
Could somebody send me the older version of the plugin?
Thanks.
~
I have a problem with Winamp plugin using last (beta) version 5.34 build 1239.
Shortly, I cannot play any tak file, the Winamp error reporter generates the following:
Winamp client version: 5.34 build 1239 Beta
winamp caused an Access Violation (0xc0000005)
in module winamp.exe at 001b:00000000.
Exception handler called in Winamp.
It seems that it is a Winamp problem, because I don't have it with older versions (2.95 and 5.13).
Unfortunately, I deleted the old version of the plugin before testing the new one so, I could not confirm if this is common behavior with 1.0.1 and 1.0.2.
Does anybody have the same problem? Any hints for overcome it?
Could somebody send me the older version of the plugin?
Thanks.
~
Do you have the audioscrobbler plugin? If so, removing it could help.
Do you have the audioscrobbler plugin? If so, removing it could help.
Well, I tried a clean installation and it worked fine.
It appeared that in_zip plugin caused the problem. I should report it to Winamp forum maybe.
~
The newest Mp3tag 2.37j Development Build (http://developer.mp3tag.de/) now supports TAK tags.
The newest Mp3tag 2.37j Development Build (http://developer.mp3tag.de/) now supports TAK tags.
Great!
The german EAC wiki at arvex.de (http://arvex.de/) now also contains information about TAK usage and provides the TAK software archives for downloading.
Thomas
TAK 1.0.1 seems to run fine under WINE: WineHQ - AppDB (http://appdb.winehq.org/appview.php?iVersionId=7660)
Looking at the 1.0 and 1.0.1 changelog, How goes the work on Unicode support?
Looking at the 1.0 and 1.0.1 changelog, How goes the work on Unicode support?
Unicode support is at position 2 of my current todo list, which can be found in TAK's Readme. Because i have very little experience with unicode, the implementation will need much testing. And because i have no access to systems running under foreign languages, i will have to ask others for helping me with the testing. Such an approach is always quite time consuming: code a bit - let the testers check it - wait for feedback - improve the code - and back to the beginning. Currently i have no time to do it. Please don't expect a new release next month. Possibly in june...
Thomas
In that case, I'll note that i have quite a few Hebrew albums, And am willing to help test Unicode when needed.
In that case, I'll note that i have quite a few Hebrew albums, And am willing to help test Unicode when needed.
Thanks for your offer!
How do I determine the length of a TAK file in seconds? I tested the file with the TAK winamp plugin and for both the TAK and the WAV file it shows a file duration of 1:06 meaning 66 seconds. If I run takc -fi to get the file duration I get 67 secs. Why is there a difference of 1 second?
C:\Program Files\TAK>takc -fi 08-Within_Temptation-Intro.tak
=== 08-Within_Temptation-Intro.tak ============================
File size: 6.18 MB
Header size: 0.42 KB
Compression: 54.85 %
Samples per channel: 2952936
File duration: 67.00 sec
Frame duration: 250 ms
Seek point interval: 1000 ms
Audio format: PCM, 44100 Hz, 16 Bits, 2 Channels
Encoder: V 1.0.1, Extra + Max
Wave file meta data: Header 44, Footer 0 Bytes
APEv2-Tag: Yes / 6 Items / 0.19 KB
Status: Ok
How do I determine the length of a TAK file in seconds? I tested the file with the TAK winamp plugin and for both the TAK and the WAV file it shows a file duration of 1:06 meaning 66 seconds. If I run takc -fi to get the file duration I get 67 secs. Why is there a difference of 1 second?
Rounding errors? Possibly Winamp is always truncating. Given your sample count and sample rate the correct length is 66.96 seconds. You may select the file in Winamp and open the file info dialog (provided by the TAK plugin). It should show you the fraction with 3 decimal places (digits) and should match this value.
Hm, TAK's file info function is reporting 67.00? Then i have done something wrong, this should be 66.96. I will look at it and fix it in the next version (I doubt, that it's urgent?).
No worries, I use shntool with the original wav files to create the file durations. but it would be nice to have the same results with takc.exe.
Is the format of TAK frozen?
No worries, I use shntool with the original wav files to create the file durations. but it would be nice to have the same results with takc.exe.
I agree. I will correct the output of the file info function.
Is the format of TAK frozen?
The container format is frozen, but new metadata structures may be added as happened with TAK 1.0.1, which introduced a metadata structure to hold encoder information.
But i plan to add new codecs in the future, for even more speed or higher compression. The container contains a numerical value which indicates the codec used for compression. A decoder has to check this value to select the appropriate codec; new codecs will require an update of the decoding library.
Codecs and container are clearly separated; even older decoders can scan for instance metadata and tags, but will not be capable to decode the audio data compressed with newer codecs.
I know that at this stage of things bit comparisons aren't particularly interesting anymore, but I'm about 2/3rds of the way through transcoding my old FLAC archives to TAK and just wanted to note that I just let foobar do a bit-compare of about 107 hours of music (about 40 gigs) and everything came back as no differences found. Going from FLAC 1.1.2 -8 to TAK -p5 has yielded some very impressive compression improvements as well, not surprisingly.
I've said it before and here again - thanks for a great codec, TBeck.
Will TAK have a Monkey's Audio's APL-liked metafile in the future?
I'd like to use metafile instead of cue files or writing tags directly to the compressed image in order to keep them clean and original.
Update 2007-04-25
TAK Decoding library 1.0.4 now is the officially recommended version. Users of foosions foobar plugin definitely should update to this version.
TAK SDK 1.0.2 still contains the Decoding library 1.0.2 but will be updated too soon. In the meantime it is recommended to manually replace the decoding dll in the SDK with the new version.
Update 2007-04-28
Replaced TAK SDK 1.0.2 with 1.0.3, which contains the TAK Decoding library 1.0.4 (instead of 1.0.2). No other changes.
Update 2007-05-15
Repaced the Winamp plugin 1.0.2 with 1.0.4, which fixes a bug when using the in_zip plugin.
is there a foobar output plugin planed?
foobar output plugins are a thing of the past.
All encoding is done by command line encoders, including the default presets.
NB: the 0.9 input component can be found here (http://foosion.foobar2000.org/0.9/).
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
thanks synthetic,
didnt know that.
err, how to integrate TAK with the command line?
i always get an error when encoding.
i put the following line into settings:
-e %d
I use "-e -p3 %s %d". I believe the p3 stands for preset 3 (High), You can change that if you want.
i put the following line into settings:
-e %d
I use "-e -p3 %s %d".
Stevie, you command has no source specified.
TAKC.EXE cannot yet accept input from STDIN, so you need to specify %s as the source (which means that foobar will create a tempory WAVE and then encode that file (%s).
As ChaosBladE has already stated, that means a syntax like:
-e -p3 %s %d
Take a look at the TAK wiki page (http://wiki.hydrogenaudio.org/index.php?title=TAK) for more info, including a full explanation of setting up foobar.
thanks a lot guys, youre helpful as always!
Good work.
Can you develop TAK filter for Adobe Audition?
Any news about TAK for non-Windows users?
Back in mid March you (TBeck] mentioned that generating binaries for *nix was on your internal to do list. I have heard nothing about it since then, and wonder if its still on this list or if its currently being worked on...
Thanks!
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
You are the first one asking for this. Which means a very low priority on my to do list...
Any news about TAK for non-Windows users?
Back in mid March you (TBeck] mentioned that generating binaries for *nix was on your internal to do list. I have heard nothing about it since then, and wonder if its still on this list or if its currently being worked on...
Thanks!
What happened since mid of march:
- i wrote a SDK and its documentation
- i coded TAK 1.0.1 and released it mid of april
- then i had nearly no time to work on TAK, nevertheless i released some bug fixes for the SDK and the Winamp plugin.
What i want to say: There was no time to work on any new features. And support for other platforms is not at the top of my to do list... (as mentioned earlier: not, because i don't want to do it, but because it means very much work. Other important items on my to do list are easier to do).
Thomas
What happened since mid of march:
- i wrote a SDK and its documentation
- i coded TAK 1.0.1 and released it mid of april
- then i had nearly no time to work on TAK, nevertheless i released some bug fixes for the SDK and the Winamp plugin.
What i want to say: There was no time to work on any new features. And support for other platforms is not at the top of my to do list... (as mentioned earlier: not, because i don't want to do it, but because it means very much work. Other important items on my to do list are easier to do).
Thomas
Thanks for the fast reply!
I was hoping that you started looking into support for other platforms when TAK reached a stable stage (version 1.0.1). But I now understand that is belongs somewhere in the distant future... (2008 maybe?)
Until then.. Thanks!
Is it possible for you to release a static library version for decoding?
Is there a directshow splitter available?
This would be a good thing
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
You are the first one asking for this. Which means a very low priority on my to do list...
Thomas
I think that is largely because it is not widely implemented in other formats and people do not understand the benefits. The wiki lossless table should be expanded to show this feature. ATM only WMA supports this among lossless codecs. Hopefully, FLAC will soon support it as well. Basically it will make it much easier to go back and update metadata with this feature because most metadata services use the original CD TOC to find metadata. In addition, my understanding is that it should not be difficult to support, meaning that while maybe a low priority it should not take long.
hmmm any chance of making a rockbox plugin?
hmmm any chance of making a rockbox plugin?
Good idea! I'd really appreciate it, if there would be some in the near future.
The header file "tak_dec_lib.h" should be modified like below:
#ifndef __TAK_DEC_LIB
#define __TAK_DEC_LIB
...
..
.
#endif
So I can include this header file in different position for serval times.
BTW: Is it possible for you to release a static library verson?
and, you can update the .h header file to support loading tak_dec_lib.dll by developers through "LoadLibrary()" so that we can put the .dll file into other folders other than the local working directory.
I was hoping that you started looking into support for other platforms when TAK reached a stable stage (version 1.0.1). But I now understand that is belongs somewhere in the distant future... (2008 maybe?)
2008 seems to be realistic.
Is there a directshow splitter available?
This would be a good thing
I agree. Possibly you will have to wait until somebody else writes one based upon the SDK. Currently i don't intend to do it myself. But maybe i get interested into doing it sometime (if i want to see, if i can do it...).
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
You are the first one asking for this. Which means a very low priority on my to do list...
Thomas
I think that is largely because it is not widely implemented in other formats and people do not understand the benefits. The wiki lossless table should be expanded to show this feature. ATM only WMA supports this among lossless codecs. Hopefully, FLAC will soon support it as well. Basically it will make it much easier to go back and update metadata with this feature because most metadata services use the original CD TOC to find metadata. In addition, my understanding is that it should not be difficult to support, meaning that while maybe a low priority it should not take long.
To be honest: When i had read your post i first had to google a bit to find out, what the embedding of the CD TOC would be good for. Now it looks as if i understood it right.
Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.
hmmm any chance of making a rockbox plugin?
Good idea! I'd really appreciate it, if there would be some in the near future.
Probably not before a source code release, which means not in the near future (this year).
The header file "tak_dec_lib.h" should be modified like below:
#ifndef __TAK_DEC_LIB
#define __TAK_DEC_LIB
...
..
.
#endif
So I can include this header file in different position for serval times.
You are right. I often tend to forget this, because it isn't needed in Delphi Pascal...
and, you can update the .h header file to support loading tak_dec_lib.dll by developers through "LoadLibrary()" so that we can put the .dll file into other folders other than the local working directory.
Maybe someone else likes to do this for me? I am not too fast in C.
BTW: Is it possible for you to release a static library verson?
I doubt that it is possible. The library is written in Delphi Pascal and therefore using Delphi's runtime library. But sooner or later i will translate it to C, then no problem.
Thomas
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
You are the first one asking for this. Which means a very low priority on my to do list...
Thomas
I think that is largely because it is not widely implemented in other formats and people do not understand the benefits. The wiki lossless table should be expanded to show this feature. ATM only WMA supports this among lossless codecs. Hopefully, FLAC will soon support it as well. Basically it will make it much easier to go back and update metadata with this feature because most metadata services use the original CD TOC to find metadata. In addition, my understanding is that it should not be difficult to support, meaning that while maybe a low priority it should not take long.
To be honest: When i had read your post i first had to google a bit to find out, what the embedding of the CD TOC would be good for. Now it looks as if i understood it right.
Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.
Thomas
I can have spoon email you the details. dBpoweramp is able to place raw CD TOC files into metadata, so he is a much better resource on what is required.
In that case, I'll note that i have quite a few Hebrew albums, And am willing to help test Unicode when needed.
Thanks for your offer!
If you still need testers for this, I have a lot of Japanese, Chinese, Korean, and Thai albums. Plus some of the Japanese ones use other characters from other Unicode ranges like
...
Hi, TBeck:
I'm using your tak decoder library for writing a decoder plug-in for a Media player.
I found that the "tak_SSD_Seek" always returned the fatal error "tak_res_ssd_Undecodable" whenever I invoked it.
Any idea about this situation?
In that case, I'll note that i have quite a few Hebrew albums, And am willing to help test Unicode when needed.
Thanks for your offer!
If you still need testers for this, I have a lot of Japanese, Chinese, Korean, and Thai albums. Plus some of the Japanese ones use other characters from other Unicode ranges like
Here is two pieces of my code
the Open decoder function:
int QDecoder::Open(QMediaReader & mediaReader)
{
TtakSSDOptions opt = { tak_Cpu_Any, 0 };
TtakStreamIoInterface sioi = { _CanRead, _CanWrite, _CanSeek, _Read, NULL, NULL, NULL, _Seek, _GetLength };
m_Decoder = tak_SSD_Create_FromStream( &sioi, &mediaReader, &opt, NULL, NULL);
int ret = 0;
_pmr = NULL;
if ( tak_True == tak_SSD_Valid( m_Decoder)) {
// get audio info
if ( tak_res_Ok != tak_SSD_GetStreamInfo( m_Decoder, &m_StreamInfo)) {
tak_SSD_Destroy( m_Decoder);
m_Decoder = NULL;
ret = 0;
} else {
// allocate decoding buffer
m_TAKBuf = new BYTE[m_StreamInfo.Sizes.FrameSizeInSamples * m_StreamInfo.Audio.BlockSize];
// save media reader
_pmr = &mediaReader;
_seekable = mediaReader.CanSeek();
ret = 1;
}
} else {
ret = (tak_res_ssd_Undecodable == tak_SSD_State( m_Decoder)) ? -1 : 0;
}
return ret;
}
and the Seek function
int QDecoder::Seek(int ms)
{
TtakResult ret;
TtakInt64 spos;
if ( tak_True != tak_SSD_Valid( m_Decoder))
return 0;
spos = (TtakInt64)(ms/1000.0 * m_StreamInfo.Audio.SampleRate);
ret = tak_SSD_Seek( m_Decoder, spos);
if ( tak_True != tak_SSD_Valid( m_Decoder))
return 0;
_pos = spos * m_StreamInfo.Audio.SampleRate * 1000.0;
return 1;
}
P.S. My "mediareader" only support read, seek, getlength, getcurpostion routines. I think it is not important for a decoder to support write function.
I know this has probably already been brought up by someone but... is any work being done to get Rockbox to play TAK files? I know TAK doesn't have the following of some of the other lossless codecs but man, it should. Anyway, just curious guys. Keep up the good work. Thanks.
I know this has probably already been brought up by someone but... is any work being done to get Rockbox to play TAK files?
Read the rest of the previous page of posts - you'll see the answer.
But speaking as a Rockbox dev (I've implemented a lot of the codecs in Rockbox), I would like to add that I would be happy to work on a TAK codec for Rockbox as soon as TBeck releases some source code (in any language, and in any state).
Very cool. Thank you. Hopefully TBeck will do that soon. I think it would be a good step in the right direction for TAK.
Here is two pieces of my code
...
P.S. My "mediareader" only support read, seek, getlength, getcurpostion routines. I think it is not important for a decoder to support write function.
That's ok. From the SDK documentation of tak_SSD_Create_FromStream:
Currently, the SSD uses the following functions of the interface:
CanRead
CanWrite
CanSeek
Read
Seek
GetLength
Most of your code looks ok. Two remarks for the Seek funtion:
and the Seek function
int QDecoder::Seek(int ms)
{
TtakResult ret;
TtakInt64 spos;
if ( tak_True != tak_SSD_Valid( m_Decoder))
return 0;
spos = (TtakInt64)(ms/1000.0 * m_StreamInfo.Audio.SampleRate);
ret = tak_SSD_Seek( m_Decoder, spos);
if ( tak_True != tak_SSD_Valid( m_Decoder))
return 0;
_pos = spos * m_StreamInfo.Audio.SampleRate * 1000.0;
return 1;
}
1) You don't have to check the validity of the decoder before calling tak_SSD_Seek(). If it was invalid before the call, the function will immediately return with an error code and your next call to tak_SSD_Valid() will return false. More info about error handling can be found in "Function results and error handling".
2) I am not sure, if your code guarantees, that the "spos" - parameter will always stay within the allowed range. From the SDK:
"ASamplePos must be a value between 0 and (stream length - 1)."
Unfortunately you haven't answered my other questions: Are you sure that your files are valid? Does at least sequential playback work with your plugin?
From my experience i would recommend to check your implementation of the TtakStreamIoInterface - interface. Here it's easy to make subtle errors...
Thomas
Unfortunately you haven't answered my other questions: Are you sure that your files are valid? Does at least sequential playback work with your plugin?
Yes, I can sure the tak files are valid. I can play/seek them with your winamp input plug-in and the foobar decoder component.
Here are my code for the TtakStreamIoInterface:
static TtakBool _CanRead(void * AUser) { return tak_True; }
static TtakBool _CanWrite(void * AUser) { return tak_False; }
static TtakBool _CanSeek(void * AUser) { return ((QMediaReader *)AUser)->CanSeek() ? tak_True : tak_False; }
static TtakBool _Read(void * AUser, void * ABuf, TtakInt32 ANum, TtakInt32 * AReadNum)
{
QMediaReader * pmr = (QMediaReader *)AUser;
*AReadNum = pmr->Read( (LPBYTE)ABuf, ANum);
if ( MSERROR_SUCCESS == pmr->GetLastError())
return tak_True;
else {
*AReadNum = 0;
return tak_False;
}
}
static TtakBool _Seek(void * AUser, TtakInt64 APos)
{
return ((QMediaReader *)AUser)->Seek( APos) ? tak_True : tak_False;
}
static TtakBool _GetLength(void * AUser, TtakInt64 * ALength)
{
QMediaReader * pmr = (QMediaReader *)AUser;
*ALength = pmr->GetSize();
if ( MSERROR_SUCCESS == pmr->GetLastError())
return tak_True;
else {
*ALength = 0;
return tak_False;
}
};The "QMediaReader" is a wrapped class which is supplied by player's development kits.
Unfortunately you haven't answered my other questions: Are you sure that your files are valid? Does at least sequential playback work with your plugin?
Yes, I can sure the tak files are valid. I can play/seek them with your winamp input plug-in and the foobar decoder component.
Thanks. This info was important, because TAK versions up to V1.0 Beta 1 could create invalid seek tables.
Here are my code for the TtakStreamIoInterface:
static TtakBool _Read(void * AUser, void * ABuf, TtakInt32 ANum, TtakInt32 * AReadNum)
{
QMediaReader * pmr = (QMediaReader *)AUser;
*AReadNum = pmr->Read( (LPBYTE)ABuf, ANum);
if ( MSERROR_SUCCESS == pmr->GetLastError())
return tak_True;
else {
*AReadNum = 0;
return tak_False;
}
}
The "QMediaReader" is a wrapped class which is supplied by player's development kits.
Probably the media reader's read function is responsible for the problems. From the SDK Documentation:
Read
Reads a maximum of ANum Bytes into ABuf. AReadNum contains the number of bytes actually read.
ATTENTION: Currently AReadNum may be less than ANum only at the end of a file!
I suppose, that the mediareader sometimes returns less bytes than requested. You may have to code a loop which calls the media readers's read function repetitively until TAK's requested byte count is reached.
If TAK get's less bytes than requested it will assume, that the file is damaged!
I hope, this helps.
Thomas
...
The "QMediaReader" is a wrapped class which is supplied by player's development kits.
...
I suppose, that the mediareader sometimes returns less bytes than requested. You may have to code a loop which calls the media readers's read function repetitively until TAK's requested byte count is reached.
If TAK get's less bytes than requested it will assume, that the file is damaged!
Hi shaohao, could you please tell me, if my last tip was helpful?
How do I determine the length of a TAK file in seconds? I tested the file with the TAK winamp plugin and for both the TAK and the WAV file it shows a file duration of 1:06 meaning 66 seconds. If I run takc -fi to get the file duration I get 67 secs. Why is there a difference of 1 second?
C:\Program Files\TAK>takc -fi 08-Within_Temptation-Intro.tak
...
File duration: 67.00 sec
...
Hm, TAK's file info function is reporting 67.00? Then i have done something wrong, this should be 66.96. I will look at it and fix it in the next version (I doubt, that it's urgent?).
Now fixed (for 1.0.2). Probably not very important, but it was part of my todo list and i liked to tick it off.
Hi shaohao, could you please tell me, if my last tip was helpful?
Hi, TBeck:
I have no time to test your tip. But I guess you are right.
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
You are the first one asking for this. Which means a very low priority on my to do list...
Thomas
I think that is largely because it is not widely implemented in other formats and people do not understand the benefits. The wiki lossless table should be expanded to show this feature. ATM only WMA supports this among lossless codecs. Hopefully, FLAC will soon support it as well. Basically it will make it much easier to go back and update metadata with this feature because most metadata services use the original CD TOC to find metadata. In addition, my understanding is that it should not be difficult to support, meaning that while maybe a low priority it should not take long.
To be honest: When i had read your post i first had to google a bit to find out, what the embedding of the CD TOC would be good for. Now it looks as if i understood it right.
Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.
CD TOCs are also used in Ripstation's ripper and will be required for support in their new metatagging tool:
http://www.hydrogenaudio.org/forums/index....st&p=503445 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=54992&view=findpost&p=503445)
Hopefully TAK will have support.
I just finished the TAK audio decoder plug-in for Quintessential Media Player 5.0 B117+
Visit My Q-Plugins Web site on SF.net and download this plug-in.
http://sourceforge.net/projects/qplugins (http://sourceforge.net/projects/qplugins)
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.
Since APEv2 supports binary data, I suggest you just dump the same data as everybody else in a "MCDI" tag item, i.e. ID3v2's MCDI (http://www.id3.org/id3v2.4.0-frames#line-706) frame. I have described the format here (http://www.hydrogenaudio.org/forums/index.php?showtopic=57010); only the first 32 bits (an application ID) is specific to FLAC.
But I'm not sure that concerns you... It's up to applications supporting such binary TOCs to store them adequately in a APEv2 tag item. Storing it in FLAC wasn't so hard either (settle on an application ID, and dump the data verbatim). I don't know what spoon is waiting for exactly.
Eli: aren't you barking at the wrong tree? Or am I missing something here?
Any updates on the new TAK version?
I'm receiving a weird error while starting up Winamp. I'm using the TAK 1.0.4.0 plugin and winamp version 5.5 beta 1500. It only happens when I have a TAK file previously loaded into the player.
--------------Boundary-00=_YYIMQL80000000000000
Content-Type: Text/Plain;
Charset="us-ASCII"
Content-Transfer-Encoding:
Winamp client version: 5.5 build 1550 Beta
Winamp caused an Access Violation (0xc0000005)
In module in_tak.dll at 001b:00d84cc3.
Exception handler called in Winamp.
--------------Boundary-00=_YYIMQL80000000000000--
When I took out the plugin, Winamp started up fine. I can send you the Winamp crash file if you would like Tbeck.
I just finished the TAK audio decoder plug-in for Quintessential Media Player 5.0 B117+
Visit My Q-Plugins Web site on SF.net and download this plug-in.
http://sourceforge.net/projects/qplugins (http://sourceforge.net/projects/qplugins)
Great news! Thank you!
TBeck, can you add the ability for TAK files to store CD TOC files? If you need more information spoon (dBpoweramp) can give you more details.
Is there a standard for APEv2 to put it into? This would be the easiest way (no work for me). Otherwises i would have to integrate a new meta data structure in the TAK container. This is always much work; even if it's easy to code it always involves a lot of testing.
Since APEv2 supports binary data, I suggest you just dump the same data as everybody else in a "MCDI" tag item, i.e. ID3v2's MCDI (http://www.id3.org/id3v2.4.0-frames#line-706) frame. I have described the format here (http://www.hydrogenaudio.org/forums/index.php?showtopic=57010); only the first 32 bits (an application ID) is specific to FLAC.
But I'm not sure that concerns you... It's up to applications supporting such binary TOCs to store them adequately in a APEv2 tag item. Storing it in FLAC wasn't so hard either (settle on an application ID, and dump the data verbatim). I don't know what spoon is waiting for exactly.
I agree.
I'm receiving a weird error while starting up Winamp. I'm using the TAK 1.0.4.0 plugin and winamp version 5.5 beta 1500. It only happens when I have a TAK file previously loaded into the player.
--------------Boundary-00=_YYIMQL80000000000000
Content-Type: Text/Plain;
Charset="us-ASCII"
Content-Transfer-Encoding:
Winamp client version: 5.5 build 1550 Beta
Winamp caused an Access Violation (0xc0000005)
In module in_tak.dll at 001b:00d84cc3.
Exception handler called in Winamp.
--------------Boundary-00=_YYIMQL80000000000000--
When I took out the plugin, Winamp started up fine. I can send you the Winamp crash file if you would like Tbeck.
Thank you for the bug report. I will probably wait until the final Winamp version is out before looking for the bug.
Any updates on the new TAK version?
For the past weeks i had nearly no time to work on the next version but i hope to be able to release it in about 2 to 4 weeks.
Thomas
For the past weeks i had nearly no time to work on the next version but i hope to be able to release it in about 2 to 4 weeks.
Thomas
Thanks for the update.