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.
I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key. here's the binary, you can try it.
To be honest since i did read this i thought you have the same problem as @KevinB52379. How does foobar multithreaded react on your system with the other builds?
As a sidenote: fast-math + AVX2 gives another nice boost to the fast clang compile.
Well, after test, I think I didn't have multithread problem like KevinB52379, my foobar2000 hmp3 batch convert have normal behavior like all other encoders(didn't slow down the system at all, my thread count is set to 0), different compilers seems just affect performance. As I mentioned above, seems all microsoft link signature works for KevinB52379, and all mingw link signature doesn't. You can find the signature using exeinfo pe, as can be found at github.
If decoding speed is a sufficient proxy, then it's easy to test this with foobar2000 (this assumes software decoding; specialized hardware will affect the speed), but there's lots of variables that could affect decoding speed. My extremely rough benchmarking shows that decoding Opus files is about 1/2 as fast as a Lame-encoded MP3 of approximately the same average bitrate.
Single-threaded decoding test (3 passes) MP3 (Lame 3.100 V2) is 1058x realtime Opus (1.4) is 539x realtime
Well, actually you're a bit wrong here, haha I did read the change log at the time but I simply forgot to do those changes later when I updated, I assumed I already made those changes....I guess lately I was frustrated by so many annoyances...Foobar v2, foo_plorg, and the list is very very long...Or as you saw recently foo_skipcount....where you helped the developer with those bugs, some of them I've also noticed...When you have many components it's hard to keep track with so many changes , especially now with Foobar v2...
I solved the problem by resetting the toolbar, then I reimported the user presets for the Playlist Tools, the other buttons didn't have many settings, so nothing is lost.
Understandable hahaha nothing to add. Glad you got it working.
Thanks to your tip I managed to solve this, I didn't use the package. I remembered that I created a smart playlist , probably 2-3 months ago....I removed that smart playlist and everything seems ok now, that error doesn't appear. I'll send you a PM with the details of that smart playlist, just in case it's useful. But there is one more issue....something that I forgot to mention last time. I also have this error:
It happens when I try to right click Action button, and also when I try to left click settings button. Thx for your patience.
Your playlist was referencing itself, which is obviously wrong. You made Playlist X with a query using Playlist X as source xd Obviously that should crash. I didn't test that specific case, but I think my latest changes should also warn about it.
About your other error, that seems some error from past versions with some color missing not added at a later update. Will look for it tomorrow. If you post here your properties of the panel (you can skip anything with paths), I will surely find it faster.
@Peter, I noticed the new foobar2000 2.x manages foo_converter.dll.cfg in a completely different way and it saves it inside the database once loaded and I have to use an older version to modify/edit it, is there a way to still save the .cfg with the new foobar2000 or force it to keep the file inside the 'configuration" dir? Thank you.
Last post by jarsonic -
I am not a lawyer, so this is not legal advice, however:
Looking at NellyMoser's patent portfolio and all the patents by the inventors of their associated patent filings, all of the patents appear to be expired due to a failure to pay maintenance fees to the USPTO as of about 2009. Even if that hadn't been the case, it seems like they would have expired around December 2023.