foo_input_awma, WMA decoder with tagging support Options

[Acropolis]

now version 0.1.5 is considered to be mature
but beware that I don't know all the attributes, so there maybe some readonly data shown as meta data or editable data shown as readonly still.

Download

change log

0.1.5
fixed: comment was not shown as meta data

0.1.4
fixed: date was not shown as meta data

0.1.3
fixed: replaygain could not be removed
fixed: readonly tags incorrectly shown as meta data and vice versa
fixed: unseen tags will be erased (now private tags will be reserved)

0.1.2
minor bug fixed

0.1.1
added replaygain support
added vbr display support (though it's inaccurate due to the api available from WMSDK)

I've been waiting for the tagging support for wma files since the first day of using 0.9, but quite frustrated until I make it with my hands.
this is a wma decoder component that supports tagging. I take it as the replacement of the wma decoder in foo_input_std, which doesn't support tagging.
the lacking functionality was almost the only reason to keep me still using 0.8.3 sometimes. now I can delete my 0.8.3 directory....

to be able to use it, please read here carefully
there is a little problem to use this plugin to handle wma over the foo_input_std, to be able to use it, the name of the dll must be alphabetically lower order than foo_input_std (that's why I use foo_input_awma instead of foo_input_wma), generally this will work.
but if not, you can try to move away foo_input_std from the component directory, then start foobar, let it remove the setting, then put it back again, and do it again with this dll. should work.

the best method is of course to remove the internal support of foo_input_std, a simple way is to patch it, but I think I can't provide the patched foo_input_std, but the above method should work, I tried that way while writing this component.

* All of my components need the VC8 runtime libraries *

cheers

This post has been edited by Acropolis: Oct 30 2006, 16:34

[machekku]

My test story:

I have some files tagged by 0.8.3. They contain standard tags (title, album, etc), but also replay gain info plus some private tags.

Standard 0.9.x cannot read replay gain nor my private tags.
Same goes for 0.9.x with your plugin.

When I tried to apply replay gain again (using 0.9.3.1 with your plugin), it seems that all tags got erased. At least the tags readable in this version of foobar appear to be not set. And it seems there is no replay gain saved, too.

But thanks for trying to add tagging support! I hope it will work soon. Good luck!

This post has been edited by machekku: Sep 11 2006, 07:32

[Zimdgre]

Now this is the greatest news of this month, thanks Acropolis, It works almost perfect here but did you dropped VBR display support?

[...Just Elliott]

Hooray! Watch the foobar user count double.

[Acropolis]

My test story:

I have some files tagged by 0.8.3. They contain standard tags (title, album, etc), but also replay gain info plus some private tags.

Standard 0.9.x cannot read replay gain nor my private tags.
Same goes for 0.9.x with your plugin.

When I tried to apply replay gain again (using 0.9.3.1 with your plugin), it seems that all tags got erased. At least the tags readable in this version of foobar appear to be not set. And it seems there is no replay gain saved, too.

But thanks for trying to add tagging support! I hope it will work soon. Good luck!

yes, I haven't added the support of replaygain tags yet, should be added with the next release.
I currently have no clue of how to just remove the tags that user clicked remove, because foobar sdk doesn't provide a way to let the component know which tag was choosed to remove, so at the moment that any tags not displayed in foobar will be removed when modifying tags.

EDIT: replaygain is now supported, and now private tags are reserved. in a word, just working well now.

Now this is the greatest news of this month, thanks Acropolis, It works almost perfect here but did you dropped VBR display support?

not dropped, just not yet implemented
the main problem is I seem like don't have any vbr wma to test, I'll add this support as soon as I know how to work it out.

EDIT: now added vbr display support, see the fist post.

This post has been edited by Acropolis: Sep 12 2006, 03:06

[musosticky]

Just tested tagging one one of the 2 wma files I have on here and it works beautifully. I'm sure you've just convinced a lot of people to join the 0.9x crowd

You seem to come out of the blue at random intervals, Acropolis and grace us with amazing ports we all missed.

[foosion]

Relying on service enumeration order is a bug. foobar2000 0.9 randomizes the order of service factories at each startup to help detect such bugs.

[saratoga]

Relying on service enumeration order is a bug. foobar2000 0.9 randomizes the order of service factories at each startup to help detect such bugs.

Haha, very nice.

Is there a correct way to override foo_input_std?

[Peter]

Is there a correct way to override foo_input_std?

No.
Randomization was added to prevent situations like with old foo_cue_ex where component author noticed that his code wouldn't work in on half of possible configurations several months after releasing it.
While this component technically does not violate the API specifications (or the SDK license), it's going to introduce unfixable or hard-to-backtrack issues related to separate WMA tag reader/writer implementations (tag writer is a subclass of tag reader and is queried back after each write).

[Acropolis]

I know relying on service enumeration order is a very bad idea, but this is just to avoid violating the sdk license when I release it, because for my own use, I patched the foo_input_std of its support of wma (I'm sure I'm not allowed to release this patch).
so if any of you can patch the dll yourself, this component is definitely the best wma decoder for 0.9 at the moment.

This post has been edited by Acropolis: Sep 11 2006, 17:15

[Yotsuya]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

[pepoluan]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

I second this. Even WinAmp can do so

[Acropolis]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

would be great.

[Earthworm]

i just waited for this. great plugin!

thank you!

[Peter]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

Standard WMA input does not support tag editing simply because I haven't had time to implement it.
Using my time on implementing per-input on/off switches just to workaround that makes no sense at all.

[FrozenSpoon]

Standard WMA input does not support tag editing simply because I haven't had time to implement it.
Using my time on implementing per-input on/off switches just to workaround that makes no sense at all.

Have you found a way to update WMA tags without rewriting the entire file? As far as I can tell, the WMSDK won't let you update WMA tags with a stream. So to stay true to the FBSDK the only way I can see it being done is to rewrite the entire file. The WMSDK readers and writers support streams but not the metadata editor.. doh..

[pepoluan]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

Standard WMA input does not support tag editing simply because I haven't had time to implement it.
Using my time on implementing per-input on/off switches just to workaround that makes no sense at all.

That's too bad.

Lots of debugging .dll's can be helped by a generic plugin on/off system... no need to manually swap the .dll's in and out of the components folder.

Edit: Of course foobar2000 must still be restarted... Firefox have an extension that allows it to restart itself; with a plugin on/off system + self-restart capability... it will be a swell idea

This post has been edited by pepoluan: Sep 11 2006, 18:49

[kalmark]

Acropolis, have you considered opening the source of your component? Not necessarily for everyone, but for the core FB2K devs? I have no idea if they'd be interested, but that way maybe your code could be included in the official release? Might be worth a question?

[Acropolis]

Acropolis, have you considered opening the source of your component? Not necessarily for everyone, but for the core FB2K devs? I have no idea if they'd be interested, but that way maybe your code could be included in the official release? Might be worth a question?

yes, if the devs want to put it to the foo_input_std, I'm happy, no more annoying patch for me.

[Zimdgre]

Does every official plugin necessarily have the nature to be totally superior than similiar 3rd party plugins in every aspect?

I don't think so.

In Windows OS, Internet Explorer couldn't surpass Opera or Firefox in term of speed or functionality and Windows Media Player never had the balls to dream about even quarter of what foobar can do. As we well known, They're all official releases from Microsoft and has been released by embed into the Windows OS. In Windows XP SP2, both IE and WMP can be disabled at end user's will, so I really can't see why Peter refused to do so.

I mean no offense, but If one don't have enough time to build a car with braking system, one should leave the rest of the job to the others rather than just made the car available for everyone while trying to bring under any attempt of install a braking system.

[Peter]

In Windows XP SP2, both IE and WMP can be disabled at end user's will, so I really can't see why Peter refused to do so.

Standard WMA input does not support tag editing simply because I haven't had time to implement it.
Using my time on implementing per-input on/off switches just to workaround that makes no sense at all.

Apart from that, I don't think adapting third party WMA tag writer code is an option (I'd have to completely proofread it regarding security/reliability issues, I'd rather just write my own when I don't have anything more important to do, maybe for one of 0.9.4.x updates), but thanks for the offer anyway.

[midgezr]

Perhaps a more elegant solution would be if the foo_input_std would add a preference page where a user could selectively enable/disable the various supported formats .. and if a format is disabled then any other component (such as foo_input_wma) could take over?

I don't quite agree with you, I think Foobar's goal is to be an all-star audio player, so the best thing for an "all-star" is to be able to support all kinds of common audio file types natively. Any other 3rd party compilation is just a substitute for the upcoming official plugin. so it's pointless to add such feature.

[tobamai]

Just a heads up for acropolis and anyone downloading this for the first time, you need the Microsoft Visual C++ 8 redistributable Service Pack 1 (I couldn't get it working with the link provided).

Thanks for a great plugin!

[nbarzgar]

PLEASE provide a valid download link!!

Thank you.

I am practically screaming with frustration and rage, there are numrous links out there but not ONE works for me!!

[Hakubo]

Why would you need it? foobar2000 natively supports tag editing in WMA files now.