Recent Posts

Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)

Last post by Hakan Abbas - Today at 19:09

* Does it still use blocksize 2048? I compared to that.

HALAC 0.3.8 uses 1536 samples per block in “-normal” mode. In “-fast” and “-ufast” modes it uses 2048 samples per block. However, there is actually no significant difference between them.

Quote from: Porcus on Today at 18:48

Tested encoding/decoding, both from file to NUL against FLAC in a a recent git build and checked roughly afterwards that it is faster than 1.4.2.
Compared to the results just posted by @ktf, HALAC outdoes FLAC at decoding in a much more pronounced way. The smaller differences at encoding could be because files are read from SSD, no RAM disk.

Corpus: my 38 CDs, one file per.

Encoding resp. decoding times in second, all are file-on-SSD to NUL:
40.4   57.2   encode/decode HALAC -ufast
49.3   97.3   encode/decode HALAC -fast
63.9   105    encode/decode HALAC normal
66.9   207    encode/decode FLAC -0b2048 -ss --no-md5
93.4   220    encode/decode FLAC -4b2048 -ss --no-md5

Here instead of doing flac at -3 and -5, I went for the middle -4 instead. It uses the -M switch that "only every now and then" re-evaluates the stereo decorrelation strategy.

Times are median of three runs, except FLAC decoding are best of two. Quite stable time consumption, in contrast to what happens if I try to write files.

Thank you Porcus for the tests and the information. Yes, actually in my tests HALAC decode times are better. But we don't know exactly about ktf's system. But we can roughly say that it is faster than FLAC.

3rd Party Plugins - (fb2k) / Re: foo_uie_webview

Last post by mjm716 - Today at 19:02

You are just purposely argumentative and it's not an appealing characteristic whatsoever.

Quote from: mjm716 on Today at 16:28

existing in threads outside of FB which doesn't crash when shit goes bad

If you'd like to do something productive, why don't you review the chart data above and show a POC that any of them are even possible with your framework?

Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)

Last post by Hakan Abbas - Today at 18:58

Quote from: mycroft on Today at 15:10

Does HALAC use any predictions similar to TAK? Including advanced multi-channel correlation?

If I find recent papers about better predictions causing better compression ratios I gonna write another lossless audio codec

I don't know exactly how TAK works, I only have some preliminary knowledge about FLAC and SLAC. I want to proceed as much as possible without being bound and influenced by certain things. This way I can be more free.
I make normal use of the correlation between the channels, so there is no separate evaluation for each block. Because in normal stereo music the correlation between the channels remains the same in most cases throughout the music.
If we want to make something that works fast, we can't do many operations. For example, sorting, median, entropy, error correction, adaptive estimation, adaptive parameterisation, advanced/complex estimation.

Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)

Last post by Porcus - Today at 18:48

Tested encoding/decoding, both from file to NUL against FLAC in a a recent git build and checked roughly afterwards that it is faster than 1.4.2.
Compared to the results just posted by @ktf, HALAC outdoes FLAC at decoding in a much more pronounced way. The smaller differences at encoding could be because files are read from SSD, no RAM disk.

Corpus: my 38 CDs, one file per.

Encoding resp. decoding times in second, all are file-on-SSD to NUL:
40.4   57.2   encode/decode HALAC -ufast
49.3   97.3   encode/decode HALAC -fast
63.9   105    encode/decode HALAC normal
66.9   207    encode/decode FLAC -0b2048 -ss --no-md5
93.4   220    encode/decode FLAC -4b2048 -ss --no-md5

Here instead of doing flac at -3 and -5, I went for the middle -4 instead. It uses the -M switch that "only every now and then" re-evaluates the stereo decorrelation strategy.

Times are median of three runs, except FLAC decoding are best of two. Quite stable time consumption, in contrast to what happens if I try to write files.

Scientific Discussion / Re: AudioWorklet-based filter bank spectrum analyzer

Last post by TF3RDL - Today at 18:10

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?)

General - (fb2k) / Re: Title formatting/syntax for proper bitdepth

Last post by wojak - Today at 17:52

@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.

3rd Party Plugins - (fb2k) / Re: Wrapped-SMP

Last post by regor - Today at 17:48

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)

General - (fb2k) / Re: Info for equalizer

Last post by Air KEN - Today at 16:46

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%]

3rd Party Plugins - (fb2k) / Re: foo_uie_webview

Last post by regor - Today at 16:33

Quote from: mjm716 on Today at 16:28

Quote from: regor on Today at 16:18
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.

3rd Party Plugins - (fb2k) / Re: foo_uie_webview

Last post by mjm716 - Today at 16:28

Quote from: regor on Today at 16:18

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?

Notice