Skip to main content ↑ ↓

Notice

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
11
foobar2000 mobile / Bogus rejection from Google Play
Last post by Peter -
Quoting last response from Google:
Quote
Status: Latest app update not accepted into Android TV on Google Play

We’ve reviewed your appeal request and found that your app, foobar2000 (com.foobar2000.foobar2000), still contains eligibility issues. We’ve included details below about the specific issue with your app and what you can do to meet the requirements for Android TV.

Step 1: Fix the eligibility issue with your app

During review, we detected the following eligibility issue and were unable to accept your app for Android TV:
No full-size app banner

Your app (version code 847) does not contain a full-size app banner and/or icon, or it is not visible in the launcher. We are targeting 1080p, which we consider xhdpi. Apps should include the banner in the xhdpi (320 dpi) drawables folder with a size of (320px × 180px) and the icon with a size of (512px x 512px). Please refer to our Provide a home screen banner article and UI Patterns documentation.

The title should help users identify apps in the launcher. Please refer to our Visual design and user interaction documentation for more information.

    For example, your icon does not fill the entire icon space. See attached screenshot.
Screenshot they attached:


Can anyone more competent at Android development explain to me what the heck this is about?

High-resolution TV banner is included. I don't know what their problem with the icon is. From the above, I'm not really sure if the problem is icon, banner, or something else.

Offending app bundle is same as these APKs.

Thanks in advance.
12
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Case -
PLR is difference between highest peak and loudness, calculated as 'peak_db' - 'LUFS-I'. Only way it would be negative is if peak was somehow smaller than loudness.
All places I saw quoting PLR numbers printed them without decimals, like https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Titleformat_Examples#Peak_to_Loudness_Ratio_.28PLR.29. I figured it's like the DR number that people want to see as integer.
13
Support - (fb2k) / Re: Unintended/accidental AVX requirement of 64-bit version
Last post by Peter -
Indeed, VS2019 supports C++20 and compiles latest foobar2000 sources without any apparent issues so far.

Another thing, VS2022 v17.10 output crashes hard if interfaced with older vcruntime DLLs, like, ones that foobar2000 has been including until now. It looks like using latest VS2022 for foobar2000 components is a bad idea becasue they'll crash in foobar2000 install having too old runtime.

Less related thing, Apple has a loose clown in their compiler deparment too, their latest linker defaults to turning C++ code into something that instacrashes on Mac OS older than 12 or so, as if they couldn't obey deployment target. I'm also using old tools there because latest can't be trusted.
14
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Defender -
@Case

Scanning speed of 0.6.9 with LRA, but without LUFS-S/M, is the same as it was with 0.6.7.

I am confused as a result of the new PLR fields.
In essence PLR is nothing else than applying peak_db on LUFS-I. If I do that based on your LUFS-I value I get a value. In the PLR field you report this value negated and rounded as an integer.

If it was only negated, I could still exactly verify it with my own calculations of LUFS-I and PLR, but because of the rounding I cannot.

Why is your PLR rounded?
Why is your PLR negated?
15
Support - (fb2k) / Re: Unintended/accidental AVX requirement of 64-bit version
Last post by marc2k3 -
Quote from: Peter on
I'm afraid that, at this rate, you'll have to run old versions of various software, not just foobar2000, on machines without AVX because other apps built with new MS compiler will manifest the same problem.

If VS2019 works, I think you could use it for the current 2.2 series. In a previous comment you said this...

Quote
I'm waiting till VS2022 17.10 before attempting any "fixes" in fb2k 2.2 series, hoping for the problem to fix itself without having to revert C++20 use in new code.

but I don't think that's right. VS2019 should be fully C++ 20 compliant.

https://devblogs.microsoft.com/cppblog/msvcs-stl-completes-stdc20/
18
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Porcus -
If I understood it right, LossyWAV's default block size choice of slightly below twelve milliseconds, is to allow for swift changes in the number of decimated LSBs. Bigger blocks would mean you would have to keep that constant over a longer time. 512 samples in LossyWAV and say 1024 in a compressor that employs a per-block wasted bits strategy, would restrict it to choosing the "worst of two".

When I suggested to facilitate LossyWAV, I didn't know whether it would be easy for HALAC to employ a user-selectable block size.

FLAC does a trick that for some signals improve compression by quite a lot, namely the partitioning with different Rice parameters. If a block is size K*2^N, then a partition order of N means that the residual coding parameter is changed every K samples; immediately after K samples there are four bits with a Golomb-Rice exponent. This instead of a low block size which would require frame headers.
Of course, if one did intend a lossy usage like this, one could have partitioned it with different wasted bits too. 

The partitioning is one reason why FLAC does better with block size 4096 than 4095. Sure if you don't use the same residual coding methods, YMMV - but we know certain signals where the advantage of rapidly changing a residual coding parameter can actually make FLAC outcompress any OptimFROG.
20
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Quote from: MihaiPopa12346 on
How did you do lossyHALAC ...
I do not have full information about the LossyWAV structure and I haven't fully examined. And I didn't do anything specifically for the content. I only disabled the prediction phase required for the lossless mode. However, I did not activate it for 0.2.8.
Considering the results in the list, the HALAC offers enough compression even in this form. For better results, the data structure needs to be examined and certain adaptations are required. Of course, time is necessary for this.