Probably not that useful in Vista and newer, since recent foobar2000 synchronizes and controls its volume through per-application levels.
I would like to have foobar2000 volume able to synchronize to windows mixer master volume. Why? Because some ASIO drivers does not sync volume to windows mixer (for example E-MU and some of ESI drivers). PS: I don't use WASAPI, it doesn't suit me.
Last post by Daeron -
You might want to consider that something inherently flawed won't be so easily solved by just throwing more horsepower at it (it will help, but it might not grant you the magnitude of gains you are wishing for).
Comparing clock speeds between different architectures is somewhat pointless (4GHz on an old Pentium 4 is not the same as on a modern CPU), so you can't just assume higher is better. Maybe you meant single threaded performance?
Cores in general is a complicated topic and you shouldn't just be looking at what a single application will be doing. Surely you won't dedicate a high-end CPU to just create your autoplaylist faster? What else will you be doing on that PC? Gaming? Number crunching? How many of your important software support scaling on multiple cores properly? How many of them will be running concurrently? Did you look at the whole platform costs (motherboard, RAM, CPU cooler, potential upgrade path later)? These to me sound like much more important questions to answer. As far as handling your autoplaylists either of those CPUs will do just fine.
If they don't, you will really have to start addressing your setup in the first place. Probably by testing what happens if you only create autoplaylists one at a time on the fly (such as marc2003's method, or facets have queries you can save too). If that doesn't work, I'd reconsider how (and why) you are doing customdb fields in the first place. Third, the example query you have listed implies to me that there might be something specific about that group of elements (genres, genres families and the artists etc) you listed. If there is, you could tag them as such so you can retrieve them quickly later.
The bottom line is that to me your situation seems like a weird edge-case scenario of combination of things not working all that well together, so I wouldn't expect the devs to be able to give you much pointers without them replicating the exact scenario and starting to swap components in and out to see which mitigates it to what extent. The best candidate for that is - unfortunately - you.
I believe I have read that AAC is a good codec for wireless because it is natively supported with aptX
Aptx is an audio codec used by some Bluetooth hardware. AAC is a different audio codec sometimes used by Bluetooth. If you had hardware that could do AAC, and your files were the right bitrate, and your software could be configured to not transcode, then AAC might be preferred. If you're just using aptx it doesn't matter what the source is.
I am looking for some advice on using wireless headphones. I find it difficult to find clear and accurate information about differences between aptX, different version of Bluetooth and combinations of codecs and protocols. I'd appreciate any tips you might have, as well as pointers to useful online resources.
I believe I have read that AAC is a good codec for wireless because it is natively supported with aptX, but I am not sure if this is still the case and if it has any real life advantages over MP3 today. My main concerns are power consumption, possibly perceivable sound quality differences, connection stability and performance reliability.
What I would like to know is:
1. With the latest versions, is there any practical difference between aptX and Bluetooth for sound purposes?
2. Using aptX, does it make more sense to play AAC or lossless files from your source to your headphones?
3. Using Bluetooth, does it make more sense to play AAC or lossless files from your source to your headphones?
4. Using aptX, does it make more sense to use AAC than MP3 to avoid transcoding?
5. Using Bluetooth, does it make more sense to use AAC than MP3 to avoid transcoding, or is transcoding unavoidable?
Thanks in advance for your input!
(Sorry if this is not the correct subforum. Feel free to move this post.)
Of course this level of complexity is ridiculous compared to SQL queries you can find in a proper DBMS, but it is actually more complex than it looks, because the %genere_family% field is a customdb field, therefore the query is based on a sort of join clause. Needless to say, most of my autoplaylists are based on genre classification, where customdb is highly involved.
And that is most likely the main reason for the long time of initializing the autoplaylists. Queries with using customdb fields are signifantly slower than queries, which are only run against the media library.
I'm sure it is. So, what is your advise to speed it up? Do you agree with Case that I'm limited primarily by the CPU? And should I trade cores for clock speed or viceversa (I can't decide between an i7-8700 or a ryzen 7 2700)? Am I right supposing I should look into DBMS hardware requirements?
Last post by EpicForever -
No problem . But credit should go to other forum user - most probably to Daeron, who helped me with exactly the same problem few years ago. I use this sorting pattern on a daily basis.
Last post by pqyt -
1. Not sure, I tend to follow the beta's rather closely. The best guess is ever since 1.4 beta 1. I'll re-install 1.3.17 to verify this. I used to rely on the behavior because when typing long queries with spaces in them fb2k tends to be greedy and starts searching too fast for my taste.
2. Thanks for the clarification. I'll pay attention to my queries and see if this explains the behavior I see.