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
3rd Party Plugins - (fb2k) / Re: [COMPONENT REQUESTS] Vectorscope (X/Y oscilloscope) and Enhanced Oscilloscope
Last post by pqyt -
Quote from: TF3RDL on
Do anyone (especially foobar2000 component developers like @pqyt) have interests on making a vectorscope component? Since @Crossover (author of foo_enhanced_spectrum_analyzer and foo_loudness_peakmeter) is probably busy with other stuffs (if my assumption of he is making both components I've wanted is false)

Also, as for the vectorscope component, I'd imagine that it optionally have phase correlation and stereo balance metering bars integrated into it, and as for the better oscilloscope component I've wanted to see, I'd like to see multiple triggering modes (e.g. zero-crossing, spectral, and envelope-based triggering) for stabilized display of audio wave shape as well as Mid/Side representations
@TF3RDL ,

I'll have a go at it when I have more time and when the updates for my other components are ready.
2
foobar2000 mobile / Re: Gapless broken on Android
Last post by magicgoose -
Quote from: lostgirl22 on
If I copy an album from the SD card to the internal memory, gapless works correctly with no gaps between tracks. I am not an Android developer, but this suggests to me that my theory about SD card read accesses taking longer on Android 13/14 than they used to may be correct. But if so I'm amazed no one else has noticed. Maybe I'm the only one who cares about gapless who still wants to use SD cards on a new phone!

Could the devs at least try reading ahead the next track slightly earlier, as I think this would solve the problem? Or allow the read-ahead time to be increased in the advanced settings in the app?
Works fine for me on A 14 and I do care about gapless (a lot).
Maybe it helps that it's LineageOS, they provide updates more often (every week) and do not include bloatware.
I checked, sadly seems like it's not available for Moto G73. Maybe eventually someone will make it happen though? If the phone is not too locked down to begin with.
3
3rd Party Plugins - (fb2k) / Re: foo_vis_milk2
Last post by Pixel8tor -
Hi oops,

First, thanks for allowing a smaller docked window size - it looks much better with my layout.

Anyway, it seems the border issue is a FB2K issue! After your question, "Do you see the same in other visualizations? ", I tried other visualizations and they all show the same issue. So it must be FB2K causing the problem, right? I suspect the icon issue is also a FB2K issue. None of these issues are in the 32bit version of FB2K. Something was changed!

I started a new thread for this: https://hydrogenaud.io/index.php/topic,126586.0.html

Thanks for looking into this. Take care.



https://hydrogenaud.io/index.php/topic,126586.0.html
4
3rd Party Plugins - (fb2k) / Re: foo_vis_milk2
Last post by A_Man_Eating_Duck -
Thank you for all you efforts in building this plugin.

Is it possible to have foo_vis_milk2 running full screen on 1 monitor while I'm using another monitor? Currently when I have foo_vis_milk2 running full screen on my left monitor, the instant I click anywhere on the right monitor it will jump out of full screen mode back to windowed.

I have also noticed that version 0.0.299-alpha crashes a lot for me, usually within the first few minutes of using it. Could it be that the preset\texture pack I'm using is too big (2.5GB+)?

The crash logs goes to the Foobar200 developer if i submit them, should I be attaching them in this thread instead?
5
Support - (fb2k) / FB2K 64bit Visualizations on multi-monitor system full screen frame/border bug
Last post by Pixel8tor -
My system: dual monitor, desktop set to "Extend", FB2k 2.15 - 64bit

If I maximize a visualization, by double-clicking on its docked window. It looks good full screen, but a window frame appears. And if I press [win+shift+right], or [win+shift+left], to move it between monitors, it shows the window border. Does anyone else see this behavior? Maybe the maximized window style needs to be changed to no frame or border? Or the origin changed? Hope you can figure it out.

This doesn't happen with the 32bit version of FB2K 2.15. No borders, and the visualization looks good full screen on either monitor.

Here are a couple of screen grabs to show what's happening. The first is a visualization running full screen on monitor A. You can see the window border on both the top and left sides.The second is of my desktop screen (the green color is my desktop) with the edge of the visualization overflowing on the extreme left.

Thanks for taking a look into this.

P.S. I also noticed with the "Spectrum Analyzer" visualization, in full screen mode, the album art shows *sometimes* even when "Show artwork on background" is unchecked.

XX
7
Scientific Discussion / Re: One updated and one new audio processing DSP library
Last post by bryant -
Quote from: bennetng on
OK found a way to improve the quality. Change sum to double in resampler.c
Code: [Select]
#if 1   // Version 1 (canonical)
static double apply_filter (float *A, float *B, int num_taps)
{
    float sum = 0.0;
Yes, that makes sense. I use this library on Raspberry Pi's and I'm concerned that using doubles for that math might slow things down too much, but I don't remember trying. I just assumed that sticking to 32-bit floats is appropriate for embedded applications, especially since we're talking noise levels far below any reasonable requirements. If it ends up being "free" though I would change that. Thanks!
8
Scientific Discussion / Re: One updated and one new audio processing DSP library
Last post by bryant -
Haha, well I wrote something offline before reading the excellent response from @danadam , but I'll still post what I wrote.

As for the C language issue, sorry about that! I normally only use dynamically allocated arrays when I’m developing because it’s so easy and intuitive and then “fix” it later so people won’t scream at me. It actually is required in C99 but Microsoft is well known for ignoring parts of standards they don’t agree with.

You can just replace the “num_channels” with the maximum number of channels you’ll ever use. If you go beyond that accidentally you would probably get a crash (and certainly bad results) but using fewer channels is fine (it just wastes a little stack space).

As for the increased noise with longer filters, I'm not really too surprised. Everything is done in 32-bit floats (including the filter coefficients) and each operation adds a little random rounding noise, and I think that’s where that noise floor comes from. As you know, the primary purpose of those longer filters is to improve the transition band slope, which continues to improve significantly beyond 300 taps. It looks like that might raise the noise floor, but that’s not something I look at too closely (other than to make sure it doesn’t show anything “funny”).

It’s also interesting that the Infinite Wave tests don’t show the same thing. This is a comparison of preset 4 with preset 3 (which has 256 taps) and the results are identical, if not slightly better at preset 4.

Thanks for pointing this out though. Next time I’m working on that I’ll see if anything pops out. I’m actually thinking of adding more noise-shaping options for decimation (including the ATH filters from @SebastianG described in his excellent Wiki article) and moving decimation into the library also so it's more easily used, so it might not be too long.
10
foobar2000 mobile / Re: Gapless broken on Android
Last post by lostgirl22 -
Quote from: MotleyG on
Quote from: lostgirl22 on
If I copy an album from the SD card to the internal memory, gapless works correctly with no gaps between tracks. I am not an Android developer, but this suggests to me that my theory about SD card read accesses taking longer on Android 13/14 than they used to may be correct. But if so I'm amazed no one else has noticed. Maybe I'm the only one who cares about gapless who still wants to use SD cards on a new phone!

Could the devs at least try reading ahead the next track slightly earlier, as I think this would solve the problem? Or allow the read-ahead time to be increased in the advanced settings in the app?
I have no issues with gapless on my older DAP, iBasso DX160 running Android 8.1. However what you have described is likely an issue Google introduced with the SAF requirements. Perhaps some sort of read ahead as you mention can help but not sure if this is the best solution for these newer devices.

I'm not sure I follow you. What other solution is there? If Google have changed something, I doubt they will change it back. So the only option is to change foobar2000 to make it work again, otherwise, as more people (unwillingly, in my case!) upgrade their phones, it will eventually stop working for everyone.

I'm assuming (and, as I said, I'm not an Android developer!) that there is some degree of read-ahead already, as surely gapless would be impossible if the app literally waits until one file is completely finished before demanding the next. So I was just proposing increasing it a tiny bit because accesses seem to take slightly longer than they used to. Maybe I'm being simplistic?