[BUG] MP3Pro plugin (in_mp3PRO.dll) doesn't load in WACUP 1.0.8.4334

[GigaWatt]

It works in Winamp 5.8, but not in WACUP 1.0.8.4334. Tried several different ways, including completely removing the native mp3 decoder.

[dro]

Can you point me to the download for the copy of the plug-in you're trying to use please.

It's not something that is intentionally being blocked but as a less commonly used plug-in (same for mp3hd) it's not something I've actively tried out so either I've managed to break compatibility vs what 5.666 does (I refuse to install the 5.8 beta due to reasons) or it's just a quirky plug-in (also likely).

-dro

[GigaWatt]

Actually, the plugin didn't work with anything above Winamp 5.24... until the Winamp 5.8 beta came out. It works as expected with Winamp 5.8 (currently using it with Winamp 5.8 ). So, yeah, it didn't work with Winamp 5.666 either (there's something in those numbers ).

Plugin attached .

EDIT: Do write if you need a sample MP3Pro file .

[dro]

Erm, I'm not sure why it's not loading for you but I've just copy+pasted the attached plug-in into both my dev & playback installs & started WACUP & it loaded ok (Win10 x64 1903 & recent updates applied). I'll have to try out Win7 later on depending on your reply.

There's nothing according to Dependency Walker that shows it using anything funky with OS api defines so that's a bit confusing as to why it's giving the not loaded status unless something else is going on (A/V maybe?) that's preventing the dll from being loaded.

-dro

[GigaWatt]

I did some testing and you're right. The MP3Pro plugin does load, BUT only if WACUP is installed in classical mode (not portable, and the screenshot I posted earlier was from a portable install). After installing WACUP in classical mode on Win 8.1 x86 and Win 10 LTSC 2019 x64 VMs, yes, the plugin did load .



But, WACUP crashes as soon as you try and play a regular MP3 file and crashes as soon as you select an MP3Pro file in the playlist.

[dro]

Can you provide me an example file please though it working in normal mode is odd as I intentionally have my dev install using a non-standard folder to try to catch cases were plug-ins are looking in default/hardcoded folder paths.

I'll have to try a portable install but I've got a feeling the plug-in is doing something weird if it's trying to take over all mp3 handling so there might be an issue with it handing off to in_mp3 due to the age of the plug-in vs input plug-in api changes that have been made since 2005).

-dro

[GigaWatt]

Can you provide me an example file please though it working in normal mode is odd as I intentionally have my dev install using a non-standard folder to try to catch cases were plug-ins are looking in default/hardcoded folder paths.

No prob, sample files attached .

I'll have to try a portable install but I've got a feeling the plug-in is doing something weird if it's trying to take over all mp3 handling so there might be an issue with it handing off to in_mp3 due to the age of the plug-in vs input plug-in api changes that have been made since 2005).

Yes, it takes over all MP3 handling. The idea was to have a single decoder for both MP3 and MP3 pro files. My guess is that the devs of the plugin were lazy and couldn't make a plugin that distinguishes between MP3 and MP3Pro files, so why not just make it decode both of them, nobody will notice the difference . I'm also guessing that Winamp's API changed considerably since 2004, 2005, and that's why the last version that allowed taking over all MP3 decoding was 5.24... and the plugin didn't work with a single version since 5.24 .

Up until 5.8 that is... oddly enough, it works great with 5.8 .

[dro]

It's most likely the native unicode changes that appeared in 5.3 that started to cause issues but 5.8 beta working is just weird as that's got other changes which the older plug-in isn't going to know about & might just be more luck that it works than anything as plug-ins interacting with other plug-ins is always messy at the best of times.

I've had a go with changes related to finding the appropriate input plug-in to use that I'd made without realising the crash reports were likely from you (it wasn't obvious they related to mp3pro playback) & I'm no longer seeing adding those files into the main playlist crashing instantly as was happening & they do play. I assume they're playing correctly as I see it's own ID3 metadata editor instead of what in_mp3 uses.

However I'm still seeing some issues like looking at it's file edit dialog which is crashing when closing it without making any changes & I've had the odd on closing error occur. Trying to have it use the normal (since 5.5) common file info / metadata editor support would probably be better than leaving it using it's own & the issues it's having (it's then just what happens if you try to edit the metadata when it's playing which isn't a good idea but people will do crazy things like that).

So the new build it will have the changes in it that appear to allow it to work ok for me (still need to do the portable mode test) & if that helps fix the crashing for you then I'll look into using via in_mp3's common file info / metadata editor support.

-dro

[GigaWatt]

It's most likely the native unicode changes that appeared in 5.3 that started to cause issues but 5.8 beta working is just weird as that's got other changes which the older plug-in isn't going to know about & might just be more luck that it works than anything as plug-ins interacting with other plug-ins is always messy at the best of times.

Beats me, I don't know how, but it works .

The plugin also has issues with scrolling through large/long MPRPro VBR files, but that's a totally different issue.

My point is, it has bugs and I'm not at all surprised that it doesn't work with anything above 5.24. Back in the day, many of us thought that Thompson would fix these issues in future releases. Unfortunately, the 1.3 version of the plugin was the last one ever released .

However I'm still seeing some issues like looking at it's file edit dialog which is crashing when closing it without making any changes & I've had the odd on closing error occur. Trying to have it use the normal (since 5.5) common file info / metadata editor support would probably be better than leaving it using it's own & the issues it's having (it's then just what happens if you try to edit the metadata when it's playing which isn't a good idea but people will do crazy things like that).

This would actually be a better option and would be appreciated if it could be implemented .

So the new build it will have the changes in it that appear to allow it to work ok for me (still need to do the portable mode test) & if that helps fix the crashing for you then I'll look into using via in_mp3's common file info / metadata editor support.

I'll test it as soon as the release is ready .

Thanks for looking into this .

[GigaWatt]

Tried the new version (Build #4346)... does pretty much the same thing, crashes ... except this time, it doesn't crash if you load just one MP3Pro file. If only one MP3Pro file is loaded in the playlist, it reads it's ID3 info correctly and looks like everything's kosher, but as soon as you hit play... nothing, nada, WACUP just hangs . On the other hand, yes, it does crash if you load multiple MP3Pro files into the playlist. Reads the first one's ID3 tag and crashes when it starts to read the second one.

When loading regular MP3 files in the playlist, it just crashes, plain and simple... you load the file in the playlist, mark it, as soon as you do, it crashes .

I don't have any email program installed, so it doesn't actually send the crash report. Is there any other way I can send you the crash report? I would also consider installing one if you think that's easier .

[dro]

The crash reporter auto-posts the crash reports as well as trying to email it though I should tweak it to not be an error if the posting worked & no local client is present (tbh I'd thought I'd done that already but I'll re-check things). Alternatively you can just manually email them to bugs@getwacup.com.

There was a batch of metadata access related crash reports within the past hour as I reply & it's probably those that were from you I'm guessing. They didn't actually indicate the mp3pro plug-in but instead implied the waveform seeker & playlist separator plug-ins. I'll do a bit more digging tomorrow as I only skimmed over them (am having a lazy day post release).

-dro

[Dr.Flay]

When I tested it, unticking "use for all MP3s" option did allow the regular decoder to work