Embeded Album Art

[thinktink]

Originally Posted by Aminifu

Take a look at my post #39 above. Do you want both images and the mp3 with or without the embeds.

Both if possible please

Originally Posted by Aminifu

The version 1.0 .ini file just has the following 3 lines:

Version 1.0 didn't use an ini.

Originally Posted by Aminifu

[Main]
EmbedOptionFirst=0
DefaultImgWriter=JPEG

That works.

Originally Posted by Aminifu

But like I said, the actual embedding goes fine. The crash happens when Winamp is just sitting there (with no song playing) displaying an image. I've removed your plug-in and everything is back to normal, even when displaying the images embedded with your plug-in.

What is showing the art? Is it the gen_classicart window or something else? Bento Skin? Winamp Modern?

Originally Posted by Aminifu

That is strange. Maybe because I'm using Windows 7. That looks like an XP dialog.

Yes, it's on Windows XP but it shouldn't matter anyway. I'll go find a 7 box to see if it does the same thing with the versioning.

[thinktink]

Originally Posted by thinktink

...Yes, it's on Windows XP but it shouldn't matter anyway. I'll go find a 7 box to see if it does the same thing with the versioning.

I just realized something. It's a w5s, not a dll, so Windows has no reason to check for a version resource unless you modify the registry to do so.


lulz

[Aminifu]

Originally Posted by thinktink

Both if possible please

The files names ending in A & F were embedded with MediaMonkey. B & E with your version 1.0. C & D with your version 1.0.2.6. The remaining mp3 does not have an embedded image.

Originally Posted by thinktink

Version 1.0 didn't use an ini.

That explains why I did not see it until after I had installed v.1.0.2.6 and then switched back. I had already installed v.1.0 before you updated it, but had not had a chance to try it until today.

[QUOTE=thinktink]What is showing the art? Is it the gen_classicart window or something else? Bento Skin? Winamp Modern?[\QUOTE]

I'm using a cPro skin, as listed in my signature below. I was using its "Now Playing" panel. I can switch to 1 of the Nullsoft skins, but I don't think it will make a difference. If it does, then I quess I won't be able to use your plug-in. Too bad for me, in that case.

Edit:

The attachment did not work. Maybe it's too big. I'll put it on a file sharing site and post the link. That will take a few minutes.

[Aminifu]

Originally Posted by thinktink

I just realized something. It's a w5s, not a dll, so Windows has no reason to check for a version resource unless you modify the registry to do so.


lulz

While waiting for my zip file to upload, can you tell me how to do that?

[Aminifu]

Ok, the link to the zip is below.

http://www.mediafire.com/?bd1a8bcv9cxedba

[thinktink]

Originally Posted by http://www.mediafire.com/?bd1a8bcv9cxedba

Permission Denied.

[thinktink]

Originally Posted by Aminifu

While waiting for my zip file to upload, can you tell me how to do that?

The attached is for Windows XP. Might work on Win 7 although not sure at all. Reboot is needed for it to take effect.

[thinktink]

Originally Posted by Aminifu

Ok, the link to the zip is below.

http://www.mediafire.com/?bd1a8bcv9cxedba

Mediafire might be blocking it because of detecting the mp3 inside the zip file. Try using a password protected 7z file instead.

[Aminifu]

Originally Posted by thinktink

Mediafire might be blocking it because of detecting the mp3 inside the zip file. Try using a password protected 7z file instead.

That sucks!. I checked and it allowed the download when I first uploaded it. Mediafire will not accept a password protected 7z from me.

I need to look for another file sharing provider.

[thinktink]

Alternatively, you can e-mail it to me in an attachment. I'll pm you my address.

[Aminifu]

Ok, try this link. It should be good for the next 7 days.

http://wikisend.com/download/633208/RepairBin.zip

I don't get MediaFire. The copyrighted and original flags in the files are not set. Are they objecting because of the artist name, alone? I've shared mp3s thru them in the past.

The 7 mp3 and 2 jpg files don't compress very much. The zip is almost 78MB, so it is too large for 1 email attachment for my web service provider to handle. I would have had to split it up. Sorry for the delays, my DSL uplink is so slow and I had to upload to Wikisend twice. The first time did not work, got to the end of the upload and the site stopped responding.

As to the crash, maybe it's a Windows 7 64-bit running a 32-bit program thing. What's weird to me is the crash did not happen during the embed, but well after when the plug-in was not doing anything. After all, it is not used or needed to display the image.

I will put v.1.0 back in the System folder and see what happens with the Nullsoft default skins.

[thinktink]

I just discovered something, maybe it's in the Beta v2 version but if you open a file with an embedded image in the Unified File Editor Pane and try to "Paste" in a new image it crashes Winamp on any skin. This was without my plugin installed. Winamp just goes "bye bye" without any warning.

[EDIT]
Yup, it's in the new Beta v2. I still had a 5.623 install to test also and it didn't crash. But the new Beta v2 even in safe mode crashes.

[Aminifu]

Originally Posted by thinktink

I just discovered something, maybe it's in the Beta v2 version but if you open a file with an embedded image in the Unified File Editor Pane and try to "Paste" in a new image it crashes Winamp on any skin. This was without my plugin installed. Winamp just goes "bye bye" without any warning.

[EDIT]
Yup, it's in the new Beta v2. I still had a 5.623 install to test also and it didn't crash. But the new Beta v2 even in safe mode crashes.

I don't understand the above. What is the Unified File Editor Pane? Are you saying trying to paste in a new image without removing the current embedded image causes an immediate crash?

EDIT:
Nevermind the above questions. Just read what you wrote in the other thread and DrO's response.


Anyway, with the issue I'm having it seems to be related somehow to cPro skins. When using Big Bento everything is stable. Switching back to a cPro skin, clicking thru a few images, then letting Winamp just sit displaying an image and it will eventually crash blaming your plug-in. This is unfortunate for me, since I have become a fan of cPro skins.

Also thanks for the registry adjustment file for reading w5s file version info. I discovered (looking for something else) that I have an app that is able to read file id information from the w5s files. I have 20 w5s files (including other 3rd party w5s files) and it's funny that only 3 of the 20 have any id information in them; yours, one of DrO's, and one of those included in the official full installation package.

[DrO]

unified file editor is the alt+3 dialog. and to save me repeating myself about this crash issue... http://forums.winamp.com/showpost.ph...9&postcount=88

as for this component crashing, i briefly looked at one of the crash reports relating to it and all i could see (didn't have a chance to check it out properly) was it messing up on the parameters it was trying to pass in a call (was like everything had been shifted along by one e.g. was setting 'type' in the width parameter). will have to rummage out proper details from the crash dump when i've a chance (unless it's fixed before then).

[Aminifu]

Originally Posted by DrO

unified file editor is the alt+3 dialog. and to save me repeating myself about this crash issue... http://forums.winamp.com/showpost.ph...9&postcount=88

Hi DrO,

We have to stop cross posting like this. You are just too quick. I was just editing my post about that question.

[DrO]

Originally Posted by Aminifu

I have 20 w5s files (including other 3rd party w5s files) and it's funny that only 3 of the 20 have any id information in them; yours, one of DrO's, and one of those included in the official full installation package.

it's something a few of us would like to have on all of the officially shipped dlls so things can be checked even if parts of Winamp are unable to run (i.e. would massively help koopa's tool).

[thinktink]

Originally Posted by DrO

...i briefly looked at one of the crash reports relating to it and all i could see (didn't have a chance to check it out properly) was it messing up on the parameters it was trying to pass in a call (was like everything had been shifted along by one e.g. was setting 'type' in the width parameter). will have to rummage out proper details from the crash dump when i've a chance (unless it's fixed before then).

Was it message 13 in api_albumart::_dispatch()?

[DrO]

no idea without re-checking (though i'd be working against the real method names not the dispatch id) which i'm not going to be able to do until tomorrow now (got too much official work that needs to be finished off tonight).

[thinktink]

Originally Posted by DrO

no idea without re-checking (though i'd be working against the real method names not the dispatch id) which i'm not going to be able to do until tomorrow now (got too much official work that needs to be finished off tonight).

Actually, I would have used it's real method name if it was documented in the copy of the SDK I have. Noticed it by accident during a debug session and saw that it was passing (const wchar_t * filename,const wchar_t * type,wchar_t **mimeType) and returning an int, sometimes 4,1, or 0 depending on what was available from the file.

#ifndef NULLSOFT_WINAMP_API_ALBUMART_H
...SNIP...
		API_ALBUMART_GETALBUMART = 10,
		API_ALBUMART_GETALBUMARTTYPES = 20,
		API_ALBUMART_GETVALIDALBUMARTTYPES = 30,
		API_ALBUMART_SETALBUMART = 40,
		API_ALBUMART_DELETEALBUMART = 50,
		API_ALBUMART_COPYALBUMART = 60,
...SNIP...

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.

[thinktink]

Originally Posted by Aminifu

...
Anyway, with the issue I'm having it seems to be related somehow to cPro skins. When using Big Bento everything is stable. Switching back to a cPro skin, clicking thru a few images, then letting Winamp just sit displaying an image and it will eventually crash blaming your plug-in. This is unfortunate for me, since I have become a fan of cPro skins
...

Ok Aminifu, I have some stuff for you to try out. Inside the attached archive are 3 different versions of the same plugin in a different folder, the names of which only have meaning to me. Manually copy and paste each version into the System directory of your Winamp install and tell me which one from which folder if any doesn't crash.

TIA

[DrO]

Originally Posted by thinktink

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]

Originally Posted by 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]

Originally Posted by Aminifu

I need to look for another file sharing provider.

my post following eggs first post:

http://webcache.googleusercontent.co...&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]

Originally Posted by thinktink

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]

Originally Posted by MrSinatra

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]

Originally Posted by Aminifu

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

Thank you for letting me know.

Originally Posted by Aminifu

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

Correct.

Originally Posted by Aminifu

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

Originally Posted by Aminifu

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

Absolutely.

Originally Posted by Aminifu

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

Originally Posted by thinktink

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]

Originally Posted by Aminifu

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]

Originally Posted by DrO

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.

Originally Posted by DrO

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]

Originally Posted by Aminifu

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]

Originally Posted by DrO

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

Originally Posted by MrSinatra

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

I like that idea.

[Aminifu]

I've been having a ball updating the low res art in some of my mp3s. Sometimes if I embed while a song is playing the embed is successful, but Winamp crashes. It is probaby due to the way the <Alt>+3 tag editor currently works. So I just want to alert people that it is best to do the embedding when the song is not playing.

The following sites are great for finding artwork:

http://www.albumartexchange.com/

http://albumart.org/

[thinktink]

Just saw your post. Sorry for the necro-bumping delay.

Originally Posted by Aminifu

I've been having a ball updating the low res art in some of my mp3s.

That's satisfying to know. Thanks.

Originally Posted by Aminifu

Sometimes if I embed while a song is playing the embed is successful, but Winamp crashes. It is probably due to the way the <Alt>+3 tag editor currently works. So I just want to alert people that it is best to do the embedding when the song is not playing.

That's down to the individual ((typically) input) plugin that supports embedding (if it does) and not the UFIP ([ALT]+[3] Editor) (well, only insofar as so-much it starts the process of updating, the data has to come from somewhere.) I've tested editing the art on live playback of files on both in_mp3 and in_bpopus. Both aren't perfect but most of the time I can get away with it without too much worry. Haven't tested the other plugins though so I don't know if any of the other ones have a particularly bad time handling live art updates or not.

[thinktink]

I got tired of having to constantly re-select the <Embed> option so I made a new version of the plugin to to allow users to configure the default behavior in lieu of the option to list the <Embed> option first in the UFIP's "Artwork type:" combo box (which didn't work like I hoped originally anyways.)

Off-Site screenshots:

[Aminifu]

Hi thinktink,

Thanx for the update. It is a pain having to select the embed option each time. I just told myself not to complain, its better than not being able to use Winamp to embed artwork.

Were you aware that recent changes to in_flac.dll broke the ability of your plug-in's previous version to embed artwork in flac files? If so, does this new version fix that or is it up to the encoder?

[DrO]

i need to review the in_flac tagging fixes and have to re-do it differently as it shouldn't be affecting this plug-in (is due to different things being cached for the alt+3 dialog and in_flac not being as smart about it as it should be, it causes things to fail).

as for the combo selection, someone should just have mentioned it and i'd have added the means for the last selection to be remembered (if relevant for the file and what's installed).