Latest WACUP public preview for x86 & x64 is build #23528 (January 12th 2026) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #23528 (January 12th 2026) (x86 & x64 changelogs)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - xVincentx

Pages: [1]
1
Preview Build Discussion / Re: Requesting old Preview Installer
« on: June 03, 2025, 08:01:06 PM »
Thank you, kind stranger! I completely missed that on the DL page.

2
Preview Build Discussion / Requesting old Preview Installer
« on: June 03, 2025, 07:43:29 PM »
Hello, I'm a longtime user of WACUP and lurker on the forums. But today, I'm asking for help obtaining a previous preview build of WACUP as the current build seems to be quite broken with its audio subsystem. It's constantly stuttering during playback, and the issue with the output plugin settings menus disappearing is a deal-breaker for me. Yes, I'm aware it's a known issue, which is why I'm not reporting it directly. I just don't have an old installer on hand for an older build to use while a new preview build is worked on to fix the issue with build 21640.

3
That would probably be it, since my entire library is OGG, and I noticed that exception getting thrown like 50 times each time a new file was played, only skipping over a very select few in my library. The kicker is, they're all encoded using ffmpeg locally on my PC, so shouldn't be throwing errors from a file that doesn't match standards. As for my Windows install, I'm just running the same Windows 11 23H2 everyone else should be running, Enterprise edition. I haven't touched any binary system files beyond just updating them through Windows' own mechanisms, and I'm up-to-date according to Settings (without going to Insider versions).

4
Makes sense. One thing I did notice, however, while using procdump, is that there is a lot of "Exception: 80000003.BREAKPOINT" messages popping up during playback. It spams a TON of these anytime an OGG or Opus file (at least most of them from my library do this, not all, I have found a few that just operate normally) gets opened by WACUP for playback (on play or track change). The address listed in the message never changes, it's always as shown for me. I also tested with multiple other popular audio formats, and it does not occur with them. This testing included AC3 stereo (which didn't work at all in Winamp), MP3, MP2, FLAC, WAV, WMA, and AAC.

Edit: I also noticed that WACUP will retain file handles on Opus and OGG media after changing playback to a different track, yet it won't retain handles on any other format after a track change. Maybe the Vorbis and Opus decoders are both bugged?
Also, the method I tried testing the AC3 files with was to use Nullsoft's DirectShow plugin to allow playback of AC3 content, but all it did was garble the output thinking it was a 5.1 surround sound track, when all it contained was stereo audio. Given the format was intended for surround sound, this was not out of expectations of what could happen.

5
Wait, you said that the times it was occurring was for those who weren't using the folder monitor? For me, it hitches itself into this infinite loop and I AM (and have been) using the folder monitor the entire time. Should I try catching the problem during a /procdump run of WACUP?

6
Update: I have screenshots of what I'm talking about available in this comment. I'm also gonna try to catch the behaviour with the procdump flag on, but that will have to occur later, as it doesn't cause WACUP to crash.

7
Hello, I've been noticing a strange behavior of the Local Library plugin that, according to patch notes, was found and fixed? It's been going on since the first version it was noticed by others in, but for me, every single other version after, including current, all seem to be afflicted by the same bug. This is even after manually ripping the EXE of the latest installer to pull the ml_ll.dll file and manually copy it into WACUP. Should I try the same idea, but with an older version to see if it's just an ml_ll.dll regression that is causing it still? I don't have a screenshot of it right now, as it seems to occur rather randomly, but it most often occurs on track change. It'll just start spinning a circle with the number 1 in parentheses and eating some CPU, like it got caught in an infinite loop trying to do something. Canceling the operation states it's trying to edit the DB in some form, and that cancelling now would mean it needs to happen later (usually it states it's trying to do a deletion).

Pages: [1]