Skip to main content

Topic: TAK 1.0.1 (Read 87336 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
TAK 1.0.1
Reply #50
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).
  • Last Edit: 03 June, 2007, 03:07:56 PM by davechapman

TAK 1.0.1
Reply #51
Very cool. Thank you. Hopefully TBeck will do that soon. I think it would be a good step in the right direction for TAK.

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #52
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:
Code: [Select]
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
Code: [Select]
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

  • shaohao
  • [*][*]
TAK 1.0.1
Reply #53
Quote
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:
Code: [Select]
    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.

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #54
Quote

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:
Code: [Select]
    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:

Code: [Select]
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

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #55
...
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?

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #56
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.

  • shaohao
  • [*][*]
TAK 1.0.1
Reply #57
Quote
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.
  • Last Edit: 29 June, 2007, 10:06:15 PM by shaohao

  • Eli
  • [*][*][*][*][*]
TAK 1.0.1
Reply #58



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

Hopefully TAK will have support.

  • shaohao
  • [*][*]
TAK 1.0.1
Reply #59
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

  • skamp
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #60
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 frame. I have described the format here; 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?
See my profile for measurements, tools and recommendations.

  • mzso
  • [*][*][*][*]
TAK 1.0.1
Reply #61
Any updates on the new TAK version?

  • spockep
  • [*][*][*]
TAK 1.0.1
Reply #62
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. 

Code: [Select]
--------------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.

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK 1.0.1
Reply #63
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

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 frame. I have described the format here; 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. 

Code: [Select]
--------------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

  • mzso
  • [*][*][*][*]
TAK 1.0.1
Reply #64
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.