Hydrogenaudio Forums

davechapman

Jun 3 2007, 13:07

QUOTE(Brydenn33 @ Jun 3 2007, 10:24)

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

Brydenn33

Jun 4 2007, 00:58

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

Jun 6 2007, 15:59

QUOTE(shaohao @ Jun 3 2007, 15:31)

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

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:

QUOTE(shaohao @ Jun 3 2007, 15:31)

and the Seek function

CODE

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

Jun 7 2007, 05:30

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

    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

Jun 7 2007, 11:29

QUOTE(shaohao @ Jun 7 2007, 12:30)

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.

QUOTE(shaohao @ Jun 7 2007, 12:30)

Here are my code for the TtakStreamIoInterface:

CODE

    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

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

Jun 20 2007, 21:57

QUOTE(shaohao @ Jun 7 2007, 12:30)

...
The "QMediaReader" is a wrapped class which is supplied by player's development kits.

QUOTE(TBeck @ Jun 7 2007, 18:29)

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

Jun 25 2007, 03:40

QUOTE(fairway @ Apr 22 2007, 19:15)

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

QUOTE(TBeck @ Apr 22 2007, 20:16)

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

Jun 25 2007, 05:27

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.

Eli

Jul 9 2007, 13:56

QUOTE(TBeck @ May 30 2007, 21:15)

QUOTE(Eli @ May 29 2007, 14:34)

QUOTE(TBeck @ May 26 2007, 21:20)

QUOTE(Eli @ May 24 2007, 13:49)

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

Aug 27 2007, 11:55

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

Aug 27 2007, 12:46

QUOTE(Eli @ May 24 2007, 13:49)

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.

QUOTE(TBeck @ May 31 2007, 03:15)

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?

mzso

Sep 8 2007, 11:18

Any updates on the new TAK version?

spockep

Sep 19 2007, 10:38

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

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

Sep 20 2007, 05:13

QUOTE(shaohao @ Aug 27 2007, 18:55)

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!

QUOTE(skamp @ Aug 27 2007, 19:46)

QUOTE(Eli @ May 24 2007, 13:49)

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.

QUOTE(TBeck @ May 31 2007, 03:15)

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.

QUOTE(spockep @ Sep 19 2007, 17:38)

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

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

QUOTE(mzso @ Sep 8 2007, 18:18)

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

Oct 6 2007, 03:23

QUOTE(TBeck @ Sep 20 2007, 13:13)

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.