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.
Just tried a WIlB's bio and got a few unresponsive script dialogs (from the component - I've seen the same on windows). Clicking stop makes the component crash. If you continue, it did eventually work and display all images/text as expected.
I guess how well it works depends entirely on the script and may be host (mine was VMware, not a proper install)
edit: georgia reborn seems unusable on my setup. I can get the initial layout showing but it's totally unresponsive with these WINE popups.
At first I thought the issue was from using the original skin folder location - `%profile%\foo_title` - so closed foobar and moved my skin to the new location - `%profile%\foo_dotnet_component_host\components\dotnet_title_bar\skins` - and CPU usage appears to be at normal levels again. (Bit of a long path mind you).
Then I thought to confirm, I'll move the folder back, restart foobar and guess what - normal CPU levels. No idea what caused it the first time.
Now just testing both foo_title and dotnet_title_bar in duplicate foobars / settings, at least happy to know I cannot pick up any difference in CPU between the two versions (it fluctuates of course, but letting it settle, they both play minimized around 1-3% CPU using exclusive output with overlay visible)
So, I dunno, apologizes for any wasted time on that. I'll keep experimenting and if anything goes off, I'll send you a PM with the theme zipped. No time for now.
(By the way, not sure if I was supposed to check out the dev build (?), but the link says "access denied" so I guess not...)
Multiple freezes and crashes, very slow, some dropdown menus doesn't work, new wine errors i never saw before.....
but the limited time before freazees or crash the clipboard seems to work
I can say if it break https or not because i can't get that far, always freezes or crash before.
Create a compile-time option, so a special libFLAC with this enabled can be distributed for use with FLAC streaming server applications. This can only be used for such applications where FLAC is dynamically linked (in other words, libFLAC is a dll or so)And who can guarantee that some incompetent person will not include such special libFLAC into some application for offline encoding? And then users of this application will ask: "Why FLAC compresses digital silence so poor?"
Merzbow: "I Lead You Towards Glorious Times".
There are genres that messes up good codecs, and this is the least compressible CDDA track in my collection. Some compression tests here. ("my final" test, my ass ... too curious. Rehab is for quitters.)
Anyway, because this is noise, one would not expect much help from stereo - indeed, tests show that the stereo file isn't much compressible from PCM, so there cannot have been much eh? Still codecs behave different. These are sorted by stereo size (mono size maintains that order except between LA -high and -high -noseek).
I tried to get three settings from each encoder: normal, high and maximal. OFR 10 was chosen as maximal by mistake, and kept as high when I discovered --preset max, and then ... Other choices were a bit ... arbitrary. The new FLAC beta produces bit-identical audio to 1.3.1, so the new "-9 -p -e" was a candidate for max (it didn't squeeze much out).
|stereo kB||mono kB||stereo − mono||left − right|
*The file fools OptimFrog's --preset max big time. And the LA's come out in the wrong order.
* I've known since long that TAK doesn't like this piece of music, and Monkey's is even worse. Those return bigger files than the WAV. But TAK in the very least can utilize stereo.
* Indeed less than half these files can get help from stereo here. FLAC does, as these presets (which include -m) pretty much brute-force searches the stereo options. TAK does even better. Two OFR modes do, so here there actually might be some support to froggy claims that it can make pretty good sense out of stereo.
* The two good WavPacks and the two good OFRs disagree with everything else about what channel should be smallest. Maybe because they are the only to make good sense out of the right channel.
Well, TheQwertiest seems to be busy with his real life problems so we have to wait a little bit more.
About the broken https; yes, 100% confirmed.
Oh sorry, fast reading.
ie6 not breaking.
I'll test it.
That's not something on WilB's hands (although he could add the SO features check to warn about the other "problems"). The clipboard additions would have to be implemented on SMP itself, the component.Seems like using wine5/ie6 fixes clipboard access without breaking https sites. html dialogs won't work though.
Another possible fix is to add utils.GetClipboardText and utils.SetClipboardText to the component which will use windows APIs and should work fine. There are some one-liners in shared.h from the foobar2000 SDK for this.
If this is feasible then all important things of panels will work.
The configuration ui is cool but anyway you can use others ways to configure the panel.
Maybe you can alert WilB to do that in biography? I could do it myself but i think that you could explain it to him better (in a developer way).
Seems like using wine5/ie6 fixes clipboard access without breaking https sites. html dialogs won't work though.Great, will add it to the popups then. paregistrase could you confirm it too?
That's some weird logic.You mentioned 'responsible disclosure'. If I distribute a bunch of files that might trigger security issues in various programs, that's hardly responsible disclosure, is it?
What I was trying to say is disclosing (notifying the security mailing list) then publishing after a wait period, is better than neither disclosing nor publishing.