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
Scientific Discussion / Re: AudioWorklet-based filter bank spectrum analyzer
Last post by TF3RDL -
New feature: Reduce "flickering" on faster (or infinite) decay rate, especially with analog-style analyzer mode though it also applies to other filter bank modes to not miss out peaks in-between frames. Especially with "accurate smoothing" enabled, which makes the averaging and peak decay calculation sample-accurate

Also, an option to "extend" spectrogram gridlines to screen width have been added for consistency with FFT spectrum analyzer and spectrogram project

BTW, early on the development of this project, there was an idea of chromagram, which visualizes distribution of notes regardless of octaves they're in. That idea was scrapped unfortunately as I'm too lazy to figure out how to implement that idea from ColorChord, with all of fractional octave divisions where the divisor allowed to be non-integer (e.g. how I've supposed to display a chromagram with 1/6.5 octave bands?)
2
General - (fb2k) / Re: Title formatting/syntax for proper bitdepth
Last post by wojak -
@Case
I just sent some (5-10) crash reports to foobar.
All are caused by foo_hdcd. All occur on one and the same track (it is a 9 second track with hdcd and none of the features). It occured on two instances of FB (normal and portable, 2.24/64, win10 pro). It occured while trying to run DRMeter, TruePeakScanner and while attempting to play that track. All other tracks from that album are ok. I started to downgrade foo_hdcd and the last version that normally plays that file is your preview from 14.11.2024 (at least I named it with that date; it is probably your first preview). All newer version crash. I tried another album and it was ok.
Can it be that the cause of the crash is that the track is just 9 seconds long? It is the track called "Convict" (second on the album) from "Operation Mindcrime 2" album by Queensryche band.
3
3rd Party Plugins - (fb2k) / Re: Wrapped-SMP
Last post by regor -
Just pushed to the repository new changes with album stats.

Next addition will be an histogram of listens per month and some kind of further analysis around that (for ex. moods changing by quarter or something along that line)
4
General - (fb2k) / Re: Info for equalizer
Last post by Air KEN -
Display in Text Display (JSP3 Sample Script), etc.
https://jscript-panel.github.io/gallery/text-display/

Output Info (foo_outinfo)
https://foobar.hyv.fi/?view=foo_outinfo
[%output_dsps%] shows nothing but "Flex DSP".

Use [%track_flexdsp%] registered in Properties > Metadata > + add new > "TRACK_FLEXDSP".

Flowin 0.2.2
https://github.com/ttsping/foo_flowin/releases

Defender - Text Display + Album Art... 2024-11-22
https://hydrogenaud.io/index.php/topic,110516.msg1054475.html#msg1054475
 

Custom text...
Code: [Select]
$font(Yu Gothic UI,16,400,0,0,0)
[%title%$crlf()]
$font(Yu Gothic UI,14,600,2,1,0)$rgb(220,40,0)
%artist%$font()[   $font(Twemoji Mozilla,16)$country_flag(%country%)$crlf()]
$rgb()
$font(Yu Gothic UI,14,400,0,0,0)
[%album% '('%date%')']$crlf()
$font(Yu Gothic UI,12,400,0,0,0)
[%codec%][ %__bitrate%kbps][ %codec_profile%][ %__tool%][ %__tagtype%]$crlf()
[%output_device%]$crlf()
[DSP: %track_flexdsp%]
5
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by regor -
Quote from: mjm716 on
Quote from: regor on
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.


All the things that can't be done, right?
? That's running outside foobar, as you are showing. Yep xd

That doesn't change that once the component thread tries to access more RAM than available on x32 it will crash. Which may have not happened to you yet, great :) Because no method currently exposed will do that. All current methods work on single paths.

You can obviously load 200 GB in a web view thread outside foobar, that proves nothing. You may well be loading external images, or the entire wikipedia xd Data is not being managed by the component at that point. Wait until there are methods for library management and you try to parse TF over 300K tracks.

Right now all your point is like saying I can run firefox with a CMD command via SMP and load 200 GB there. Obviously, you can. And you can also send back and forth data via JSON as long as you are sending anything under <2~3gb. Which is essentially what this component does (but showing the "firefox" window within a panel). And whenever this component tries to send bigger than that, it will crash on x32. But obviously that will never happen in UI scripts.
6
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by mjm716 -
Quote from: regor on
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.


All the things that can't be done, right?
7
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by regor -
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.

Quote
Also as I've said many times in the past, I would love to use your charts framework - comprehensive libary statistics would be my utopia - but it doesn't get off the starting block (for me!) because the core components crash foobar with the first computation of your framework.
You simply refuse to use foobarx64 and JSplitter, but that's your problem. You can not ask foobar to handle +3gb of ram for things running within foobar without x64 binaries.

Quote
You are naturally looking after your self-interest, but if not derogatory, you are definitely over valuing engineering and under-valuing creativity; while not exclusive, neither is that easy. 
That's just your supposition about me.  ;)  Which is fine, everybody may have opinions. I would love this component to grow and support both sides.

Quote
There has long been a vacuum of simple UI/front-end things here.
That's for sure. But it has not been due to JS usage vs Web View, which is my point. SMP also supports HTML parsing and CSS, is just that some people avoid to use it because it breaks wine compatibility ;)

Anyway I agree HTML and CSS are easier than using just JS, and we share similar thoughts about most things.
8
3rd Party Plugins - (fb2k) / Re: foo_uie_webview
Last post by mjm716 -
That's what I was implying...

Quote from: mjm716 on
Both are stagnant waters for many reasons,

Clearly you, myself, @MordredKLB and others have been fed up with the situation for some time.

Quote from: regor on
Obviously rendering HTML + JS is going to be easier for UI things since you are just working over +20 years of work from other people xd Who doubts that? That has nothing to do with the scope of the component, and if the idea is to manage a library

Yep. (actually ~30) years for people here to draw upon and finally new sprouts are beginning to take hold.
Who the hell wants to reinvent the wheel to increase the delightful nature of their music player.

It certainly has much to do with the current scope of webview.
As we both agree, there are half-baked backend tools here for awhile, but doing UI with them has been a misery.

Managing a libary with webview is your own projection. Maybe yes, maybe no.

Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.

Also as I've said many times in the past, I would love to use your charts framework - comprehensive libary statistics would be my utopia - but it doesn't get off the starting block (for me!) because the core components crash foobar with the first computation of your framework.

(I NEED this in FB!)


Quote from: regor on
And "simple UI things" is not a derogatory name. Many things in Web view are pretty simple xd they are not in JSP/SMP. But they are just that, UI things. So I asked the dev to understand what will be the scope of the component to think about creating my own scripts here or not.

You are naturally looking after your self-interest, but if not derogatory, you are definitely over valuing engineering and under-valuing creativity; while not exclusive, neither is that easy. There has long been a vacuum of simple UI/front-end things here.

The recent 7000 posts about 16+ year-old vumeters, which broke Marc's brain/spirit, shows the interest in silly UI things is just as great as for those looking for the next great js smooth playlist.
9
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Porcus -
* It seems HALAC 0.3.8 does make use of stereo decorrelation, even in the -ufast option: "mono as stereo" files compress much better than with flac -0, which is dual mono.
* Does it still use blocksize 2048? I compared to that.

A quick test of compressions, not (yet) speeds, with my 38 CDs.

-ufast compresses slightly better than flac -0b2048, but the difference is all down to the "mono as stereo" files. Without them, HALAC would still compress better on the metal, but worse on the classical and "none of these" sections.
-fast was compared to flac -3b2048 which is also dual mono.  They would have been practically tied (52.83% vs 52.81) with HALAC number on the stereo-as-mono.  Also here, HALAC does better on metal and worse on classical.
-normal was compared to flac -5b2048 (that is, default except half the block size).  HALAC loses narrowly in all three genres, biggest difference was 0.21 percentage points for the classical section.

All FLAC were run with --no-padding
10
FLAC / Re: FLAC-git Releases (Code Base v1.4.x)
Last post by Replica9000 -
I could maybe see something like this...
"flac git-d34489c4 20240831 1.4.4_BETA-1"
"flac git-d34489c4 20240831 1.4.4_RC-2"

Stable releases don't get pushed out so often that you can't stop by the git once in a while to see where things are at.