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.
* As for running quiet: hyperfine suppresses console output, and a bit of non-rigorous testing indicates that running quiet doesn't matter for ffmpeg when tested by hyperfine (it could matter in real-life ...). But wvunpack runs the percent progress in the window's title bar, and hyperfine does not suppress that!
flac then. @ktf : * I will re-run when I am back at the same computer. The chance for human error is certainly positive - like, copy + paste suddenly overwrote something in a spreadsheet. I haven't automated this. * The files that ffmpeg reject are not about only being one frame - the 6ch (subset!) file I posted at https://hydrogenaud.io/index.php/topic,125848 is a full second. What happened to the attachment posted in this thread was that I traversed the possible -b's and found where the trouble started - then I cut the source down to the precise number of samples to see if "single frame" would still trigger it. Of course, I carelessly posted the last file created. * Question: it seems that reference flac omits MD5 calculation from -t and -d if the file has no MD5 in STREAMINFO? But there is no way to force it not to otherwise?
Last post by Porcus - WavPack again. Only .wv in this post. wvunpack and ffmpeg
-z0q and time. Does console output slow it down? TL;DR: -vv is so fast that one can argue that yes it does.
An initial test wasn't dramatic: hyperfine on single untagged -f-encoded file indicated a cost of 0.05 seconds on decoding to NUL and 0.02 seconds for fast verify. But, then. Since there is only wvunpack against itself to test on this matter, and it supports wildcards, I took two actual albums, with tags and all, in separate tracks, on a spinning drive: one full CD 75 minutes of Bach's organ works, 652 kbit/s using, 28 tracks/files. Black Sabbath s/t, 38:14, a CD split in 7 tracks/files, 903 kbit/s. Both using -x6.
Fast verification: -qz0 is significantly faster, in percents. 0.1 seconds isn't much though, but if one has a full TB of CDs (like 3000 of them), it will add up to a few minutes. 25 runs with two seconds sleep in between: wvunpack *.wv -vv -qz0: 304 ms on Bach and 187 ms on Black Sabbath wvunpack *.wv -vv : increases by 103 ms (36 percent) resp. 81 ms (46 percent)
Decoding to -o - > NUL: Since that takes more time, the percentages aren't that impressive of course. The differences in time look suspicious to be honest, but 19 runs and not too outrageous standard deviations: wvunpack *.wv -z0qy -o - > NUL : 9.265 s ± 0.024 s resp. 4.917 s ± 0.025 s wvunpack *.wv -yo - > NUL : 9.698 s ± 0.032 s resp. 5.039 s ± 0.013 s Writing to the same spinning drive would bring it to 30 or 15 seconds, and that kinda sets the perspective. But the fast decoding is now so fast that it seems that reporting the progress makes for something if one is scanning
Decoding speeds again. Tested more multithreading. TL;DR: wvunpack --threads=<N> beats ffmpeg -threads <N> at decoding - with one exception where block size was forced to maximum.
I did the "shorter" half-hour file. Commands were like the following: ffmpeg -threads 8 -i ¨3x.wv.-fx0.wv -hide_banner -loglevel error -f wav -y NUL .\wvunpack --threads=8 ¨3x.wv.-fx0.wv -z0qyo -o - > NUL the latter being the fastest. -fx0 in the filename because that option (it means -f ; -x0 in new releases means "no x", that is good for FOR looping). And yes there are two "o" options because I didn't spot it, but wvunpack didn't object.
Times first, mean ± stdev - having sorted the output by the .wv file and then by speed, fastest at top:
A couple of remarks: * I ran ffmpeg and wvunpack alternating with the same threads count, so that none of them should be disadvantaged over the CPU having just reacted to something (throttling or whatever). To make sure, I ran it twice: once with ffmpeg then wvunpack, once with wvunpack then ffmpeg. Very small differences. * What I didn't think of ... because I am normally juggling a few versions of encoders, I the current wvunpack.exe to the same directory - it shouldn't make for a time advantage?! Maybe fix PATH next time.
WavPack -vv fast verification redux: TL;DR: Put the --threads differences down on my system not being more consistent than the data below ... arguably, less consistent.
In case anyone is interested, I dump the hyperfine output in here. Same files. Ran with and without threads (and a couple extra to check for inconsistencies, not included; one was off, but betrayed by a high stdev).
USB3 spinning drive. Fastest was 105.1 ms ± 2.8 ms
* 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).
* 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?
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?
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.