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
Support - (fb2k) / Re: Resampler dbpoweramp/SSRC and RetroArch do not null, why?
Last post by Case -
I can't point you to any literature, sorry. I'm not sure if my terminology is correct. The samples have shifted a bit during processing while the sampling rate was still high, possibly because of some rounding error. Once that shifted signal is downsampled, the offset error gets transferred to the downsampled signal. Since the shift isn't large enough to be represented in full samples in the target sample rate, I called it subsample offset.
Below you'll see screenshots from 96 kHz source file downsampled to 48 kHz. It looks like the 96 kHz signal has shifted by one frame causing the 48 kHz version to have 0.5 frame offset compared to non-shifted downsample.
SSRC: X
SOX: X
2
3rd Party Plugins - (fb2k) / Re: External Tags
Last post by Case -
Quote from: Porcus on
It seems that external tags can not be preserved when renaming files outside fb2k - except maybe in ADS? Have I understood correctly that
* Using SQL: linked to file name, lost if file is moved or renamed
* folder.tags: contains file name, lost if file is moved or renamed, but can be recovered by editing the file
* .tag file. Has same name as the media file, can be recovered by copying the filename manually
Alternate Data Stream is kept along with the file by the OS when possible. As long as the track stays on a file system where it's supported, it will follow the file. At least when using Explorer.
SQLite format is quite simple. There are tables for art and tags. You can use any SQLite browser to open the database and correct the path in the tables.
External APE tag is easy to manually repair too. Just rename or copy the file over.
Folder tag is the only one that isn't easy to manually alter.

Quote from: Porcus on
But there has been this issue that foo_renamer does not rename over the .tag file if renaming also changes directory
I recall I improved things with foo_renamer. Have you still had issues?

Quote from: gadgetogogo on
Is this possible with external tags or not at all ? I am using the SQLite database, if that matters.
Unfortunately the native Properties dialog doesn't call any of the External Tags component's code when it detects the referenced file is missing. Otherwise your idea should work in theory.
3
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.
4
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.
5
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.
7
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.
9
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.

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