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.
Last post by Kamedo2 -
TSAC: Very Low Bitrate Audio Compression was updated from tsac-2024-04-08-win64.zip to tsac-2024-05-08-win64.zip. I thought it could be a typo, but the hashes didn't match in libnc.dll, libnc_cuda.dll, readme.txt (just an addition of a sentence "The CPU +must support the AVX2 instruction set in order to run the program.") and tsac.exe, so it is a new version.
the artist flags will be displayed if you have tagged your music files with %artistcountry% in the lower bar and also use it in the Biography. If there is no %artistcountry% metadata, no flag will be displayed in the lower bar, but it will use the Wikipedia metadata ( if available ) in the Biography.
To add additional tags in the "More Tags:" section in the lookup menu of the biography, open your "foobar2000\profile\cache\biography\biography.cfg" and go to the bottom and find these:
I would advise to not add the instruments in the performer because of compatibility issues with not only foobar but also other software when doing a query search on this metadata field. As you mentioned, it will not recognize and ignore the parentheses or brackets. Although this could be done with additional title format pattern throughout library, biography and other parts, but imo it is not recommended.
Last post by maikmerten -
Thanks for these fresh builds!
I feel like in the not-too-distant future, I should merge dev to main and tag a new release. The console speed increases, the downsampling fixes and the somewhat reworked help might warrant a new version.
(I've been doing things on on the dev branch to avoid burning through versions numbers too quickly.)
Last post by Klymins - @mycroft First answer: This does not change anything, noise shaping still can't push the noise into the inaudible frequencies at these lower sampling rates because they are above the Nyquist limit.
However, I am almost convinced that this is not a personal mistake. Every time I access foobar2000 directly from File Explorer (Windows 10 x64) where a certain directory contains more than 15 songs, the player does not open to play the files. To do so, I open a directory and click on the "Play all" command in File Explorer. Any directory with up to 15 tracks this command works correctly.
Last post by Porcus -
A little bit of testing, although the algorithm itself isn't changing. But over the years, some codecs have been upgraded.
What I did: Took 219 minutes (first ten and a half minutes of each of 7+7+7 albums from my signature), processed with lossywav -C, compressed both original, lossy and correction file at various settings. Tested in particular block size 1024 just to see whether the penalty is severe. Re-did FLAC with 1.4.3 beta "d". Included WavPack even if that has its own hybrid mode which is easier to manage.
CDDA, all numbers in kbit/s or differences thereof. * lossless, no block size set: Because if you don't want to use LossyWAV, you don't want to fiddle with that switch. *"corr., def" is the correction file but compressed without imposing block size. That gives slightly better results. It is commented on. * "cost of two files": Difference between sum of the lossy (with block size set) and correction (without) - and lossless (without).
.
lossless, no block size set
cost of two files
lossy
corr., def.
wav
1411
1411
1411
1411
WMAL
778
196
487
487
WavPack, 512
with --merge-blocks. Virtually no penalty for double block size. 4 to 7 kbit/s penalty for storing correction file with same setting
fast
779
128
473
434
default
760
122
458
424
-hx
748
123
455
416
-hhx4
743
115
447
411
Multi-threaded -hhx6 shaves 1 off the lossy.
FLAC, 512
-0b512
841
84
486
439
Double blocksize penalty: 12
-2eb512
799
97
459
437
Double blocksize penalty: 11
-5b512
756
98
432
423
Double blocksize penalty: 5. 8 kbit/s penalty for storing correction file with same setting
-8pb512
751
99
429
421
Double blocksize penalty: 6. 8 kbit/s penalty for storing correction file with same setting
TAK, 512
-p0 -fsl512
756
77
427
406
Double blocksize penalty: 8. 12 kbit/s penalty for storing correction file with same setting
-p2 -fsl512
734
86
418
402
Double blocksize penalty: 4. 16 kbit/s penalty for storing correction file with same setting
-p4m -fsl512
721
93
414
400
Double blocksize penalty: 4. 17 kbit/s penalty for storing correction file with same setting
ALS
-l -n512
751
75
411
415
Double blocksize penalty: 13. 4 kbit/s penalty for storing correction file with same setting
-7 -p -l -n512
719
87
407
399
Better use double blocksize! 8 kbit/s penalty for storing correction file with same setting
-7 -p -l -n1024 (!)
719
399
Going out on a limb, it should be no surprise from what one already knew about that TAK that it could be the codec of choice for LossyWAV: * Compresses impressively * Downsides of TAK less applicable to LossyWAV users: they know what they are doing, so they could likely handle TAK too - and find a player that supports it. * TAK natively supports RIFF chunks, no issues about remembering the foreign metadata switch in FLAC * ... so does WavPack, but WavPack users would likely rather use the format's own hybrid.
A couple of remarks on other codecs * Interestingly, but hardly not anything recommended due to speed: The ALS -7 -p setting does better with block size 1024. I guess it does some optimization under the hood, you should get something out of waiting for this ridiculous amount of time. * FLAC roundoffs could be affected by inconsistent padding since I ran the lossy+correction parts afterwards, having upgraded to beta 1.4.3d * From this one could doubt that WMAL is "LossyWAV compatible" - it is, it is just a bad performer overall. Next table shows that the two-file penalty is less than for OptimFROG.
For reference, the following uses LossyWAV as one should absolutely not do it: Included codecs that don't use wasted bits; No block size options applied - except I did apply -z3 -7 -l -p -n512 for the ALS RLSMS mode which apparently does not honour it (and shouldn't be used for anything either).
.
lossless
cost of two files
lossy
wav
1411
1411
1411
cuetools ALAC
761
430
772
Monkey’s extra high
721
446
739
ALS RLSMS with everything
713
438
733
OptimFROG default
724
264
600
WMAL
778
196
487
WavPack default
760
199
535
FLAC default
756
143
476
TAK default
734
139
472
ALS default
751
108
444
ALS -7 -p -l
719
86
406
Here, all three columns are same setting, and "cost of two files" is also difference between apples and apples.
Last post by forart.eu -
(@Admins: since has not been approved as news, this is the normal discussion version of the post)
Sounds more like a "wannabe" than a working project, but some (Archivist Licensed) source code seems available:
Quote
Fourier Analogue-in-Digital is an uncompressed codec like WAV or AIFF rather than FLAC or ALAC. Unlike WAV or AIFF, which store PCM, FrAD stores energy density per frequency.
FrAD is a codec that nobody owns, nobody patents, and is standardised in so much detail that anyone can easily implement it in any language, even if the original implementation is lost. It also supports tags, cover art, and sequential search, and the original implementation can be supported by any OS on any machine that supports Python.
The main difference between any other formats and FrAD is its resilience to corruption and robustness. For many audio files that are branched fron PCM, even a flip of a bit or two can result in popping noise, failure to play the corrupted frame, or even the loss of all subsequent audio information. FrAD, however, provides robust error recovery such that sporadic flipping of a few bytes is not even a concern.