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
2
General - (fb2k) / Re: Lame Settings for Foobar Conversion, CBR 128
Last post by Apesbrain -
Then I guess the only important part here:
Code: [Select]
-S --noreplaygain -b 128 - %d
is the "-b 128" right?
Well, some of those other parts are important as the conversion won't run without them. But, yes, you've got the idea.

The bitrate options are CBR, ABR (rarely used), and VBR:
https://timothygu.me/lame/usage.html

For playback in the car, I typically encode to -V4.
3
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
I tested FLAC in containers. Not CAF, I forgot about that one. With and without multithreading ffmpeg. This time I tried a shorter file - half an hour - because there were so many to run through.
With quite extreme settings, including blocksize 16 - that malice paid off ...
Turns out ffmpeg refused to remux the uncompressed flac streams into any of the three containers I tried.

Container overhead
* flac -5 is a sane setting, and the biggest overhead for that one was 0.44 percent (not percentage points) for OGG container
* Blocksize 16 is just nuts, but for what the file sizes are worth - .wav in the middle. No padding:
323 001 659 ¨3x.flac-8b16.flac
328 733 400 ¨3x.flac-8b16.flac.oga
331 702 604 ¨3x.wav
343 738 725 ¨3x.flac-8b16.flac.mp4
354 113 911 ¨3x.flac-8b16.flac.mka
9.6 percent penalty for putting it in Matroska. I used ffmpeg, comments like ffmpeg -i ¨3x.flac-8b16.flac -acodec copy -vn -sn ¨3x.flac-8b16.flac.mka


For sorting I moved the ".oga" etc. to a separate column. ¨3x.flac-5.flac <tab> .oga means the file is an OGG containered ¨3x.flac-5.flac.oga .  (The reason for the "¨" is to make sure the test audio files had a character nothing else had.)
Threadsdecodersettings on encodingcontainerspeed x realtimecomment
1flac.exe¨3x.flac-0b65535--no-md5--uncompressed.flac500
1ffmpeg¨3x.flac-0b65535--no-md5--uncompressed.flac8791That is extreme!
7ffmpeg¨3x.flac-0b65535--no-md5--uncompressed.flac8685
1flac.exe¨3x.flac-0b65535--no-md5.flac527
1ffmpeg¨3x.flac-0b65535--no-md5.flac1474about same for containers
7ffmpeg¨3x.flac-0b65535--no-md5.flac3544slower than containers
7ffmpeg¨3x.flac-0b65535--no-md5.flac.oga4919
7ffmpeg¨3x.flac-0b65535--no-md5.flac.mp46013mp4 very fast
7ffmpeg¨3x.flac-0b65535--no-md5.flac.mka5932
1flac.exe¨3x.flac-0r0--no-md5.flac518
1ffmpeg¨3x.flac-0r0--no-md5.flac1049about same for containers
7ffmpeg¨3x.flac-0r0--no-md5.flac1869containers are only slightly faster.
7ffmpeg¨3x.flac-0r0--no-md5.flac.oga1879
7ffmpeg¨3x.flac-0r0--no-md5.flac.mp41918
7ffmpeg¨3x.flac-0r0--no-md5.flac.mka1924Not that much faster
1flac.exe¨3x.flac-5.flac518
1ffmpeg¨3x.flac-5.flac966about same for containers
7ffmpeg¨3x.flac-5.flac2981
7ffmpeg¨3x.flac-5.flac.oga3600noticeably faster in all containers
7ffmpeg¨3x.flac-5.flac.mp43827
7ffmpeg¨3x.flac-5.flac.mka3854
1flac.exe¨3x.flac-8b16.flac247
1ffmpeg¨3x.flac-8b16.flac80about as slow for containers
7ffmpeg¨3x.flac-8b16.flac31Even slower! And about as slow for containers
1ffmpeg¨3x.flac-8pr8--lax-l32.flac669about the same for containers. Forgot to run flac.exe on this one.
7ffmpeg¨3x.flac-8pr8--lax-l32.flac2493
7ffmpeg¨3x.flac-8pr8--lax-l32.flac.oga2599
7ffmpeg¨3x.flac-8pr8--lax-l32.flac.mp42631
7ffmpeg¨3x.flac-8pr8--lax-l32.flac.mka2642
I am not sure how ffmpeg -threads 1 works, if I should use "0" to get single-threaded? Because it does decode much quicker than reference flac. I also did ffmpeg decoded without -threads command, that uses all 8, and that would improve the flac-in-other-containers slightly (but harm wavpack slightly, I leave that for a separate post).

So table does not list speed for ffmpeg without -threads, nor for the following:
* the same entire thing ran on USB3-connected spinning drive. Differences were just very minor. These figures are on internal SSD.
* reference flac.exe decoding -8pr8 --lax -l32 because human error
* ogg/mp4/mkv decoded with ffmpeg -threads 1, those were pretty much the same as .flac speeds
* same for the -8b16 in containers, those were just as horrible as .flac
Yes blocksize 16 decodes slow, but ffmpeg just does it terribly.

All ffmpeg had a "-hide_banner -loglevel error" but I don't know if that matters when hyperfine doesn't display it.

I also went the other way with a bigger file, 219 minutes. No fancy table formatting here, I just paste hyperfine output. No containers tested that time. Fastest decoding took 1.054 seconds, and then:
Code: [Select]
Summary
  ffmpeg -i ¨219min.flac-0b65535--no-md5--uncompressed.flac -hide_banner -loglevel error -f wav -y NUL  ran
    1.02 ± 0.02 times faster than ffmpeg -threads 1 -i ¨219min.flac-0b65535--no-md5--uncompressed.flac -hide_banner -loglevel error -f wav -y NUL
    1.04 ± 0.02 times faster than ffmpeg -threads 7 -i ¨219min.flac-0b65535--no-md5--uncompressed.flac -hide_banner -loglevel error -f wav -y NUL
    2.80 ± 0.04 times faster than ffmpeg -threads 7 -i ¨219min.flac-0b65535--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
    2.83 ± 0.16 times faster than ffmpeg -i ¨219min.flac-0b65535--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
    4.07 ± 0.06 times faster than ffmpeg -i ¨219min.flac-7--lax-l32.flac -hide_banner -loglevel error -f wav -y NUL
    4.19 ± 0.08 times faster than ffmpeg -threads 7 -i ¨219min.flac-7--lax-l32.flac -hide_banner -loglevel error -f wav -y NUL
    6.09 ± 0.08 times faster than .\wvunpack --threads=7 ¨219min.wv.-fx0.wv -z0qyo -o - > NUL
    6.26 ± 0.09 times faster than ffmpeg -threads 7 -i ¨219min.flac-0r0--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
    6.33 ± 0.18 times faster than ffmpeg -i ¨219min.flac-0r0--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
    6.58 ± 0.15 times faster than ffmpeg -i ¨219min.wv.-fx0.wv -hide_banner -loglevel error -f wav -y NUL
    6.86 ± 0.12 times faster than ffmpeg -threads 7 -i ¨219min.wv.-fx0.wv -hide_banner -loglevel error -f wav -y NUL
    7.21 ± 0.09 times faster than .\wvunpack --threads=7 ¨219min.wv.-gx1--blocksize=4096.wv -z0qyo -o - > NUL
    7.42 ± 0.10 times faster than .\wvunpack --threads=7 ¨219min.wv.-gx1.wv -z0qyo -o - > NUL
    7.99 ± 0.11 times faster than ffmpeg -threads 1 -i ¨219min.flac-0b65535--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
    8.37 ± 0.25 times faster than ffmpeg -i ¨219min.wv.-gx1.wv -hide_banner -loglevel error -f wav -y NUL
    8.58 ± 0.15 times faster than .\wvunpack --threads=4 ¨219min.wv.-fx0.wv -z0qyo -o - > NUL
    8.71 ± 0.12 times faster than ffmpeg -threads 7 -i ¨219min.wv.-gx1.wv -hide_banner -loglevel error -f wav -y NUL
    8.78 ± 0.16 times faster than ffmpeg -i ¨219min.wv.-gx1--blocksize=4096.wv -hide_banner -loglevel error -f wav -y NUL
    9.34 ± 0.14 times faster than ffmpeg -threads 7 -i ¨219min.wv.-gx1--blocksize=4096.wv -hide_banner -loglevel error -f wav -y NUL
    9.93 ± 0.49 times faster than .\wvunpack --threads=4 ¨219min.wv.-gx1--blocksize=4096.wv -z0qyo -o - > NUL
   10.18 ± 0.13 times faster than .\wvunpack --threads=7 ¨219min.wv.-hx2.wv -z0qyo -o - > NUL
   10.46 ± 0.21 times faster than .\wvunpack --threads=4 ¨219min.wv.-gx1.wv -z0qyo -o - > NUL
   11.34 ± 0.15 times faster than ffmpeg -threads 1 -i ¨219min.flac-0r0--no-md5.flac -hide_banner -loglevel error -f wav -y NUL
   11.50 ± 0.16 times faster than ffmpeg -i ¨219min.wv.-hx2.wv -hide_banner -loglevel error -f wav -y NUL
   12.21 ± 0.16 times faster than ffmpeg -threads 7 -i ¨219min.wv.-hx2.wv -hide_banner -loglevel error -f wav -y NUL
   12.99 ± 0.17 times faster than .\wvunpack --threads=7 ¨219min.wv.-hhx3.wv -z0qyo -o - > NUL
   14.02 ± 0.19 times faster than .\wvunpack --threads=4 ¨219min.wv.-hx2.wv -z0qyo -o - > NUL
   14.68 ± 0.19 times faster than ffmpeg -i ¨219min.wv.-hhx4--blocksize=131072.wv -hide_banner -loglevel error -f wav -y NUL
   15.45 ± 0.21 times faster than ffmpeg -i ¨219min.wv.-hhx3.wv -hide_banner -loglevel error -f wav -y NUL
   15.53 ± 0.21 times faster than ffmpeg -threads 7 -i ¨219min.wv.-hhx4--blocksize=131072.wv -hide_banner -loglevel error -f wav -y NUL
   16.35 ± 0.22 times faster than ffmpeg -threads 7 -i ¨219min.wv.-hhx3.wv -hide_banner -loglevel error -f wav -y NUL
   16.53 ± 0.22 times faster than ffmpeg -threads 1 -i ¨219min.flac-7--lax-l32.flac -hide_banner -loglevel error -f wav -y NUL
   17.87 ± 0.24 times faster than .\wvunpack --threads=4 ¨219min.wv.-hhx3.wv -z0qyo -o - > NUL
   19.32 ± 0.27 times faster than .\wvunpack --threads=7 ¨219min.wv.-hhx4--blocksize=131072.wv -z0qyo -o - > NUL
   20.56 ± 0.27 times faster than .\wvunpack ¨219min.wv.-fx0.wv -z0qyo -o - > NUL
   23.03 ± 0.31 times faster than .\flac ¨219min.flac-0b65535--no-md5.flac -fo NUL
   23.53 ± 0.31 times faster than .\flac ¨219min.flac-0r0--no-md5.flac -fo NUL
   24.39 ± 0.54 times faster than .\flac ¨219min.flac-0b65535--no-md5--uncompressed.flac -fo NUL
   25.68 ± 0.34 times faster than .\flac ¨219min.flac-7--lax-l32.flac -fo NUL
   25.74 ± 0.34 times faster than .\wvunpack ¨219min.wv.-gx1.wv -z0qyo -o - > NUL
   25.98 ± 0.34 times faster than .\wvunpack ¨219min.wv.-gx1--blocksize=4096.wv -z0qyo -o - > NUL
   27.86 ± 0.37 times faster than ffmpeg -threads 1 -i ¨219min.wv.-fx0.wv -hide_banner -loglevel error -f wav -y NUL
   28.06 ± 0.37 times faster than .\wvunpack --threads=4 ¨219min.wv.-hhx4--blocksize=131072.wv -z0qyo -o - > NUL
   33.95 ± 0.45 times faster than .\wvunpack ¨219min.wv.-hx2.wv -z0qyo -o - > NUL
   36.93 ± 0.50 times faster than ffmpeg -threads 1 -i ¨219min.wv.-gx1.wv -hide_banner -loglevel error -f wav -y NUL
   40.31 ± 0.63 times faster than ffmpeg -threads 1 -i ¨219min.wv.-gx1--blocksize=4096.wv -hide_banner -loglevel error -f wav -y NUL
   42.66 ± 0.56 times faster than .\wvunpack ¨219min.wv.-hhx4--blocksize=131072.wv -z0qyo -o - > NUL
   43.94 ± 0.58 times faster than .\wvunpack ¨219min.wv.-hhx3.wv -z0qyo -o - > NUL
   49.46 ± 0.66 times faster than .\flac ¨219min.flac-8b16.flac -fo NUL
   52.08 ± 0.72 times faster than ffmpeg -threads 1 -i ¨219min.wv.-hx2.wv -hide_banner -loglevel error -f wav -y NUL
   65.43 ± 0.86 times faster than ffmpeg -threads 1 -i ¨219min.wv.-hhx4--blocksize=131072.wv -hide_banner -loglevel error -f wav -y NUL
   69.96 ± 1.06 times faster than ffmpeg -threads 1 -i ¨219min.wv.-hhx3.wv -hide_banner -loglevel error -f wav -y NUL
  177.26 ± 2.49 times faster than ffmpeg -threads 1 -i ¨219min.flac-8b16.flac -hide_banner -loglevel error -f wav -y NUL
  427.60 ± 5.75 times faster than ffmpeg -threads 7 -i ¨219min.flac-8b16.flac -hide_banner -loglevel error -f wav -y NUL
  430.33 ± 7.03 times faster than ffmpeg -i ¨219min.flac-8b16.flac -hide_banner -loglevel error -f wav -y NUL
7
Other Lossy Codecs / Re: Index tables for unofficial IMA ADPCM bit depths
Last post by Bogozo -
@Case Codec's are not only required for high-performance computers, they are also required for tiny microcontroller's and etc.. Using a modern codec like MP3 can be very hard or impossible with these tiny MCU's and etc.. So, ADPCM is still required for some low processing power tasks. I'm asking this because i want to use ADPCM with Arduino. Anyway, thanks for recommendation.
Are you going to use "tiny MCU" to decode or to encode?
8
General - (fb2k) / Re: Tagging with an iterative loop e.g. tag automatically according to folder order
Last post by timalina -
I want to avoid doing it one disc at a time if possible as I'll be doing other editing as albums (consolidating the Album tags and removing the 'CD1'-type suffixes), because some sets contain quite a lot of CDs (with volumes containing sub-volumes), and because the scope for errors will be greater.

I've never used foo_sqlite or Masstagger, but I'll look into them. Even if it's not the solution I'm looking for, perhaps I'll find a better way once I work them out.
Thanks, but I've got thousands of folders without a consistent structure, so parsing strings would be laborious.

Also, I'm wanting to edit the album tags as I go (to removed 'CD 1'-type suffixes and make the album tags identical, so manual tagging would be quicker than parsing.

Really, I'd want something that works in a similar way to the 'Auto track number' function, but for Discnumbers.
You could do it with foo_sqlite, but if you're just doing one album at a time it's probably just as easy to do it with Masstagger scripts and keyboard shortcuts e.g. one script to set discnumber to 1 (Ctrl+1), one to set discnumber to 2 (Ctrl+2) e.t.c., and do it from the playlist window.

I don't use the Properties panel for editing but given there's an 'Auto track number' I'm surprised there's not an equivalent for discnumber.
9
Opus / Opus decoding complexity
Last post by Klymins -
Hello. Assume the maximum possible complexity of a non-freeformat MP3 decoding process is X, what is the roughly maximum possible decoding complexity of non-custom Opus in X (2x, 5x, 10x etc)? Opus is described as a hero but i'm afraid it is very complex and hard.
10
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Wombat -
I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.
here's the binary, you can try it.
To be honest since i did read this i thought you have the same problem as @KevinB52379.
How does foobar multithreaded react on your system with the other builds?

As a sidenote: fast-math + AVX2 gives another nice boost to the fast clang compile.