Hydrogenaudio Forums

Lossless Audio Compression => Lossless / Other Codecs => Topic started by: TBeck on 2007-03-09 22:03:32

Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-09 22:03:32
TAK 1.0.1 Development

Some information about the next TAK version and some future plans.

SDK

I rewrote considerable parts of TAK to make interfacing to external Application via my new SDK easier. The first SDK version will probably only contain decoding functionality. It consists of a Windows DLL and Header files in Pascal and C.

TAK 1.0.1 will use the modified code, which also contains some improvements, for instance even better handling of damaged files.

Speed

Although the code of TAK 1.0 already was highly optimized, i could squeeze a bit more speed out of it. Encoding may be up to 5, Decoding up to 8 percent faster in V1.0.1 (CPU dependend). I doubt, that i can make decoding even faster without breaking the format compatibility. But future improvements of the encoding speed are possible.

Winamp plugin

As soon as my SDK is done, i will recompile the Winamp plugin (which is using the SDK code) and release it as beta version.

Plugins for other players...

may follow. My SDK already seems to work very well with some other popular player... But that's confidential for now.

Release date

As soon as possible. But currently i have to work on some other things, therefore it may take some weeks.


Future plans

More speed

Earlier i wanted to develop a dedicated Turbo codec with considerably higher decoding speed. It should only be used for preset Turbo.

But after some evaluation i found out, that the speed oriented modifications have so little effect on the compression efficiency (less than 0.02 percent), that it is appropriate to apply them to any preset! Therefore i prefer to build a new all-in-one codec with higher decoding speeds for any preset.

Better compression

I have some new ideas for compression improvements and first evaluations are looking promising. It seems possible to achieve about 0.2 to 0.3 percent better compression for preset Extra.

More exciting are possible improvements of preset Turbo, Fast and Normal. Some files really like the PreFilter option, which is beeing applied in presets High and Extra. Unfortunately this option slows down both encoding and decoding.

But i have found a way to achieve about 60 percent of the PreFilter efficiency without any impact on encoding or decoding speed! Hence the faster presets will compress better without loosing any speed.

And there is another idea to improve the channel decorrelation of preset Turbo. If it works, it will increase the compression efficiency with no effect on decoding speed but at the price of a bit slower encoding.

When will the new codec be available?

When it is done! It needs much time to evaluate my new ideas and to check interactions with the existing methods of the current codec.

  Thomas
Title: TAK 1.0.1 Development
Post by: Night Rain on 2007-03-09 22:17:59
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.
Title: TAK 1.0.1 Development
Post by: kanak on 2007-03-09 23:04:12
I agree with Night Rain. I've adopted TAK and recompressed all my lossless to TAK @ 4 (saving anywhere from 3 to 25 mb per album), but now i have a bunch of lossless files that i need to use an entirely different player to playback! Not a nice situation.

Please give the foobar playback plugin atleast as much priority as the winamp one. Please.

Could you also elaborate on the Replaygain support?

Thanks for your work on tak.
Title: TAK 1.0.1 Development
Post by: Paws on 2007-03-09 23:11:53
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.


I would love to have this. It's a great lossless codec.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-09 23:24:55
Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

Please give the foobar playback plugin atleast as much priority as the winamp one. Please.


Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

I would love to have this. It's a great lossless codec.

Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...
Title: TAK 1.0.1 Development
Post by: kanak on 2007-03-09 23:31:30
Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...


Why not release it as a pre-alpha or something so we can tool around? 
Title: TAK 1.0.1 Development
Post by: Night Rain on 2007-03-09 23:34:40

Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

Please give the foobar playback plugin atleast as much priority as the winamp one. Please.


Try releasing the code and a Foobar plugin. I think a lot of interest has waned by your lack of followthrough.

I would love to have this. It's a great lossless codec.

Probably i wasn't clear enough: Plugins for other players have a very high priority for me! That's the primary reason why i am working on my SDK. It's close to an release, but it needs some more testing performed by other developers and i have to write some documentation. I simply can't do this immediately because i currently have to work for money...


Perhaps version 1 should not have been released until more was ready. I see a steady decline in interest in TAK.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-09 23:49:41
Perhaps version 1 should not have been released until more was ready. I see a steady decline in interest in TAK.

Why that?

Because there are a bit less posts regarding TAK at hydrogen? (Except about logo or wiki...) What should people post? Before the release i have frequently asked for testing or feedback and the members responded. It would be easy to increase the frequency of TAK posts by asking for some pre release tests. Would this mean, that TAK is more alive?

Oh, i am not sure, if i have seen a post in the WavPack forum today. Is this a bad sign for WavPacks future?

Until now i myself have not performed any serious promotion work for TAK (outside of hydrogen). Therefore TAK 1.0 possibly has been some kind of a secret release...

  Thomas
Title: TAK 1.0.1 Development
Post by: Eli on 2007-03-10 01:14:36
Speed

Although the code of TAK 1.0 already was highly optimized, i could squeeze a bit more speed out of it. Encoding may be up to 5, Decoding up to 8 percent faster in V1.0.1 (CPU dependend). I doubt, that i can make decoding even faster without breaking the format compatibility. But future improvements of the encoding speed are possible.



Better compression

I have some new ideas for compression improvements and first evaluations are looking promising. It seems possible to achieve about 0.2 to 0.3 percent better compression for preset Extra.

More exciting are possible improvements of preset Turbo, Fast and Normal. Some files really like the PreFilter option, which is beeing applied in presets High and Extra. Unfortunately this option slows down both encoding and decoding.


If you have ways to significantly improve speed and/or compression I think you should go ahead and use all of the tricks NOW, even if it breaks current compatibility. TAK looks to be a very promising Lossless codec in the FUTURE. There should be very few if any people with a significant number of tracks in the TAK format. If you really want the format to compete it needs to be as good as possible. It seems to perform a bit better then FLAC (dont know vs 1.1.4), but for people to really want to change from a heavily supported, well documented, opensource format you need to really blow the old codec out of the water.
Title: TAK 1.0.1 Development
Post by: Lyx on 2007-03-10 01:26:22
I agree that any format-compatibility breakage should happen rather soon if it is worth it. TAK as well as lossless-codecs in general are just at the beginning of their journey. If it is worth it, then better break now instead of later.

- Lyx
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-10 01:46:34
If you have ways to significantly improve speed and/or compression I think you should go ahead and use all of the tricks NOW, even if it breaks current compatibility. TAK looks to be a very promising Lossless codec in the FUTURE. There should be very few if any people with a significant number of tracks in the TAK format. If you really want the format to compete it needs to be as good as possible. It seems to perform a bit better then FLAC (dont know vs 1.1.4), but for people to really want to change from a heavily supported, well documented, opensource format you need to really blow the old codec out of the water.


I agree that any format-compatibility breakage should happen rather soon if it is worth it. TAK as well as lossless-codecs in general are just at the beginning of their journey. If it is worth it, then better break now instead of later.

Much easier said than done!

As i wrote earlier, it took me years to develop the current version of TAK! It can take up to a year to build a new codec with implementations of all the ideas i have. This involves evaluations, optimizations and very much testing and verification.

Maybe i will release an intermediate version. But if i do this, i will also include a function to use Tak files as encoder input for an easy upgrade to the new codec.
Title: TAK 1.0.1 Development
Post by: Destroid on 2007-03-10 01:59:32
I wanted to be one of first to say, "Thanks for the good news about TAK!"

For what it's worth, I don't see a plethora of users outside HA that use Foobar, so I don't care about the lack of a Foobar plugin, the Winamp plugin is a better start.

I await for the person clever enough to use the upcoming SDK to make a TAK_flt.dll (a.k.a. Cooledit filter)
Title: TAK 1.0.1 Development
Post by: bhoar on 2007-03-10 02:18:03
As i wrote earlier, it took me years to develop the current version of TAK! It can take up to a year to build a new codec with implementations of all the ideas i have. This involves evaluations, optimizations and very much testing and verification.

Maybe i will release an intermediate version. But if i do this, i will also include a function to use Tak files as encoder input for an easy upgrade to the new codec.


T - does the TAK file/storage format include a dataformat versioning field somewhere in the header or stream, to ensure that future decoders will be able to route the data to the older vs. newer engines?

-brendan
Title: TAK 1.0.1 Development
Post by: sPeziFisH on 2007-03-10 09:35:06
you take care of your music-collection, you are using lossless-codecs for backing up, you are willing to invest some time for your collection, you are able to work with new codecs to get any benefits and you decided to for some reasons, you are able to cope with encode-decode...

..then I don't get the clue - you are aware of using an really interesting and promising new codec, for ree, encoding & decoding is possible, playback needs time (with foobar) as - said more than 10 times - the SDK has to be finished, with winamp it's possible (you can use 1by1 (http://mpesch3.de1.cc/) for light-weighting), and..

no no, I am not argueing, but still wondering why someone has to answer and comment all the questions and comments spent again and again.
And if it's brought too early for you, don't use it, it's not adressed to you..
Title: TAK 1.0.1 Development
Post by: sundance on 2007-03-10 09:58:28
Quote
Could you also elaborate on the Replaygain support?

Maybe I missed something, but I always thought that replaygain support isn't a codec's feature but a player's. If e.g. TAK is going to use APEv2 tags and corresponding replaygain tags are stored, I'm pretty sure that foobar (and other players reading that tags) will be able to use it...
Title: TAK 1.0.1 Development
Post by: jido on 2007-03-10 23:36:24
Nice progress with TAK, I didn't expect performance improvements so soon after 1.0.
Good news about the SDK l guess that means more plugins coming soonish.

Interest for TAK waning? Hello, when has it taken off anyway? Afaik it is still a ha.org private affair at the moment.

TAK does blow FLAC (which is not an old codec) out of the water by compressing more at comparable speed. But if that is not something that matters to me, I will keep using FLAC which is the best choice in my case. People will keep using different lossless codecs and that is good.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-11 01:00:27
I wanted to be one of first to say, "Thanks for the good news about TAK!"

Hi Destroid, thank you!

T - does the TAK file/storage format include a dataformat versioning field somewhere in the header or stream, to ensure that future decoders will be able to route the data to the older vs. newer engines?

Surely! Both the header and the stream itself (which is also decodable without the header available) contain info about the codec version and the decoding requirements (calculation complexity).

..then I don't get the clue - you are aware of using an really interesting and promising new codec, for ree, encoding & decoding is possible, playback needs time (with foobar) as - said more than 10 times - the SDK has to be finished, with winamp it's possible (you can use 1by1 (http://mpesch3.de1.cc/) for light-weighting), and..

no no, I am not argueing, but still wondering why someone has to answer and comment all the questions and comments spent again and again.
And if it's brought too early for you, don't use it, it's not adressed to you..

Thank you for those words...

Nice progress with TAK, I didn't expect performance improvements so soon after 1.0.

I had not planned to work on improvements, but while cleaning up my source code for the SDK i found some opportunities for optimizations and couldn't resist...

The same was true for the new ideas for compression improvements for future versions. I haven't worked on this for some time and this break possibly was useful for building up some new connections in my mind...

Interest for TAK waning? Hello, when has it taken off anyway? Afaik it is still a ha.org private affair at the moment.

I agree. And that's intentional...
Title: TAK 1.0.1 Development
Post by: spockep on 2007-03-11 17:40:33
This is a great list of improvements.  Looks like TAK is coming along great for being so new.  The ability to use tagging is the only really great thing that is missing.  Keep up the great work!!
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-26 09:43:11
Current progress

yes, there is progress!

The work on the SDK documentation has taken much time. The code is complete and currently beeing tested by some other developer.

I added a new meta data structure to the format, which contains the encoder version, the preset and the evaluation level. No, i haven't forgotten it in TAK 1.0, but it would have been quite useless with all the encoder options available. The main purpose of this info is the possibility to define conditions for transcoding purposes, for instance: Transcode any file to preset HIGH / Evaluation MAX if it has been compressed with weaker settings. Such rules would have been far too complicated if you had to deal with all the encoder options of TAK 1.0. But since TAK 1.0.1 will remove these options and instead add a new evaluation level EXTRA, it's now practicable.

Evaluation EXTRA is especially interesting if applied to Presets TURBO or FAST, because it significantly increases compresion (up to 0.30 percent) with a speed penality of only 25 to 30 percent.

Because i anyhow had to write some code to check the new meta data structure, i added a new feature: TAK 1.0.1 can show you some information about the internals of TAK files. It looks like this:

Code: [Select]
=== BeautySlept.tak ===========================================

  File size:                     1.64 MB
  Header size:                   0.18 KB
  Compression:                  62.44 %
  Samples per channel:         689262
  File duration:                16.00 sec
  Frame duration:                  94 ms
  Seek point interval:            937 ms
  Audio format:            PCM, 44100 Hz, 16 Bits, 2 Channels
  Encoder:                 V 1.0.1, Preset Turbo, Evaluation Standard
  Wave file meta data:     Header 46, Footer 0 Bytes
  Status:                  Ok


As usual this info can also be collected from a set of files and be written to a log file.

  Thomas
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-30 16:21:32
Current progress

Well, it will take a bit longer to finalize my SDK. I have deceided to add support for reading APEv2 tags, which is the recommended tagging standard for TAK. This means more testing, documentation and translation.

When it's done i will also release a new WinAmp plugin with APEv2 support.

  Thomas
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-30 16:47:56
Hi Thomas.

I'm confused.  Reading?  I know plugins will need to read tags, but I would have thought TAK only need be concerned about writing tags.

Not that I know diddly of course, just an opportunity to say hi and maybe squeeze you for a little more info...
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-30 17:21:22
Hi Thomas.

Hi Neil  .
I'm confused.  Reading?  I know plugins will need to read tags, but I would have thought TAK only need be concerned about writing tags.

Not that I know diddly of course, just an opportunity to say hi and maybe squeeze you for a little more info...

Hm, maybe you are right. The reason why i wanted to add support for reading tags:

1) The wavpack sdk and other sdks support it. Me too!

2) The winamp playback plugin interface contains functions to request tag info. I want to provide it.

3) Writing code to read the tags is a good starting point for me to learn a bit more about APEv2 tags. It's less dangerous than writing them (if there are bugs in the code).

4) Probably i will later add an option to move the APEv2 tag into TAK's meta data structure located at the beginning of the file. Then you will need TAK's functions to access it.

I used the TAG tool from your homepage to add tags to my test files. Thank you! When i looked at the header and footer it generated, i was a bit surprised.

You know that there are two flags in both the APEv2 header and footer, indicating if there is also a footer respectively header.

This is the result from tags created with TAG.EXE (appended to the file end):
Code: [Select]
Header
  ContainsHeader = False
  ContainsFooter = False
Footer
  ContainsHeader = True
  ContainsFooter = False


I would have expected this (if header and footer are present):

Code: [Select]
Header
  ContainsHeader = True
  ContainsFooter = True
Footer
  ContainsHeader = True
  ContainsFooter = True


Ok, the most important information is there: if you read the footer at the file end, you indeed only need to know if there is also a header. But i was surprised.

Another question about the format: Items (or Keys) can contain multiple values seperated by NULL. Is this option really used?

  Thomas
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-30 17:34:45
Well, seems like you do have good reason.  I should have known.

Thanks for the info RE: Tag.  Tag was written by Case and I have merely made a few mods and updated the libraries.  I am aware that there are headers and footers but I have no idea what Tag is doing in this area.  I may have to read up on the spec as well!

foobar has functionality for multiple values in one tag.  I think it may be used more so with tagging classical music.  In essence, I would say "yes" - but I hope that someone with more tagging experience sees this and responds with more clarity.

Thanks for the info, and good luck with the continuing work.  Whether I respond or not I do always read your updates with interest.
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-30 20:14:17
On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-30 20:47:58
On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

Totally!

I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.

Me too! Painful... Well, things may get better soon, because i just ordered some new glasses. Now i know, how urgent this was...

Thank you!

  Thomas
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-30 21:34:28
Cool.  Thanks for the confirmation. 

Looking forward to seeing the advancements.

BTW: I assume that you are aware of the spec (http://wiki.hydrogenaudio.org/index.php?title=APEv2_specification) in the wiki?  I guess you must be, but I thought I may as well mention it.

Cheers Thomas.
Title: TAK 1.0.1 Development
Post by: bryant on 2007-03-30 22:01:18
On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.

BTW, there is some reason behind this madness. The original APEv1 tag didn't have any of those flags and did not have the header at all (only the footer). So, the values of the flags were chosen so that all zeros meant "no header, this is the footer" which allows the new format to be backward compatible with APEv1 tags (not counting the UTF-8 issue, of course).
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-30 22:35:29
BTW, there is some reason behind this madness. The original APEv1 tag didn't have any of those flags and did not have the header at all (only the footer). So, the values of the flags were chosen so that all zeros meant "no header, this is the footer" which allows the new format to be backward compatible with APEv1 tags (not counting the UTF-8 issue, of course).
Ah, thanks for the background info David.

@Thomas, FYI, Tag.exe can set multiple values for a tag.  The separator was "; ", but following a request from a user I amended it, as many people embed the EAC log which often (always?) contains "; ".  I amended the separator to "<>"  to try to stop any ambiguity.  foobar uses ";".  In retrospect I probably should have left it as "; " and done something about "; " in files used with the -f switch... No-one's said anything about it and I do wonder whether anyone uses the functionality.

I think it is very useful to be able to set a tag from the contents of a file.  That's the whole reason I made the effort to adapt Case's Tag in the first place (my site has a link to the initial thread).  WavPack has had the functionality for a while (kudos to David!), and FLAC now has also.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-30 23:35:05

On checking I think Tag is fine.

The header says "Tag contains a header, tag contain a footer, this is the header" (31 = 1, 30 = 0, 29 = 1) while the footer says "Tag contains a header, tag contain a footer, this is the footer" (31 = 1, 30 = 0, 29 = 0).

Do you agree?

I was confused for a while, until I realised that bit 30 as 0 meant there was a footer.

BTW, there is some reason behind this madness. The original APEv1 tag didn't have any of those flags and did not have the header at all (only the footer). So, the values of the flags were chosen so that all zeros meant "no header, this is the footer" which allows the new format to be backward compatible with APEv1 tags (not counting the UTF-8 issue, of course).

Good to know that the madness does make sense. Thank you.

@Thomas, FYI, Tag.exe can set multiple values for a tag.  The separator was "; ", but following a request from a user I amended it, as many people embed the EAC log which often (always?) contains "; ".  I amended the separator to "<>"  to try to stop any ambiguity.  foobar uses ";".  In retrospect I probably should have left it as "; " and done something about "; " in files used with the -f switch... No-one's said anything about it and I do wonder whether anyone uses the functionality.

Hm, i was referring to the APEv2 wiki: APE Item Value -> List of entries:

"Items are not zero-terminated like in C/C++. If there's a zero character, multiple items are stored under the key and the items are separated by zero characters."

Possibly the fact that TAG isn't using zero characters should tell me something. Maybe the zero character variant is rarely beeing used...

I think it is very useful to be able to set a tag from the contents of a file.  That's the whole reason I made the effort to adapt Case's Tag in the first place (my site has a link to the initial thread).  WavPack has had the functionality for a while (kudos to David!), and FLAC now has also.

Oh yes, this option would also be useful for my current testing of my tag reader. But i am not sure, if i will add tag writing functions to TAK 1.0.1.

Unfortunately i myself am rarely performing tagging. Therefore i am lacking practical experience. Yes, i can read specifications (not always right!) and put them into code. But from my experience this isn't always sufficient, you often need practise to make it really good or find details missing in the specification. I will first release a version with tag reading functions and if everything works well later add the write functions.

  Thomas
Title: TAK 1.0.1 Development
Post by: bryant on 2007-03-31 00:01:02

@Thomas, FYI, Tag.exe can set multiple values for a tag.  The separator was "; ", but following a request from a user I amended it, as many people embed the EAC log which often (always?) contains "; ".  I amended the separator to "<>"  to try to stop any ambiguity.  foobar uses ";".  In retrospect I probably should have left it as "; " and done something about "; " in files used with the -f switch... No-one's said anything about it and I do wonder whether anyone uses the functionality.

Hm, i was referring to the APEv2 wiki: APE Item Value -> List of entries:

"Items are not zero-terminated like in C/C++. If there's a zero character, multiple items are stored under the key and the items are separated by zero characters."

Possibly the fact that TAG isn't using zero characters should tell me something. Maybe the zero character variant is rarely beeing used...

I think maybe two different things are being discussed here.

In the APEv2 tag there may be multiple items stored under the same key, and these are separated by NULLs (although the last one doesn't have a NULL because the byte count is used for the length). However, when the strings are specified (or displayed), there's no way to input (or output) a NULL, so this has to be converted into some other regular but uncommon character. I used a \ when I display tags using wvunpack.exe because a tag editor I was using for testing (Mp3tag) used this. However, I don't have this facility when the tags are created because I assume that if people want to get that fancy with tags they'll be using a dedicated editor (EAC has no way to specify multiple items, AFAIK).

It's too bad that neither of the original creators of APE tags are still active with them because the spec could use a little clarification (like some standardized key names). Oh well...

David
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-31 00:16:47


@Thomas, FYI, Tag.exe can set multiple values for a tag.  The separator was "; ", but following a request from a user I amended it, as many people embed the EAC log which often (always?) contains "; ".  I amended the separator to "<>"  to try to stop any ambiguity.  foobar uses ";".  In retrospect I probably should have left it as "; " and done something about "; " in files used with the -f switch... No-one's said anything about it and I do wonder whether anyone uses the functionality.

Hm, i was referring to the APEv2 wiki: APE Item Value -> List of entries:

"Items are not zero-terminated like in C/C++. If there's a zero character, multiple items are stored under the key and the items are separated by zero characters."

Possibly the fact that TAG isn't using zero characters should tell me something. Maybe the zero character variant is rarely beeing used...

I think maybe two different things are being discussed here.

In the APEv2 tag there may be multiple items stored under the same key, and these are separated by NULLs (although the last one doesn't have a NULL because the byte count is used for the length). However, when the strings are specified (or displayed), there's no way to input (or output) a NULL, so this has to be converted into some other regular but uncommon character. I used a \ when I display tags using wvunpack.exe because a tag editor I was using for testing (Mp3tag) used this. However, I don't have this facility when the tags are created because I assume that if people want to get that fancy with tags they'll be using a dedicated editor (EAC has no way to specify multiple items, AFAIK).

I added two different values to one key with TAG, and TAG seperated them only with "<>" (says my hex editor), but not with a zero character... But you are right, my initial question referred to the binary representation of the tag, not the way it is beeing specified at the command line.
Title: TAK 1.0.1 Development
Post by: Wombat on 2007-03-31 00:53:07
Until tak gets some attention by users like for example the Slimdevices people do it isn´t necesary to offer any improvements. Is it?
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-31 01:15:25
Until tak gets some attention by users like for example the Slimdevices people do it isn´t necesary to offer any improvements. Is it?

If i had only worked on TAK if i got enough attention, it never would have been released. I think, that most developers of free software are being driven by their own interest into their work, they want to see what they can achieve. Without this internal motivation there probably would be very little progress.

I myself have a very clear conception of what i would like TAK to be and currently it is far away from this...

Should i wait with the release of for instance the SDK? Well, i already got requests from other developers who want to add TAK support to their applications. Those improvements are a precondition for more support and attention.

IMHO: Probably the interest into hardware implemetations is a bit overemphasized (not representative) at hydrogen.
Title: TAK 1.0.1 Development
Post by: Wombat on 2007-03-31 02:44:22
Don´t misunderstand me. TAK is cool, but with my Core2 and plenty of processing power i don´t know why i should go for 3% of less space if space doesn`t cost much.
Even if your ideas are real breaktroughs i always think why we do need another lossless codec!?
Here on Hydrogen of cause you´ll reach some attention.
Sorry, i am to dump to create such codec nobody needs.
Playing around with bytes is another story...
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-31 02:59:32
Don´t misunderstand me. TAK is cool, but with my Core2 and plenty of processing power i don´t know why i should go for 3% of less space if space doesn`t cost much.

That's a point of view i can perfectly understand. It's probably a matter of personal taste. For some people 3 percent are important, for others not. I remember many posts of people who have switched to WavPack because of 1 percent better compression.

BTW: I received a mail from one happy user who transcoded his audio books (mostly speech) from FLAC to TAK and reported 10 percent better compression. (Caution: Don't expect such a big improvements for music. Although i know that TAK performs quite well on speech, 10 percent is a really rare result).

Sorry, i am to dump to create such codec nobody needs.

I doubt, that nobody is interested into TAK. If someone really needs it, is a different matter.
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-31 06:52:21
I think maybe two different things are being discussed here.

In the APEv2 tag there may be multiple items stored under the same key, and these are separated by NULLs (although the last one doesn't have a NULL because the byte count is used for the length). However, when the strings are specified (or displayed), there's no way to input (or output) a NULL, so this has to be converted into some other regular but uncommon character.
I added two different values to one key with TAG, and TAG seperated them only with "<>" (says my hex editor), but not with a zero character... But you are right, my initial question referred to the binary representation of the tag, not the way it is beeing specified at the command line.
David is correct that I was discussing the interface, rather than the storage method - in Tag.exe the null separator is created using "<>".  I tested this yesterday following your initial enquiry, and did note that it looks awful when displaying current tags, so I'm thinking of changing it to something more aesthetic, or reverting to "; " and pre-processing the content of files.

When I tested I loaded the tagged files into foobar, and foobar listed them with the ";" separator as expected (or "," in ColumnsUI).  I'm very confused regarding what you have seen in your hex editor -  I guess I best take a look also.  Given the following screenshot though I can't see how it can be the case - unless perhaps you used it in a field that won't allow it (if there is such a thing).

(http://img227.imageshack.us/img227/72/nullol5.th.jpg) (http://img227.imageshack.us/my.php?image=nullol5.jpg)

Edit: OK, tested in hex editor and the null char does exist (see screenshot below).  Confused.

(http://img295.imageshack.us/img295/5412/hexoj0.th.jpg) (http://img295.imageshack.us/my.php?image=hexoj0.jpg)

Edit: FYI, I have just tested reverting to "; " as the separator, but ignoring it in tag sizes greater than 256 bytes, which I would presume to be file contents (like the EAC log).  I am happier with this implementation, especially as I don't like to mess with Case's "concepts" if I can help it.  If you would prefer this version you can download it here (http://www.synthetic-soul.co.uk/files/tag_2.0.52b1.zip).  At a later date I might check that there is no way that I can tell if the tag was from file contents or not.  I don't think there is, but this would be better then the 256 bytes check.
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-03-31 15:51:00
I use my project Dynamite for add APE Tag v2.00 in TAK files... 

Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-31 16:04:25
I think maybe two different things are being discussed here.

In the APEv2 tag there may be multiple items stored under the same key, and these are separated by NULLs (although the last one doesn't have a NULL because the byte count is used for the length). However, when the strings are specified (or displayed), there's no way to input (or output) a NULL, so this has to be converted into some other regular but uncommon character.

I added two different values to one key with TAG, and TAG seperated them only with "<>" (says my hex editor), but not with a zero character... But you are right, my initial question referred to the binary representation of the tag, not the way it is beeing specified at the command line.
David is correct that I was discussing the interface, rather than the storage method - in Tag.exe the null separator is created using "<>".  I tested this yesterday following your initial enquiry, and did note that it looks awful when displaying current tags, so I'm thinking of changing it to something more aesthetic, or reverting to "; " and pre-processing the content of files.

When I tested I loaded the tagged files into foobar, and foobar listed them with the ";" separator as expected (or "," in ColumnsUI).  I'm very confused regarding what you have seen in your hex editor -  I guess I best take a look also.  Given the following screenshot though I can't see how it can be the case - unless perhaps you used it in a field that won't allow it (if there is such a thing).

Well, i should have shown you my command line parameters...

Code: [Select]
TAG.EXE --artist "My Artist 1<>My Artist 2" --artist "My Artist 3"

TAG will separate "My Artist 1" and "My Artist 2" with a zero char. Fine. But then it will add "<>My Artist 3", hence use "<>" instead of a zero as separator.

Until your latest post i always used: "TAG.EXE --artist "My Artist 1" --artist "My Artist 2", and you were probably talking about TAG.EXE --artist "My Artist 1<>My Artist 2". This generated more confusion... Sorry. Next time i will immediately post the cmd line.

I don't know how important this minor bug is, probably nobody else is using my syntax. And maybe i should read TAG's documentation...
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-03-31 17:07:33
I don't know how important this minor bug is, probably nobody else is using my syntax. And maybe i should read TAG's documentation...


Why don't use Delphi component that I've sent to you, Thomas? 
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-31 20:01:54
Well, i should have shown you my command line parameters...

Code: [Select]
TAG.EXE --artist "My Artist 1<>My Artist 2" --artist "My Artist 3"

TAG will separate "My Artist 1" and "My Artist 2" with a zero char. Fine. But then it will add "<>My Artist 3", hence use "<>" instead of a zero as separator.

Until your latest post i always used: "TAG.EXE --artist "My Artist 1" --artist "My Artist 2", and you were probably talking about TAG.EXE --artist "My Artist 1<>My Artist 2". This generated more confusion... Sorry. Next time i will immediately post the cmd line.

I don't know how important this minor bug is, probably nobody else is using my syntax. And maybe i should read TAG's documentation... crying.gif
Hmmm... I think your syntax is a little odd, but I am confused by the results.  I will take a look.  Thanks for highlighting it, but I can't promise that I can resolve it. 

Why don't use Delphi component that I've sent to you, Thomas? huh.gif
Your link doesn't work for me.  I just get redirected to http://home.altervista.org/site/ (http://home.altervista.org/site/).  Edit:  It seems to work now - possibly because I first visited your homepage (http://oviri.altervista.org/).

Does your app deal with tagging multiple values?
Title: TAK 1.0.1 Development
Post by: kanak on 2007-03-31 20:05:51
Why don't use Delphi component that I've sent to you, Thomas? huh.gif
Your link doesn't work for me.  I just get redirected to http://home.altervista.org/site/ (http://home.altervista.org/site/).



Try copying the URL and pasting it in the address bar (instead of clicking the link). It worked for me.
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-03-31 20:10:36
Yes, thank you. That's how I go it to work eventually.  After visiting his homepage the link seemed to work as well.  I guess it's some hotlinking thing...
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-03-31 22:32:49

I don't know how important this minor bug is, probably nobody else is using my syntax. And maybe i should read TAG's documentation...


Why don't use Delphi component that I've sent to you, Thomas? 

Simply because i only had TAG when i started my testing. And for my (batch controled) testing purposes a command line tool was better suited. But i will try your tool soon. 

Well, i should have shown you my command line parameters...

Code: [Select]
TAG.EXE --artist "My Artist 1<>My Artist 2" --artist "My Artist 3"

TAG will separate "My Artist 1" and "My Artist 2" with a zero char. Fine. But then it will add "<>My Artist 3", hence use "<>" instead of a zero as separator.

Until your latest post i always used: "TAG.EXE --artist "My Artist 1" --artist "My Artist 2", and you were probably talking about TAG.EXE --artist "My Artist 1<>My Artist 2". This generated more confusion... Sorry. Next time i will immediately post the cmd line.

I don't know how important this minor bug is, probably nobody else is using my syntax. And maybe i should read TAG's documentation... crying.gif

Hmmm... I think your syntax is a little odd, but I am confused by the results.  I will take a look.  Thanks for highlighting it, but I can't promise that I can resolve it. 

I am really not sure if a fix is neccessary (definitely not for me). Possibly a hint in the documentation would be sufficient (if it is not already there). Hey, you don't have to use my odd syntax!
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-04-01 04:56:08
Does your app deal with tagging multiple values?


Sure 

Just open a file (or use Drag'N'Drop) and you can add, edit or remove APE Tag 

Naturally it's only an example (i made it in five minutes)...

In theory he can support Monkey's Audio and WavPack and all files who support APE Tag 


Simply because i only had TAG when i started my testing. And for my (batch controled) testing purposes a command line tool was better suited. But i will try your tool soon. 


It' s very simple tu use it; just add a component in your form, set filename and he will return APE Tag Info 

 
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-04-01 07:12:16
Does your app deal with tagging multiple values?
Sure 

Just open a file (or use Drag'N'Drop) and you can add, edit or remove APE Tag wink.gif
If you re-read the posts previous to this you'll understand what I am talking about.
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-04-01 14:31:17
Do you understand "formats" for values Synthetic Soul?
Title: TAK 1.0.1 Development
Post by: HisInfernalMajesty on 2007-04-01 15:19:57
Happy Anniversary!

I know I'm a new name to these posts, but I've been following the development of TAK ever since it was introduced one year ago, and boy has this project come a long way!

I want to say congrats to you Thomas and all of the progress you've made over the year and I wish you luck for another great year
Title: TAK 1.0.1 Development
Post by: kanak on 2007-04-01 16:48:57
Do you understand "formats" for values Synthetic Soul?


You are talking about your program supporting multiple formats like TAK, APE etc

Synthetic Soul and TBeck are talking about adding tag with multiple values for same field... like Artist=Metallica, Artist=Beatles, Artist=Flaming Lips.
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-04-01 20:56:57
Synthetic Soul and TBeck are talking about adding tag with multiple values for same field... like Artist=Metallica, Artist=Beatles, Artist=Flaming Lips.


Ah, now I have understood 

No, but to what purpose? 

If artists are more than one it is enough type Metallica/Megadeth/Slayer, not? 
Title: TAK 1.0.1 Development
Post by: kanak on 2007-04-01 21:20:56

Synthetic Soul and TBeck are talking about adding tag with multiple values for same field... like Artist=Metallica, Artist=Beatles, Artist=Flaming Lips.


Ah, now I have understood 

No, but to what purpose? 

If artists are more than one it is enough type Metallica/Megadeth/Slayer, not? 


My example wasn't a good one.

A better use would be for genres or for styles (if you get data from allmusic for example).
Title: TAK 1.0.1 Development
Post by: QHOBBES 2.0 on 2007-04-01 22:30:37
No, but to what purpose? 

If artists are more than one it is enough type Metallica/Megadeth/Slayer, not? 


I know of one situation where this would be useful. I listen to mash-ups, and label the Artist field like "Police, The vs. Snow Patrol" because I like to display my songs in my playlist as Artist - Song. Now let's say I use Winamp, cuz I do, and I wanted to have that song in my database for both The Police and Snow Patrol. The only way to really accomplish this, IIRC, would be to have multiple artist fields.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-04-01 23:45:22
Happy Anniversary!

I know I'm a new name to these posts, but I've been following the development of TAK ever since it was introduced one year ago, and boy has this project come a long way!

I want to say congrats to you Thomas and all of the progress you've made over the year and I wish you luck for another great year

Thank you very much!

I haven't noticed it, because i just was very involved into the work on TAK. The same happened a year ago. History repeats... but it's never the same! (From Bruce Cockburn's "And we dance").

Back to TAK's tags (Speaking this out loud and fast a 50 times is a good exercise...):

Currently TAK's SDK support for APEv2 tags will have the following restrictions:

1) Maximum total tag size is 16 MByte.
2) Not more than 100 items (key/value pairs, multiple values per item don't count) per tag.

This shouldn't be a problem?

  Thomas
Title: TAK 1.0.1 Development
Post by: Dr. Oviri on 2007-04-02 02:35:32
I know of one situation where this would be useful. I listen to mash-ups, and label the Artist field like "Police, The vs. Snow Patrol" because I like to display my songs in my playlist as Artist - Song. Now let's say I use Winamp, cuz I do, and I wanted to have that song in my database for both The Police and Snow Patrol. The only way to really accomplish this, IIRC, would be to have multiple artist fields.


Refined idea ... I like it 
Title: TAK 1.0.1 Development
Post by: Synthetic Soul on 2007-04-02 07:01:58
Currently TAK's SDK support for APEv2 tags will have the following restrictions:

1) Maximum total tag size is 16 MByte.
2) Not more than 100 items (key/value pairs, multiple values per item don't count) per tag.

This shouldn't be a problem?
I can't imagine even classical muic taggers or album art freaks requiring that much.  Sounds good.
Title: TAK 1.0.1 Development
Post by: gaekwad2 on 2007-04-02 11:21:36
As long as they don't try to embed scanned covers as 16bit tiffs.
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-04-02 14:13:07
As long as they don't try to embed scanned covers as 16bit tiffs.

Yes, that's possible.

Fortunately the limitation is nothing fundamental. It's only two constants in my code which can easily be changed. Currently my sdk library loads the whole tag at once into memory. For very large tags i would prefer to load each tag item separately to save memory, which needs some code modifications i currently don't want to perform. Possibly it doesn't really matter because PC's today are so well equipped with memory. I am simply a bit anal regarding resource consumption of my software...

  Thomas
Title: TAK 1.0.1 Development
Post by: Sunhillow on 2007-04-02 17:25:23
I am simply a bit anal regarding resource consumption of my software...

Exactly such worries lead to efficient code. Please don't change your mind in this matter
Title: TAK 1.0.1 Development
Post by: UltraWWW on 2007-04-30 15:53:14
I want a plugin for foobar 0.8x, Did someone would develop it ?
Title: TAK 1.0.1 Development
Post by: Squeller on 2007-05-03 11:03:44
I want a plugin for foobar 0.8x, Did someone would develop it ?
This is very unlikely. Why do you still need 0.8?
Title: TAK 1.0.1 Development
Post by: yerma on 2007-05-04 10:33:12
One question for Tom: on your homepage and in the HA-Wiki, it says: "Future Features: MD5 audio checksums for verification and identification". What should we expect?
Title: TAK 1.0.1 Development
Post by: TBeck on 2007-05-04 22:04:43
One question for Tom: on your homepage and in the HA-Wiki, it says: "Future Features: MD5 audio checksums for verification and identification". What should we expect?

A new meta data structure to hold the MD5 checksum of the raw uncompressed audio data. Users may use this as a fingerprint to check for duplicate audio files (identification).

Since each single frame (containing not more than 250 ms of the audio data) is already protected by a 24 bit crc checksum, verification of the data integrity via an additional MD5 seems to be less important.
Title: TAK 1.0.1 Development
Post by: yerma on 2007-05-05 08:46:35
Thanks for the info, Thomas. So I guess I can start converting...  (Currently, I use MD5sums for my FLAC files for error detection, which is quite a hassle everytime I add files or change tags...)
Title: TAK 1.0.1 Development
Post by: jcoalson on 2007-05-06 19:43:20
Thanks for the info, Thomas. So I guess I can start converting...  (Currently, I use MD5sums for my FLAC files for error detection, which is quite a hassle everytime I add files or change tags...)

FLAC already has an internal MD5 on the uncompressed audio which does not change when you edit tags or any metadata.
Title: TAK 1.0.1 Development
Post by: aeroman on 2007-05-06 23:34:14
ThAnK YoU Thomas for your brilliant work  !
Title: TAK 1.0.1 Development
Post by: yerma on 2007-05-07 10:28:03
FLAC already has an internal MD5 on the uncompressed audio which does not change when you edit tags or any metadata.

Well, I hadn't thought much about it after an external drive started to corrupt files, most of them MP3. After that, I added MD5-sums to my MP3 archive and while I was at it, to my FLAC archive as well. You're always smarter afterwards...
Title: TAK 1.0.1 Development
Post by: UltraWWW on 2007-05-07 16:04:11
I want a plugin for foobar 0.8x, Did someone would develop it ?
This is very unlikely. Why do you still need 0.8?

I think 0.9x can not replace 0.8x complete. is it too difficult to develop .8x plugin?
Title: TAK 1.0.1 Development
Post by: foosion on 2007-05-13 20:12:30
I think 0.9x can not replace 0.8x complete. is it too difficult to develop .8x plugin?

The problem is finding someone who is interested in developing and maintaining a plugin for 0.8.3.
Title: TAK 1.0.1 Development
Post by: UltraWWW on 2007-07-09 11:55:44
I think 0.9x can not replace 0.8x complete. is it too difficult to develop .8x plugin?

The problem is finding someone who is interested in developing and maintaining a plugin for 0.8.3.

Dear foosion,
I guess maybe it's easy job that you can develop the plugin for 0.8.3.
Many user of 0.8.3 in my country is more than 0.9.x, they're interest in TAK, but don't want to use 0.9.x recently. so it's the big obstruction of popularize TAK format. Could you be willing to solve it? many thanks.
Title: TAK 1.0.1 Development
Post by: foosion on 2007-07-09 17:57:34
I have made a decision that I will no longer develop or maintain plugins for foobar2000 0.8.3; I will not make an exemption for TAK.
Title: TAK 1.0.1 Development
Post by: kanak on 2007-07-09 19:54:54
but don't want to use 0.9.x


Why not? the only reason i've heard for sticking to 0.8x is to that it works better with WINE than the latest version. Do you have other reason(s)?
Title: TAK 1.0.1 Development
Post by: willardjuice on 2007-07-09 20:21:03

but don't want to use 0.9.x


Why not? the only reason i've heard for sticking to 0.8x is to that it works better with WINE than the latest version. Do you have other reason(s)?



I use .9, but I miss dearly "true random" playback and (most of all) a functioning ASIO plugin.  Some people also don't like how the database system has changed.  The .9 SDK isn't as "open" as the .8.3 SDK (one can't make an output plugin, etc) .  Basically little things, it varies from person to person on why exactly 8.3 is better than .9 to them, but you get the idea. 

Still though, .9 is overall superior to .8.3 imo.
SimplePortal 1.0.0 RC1 © 2008-2020