Embeded Album Art

[DrO]

After experimenting with it I think it's to let Winamp know what to display for the type of image that the file being referenced holds in the UFIP.

correct, it's used for the header line on the albumart page and #13 isn't documented as it is new to 5.7 and so as there's not been a new sdk done (i know the sdk is generally shit / behind) and no one expected someone to be reverse-engineering things in the way that you are. there will be a new sdk released, but things are still changing in the beta so there's no point in putting out something (plus who is there making plug-ins using any of the recent stuff anyway... other than you).


anyhoo, it's API_ALBUMART_GETALBUMART = 10 which is leading to the crash in the report i looked at. have included the call stack and the parameters seen in the method call. if anything i'd say it's gen_ff at fault but then your component should probably not crash when trying to deal with bad data if that is what is going on.

code:


bpembededart.w5s!0064a0b1() 	

gen_ff.dll!api_albumart::GetAlbumArt(const wchar_t * filename=0x01b2dff0, const wchar_t * type=0x01c5ff88, int * w=0x075a72ac, int * h=0x01b2dff0, unsigned long * * bits=0x00000000)  Line 76 + 0x4a bytes	C++

gen_ff.dll!AlbumArtThreadContext::LoadArt()  Line 229 + 0x12 bytes	C++

gen_ff.dll!AlbumArtThreadPoolFunc(void * handle=0x00000000, void * user_data=0x0cf5eff8, int id=0)  Line 251 + 0x9 bytes	C++

winamp.exe!ThreadID::ThreadFunction()  Line 217	C++

kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	

ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	

ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

code:
filename	0x01b2dff0 <Bad Ptr>	const wchar_t *

type	0x01c5ff88 "ﾔDž畼"	const wchar_t *

w	0x075a72ac string L"cover"	int *

h	0x01b2dff0	int *

bits	0x00000000	unsigned long * *

[thinktink]

Ok, I think I know what's going on.

In my handler of the GetAlbumArt function I am chucking the type string into a wide char class handler for the function of filtering out all references to L"<Embed>" before calling the original GetAlbumArt function. If gen_ff is hosing the parameters that would explain alot of why I haven't been able to debug it myself. However, since writing the plugin I don't think Winamp has ever once called in with the L"<Embed>" string included so I'll try passing the buck directly onto Winamp and see if it clears up.

Just for your amusement, this was the whole of my GetAlbumArt function:

//---------------------------------------------------------------------------
int TMyAlbumArtApiCallback::GetAlbumArt(const wchar_t * filename, const wchar_t * type, int * w, int * h, ARGB32 ** bits)
{
        UniString Type=type;
        int p=IsMyType(Type);
        if(p>0)
        {
                Type=Type.Delete(p,wcslen(ADDTYPENAME));
        }
        return ApiAlbumArt->GetAlbumArt(filename,Type.c_bstr(),w,h,bits);
}
//---------------------------------------------------------------------------

[thinktink]

...I'll try passing the buck directly onto Winamp and see if it clears up. ...

This new attached version seems to have done the trick. The attachment also includes an updated version of the api_BogProgEmbededArt.h header that corrects the bad safe macro.

[MrSinatra]

I need to look for another file sharing provider.

my post following eggs first post:

http://webcache.googleusercontent.com/search?q=cache:cBFGL00OZiMJ:forums.winamp.com/showthread.php%3Fp%3D2910215+&cd=3&hl=en&ct=clnk&gl=us

as to issue, its odd to me that just doing a paste when the file has an embed but the plugin is NOT installed, would crash the beta, but it seems like the devs have a handle on it.

[Aminifu]

This new attached version seems to have done the trick. The attachment also includes an updated version of the api_BogProgEmbededArt.h header that corrects the bad safe macro.

Hi thinktink,

Version 1.0.3.8 seems to have fixed my crashing problem with the cPro skins. Winamp with my usual cPro skin has been showing an album cover for over an hour with no problems.

I assume the .h header file is for other dev types like yourself, it is nothing that I have to do anything with. Correct?

Will you answer 3 more questions, please (excluding this one ).

With the previous versions, I used the load button on the left to select an image file and the paste button on the right to embed it (since the paste button on the left did not seem to work). Is this the correct procedure?

Can I use the quality option in the BPEmbededArt.ini file to experiment with compression levels? Are the lines for the JPEG and PNG writers needed? I'm currently using an .ini file with the same 3 lines I posted before (#40).

[Aminifu]

my post following eggs first post:

Thanks for jogging my memory about those posts. I did not paid them much attention at the time, since the main issue was something else. Sometimes OT stuff is important.

Did some research and found out that Mediafire bowed to pressure from the music and movie industries a few months ago. Anyway if Wikisend craps out on me too, I now know of another alternative.

[thinktink]

...seems to have fixed my crashing...

Thank you for letting me know.

...I assume the .h header file is for other dev types like yourself, it is nothing that I have to do anything with...

Correct.

...I used the load button on the left to select an image file and the paste button on the right to embed it (since the paste button on the left did not seem to work). Is this the correct procedure?...

I have no idea.

...Can I use the quality option in the BPEmbededArt.ini file to experiment with compression levels?...

Absolutely.

...Are the lines for the JPEG and PNG writers needed? I'm currently using an .ini file with the same 3 lines I posted before (#40).

Technically nothing is needed but to set the various options for the writer configurations they are needed. Since the writers are referenced also by GUID instead of just by name you will need to use the .ini file in the .7z file I provided since there's no core function in Winamp to allow a user to enumerate the GUIDs of the various components in Winamp. And as of this post the only valid configuration option available is the "quality" setting for the JPEG writer, which is a value between 0 and 100, and I think I read somewhere "lossless" is also an available value for that option.

[Aminifu]

Technically nothing is needed but to set the various options for the writer configurations they are needed. ...

Ok, thanks for the info.

And thanks again for this plug-in and for doing your part to keep 3rd party Winamp development alive! If the Nullsoft folks can ever get the time to update the docs, maybe more people will come back and contribute stuff. The update should be a separate, paid, project, imo.

[DrO]

If the Nullsoft folks can ever get the time to update the docs, maybe more people will come back and contribute stuff.

doubtful as no one typically wants to make plug-ins other than now playing spammer plug-ins (which have been done to death and even that has dried up).

really Winamp is not of interest to people to work on making plug-ins for as users expect plug-ins to be free because the main bulk of the player is and there has always been a backlash against plug-in devs trying to get a fair amount back for the work they put in.

plug-ins and skins are nice and all that, but most users don't bother to download and install them. they just use what is provided and that is all they want.

it's only more involved users who even dabble with plug-ins and skins (i know that won't be liked but we've got stats to confirm that is the case). plus being on the forum skews what is the 'norm'.


finally the people who know the sdk are the ones who don't have the time to work on updating the documentation in it (i've done what i can over the years to update things but when there's little demand for updates it just slips to the bottom of a never-ending pile). plus Winamp has always been known for a shit sdk irrespective of the dev team at the time so at least we've maintained that level of consistency with it.

[Aminifu]

and plug-ins and skins are nice and all that, but most users don't both to download and install them. they just use what is provided and that is all they want.

I agree that the last few generations of users (of almost everything) have been conditioned for an 'out-of-the-box' experience only. That's why they never look at, or for, the options. This is a shame, especially for Winamp, imo.

It also doesn't help to have so much obsolete stuff on the main site. Downloading and installing stuff that doesn't work, is a big turnoff. But, that's another issue.

finally the people who know the sdk are the ones who don't have the time to work on updating the documentation in it (i've done what i can over the years to update things but when there's little demand for updates it just slips to the bottom of a never-ending pile). plus Winamp has always been known for a shit sdk irrespective of the dev team at the time so at least we've maintained that level of consistency with it.

That's why I said it should be a separate paid job/task for these people. But if management doesn't think its worthy of consideration, then nothing will be done. Another shame.

And I'm not knocking what you official devs do. You manage to get a hell of a lot done anyway, under the circumstances.

[DrO]

It also doesn't help to have so much obsolete stuff on the main site. Downloading and installing stuff that doesn't work, is a big turnoff. But, that's another issue.

it's been covered a fair bit before. in most cases skins work fine irrespective of the client / OS version. it's plug-ins which are the issue and in honesty, if plug-ins which have issues or only work up to a given version were removed, there'd basically be no point in the plug-ins section on the site. but this has already been covered before in having legacy sections, validating what version and OS are supported etc but it's still coming down to a matter of time and resources. so maybe it would be better to just drop the plug-ins section.

[Aminifu]

... but this has already been covered before in having legacy sections, validating what version and OS are supported etc but it's still coming down to a matter of time and resources. so maybe it would be better to just drop the plug-ins section.

I think it would be better to hire a couple knowledgeable, retired or semi-retired (minimum wage folks) people to sort out the section as you indicated. Just a thought.

[thinktink]

This should be my very last update to this plugin at least for a very long time.

This package includes a front-end plugin for configuring the embedded art settings instead of having to play phuck-a-duck with the ini file. The package also includes an updated version of the bpembededart.w5s (with the similarly updated api_BogProgEmbededArt.h header file) that implements the new function "DelWriterConfig", which for the life of me I can't figure out why I didn't originally implement that to begin with.

Anyways, attached.

No vcl included in the front-end plugin so it should allow Winamp to load fast and also remain small~ish.

[MrSinatra]

sorry to take this OT, but I do think plugins matter. I don't use a lot of them, but the option alone is important. if you had a "plugin store" to customize your winamp from within winamp, I think you might see more people use them, and maybe pay for them, like you do the android app.

there's a catch22 going on here. on the one hand, the devs say no one cares about plugins, they don't matter. but in the same breath they say that their hands are tied to making any changes due to legacy issues and need to support legacy stuff, etc...

I've seen other much smaller projects have even today much more 3rd party plugin development. having a repository and being able to activate/deactivate from within the app seems to bring them out, as does being open source, and probably other factors.

if winamp were more closed, you wouldn't have the ability to have your droid control winamp, or play certain filetypes. you wouldn't have 3rd party airplay or any number of other things. i might not use many of them, but i know i can, and if the one or two i cared about was cut, i'd have to find something else. i might not use most of the stuff i have on my swiss army knife, but there's a reason i have it as opposed to another knife.

[thinktink]

...a "plugin store"... ...from within winamp...

I like that idea.