Embeded Album Art

[Aminifu]

Originally Posted by DrO

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

With all you have on your plate at the moment, I feel somewhat guilty adding to it.

[DrO]

is my fault as i should have re-worked it better to begin with *shrugs*

[thinktink]

Originally Posted by Aminifu

...told myself not to complain...

Please, complain, probably would have done it sooner if you had.

Originally Posted by Aminifu

Were you aware that recent changes to in_flac.dll broke the ability of your plug-in's...

I was not aware. However, even if I was I probably would not have been able to resolve it myself (with semi-confirmation of DrO's previous comments) since the plugin treats all files (and indirectly, all input plugins) the same, there are no internal special provisions for different input plugins.

Originally Posted by DrO

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

That would probably still be helpful even with the updated version of the plugin.

[DrO]

Originally Posted by thinktink

That would probably still be helpful even with the updated version of the plugin.

will try to get that into things along with sorting out the mess that is in_flac (as it's the only one which does things weirdly for the alt+3 dialog which should not be the case anyway).

[thinktink]

Wh00t! Plugin passed review muster!
http://www.winamp.com/plugin/bogprog...ded-art/222666

The version posted on the plugins page includes a German language file for the front-end plugin. If somebody else wants to send me translations for other languages (or a better one for the German language) I would welcome them.

[Koopa]

I will send you a better German languagefile (or I will add them to my language pack installer, if you want) Your translation file is a bit..weird.

It seems, that you missed to localize one string:

[Koopa]

Here is a German language file, which fixes all issues in yours. Though, the entry on my above screenshoot is not localizable.

The 'Writer' config presets are not loacalizable either.
I also think the English word 'Writer' does not explain what this config is meant to do. You really should add some short explanation text.

The 'Presets' dropdown list should be called 'Extensions list' and should show some possible file extensions, take a look at the Nullsoft DirectShow Plugin for an example.

[Edit]

I've increased the size of the dropdown list in the unified tag editor for German:



So so that a translation string has enough room. It will be available in the next Winamp release.

[thinktink]

Originally Posted by Koopa

...Your translation file is a bit..weird.

I figured it would be wrong. Never would've guessed weird. lulz I have replaced my de-de language file with yours and it will be included on the next release (which will be soon~ish since I found some small coding errors.)

Originally Posted by Koopa

It seems, that you missed to localize one string:...

The circled part of the string in the image was taken from Winamp, not generated from the w5s plugin. The only part of that string that is from the w5s is the <NoEmbed> part. The reason why it's not localizable is because I return it from the calls to api_albumart::GetAlbumArtTypes(...) and api_albumart::GetValidAlbumArtTypes(...). I was going to localize it but during my preliminary testing to see what would be required to do it I discovered that the strings I was receiving were not localized. I figured why bother to localize the plugin if it wouldn't work anyways.

Originally Posted by Koopa

...

The 'Writer' config presets are not loacalizable either.
I also think the English word 'Writer' does not explain what this config is meant to do. You really should add some short explanation text.

"Writers" was what I came up with at the time when I wrote the plugin. Was drawing a blank so I just used the generic WASABI object type. That part of the configuration gets a bit deeper than probably what most people would get into anyways and since the writer object configuration parameters/values aren't localizable I figured it would be enough for those brave enough to venture into the belly of the beast.

Originally Posted by Koopa

The 'Presets' dropdown list...

Not following the reference. I don't have a presets dropdown.

[Koopa]

Originally Posted by thinktink

Not following the reference. I don't have a presets dropdown.

"Default Embed Type". You may should show other types, which are possible "gif; bmp" etc

Sorry my bad.

Fixed a glitch in the German file use this:

http://www.meggamusic.co.uk/shup/138...pembededart.7z

The circled part of the string in the image was taken from Winamp

Hmm, I cannot find that string in winamp.exe or any other file. The standard string is localizable (and already localized), so no idea what other string you are using.

-Chris

[thinktink]

Originally Posted by Koopa

Default Embed Type

Sorry my bad.

lulz, my brain was all like floating in outer space going "what in teh hell is this fool talking about, there's only one dropdown and I don't have presets".

Anyways, no, the value not localizable since it's used to match the name/type of the default image type/writer to use when the image data is sent to the plugin in Winamp's native raw ARGB format.

[thinktink]

Originally Posted by Koopa

"Default Embed Type". You may should show other types, which are possible "gif; bmp" etc

Oh, you mean like change it to a dropdown with the possible values preloaded? If that's not what you meant, I might still do it anyways since it's a good idea.

Originally Posted by Koopa

Fixed a glitch in the German file use this:...

Thanks.

Originally Posted by Koopa

Hmm, I cannot find that string in winamp.exe or any other file. The standard string is localizable (and already localized), so no idea what other string you are using.

I can't find it either but it's coming from somewhere. Screenshot of project-global search for the string:

[Koopa]

Oh, you mean like change it to a dropdown with the possible values preloaded? If that's not what you meant, I might still do it anyways since it's a good idea.

For example.

The string for the already localized version should be:

420, "cover" in winamp.exe.

You are may able to use this instead?

[thinktink]

Originally Posted by Koopa

The string for the already localized version should be:

420, "cover" in winamp.exe.

You are may able to use this instead?

It seems you still don't understand.

TLDR; answer:
No, I cannot use it.

Long answer:
I can not use any localized "cover" string because I'm not the one generating it. Winamp is. Winamp has to give me the localized version of the string to my plugin from the Album Art API. The API was designed for expandability and if I hard code a list (to which then you are proposing to be localized) it will break the plugin, Album Art API, or Winamp down the road. My plugin receives a string list of available art types from Winamp, and depending on my plugin's settings, my plugin duplicates the entries and dynamically adds the <Embed>/<NoEmbed> options to the duplicates. Then that list is passed on to Winamp through the API. The only thing on that combobox I can localize are the "Embed" and "NoEmbed" strings. The Dev. Team would be the ones to localize the "cover" string, whether after it calls the AlbumArt API or in the AlbumArt API.

[dstudd]

Hi Thinktink,

I have been using BogProg Embeded Art v1.0.4.9 for some time now and found it to be an excellent plug-in to get around 's lack of Embedded Artwork options.

However, since upgrading to your current version of BogProg Embedded Art v1.1.5.14, it has been causing v5.7.0.3444 ßeta to crash consistently.
I've yet to try it on v5.65.3419, but have enclosed an Error Feedback Report for you.

I've gone back to BogProg Embeded Art v1.0.4.9, which has solved the problem for now.

Cheers.

[thinktink]

Originally Posted by dstudd

... v5.7.0.3444 ßeta ...

How are you even able to run that. I just downloaded that and installed it and tried to run it and it tells me that it's longer than 4 weeks old and tries to open my browser to download current version.

[dstudd]

How are you even able to run that. I just downloaded that and installed it and tried to run it and it tells me that it's longer than 4 weeks old and tries to open my browser to download current version.

A utility called 'RunAsDate' does the trick...

Inject a false system time into the application
- Recommend
- A freeware app that does this is RunAsDate (Utilize immediate mode)

(http://forums.winamp.com/showpost.php?p=2965985&postcount=18)

Hope that helps...

[thinktink]

Originally Posted by dstudd

...However, since upgrading to your current version of BogProg Embedded Art v1.1.5.14, it has been causing v5.7.0.3444 ßeta to crash consistently.

...

I was unable to get any crashes on Win7 Pro x64 with the version of the plugin you mentioned. However, I was unable to test with v5.7.0.3444 Beta of Winamp since it won't let me run it. The only thing I saw was a bug that I've already fixed in a yet-to-be-released internal build.

Maybe if you tell me exactly what you were doing or trying to do just before Winamp crashed then I might be able to find something obvious in the code directly.

[thinktink]

Originally Posted by dstudd

A utility called 'RunAsDate' does the trick...


(http://forums.winamp.com/showpost.php?p=2965985&postcount=18)

Hope that helps...

Didn't work as advertised. I had to retard my system clock to August manually to get it to run right. Preferences window wouldn't come up when run under 'RunAsDate'.

Anwyays, I was unable to replicate your issue under the Beta. Probably the reason it's crashing is because you have to run it under 'RunAsDate' since I'm seeing weirdness with it under 'RunAsDate'.

[DrO]

i've managed to dig out a copy of the 3444 pdb files and it's not a 'clean' Winamp install this is happening with (am seeing a number of my plug-ins in there along with a few other 3rd party plug-ins).

afaict it's happening with a modern skin being used when an albumart callback in gen_ff is being fired with it going to a GetAlbumArt(..) call and then it drills down into bpembededart.w5s before giving

Unhandled exception at 0x0068a89f in _crash.dmp: 0xC0000005: Access violation reading location 0x00000004.

which to me implies it's trying to access the member variable of something which is not present (though why bpembededart.w5s would even be called in that scenario i don't know).

[thinktink]

Originally Posted by DrO

...(though why bpembededart.w5s would even be called in that scenario i don't know).

Embedded art hooks the entire api_albumart Wasabi API, not just api_albumart::SetAlbumArt. Therefore, any call to api_albumart::* goes to my plugin first. It's done this way to filter the <(No)Embed> strings before passing it on to the actual api_albumart (if/when done so.)

I'll have another look at api_albumart::GetAlbumArt(...) to see if anything obvious pops.

[thinktink]

I'm wondering if maybe it's this--> http://forums.winamp.com/showthread....59#post2920259 issue again since I put the filter code back into ::GetAlbumArt since I no longer use that Beta. Still not able to replicate the issue though.

@dstudd, are you using a cPro skin?

[DrO]

it's the same issue in the newer crash report.

[thinktink]

/sigh

Figures...

With the latest Beta I'm getting some weirdness. Near the return from the call to ::GetAlbumArt the plugin is throwing AV on a call to stdlib::free in my Unistring handler after having called the original api_albumart::GetAlbumArt(...). The parameters are fine (at least it looks that way) and I have a sneaking suspicion that the original api_albumart::GetAlbumArt(...) is sometimes trying to free the (...,type,...) parameter when it shouldn't (at least the SDK doesn't say it will.)

Can you check the code to see if it is?

Is happening on an mp3 file though I didn't test on a different file type.

[thinktink]

Stick a f'ng fork in me I'm done. I've had it up to here with this repeating crash BS. Belay my last DrO, I've made my own ::GetAlbumArt handler.

[DrO]

from the stack i'm not able to work out what (at least not obviously at the moment) the call is which is then causing GetAlbumArt(..) anyway, though as it's on a different thread, might be variance in the memory mode being used for the actions (most cases it's meant to be using the sysmemmgr to handle things) or it's some sort of abi incompatibility between things (cannot not rule that out as an option).

[thinktink]

Originally Posted by DrO

from the stack i'm not able to work out what (at least not obviously at the moment) the call is which is then causing GetAlbumArt(..) anyway, though as it's on a different thread, might be variance in the memory mode being used for the actions (most cases it's meant to be using the sysmemmgr to handle things) or it's some sort of abi incompatibility between things (cannot not rule that out as an option).

Thanks for looking, even if only preliminarily, it helps to solidify my current solution: implement it myself and bypass the original call entirely.

And on that note, is there anything I should call or do in my own ::GetAlbumArt(...) implementation other than get the art from the file embed?

[thinktink]

Wow, auto-tag kicks butt! I had recently encoded a Kenny G test vector I got from Aminifu into Opus. Saw the button for the first time and decided "what the hell, I'll give it go, my brain has melted already, why not pound what little is left of it into oblivion for the rest of the day and see what happens..."

Compliments to the implementer(s).

[thinktink]

For all you lossless HQ album art freaks:

Highly experimental although really not much to it. It just stores the raw ARGB data from Winamp.

Note: The image format is (presumably) not compatible with anything other than Winamp.

Attached.

[dstudd]

Been off the radar awhile.

@dstudd, are you using a cPro skin?

Yes, Using Classic Pro v2.02 with FusionAmp_WA-5 Skin.

[thinktink]

k, see if the attached version solves it.

This new version also changes the default embed type edit to a drop down combo box and adds support for localizing the "<Embed>" and "<NoEmbed>" strings and includes a separate German language file for it.

[dstudd]

see if the attached version solves it.

Winamp v5.66 crashes using BogProgEmbeddedArt v1.2.5.20

(Winamp v5.66 is configured using cPro v2.02 & FusionAmp WA-5 Skin.)

See attached crash report.

[thinktink]

Did it crash while the playlist had an item with no embedded art highlighted?

[dstudd]

Did it crash while the playlist had an item with no embedded art highlighted?

All items in my playlist have embedded art.

[thinktink]

See if it still crashes with the attached...

[Aminifu]

Hi thinktink,

Well I've not had any crashes with the latest version (using cPro v2.02 engine with the cPro v1 skin listed in my signature) and Winamp v5.6.6.3507. I've tried it with flac and mp3 files.

Looks like you fixed it.

Hopefully, dstudd will also report success. The original artwork function of the <alt+3> editor (making independent folder image files) also works with no problems, which it should since your plug-in never interfered with that.

PS:
I've not tried embedding to a playing file. That was causing random crashes before (due to the codecs which you have no control of), so its safer to work with non-playing files. Maybe that is what dstudd is/was doing. He didn't say.

[dstudd]

Hi thinktink,

Results are all good this end too (using Winamp v5.6.6.3507 with cPro v2.02 engine & FusionAmp WA-5 Skin).
I've tried it with MP3 & Flac files, tried giving it a hard time with lots of stopping & starting & by embedding to a playing file, but so far I cannot fault it.

I notice you've also included a pull down menu for 'Default Embed Type' under preferences.

Looks like another job well done. Many thanks for you persistence.

Originally Posted by Aminifu

I've not tried embedding to a playing file. That was causing random crashes before (due to the codecs which you have no control of), so its safer to work with non-playing files. Maybe that is what dstudd is/was doing. He didn't say.

Embedding to a playing file is something I've always tried to avoid, knowing it sometimes crashed, but simply thinking I was pushing fate.
However, as I said mentioned earlier, it now appears to pass that test too.

[Aminifu]

Originally Posted by dstudd

Embedding to a playing file is something I've always tried to avoid, knowing it sometimes crashed, but simply thinking I was pushing fate.

I assume you meant to write "... not knowing it sometimes ...". Anyway, thanks for giving it the 'acid' test.

[dstudd]

Originally Posted by Aminifu

I assume you meant to write "... not knowing it sometimes ...". Anyway, thanks for giving it the 'acid' test.

Hi Aminifu,

Not really. I was aware it would occasionally crash, should you try embedding a playing file, but to me this was not really an issue.
I prefer to edit non-playing files to avoid potential problems anyway.

I was more concerned with Winamp randomly crashing with this plug-in, since updates were made after v1.0.4.9.
Looks like that's all sorted now with this current update.

This plug-in has been a God-send, as embedding files in Winamp is something I'd wanted to try since the 'Artwork Editor' option became available.

Once again, thanks for making this wish come true thinktink.


Now if we could only save Winamp's future!
The Petition at https://www.change.org/en-AU/petitio...go-open-source looks encouraging. Currently over 9,000 signatures!

May Winamp continue whipping the Lamma's Ass!

[thinktink]

Outstanding news.

[thinktink]

All future updates for this plugin will be posted here. Please update your links.