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
Other Lossy Codecs / Re: Descript Audio Codec (.dac) - 90x smaller than .wav?
Last post by C.R.Helmrich -
... it's made a 40MB exe ...
This does not include the weights file which is ~300MB. The weights file contains the model data used to encode and decode the audio and is a necessity, and the model is not interchangeable. You have to use the same model to decode any encoded file.
Thanks for the analysis! Out of curiosity: could you 7zip (preset Ultra) that 40MB exe and 300MB weight file and let us know what file size comes out? That would be a rough estimate of how much room for reduction there is.


3rd Party Plugins - (fb2k) / Re: [fb2k v2] SQLite Utilities (foo_sqlite)
Last post by SimBun -
The section you highlighted is the code that computes and rounds the rating, so if you wanted to change the logic it would go there.
If you run the following code it'll show you everything you could reference in your calculation - although likely it's just length_seconds that would be of interest.

Finally I've been thinking about averaging the rating weighted on track length (sometimes I do have instrumental only tracks which can be >3 mins on which i defined a rating of 1)
I tried to play with length_seconds and with the sum() function to get total album length but without succes so far, still investigating  ;)
To sum length_seconds it's simply:
Code: [Select]
sum(length_seconds) as name_of_calculated_column
For the average you'd just need to use "avg" instead of "sum".

So in the original sql it would be:

Code: [Select]
  select album,
         [album artist],
         round(avg(rating), 2) albumrating,
         sum(length_seconds) as total_album_length_seconds
  from Playlist
  where playlist_index = active_playlist()
        and rating <> 1
  group by 1, 2, 3;
foobar2000 mobile / Re: Report a whole track album playback bug V1.4
Last post by Peter -
Please clarify:
".Click on Settings,process INDEX to newlist"

A video of what you did would help too, if you're having trouble explaining.

Can anyone else reproduce this? I assume it has to do with playing external cuesheets and manipulating playlists, but creating a playlist with cuesheet then playing it didn't crash for me.

I've been trying to find matching crash reports in Google Play, but they've done something weird with the system, probably to "protect privacy", and no useful info can be extracted whatsoever (no stack traces etc).
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
While my computer is chugging off on upsamples ... warning for back-of-envelope quality calculations:

The thing about a signal that is a single sine, is that you can predict them by two coefficients of which one is = -1.
You have a predictor x(N+1) = x(N) * 2 cos q - x(N-1) and with q fit to pi* 2f/F where f is the sine's frequency and F (>2f) is the sampling frequency, then you are all good - provided that the format can offer high enough precision for that 2 cos q.

... and, well: An "optimal" coefficient would be around 1.65313038269 i.e. 6771.22204748 * 2-12, and although a simple -l2 does not catch it, -pl2 finds 6771 * 2-12. Maybe, for all that I know, 27085 * 2-14 or  54170 * 2-15 would do better, maybe not.

@ktf : out of "curiosity", is it possible to force-feed libflac a given predictor vector and test (6771 * 2-12, -1) vs  (27085 * 2-14, -1) vs  (54170 * 2-15, -1) on this file?
Asking because - semi-educated guesswork, but I might hit it - the explanation might be as follows:
* for -l2, where there would be a perfect predictor if resolution & accuracy were infinite, this is either "a format resolution issue" limited by the right-shift being at most 15 bits, or "an accuracy issue" where intermediate calculations should use an even more precise variable type.
* when order becomes > 2, we have a uniqueness issue on top. There are several "infinite-precision predictors" that would hit the sine exactly, the number of degrees of freedom should be some k = (order minus two) for a pure tone. With finite precision, that means to walk through that grid to find a benevolent roundoff error. Not sure if that is worth to code - likely the alternative with -e, possibly with a few apodization functions too, works as a "try a few arbitrary ones" with the added benefit that if it finds a good one at lower order, it saves the space a coefficient would take. 
But "uniqueness issue on top" does not rule out the resolution issue or the accuracy issue.

So if I am right about this, then question is, does it actually hit the best 2nd order predictor the format can offer. If it does not, then one can scratch one's head over whether the double precision change was enough. If it hits the best available 2nd order predictor, then improving over that is a mess ...
... but, can the algorithm detect whether you are close to a singularity? Because then the following is a thinkable option: if that is detected, invoke a more exhaustive search. And that might be an idea even for more general signals.
3rd Party Plugins - (fb2k) / Re: Playlist Organizer (aka foo_plorg) replacement on Jscript Panel 3
Last post by etip -
Playlist Organizer (Jscript Panel 3)

Version change :
- Added a "Theme management" functionality.
  • Create up to 10 themes from the current configuration (name have to be unique)
  • Choose a theme amongst a list and change the current configuration
  • Update a theme with the current configuration
  • Rename a theme (cannot duplicate name)
  • Delete a theme
A new file will be created in the fb.ProfilePath (next to the "pl_organizer.txt" file) to store the themes' data.

This is still beta although i did a few tests, please let me know if you find bugs.
Any feedback is welcome.