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
3
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by bryant -
* ffmpeg -threads 1 decodes nearly twice as fast as reference flac at -5, but several times slower at low block sizes
Of course I dove into that, because if FLAC can be twice as fast, that would be great! But I cannot reproduce, not on Linux nor Windows, not on SSD nor ramdisk. Can you check your results and see whether a different way of collecting times gives you the same result?
My results (see reply #7 above) show FFmpeg -threads 1 decoding right in between FLAC with md5 and FLAC without md5.

As Porcus mentioned, FFmpeg doesn't seem to pay attention to whether the FLAC file has an md5, but the question is whether it always calculates the sum (in which case it's faster than FLAC) or never does (in which case it's slower). My guess would be that it doesn't.

Single-threaded FFmpeg being slower than native WavPack could be explained by its lacking the ASM optimizations, which really don't make sense there for such a niche format (from a maintenance point of view).
5
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by ktf -
@ktf, of course there is nothing wrong with the file? The blame is squarely on ffmpeg?
I see nothing wrong with the file. Maybe the problem is that it consist of a single block?

* ffmpeg -threads 1 decodes nearly twice as fast as reference flac at -5, but several times slower at low block sizes
Of course I dove into that, because if FLAC can be twice as fast, that would be great! But I cannot reproduce, not on Linux nor Windows, not on SSD nor ramdisk. Can you check your results and see whether a different way of collecting times gives you the same result?
6
Opus / Re: Opus v1.5.2
Last post by Kraeved -
It's at least partly due to the LACE/noLACE postprocessing for low bitrate voice.

Low bitrate voice? It reminds me of this topic where we were looking for a way to compress 11025 Hz 16 bit mono file (history.wav) with speech and some music in the background. We started with 24 kbps, went down to 16 kbps, and ended with 12 kbps MP3 and AAC SBR, which sound not just intelligible, but satisfying. What can Opus offer here?
8
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by mudlord -
When my improvements are over, it can be a codec that everyone can use.

Yep. I tried explaining to Kraevad that sometimes up until that point, a project is not for everyone *or anyone* at all, and that its purely a prototype. Like I have some personal projects which still have things cooking or I don't feel are up to any sort of standard that I feel comfortable to be public, so things like widespread vectorization/threading or even GPU support are not there yet, so I stick to SSE4/AVX2/NEON/GL4.6 until that time comes, because I am more focused on getting things working *at all* rather than any semblance of widespread appeal.
10
Uploads - (fb2k) / Re: foo_converter.dll.cfg
Last post by marc2k3 -
Nope, you can't keep the old .cfg file with fb2k v2. As you've discovered, it will read data from these files if it finds them on startup but then nuke it when fb2k is closed.

It's quite possible you have other component .cfg files in your configuration folder and that's perfectly normal. When components are compatible with v1, they continue to use the old configuration files. Only components made exclusively for fb2k v2 have their settings saved in config.sqlite - and this obviously applies to foo_converter bundled with the latest versions.