Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK 1.0.1 Development (Read 56881 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK 1.0.1 Development

Reply #50
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.
[span style=\'font-size:8pt;line-height:100%\']"We will restore chaos"-Bush on Iraq[/span]

TAK 1.0.1 Development

Reply #51
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

TAK 1.0.1 Development

Reply #52
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 

TAK 1.0.1 Development

Reply #53
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.
I'm on a horse.

TAK 1.0.1 Development

Reply #54
As long as they don't try to embed scanned covers as 16bit tiffs.

TAK 1.0.1 Development

Reply #55
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

TAK 1.0.1 Development

Reply #56
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

TAK 1.0.1 Development

Reply #57
I want a plugin for foobar 0.8x, Did someone would develop it ?


TAK 1.0.1 Development

Reply #59
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?

TAK 1.0.1 Development

Reply #60
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.

TAK 1.0.1 Development

Reply #61
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...)

TAK 1.0.1 Development

Reply #62
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.

TAK 1.0.1 Development

Reply #63
ThAnK YoU Thomas for your brilliant work  !

TAK 1.0.1 Development

Reply #64
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...



TAK 1.0.1 Development

Reply #67
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.

TAK 1.0.1 Development

Reply #68
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.

TAK 1.0.1 Development

Reply #69
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)?

 

TAK 1.0.1 Development

Reply #70

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.