Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Recent Posts
FLAC / Re: FLAC v1.4.0 (Release)
Last post by Porcus -
FLAC 1.4.1 is out.
God damn it, now we have to test it all over again :)
Changes aren't that much. Mainly, the help files were wrong - so flac --help and --explain showed old obsolete information. According to,123014.msg1016154.html#msg1016154 , "Binary might be an unmeasurable tiny amount faster because the binary is slightly smaller."

So I guess performance tests on official 1.4.0 are still valid. But, people are pumping out new compiles faster than they can be tested.
And faster than the damn overzealous antivirus engines can get their act together. I got a ton of them new builds blocked.
General - (fb2k) / keeping 32 and 64 bit versions installed at the same time. will they conflict?
Last post by radorn -
--------------accidentally posted here when it should be in the foobar2000 section---------------------

I've already installed v2.0 beta on top of the old v1.6.x stable, and have seen the copied profile folder. But how about having both 64bit and 32bit versions installed? How well will that work? Should I expect breakage? My worry is mainly about having them fighting over settings and one or both acting out because of that.
Is the new scheme designed so that both versions can coexist or do I have pick one and stick to it?
I'm kind of concerned about components I use, particularly rare input ones, even from outside the repository, so I'm not yet ready to do away with the 32bit version and switch over to 64. I would like to use both.

3rd Party Plugins - (fb2k) / Re: Spider Monkey Panel (foo_spider_monkey_panel)
Last post by marc2k3 -
I'd wrap all WshShell.Run calls in try/catch just to be safe.

The album art sample bundled with SMP uses it. Double click the panel to test. It will silently fail if no application is associated with the image type.

As for the person with the problem, did they associate a .jpg file with Explorer? If it doesn't work, right click a jpg>Open with

Make sure to check that box.
3rd Party Plugins - (fb2k) / Re: JScript Panel
Last post by marc2k3 -
Cool.  8)

I was using windows 10 previously but nuked the windows store (and built in webp support) with a powershell script so I used the google webp installer. I guess that's why I couldn't recreate the problem when you originally reported it.

Since using windows 11, I was relying on the store version of webp and that was the failure point. It worked most of the time but wasn't 100% reliable. I wasn't going to tell everyone on 10/11 they must use the google installer so I used their open source libwebp library to do it myself.
3rd Party Plugins - (fb2k) / Re: Spider Monkey Panel (foo_spider_monkey_panel)
Last post by Ottodix -
It's entirely up to each user to set a default app for opening jpg (or any other) files. On clean installs, the user is usually prompted the first time they try and open a file from Explorer. Once that is done, the script should succeed.
I don't think it's the right explanation. I just tried on windows 10 to unset the default app for .jpg, and the script then crashed, saying "unfound app"
One user reported that nothing happens on windows 11 on his side, no error message, just nothing
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by ktf -
@ktf: When you wrote that -0 to -2 got faster, does that apply to decoding as well?
Nope. The two things are fundamentally different problems, improvements to one are rarely applicable to the other.

My most plausible explanation here is simply differences between CPUs. Perhaps newer CPUs can better precondition the code used for decoding fixed subframes. Branch prediction and other front-end wizardry are a major factor in the performance of today's CPUs.

edit: I've always been baffled by -3 being decoded faster than -2. The decoding results here make much more sense. In the past, @Porcus found that blocksize has a profound influence on decoding speed. Might be related to training of branch prediction. It might be that newer CPUs have branch prediction with a larger capacity, in which this training only has to happen once every file instead of once every block. In that case, influence of block size might be much smaller.