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.
Last post by sacdman -
I have downloaded and reinstalled Foobar v2.1.4 X64 and reinstalled it. When I check the online troubleshooter, I get this message...
You have reached this page because you appear to be running a modified or corrupted version of foobar2000, one that did not come from us.
We strongly recommend that you uninstall your copy of foobar2000 and scan your system for malicious software.
Note that you should always download foobar2000 from the official site (www.foobar2000.org). Download it from any other source at your own risk. We have no control over what other people put in their "foobar2000 installers" and take no responsibility for any damage to your system they might cause."
I think this might be in error, since I have downloaded my version of foobar right from foobar2000.org. Any ideas?
Last post by Case -
I don't really understand why people ask foobar2000 questions on reddit. Reddit doesn't even seem to show that the original post in the thread you linked was later edited to contain the bit about Android - initially it had no OS information making majority of the replies irrelevant/incorrect.
Android has no SMB support built-in. Android doesn't support FTP either, but it's much simpler protocol and Peter could add support for it relatively easily and quickly. So officially there is no way to add SMB shares to mobile foobar2000. In theory a program that adds SMB support to the OS might work. I found this program that claims to do it: https://play.google.com/store/apps/details?id=com.connectedway.spiritcloud.
As a workaround you could run FTP server on Windows and share the same paths over FTP.
Last post by Revup67 -
Hi Peter - thanks - saw the changelog for 2.2 Preview today 4-26-24 - "Prevented Media Library search from clearing other playlists with enter key if library selection playlist feature is active."
Last post by eagleray -
After a two week break a new build of 2.7 preview now offers more main window customization options. Looks like to me there's going to be a lot more development in this are before a stable 2.7 is out.
What I would really love to see is the conversion functions from the Win version added. Free apps which perform these functions on a Mac are not easy to use. Being able to split a compressed single file with a cue sheet into separate compressed files is a very useful function.
Very good, should improve performance with all Windows compiles.
Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.
Finally, the gcc's speed is identical to clang's build, thank you @Case, I do believe this patch will also solve @KevinB52379's Zoomtext compatibility issue. Here's the dev binary(include both gcc and clang) for test purpose.
* As for running quiet: hyperfine suppresses console output, and a bit of non-rigorous testing indicates that running quiet doesn't matter for ffmpeg when tested by hyperfine (it could matter in real-life ...). But wvunpack runs the percent progress in the window's title bar, and hyperfine does not suppress that!
flac then. @ktf : * I will re-run when I am back at the same computer. The chance for human error is certainly positive - like, copy + paste suddenly overwrote something in a spreadsheet. I haven't automated this. * The files that ffmpeg reject are not about only being one frame - the 6ch (subset!) file I posted at https://hydrogenaud.io/index.php/topic,125848 is a full second. What happened to the attachment posted in this thread was that I traversed the possible -b's and found where the trouble started - then I cut the source down to the precise number of samples to see if "single frame" would still trigger it. Of course, I carelessly posted the last file created. * Question: it seems that reference flac omits MD5 calculation from -t and -d if the file has no MD5 in STREAMINFO? But there is no way to force it not to otherwise?
Last post by Porcus - WavPack again. Only .wv in this post. wvunpack and ffmpeg
-z0q and time. Does console output slow it down? TL;DR: -vv is so fast that one can argue that yes it does.
An initial test wasn't dramatic: hyperfine on single untagged -f-encoded file indicated a cost of 0.05 seconds on decoding to NUL and 0.02 seconds for fast verify. But, then. Since there is only wvunpack against itself to test on this matter, and it supports wildcards, I took two actual albums, with tags and all, in separate tracks, on a spinning drive: one full CD 75 minutes of Bach's organ works, 652 kbit/s using, 28 tracks/files. Black Sabbath s/t, 38:14, a CD split in 7 tracks/files, 903 kbit/s. Both using -x6.
Fast verification: -qz0 is significantly faster, in percents. 0.1 seconds isn't much though, but if one has a full TB of CDs (like 3000 of them), it will add up to a few minutes. 25 runs with two seconds sleep in between: wvunpack *.wv -vv -qz0: 304 ms on Bach and 187 ms on Black Sabbath wvunpack *.wv -vv : increases by 103 ms (36 percent) resp. 81 ms (46 percent)
Decoding to -o - > NUL: Since that takes more time, the percentages aren't that impressive of course. The differences in time look suspicious to be honest, but 19 runs and not too outrageous standard deviations: wvunpack *.wv -z0qy -o - > NUL : 9.265 s ± 0.024 s resp. 4.917 s ± 0.025 s wvunpack *.wv -yo - > NUL : 9.698 s ± 0.032 s resp. 5.039 s ± 0.013 s Writing to the same spinning drive would bring it to 30 or 15 seconds, and that kinda sets the perspective. But the fast decoding is now so fast that it seems that reporting the progress makes for something if one is scanning
Decoding speeds again. Tested more multithreading. TL;DR: wvunpack --threads=<N> beats ffmpeg -threads <N> at decoding - with one exception where block size was forced to maximum.
I did the "shorter" half-hour file. Commands were like the following: ffmpeg -threads 8 -i ¨3x.wv.-fx0.wv -hide_banner -loglevel error -f wav -y NUL .\wvunpack --threads=8 ¨3x.wv.-fx0.wv -z0qyo -o - > NUL the latter being the fastest. -fx0 in the filename because that option (it means -f ; -x0 in new releases means "no x", that is good for FOR looping). And yes there are two "o" options because I didn't spot it, but wvunpack didn't object.
Times first, mean ± stdev - having sorted the output by the .wv file and then by speed, fastest at top:
A couple of remarks: * I ran ffmpeg and wvunpack alternating with the same threads count, so that none of them should be disadvantaged over the CPU having just reacted to something (throttling or whatever). To make sure, I ran it twice: once with ffmpeg then wvunpack, once with wvunpack then ffmpeg. Very small differences. * What I didn't think of ... because I am normally juggling a few versions of encoders, I the current wvunpack.exe to the same directory - it shouldn't make for a time advantage?! Maybe fix PATH next time.
WavPack -vv fast verification redux: TL;DR: Put the --threads differences down on my system not being more consistent than the data below ... arguably, less consistent.
In case anyone is interested, I dump the hyperfine output in here. Same files. Ran with and without threads (and a couple extra to check for inconsistencies, not included; one was off, but betrayed by a high stdev).
USB3 spinning drive. Fastest was 105.1 ms ± 2.8 ms