Skip to main content


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.
Recent Posts
3rd Party Plugins - (fb2k) / Re: foo_uie_lyrics3
Last post by veksha -
@veksha:  I noticed that you have posted .42 of Multisource over at Reddit.  Can you tell us what changes were made from .41?  I have been having such problem-free results with .41 that I hesitate to update it without knowing if there are any performance improvements I might benefit from.  Thanks.
Hi, @sveakul . I had some very rare crashes with 0.41. @Sergey77 reported some more to private message box. So 0.42 is an attempt to fix them. (My guess is there will be less or almost no crashes on multi-core systems, but on a single-core processor it can happen more often. i'm not a huge expert in developing multi-threaded applications, so I'm learning along the way.)   :))
Development - (fb2k) / Foobar.exe's abort_callback in simple_thread_task causing crashes
Last post by MordredKLB -
So I and my users are encountering an intermittent crash that appears to be some kind of timing/race condition thing when aborting searches in my foo_musicbrainz component.

I first query musicbrainz to get a list of matching results, and then I spawn a number of simple_thread_task's, one for each result which does the individual queries. Every one of these threads is spawned from a threaded_process_callback which gets a abort_callback& from foobar and passes it down to all the simple_thread_tasks.

Occasionally, when a user aborts a search I will get access_violations (which crash) attempting to do anything with the abort_callback (i.e. abort->is_aborting()). Unfortunately, all VS2019 will tell me is that abort_callback comes from foobar.exe and provides no useful information, so I can't tell if the ptr is now garbage, or if some value inside the object has been corrupted.

It's real intermittent so sometimes I can abort 20 times in a row and they all exit gracefully, and then other times, the first abort causes it to happen.

I'm encountering this using 1.6.5 and SDK 2021-02-23. Users have reported it in 1.6.6b7 as well.

There is certainly a chance that I'm doing something wrong, but it feels like this is an issue with foobar. @Peter, if this is something you think is worth investigating, you can get the latest beta here with the corresponding pdb.
Other Lossy Codecs / Re: exhale - Open Source xHE-AAC encoder
Last post by guruboolez -
Bitrate is not fully comparable: exhale d (SBR) is ~74 kbps and exhale 2 is ~80 kbps (and Exhale e is ~86 kbps on my bitrate table).
Interesting test.  :) 
I guess It wouldn't be bad idea to test both SBR ~74 and ~86 kbps settings and calculate an estimate score (at imaginary ~80 kbps) by averaging both values.
It's indeed a good but time expensive solution.

Some score/MOS estimation of mine for SBR:

50 kbps to 61 kbps [+11 kbps] = +0.49
61 kbps to 73 kbps [+12 kbps] = +0.20
73 kbps to 85 kbps [+12 kbps] = +0.10…0.15 [estimation]
so 80 kbps => +0.05 to +0.07 = 3.77 to 3.79
3rd Party Plugins - (fb2k) / Re: foo_musicbrainz
Last post by MordredKLB -
Beta 6 fixes issues with dumb popups when aborting a search. It does not solve the odd crash when aborting, that I think is an foobar issue. Will be opening another thread for Peter to take a look at that.
Listening Tests / Re: Personal Blind Listening Test of Opus and the exhale xHE-AAC encoder
Last post by guruboolez -
@Kamedo2  @guruboolez

Is this test at 64k - 80k also relevant when using bluetooth device such as headphones/speakers or is better to use higher bitrate source which is better at transcoding when using bluetooth device? Should 80k be of acceptable quality also for bluetooth?
As I understand, no matter which format/codec is used, transcoding to bluetooth codec always occur.
During the last two weeks I used my smartphone to stream xHE-AAC stream over bluetooth: on my car, but also on earbuds. I only add xHE-AAC encodings on my phone for pop/rock/metal albums (no classical music so far). And the bitrate was… 24 kbps (twenty four, yes—with Fraunhofer's encoder). I know it sounds totally silly but I was really curious to check how it sounds in real life and not only on ABC/HR tests. More than 400 GB are available on my phone+SD card so I have no space issue.

So how does it sound: If I wouldn't replace my FLAC with xHE-AAC at 24 kbps encodings for archiving purpose I must say that with this kind of music sound quality is really great to my ears, especially while listening in the car. I really had a lot of pleasure while listening these albums. Some constant issues are slightly audible but I quickly forget them (precisely because those issues are constant and not erratic). I caught two or three strong and ugly artifacts—which is a ridiculously small amount at this insane bitrate. Just to give an idea: one hour of music only needs 10 MB. As a consequence 1000 hours of music can be stored in a fraction of a SD card or internal memory (10 GB).

My phone feeds my earbuds over bluetooth with AAC and my car with SBC. I don't think it significantly affects sound quality.

So to answer your question: 80 kbps is more than an "acceptable" basis for BT streaming :)

NB: as a consequence of this unbelievable experience I've started today a listening test in order to compare OPUS and xHE-AAC at 12, 24 and 32 kbps  :))
3rd Party Plugins - (fb2k) / Re: foo_uie_lyrics3
Last post by sveakul -
@veksha:  I noticed that you have posted .42 of Multisource over at Reddit.  Can you tell us what changes were made from .41?  I have been having such problem-free results with .41 that I hesitate to update it without knowing if there are any performance improvements I might benefit from.  Thanks.
SimplePortal 1.0.0 RC1 © 2008-2021