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: foo_quicksearch
Last post by NEMO7538 -
Hello,
With the very kind help from rtldg the quicksearch toolbar has been ported for compatibility with foobar version 2.0 and newer.
It can be downloaded as usual from foobar components repository and now contains 32 bits and 64 bits version.

As it is a new build, please report any issue or comment.
In particular we would appreciate a test with column UI if anyone is using it with the component.
2
General - (fb2k) / Re: "Undoing" AutoCapitilise ?
Last post by Case -
Quote from: KthugS on
Anyway, what happened 15 years ago that led to foorious being banned?
or will I automatically be banned if I simply don't visit for a long time?
I have no idea what foorious has done, but not posting does not get anyone banned.

Turning your account into a spam bot is a sure way to get banned. Breaking rules repeatedly and then not listening to moderation would probably also get someone banned. The stuff that has caused the banning to happen is most likely removed as it has been either illegal or just nonsense and waste of space.
3
Support - (fb2k) / Re: Foobar2000 v2.* playback sound quality lower than v1.X
Last post by mudlord -
Quote
It doesn't mean that my original statement regarding the v1/v2 differences is false!

Unlike other forums, these forums rely on scientific proof for claims. Just taking your word for there is quality differences is not enough. It has to be reproducible by other people and in a way that rules out imagining things. Thats what double blind tests are about.
5
Polls / Re: 2024 Format Poll [Lossy/Semi-Lossy]
Last post by 2012 -
* Lumping xHE-AAC/USAC with older AAC formats is not useful. USAC's story is separate even platform/decoder support wise.

* "use" is ambiguous.
  * Does consuming content with a codec considered use?
  * If yes, then we all probably consume (E-)AC3. And MP2 is quite alive in broadcast too, making @guruboolez objection to its inclusion off the mark.
  * IMHO, defining "use" as "encoding to" would be more useful, either here or in a separate poll.
7
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
ODD SMALL BLOCK SIZES (and a couple more normal-sized)

Because I didn't pay sufficient attention to my own testing, I ran something more - testing blocksizes that nobody wants to use. (Reason for that: make sure there is no partitioning for the residual, so there are no differences in that.)

Took the 219 minute CDDA .wav file and made 30 .flac files:
-0 and -5 at fifteen distinct block sizes, all odd numbers to be sure I didn't test different handling of partitioning.
Most are too low to be interesting! (Why? I'll explain at the end.)
17, 23, 31, 45, 65, 97, 147, 223, 341, 523, 803 <in between here is the -0 to -2 preset blocksize!> 1237, 1907, 2941 <in between here are the other presets> 4537 (ffmpeg uses the subset upper bound of 4608)

Those were encoded repeatedly using different FLAC releases (Xiph builds ... I hope I didn't get that wrong!). Timings for the -0b<N> and -5b<N>:

To the right end of both diagrams, you see that 1.4.3 has gotten rid of the slowdown around the 4096 blocksize, which is good because that is a default.



Then decoding. Note, here the flac versions are different! Because the results were a bit surprising, I dug up 1.3.1 too (a tinytiny bit slower than 1.3.4, I deleted the latter to get the number of curves down) and also 1.2.1. Omitted is also 1.4.2 which is as good as tied to 1.4.3. Kept in both the 32-bit and 64-bit version of 1.4.3 (it being the current release).
And here the block sizes are visible, I lost them from the encoding charts ...

1.3 is much faster at the small block sizes! At the very smallest, 17 samples, it decodes at at 22 seconds, 1.4 needs 40, 1.4 32-bit needs 60. That is a little bit of difference?!
The observation that 1.4.3 32-bit crosses 1.2.1 this way also indicates that something got lost since 1.3.

Note the difference between 64-bit builds is pretty much nothing at the reasonable block sizes. Don't overinterpret this
Imgur album: https://imgur.com/a/JDAccOD


* Comparison with ffmpeg - which spends bonkers amounts of time at small blocks - at https://hydrogenaud.io/index.php/topic,125791.msg1044102.html#msg1044102

* Why these block sizes? I tried the minimum block size over in that thread, and since ffmpeg did so horrible, I set out to check (1) where it would start to behave normal, and (2) what is then ... normal? Reference implementation for comparison. And then it turned out, differences between versions ... and a new run.


Corpus: I took twenty-one of the CDs in my signature (7 in each broad subdivision), the first ten and a half minute of each, merged to a 219 minute WAVE file.
Timing was done overnight with hyperfine, warmup + 5 runs with 30 seconds cooldown in between (ffmpeg last), and times are median of 5.

8
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
@bryant on WavPack:
Whether wvunpack --threads=<N> vs ffmpeg -threads=<N> is apples to apples ... I don't know. It might be "better" than comparing wvunpack --threads vs ffmpeg (spawning all), and all I could do was to get it down to thread count matters enough to tilt the numbers.


@ktf on FLAC:
Sure if we could just pick up some magic and speed up stuff. Anyway I made a mess out of it, first time I was not sure whether ffmpeg -threads 1 meant "single thread" or "one worker in addition to the bookkeping/parsing", so is part of my lame excuses.
But:
I got something that you could maybe speed up for: it seems 1.3.x does small blocks faster than 1.4.x. Since I got this wrong AND didn't stay completely consistent on which flac executable I used, I ran it together with a test to see when ffmpeg stops making a fool of itself (it was at block sizes below reference's -0/-1/-2, that is good):

What I did: explained over in the FLAC test thread: https://hydrogenaud.io/index.php/topic,123025.msg1044103.html#msg1044103 With more diagrams, including 1.2.1. And encoding.

Anyway, ffmpeg starts behaving "more normal" at "normal" block sizes.
For reference flac it might look surprising that -5 and -0 make so little difference. But most of the graph is for (too!) small block sizes, and apparently the time penalty for processing those, override the calculation job.




@mycroft :
"seditious" sounds like you just learned a new bad word and is waiting to use it ... couldn't you be constructive and educate instead?
For better or for worse, FLAC's design is frozen long ago, and for now it stays the biggest player in the lossless audio files market, at least disregarding silver discs.
But good that you actually contribute repairing bad code, and not only whine toxicity.
9
3rd Party Plugins - (fb2k) / Re: foo_enhanced_spectrum_analyzer
Last post by TF3RDL -
Quote from: TF3RDL on
@Crossover, what about non-power of two FFT sizes like 4800 samples (100ms at 48kHz samplerate)?
Feature request: Being able to set FFT size to specified length in milliseconds instead of samples as get_chunk_absolute() in fb2k SDK takes length in seconds rather than in samples

This makes the window length in seconds/milliseconds samplerate-independent when you set the unit for "FFT size" to milliseconds
10
Polls / Re: 2024 Format Poll [Lossy/Semi-Lossy]
Last post by guruboolez -
WavPack is missing. You should add it.
You should also remove VQF, Real Audio, SBC, Encodec, MP1 and MP2: they are nonsensical in 2024. If you really need to offer an exhaustive overview of vintage formats, check https://www.rarewares.org/rrw/programs.php and give to Mafuka a chance ;)
xHE-AAC is different from AAC (LC and HE), I would make a different entry for it.


EDIT: I would also remove WMA: 0 vote in 2016
https://hydrogenaud.io/index.php/topic,112400.0.html

EDIT2: there's already a 2024 lossy poll:
https://hydrogenaud.io/index.php/topic,125552.0.html