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
21
Support - (fb2k) / Re: foobar2000 for Mac: bugs & wishes
Last post by ukg123 -
Thanks so much for the latest update, having the library on the side is a game changer.

One major bug from my side is regular buffering/stuttering when playing FLAC files from my NAS (every minute or so). This issue only happens with foobar, the same files from the same NAS play fine on Cog and VLC. This was a known issue with VLC and they patched it relatively recently. Would be great to have this addressed.
23
Uploads - (fb2k) / Re: foo_dsp_lowpass plugin
Last post by Case -
Attached is a version with fixes to Default button and channel mask retaining. And added features are dark mode and 64-bit foobar2000 support.
24
General - (fb2k) / Re: UPnP MediaRenderer output | discussion
Last post by SimBun -
Quote from: Acell on
I face no issue when I stream by an App on my smartphone (Atoll's one or BubbleUPnP ) from my NAS or from Foobar2000 Audio server (or MinimServer).
When using BubbleUPnP (or the Atoll app) to control playback, the controller sends the renderer (the Atoll) metadata about the resource it wants to play, which includes not only your tag metadata (album, artist e.t.c.) but also the URL of the track to play and any associated artwork. As the Atoll approaches the end of the current track it requests the next track from the controller and the cycle continues with new metadata being sent.

UPnP MediaRenderer doesn't send tracks, it sends foobar's output as a single audio stream (to the Atoll it's one very long track), so there's no way to provide updated metadata.

Quote from: Acell on
My issue is when I want to use Foobar2000 on my PC, to take advantage of its huge potential for sorting my around 10 000 albums, that not allows Smartphone's App.
Whilst it's not as flexible as foobar MinimServer is very configurable. What is it you find lacking?
26
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
FLAC: BLUNT BLUNDER on me  :-[

@korth as mod: I don't want to "shield myself against my own mistakes" here, but if you think it is OK - it being on a previous page with misleading numbers right in user's face - would you maybe please moderate in an extra first line in Reply #13 like e.g. the follows:
Mod note: Porcus facepalms and suggests to read Reply #28 for correction


Anyway, after having tried ffmpeg -threads this and that and around, I found the mistake not in the ffmpeg command, but in the flac command. It is even in the codebox, where flac was run with options -fo NUL ... without "-d". So it spendt time re-encoding to FLAC. Thank you to @ktf for spotting the anomaly.

Here are some hopefully more sane numbers, where reference FLAC (1.4.2 was used ... for dumb reasons) beating ffmpeg -threads 1.
Decoding times on SSD to NUL, the 1.060 seconds means 1774x real-time

Encoded with -0b65535 --no-md5 --lax
 1.060 s ±  0.009 s    flac (1.4.2)
 1.278 s ±  0.008 s    ffmpeg -threads 1
 0.842 s ±  0.007 s    ffmpeg -threads 2
 0.591 s ±  0.030 s    ffmpeg -threads 3
 0.522 s ±  0.010 s    ffmpeg -threads 4
 0.506 s ±  0.012 s    ffmpeg -threads 6
 0.538 s ±  0.007 s    ffmpeg, default threads (detects all eight)
 
Encoded with -0r0 --no-md5, reference FLAC single-threaded beats ffmpeg -threads 3
 1.144 s ±  0.015 s    flac (1.4.2)
 1.799 s ±  0.005 s    ffmpeg -threads 1
 1.642 s ±  0.005 s    ffmpeg -threads 2
 1.163 s ±  0.007 s    ffmpeg -threads 3
 0.998 s ±  0.014 s    ffmpeg -threads 4
 0.981 s ±  0.015 s    ffmpeg -threads 6
 1.019 s ±  0.012 s    ffmpeg, default
 
Encoded with default -5   
 1.552 s ±  0.011 s    flac (1.4.2)
 1.967 s ±  0.006 s    ffmpeg -threads 1
 1.290 s ±  0.012 s    ffmpeg -threads 2
 0.899 s ±  0.008 s    ffmpeg -threads 3
 0.725 s ±  0.003 s    ffmpeg -threads 4
 0.654 s ±  0.052 s    ffmpeg -threads 6
 0.619 s ±  0.006 s    ffmpeg, default
 
Encoded with -8pl32 -r8 --lax
 2.056 s ±  0.019 s    flac (1.4.2)
 2.818 s ±  0.006 s    ffmpeg -threads 1
 1.746 s ±  0.029 s    ffmpeg -threads 2
 1.227 s ±  0.021 s    ffmpeg -threads 3
 1.038 s ±  0.003 s    ffmpeg -threads 4
 0.784 s ±  0.004 s    ffmpeg -threads 6
 0.739 s ±  0.013 s    ffmpeg, default
 
Encoded with -8b16
 5.476 s ±  0.034 s    flac (1.4.2)
24.328 s ±  0.186 s    ffmpeg -threads 1 <------- ooh bad
61.104 s ±  0.582 s    ffmpeg -threads 2 <------- and the "even worse" starts already here!
61.290 s ±  0.501 s    ffmpeg -threads 3
60.371 s ±  0.438 s    ffmpeg -threads 4
60.236 s ±  0.709 s    ffmpeg -threads 6
61.878 s ±  0.492 s    ffmpeg, default

There is not much gained above 4 threads (this is a 4-core 8-thread CPU) except the 8pl32-etc. file.

Commands given:
flac <file> -ss -dfo NUL
ffmpeg -threads <T> -i <file> -hide_banner -loglevel error -f wav -y NUL
27
WavPack / Re: -h as the new default mode
Last post by Porcus -
@Kraeved :
Old code snippets die hard - for example for Monkey's Audio (Ashland develops for JRiver), the last available chm help file had a screen where there was no "Insane", before it was removed as outdated in 2022 ...
And JRiver was first released in, *looks up*, 1998 - before FLAC.
FLAC -6? At 0.x , -6 was the default. Could have stuck.
Not recommending -hh? The WavPack manual still warns against it for legacy hardware players. There were some Rockbox'ed hardware players where -h would decode slower than Monkey's Fast, although -hh decodes lighter than any Monkey on desktop.

28
3rd Party Plugins - (fb2k) / Re: foo_vis_spectrum_analyzer
Last post by TF3RDL -
Quote from: pqyt on
- Vertical scrolling spectogram, aligned with the bars of the spectrum analysis on top.
Finally, a sneak peek of combined spectrum/spectrogram visualization, which is I want for @Crossover's Enhanced Spectrum analyzer component

Quote from: pqyt on
- Left/Right and Mid/Side level meters with configurable channel pair.
BTW, this makes me want more Mid/Side visualizations (e.g. a Mid/Side peak/RMS meter and a M/S spectrum analyzer)