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
1
General - (fb2k) / Re: Possibility of releasing the source code of FB2K
Last post by jarsonic -
Quote from: papavlos on
One small remark though - inheritance.
We have the case of `foo_upnp` plugin with lost author where lots of people (me included) still are forced to run 32-bit fb2k just because of lack of possibility to compile the plugin to 64-bits. With NO alternative available.

Who knows? Maybe there will be a first-party UPnP solution for foobar2000 at some point in the future.
2
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by Porcus -
Quote from: Case on
Curious 80's tech. The Motorola chips used in there were actually based on 24 bit words. Wikipedia tells the Motorola has two special registers allowing them to operate together as one 48 bit register.
Others used that too. B&K did. Meridian's DSP series active loudspeakers (those taking digital input) used Motorola 56k over thirty years ago (I think they migrated to Freescale).
3
Polls / Re: 2023 Lossless format poll
Last post by Porcus -
For those who want a poll over options, then "default / lighter than default / heavier than default" is likely the big question. Sure refalac has a so-called "fast" mode, but that isn't even lightweight, just encoding fast.

Quote from: mycroft on
All these encoders use old vintage technology.

What newer methods have brought improvements to the table really?
HALAC attempted ANS residual compression, but reverted to Rice.
4
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by genuine -
I've heard about the success of the HALIC image compression codec. But then it feels a little strange to see such a success in the audio codec as well. Because these are quite different areas.
According to the current results, the critical level has been exceeded. I think the results are excellent. So I don't know how much more compression can be done by processing so quickly. Not to mention multithread encode and decode. Theoretically, more is always possible, but practically it is not.
Can't the crazy Rice encoder and decoder that you used in HALAC also be used in FLAC? Is there such a compatibility?
7
3rd Party Plugins - (fb2k) / Re: foo_openlyrics (not my release)
Last post by sveakul -
Quote from: gfxnow on
I am confused about how the "Preferred lyric type" setting relates to the "Search order" list.
I have local files set at the top of the search order followed by Bandcamp, Musixmatch, LRCLib and Genius.
It will not affect the order of the sites searched, only "Search order" will do that.  What I don't know is if static lyrics are found at a site but not synced, it will continue to search past that site instead of just pulling the static lyrics and stopping, because the word used is "preferred" not "only."

If a song already has embedded/saved lyrics and you want to search again later to see if a site has added another type, you would need to move "local files" to the bottom of the order list.

You may want to try the standalone LRCGET for a more "drop the boom" approach:
https://getmusicbee.com/forum/index.php?topic=42098.0

https://github.com/tranxuanthang/lrcget
8
FLAC / Re: FLAC-git Releases (Code Base v1.4.x)
Last post by rennie -
Would it be possible to add the Code Base Number to the ID of newer builds?

I think it would better to identify the used FLAC git version by "reference libFLAC 1.4.3 git-5152c6c 20241030" OR "reference libFLAC 1.4.3 (git-5152c6c) 20241030" OR "reference libFLAC 1.4.3 20241030 git-5152c6c" OR "reference libFLAC 1.4.3 20241030 (git-5152c6c)" for example.

Especially the last two proposed identifiers would be as similar as possible to the ID of the latest official release (which is "reference libFLAC 1.4.3 20230623").

9
3rd Party Plugins - (fb2k) / Re: Made with foo_uie_webview
Last post by mjm716 -
Quote from: sq68 on
carousel_a5.html86 bit is working properly. But a few seconds after the 64-bit resizing won't display the image?

I use x86, but installed a fresh x64 and it worked fine.
It is not a live resize - resize panel and then reload a track to update view.

Did you check console (via Inspect) for errors?
Check memory behavior in Process Explorer, are you using 50 very large images?
10
3rd Party Plugins - (fb2k) / Re: Made with foo_uie_webview
Last post by ApacheReal -
In progress...



In addition to lyric management, now the animation API does not need internal covers, plus many other fixes.

Having removed the internal covers from the API management makes it possible not to have any blocks with the Vu Meters / waveform and seek bar.

It's all due to foobar200's management of the internal covers which goes into crisis with third-party plugins, now the problem is definitively solved.