...I wouldn't expect it to scale well at all on multiple cores. I personally think it's generally a good idea to assume that applications won't properly use your additional cores unless proven otherwise. It might also just be limited by your I/O. You could try giving it only one of your CPU cores and see how that affects startup times (and CPU utilization). You could also move a portion of your library to your SSD, benchmark startup times with only those tracks in your database. Then do the same but using your HDD and extrapolate the results. I wouldn't be surprised if that actually net you much better results alone, while more cores not so much.
Last post by Vicas -
I see your concern but in my opinion scrolling is very nice and useful option, as you can chose where to drop files. (may it be end of playlist, before or after an album, song etc)
Last post by tedsmith -
You may already know this but FWIW:
What you are experiencing isn't directly related to the new foobar2000 releases.
With the 1.xx releases of foo_input_sacd you don't need the ASIO proxy, you just use the device's ASIO (or it's WASAPI, …) driver directly.
Earlier foo_input_sacd's (before foo_input_sacd 1.1.0 I think) don't work with the beta foobar2000's but that is a problem with foo_input_sacd, not with foobar2000 and foo_input_sacd 1.1.0 works with the foobar2000 betas.
With older foo_input_sacd's you would also run, say, ASIOProxyInstall-0.8.3.exe to get foo_dsd_asio, an ASIO proxy that could translate native DSD to, say, DoP. That translation directly in the newer releases of foo_input_sacd.
AFAIK you can't use the newer foo_input_sacd's to send native DSD. There were some releases about 1.0.0 to 1.0.3 of foo_input_sacd that tried to do native DSD, but there were bugs.
foobar2000 betas (and previous releases) and foo_input_sacd_1.1.0 work fine here to play DSD (via DoP).
Tho I haven't tried it recently the later releases of foo_input_sacd_1.xx provide a "DSD Processor" which does DSD -> DSD and PCM -> DSD conversions.
Last post by Peter -
Thanks. Problem recreated and fixed for the next update.
It appears that Microsoft made up their minds and all the fields now stick between tracks unless explicitly cleared, this seems to have changed between Windows 10 1803 and the previous version. At least my development machine on older Windows 10 did not have this bug < cue Intel 600p SSD rant > but another machine running version 1803 did.
Glad we got it sorted out before foobar2000 v1.4 stable.
Last post by Daeron -
Just to clarify I meant flawed in terms of interfering with your usage (slow). I wasn't questioning whether the functionality provided is something you want.
To sum it up I would personally expect the worst. As I recall foo_customdb is fairly old and not maintained by now, meaning any newer SQLite improvements are not available and what's there might be poorly implemented as well. On top of that many problems might just come from the DB design itself and probably would need a lot of work to work around (if possible at all) to not slow down.
Meaning basically that I wouldn't expect it to scale well at all on multiple cores. I personally think it's generally a good idea to assume that applications won't properly use your additional cores unless proven otherwise. It might also just be limited by your I/O. You could try giving it only one of your CPU cores and see how that affects startup times (and CPU utilization). You could also move a portion of your library to your SSD, benchmark startup times with only those tracks in your database. Then do the same but using your HDD and extrapolate the results. I wouldn't be surprised if that actually net you much better results alone, while more cores not so much.
In any case there are way too many moving parts here and the only thing you can do is poke at it and see what it likes and what it doesnt, then try to explain why. At least that's how I would approach it.
Last post by dejanm -
I do not want to start religious discussions DSD vs PCM. That is also not the point when you build a product like Foobar.
Earlier versions of F2K had the possibility to open two control panels: one of driver itself (in this case that would be Pioneer driver) and ASIO Proxy. Now there is no such possibility. Therefore, I cannot assign Pioneer driver to the ASIO Proxy (what I did - I install the trial of JRiver and there did this association, and then it works also in F2K - but that is not how it should be). Why it would be difficult to integrate in F2K, just like it has been done in JRiver, SACD plug-in, Asio support and Asio Proxy, provide couple of panels where it can be simply selected the output driver and in that way make DSD support available and easy to use.
I am using foo_input_sacd having in that way the capability to convert DSD into PCM. That part is working just fine. But the users want to have the flexibility to use different formats. You know how we are ...
Last post by enofile -
Please excuse my lack of knowledge. I am 68, and have issues with digital applications. I just purchased a Teac Ai 301 DA integrated amp. It has a USB post and I want to play music from Foobar 2000 through the Coincident Victory II speakers hooked into the amp. However, when I plug my iPad into the USB post, music just comes out of the iPad speakers. I do not comprehend why the speakers are circumvented. With Bluetooth, streaming music from Spotify is played through the Coincidents. Can anyone help me. Also, when I install the Foobar2000 app on to my iPad, it oddly is downloaded to the Video Recorder. Where should Foobar2000 land on my iPad? Certainly, the Video Recorder is not the correct runway. Thank you.
Last post by darkbyte -
I was testing Bluetooth's default SBC encoder for car listening in the past, and I've found that highly compressed sources can sound bad when further transcoded for Bluetooth transmission (this is with a recent Android version which uses the higher bitpool setting, I'm not familiar how iPhone behaves in this situation).
Without any scientific evaluation, just as an idea where you can start experimenting, in my findings you cannot go wrong with : - Lossless, or LossyWav or WavPack Lossy (basically any encoder which lower bit depth and shift introduced noise in the upper frequency domain), this was the best source in my opinion for further transcoding - Musepack (matches nicely with SBC's subband allocation), my second best choice - AAC-LC/MP3 >= 160kbps - Opus >= 96kbps - HE-AAC (I've tried this with web radio stations and seems to keep the stereo separation nicely, also the highs are already artificially altered so SBC doesn't seem to make much of a difference anyway)
Just my 2 cents. With AptX I don't think you have to care too much about the source, because AptX seems to work very much like LossyWav and makes a variable bit depth encoding.