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
Lossless / Other Codecs / Re: Tested: Lossless decoding speed, multithreaded - and fast verification
Last post by Porcus -
BLUNDER on me and on ffmpeg.

ffmpeg errs out on the ¨3x.flac-0b65535--no-md5--uncompressed.flac also when decoding. Of course I should have checked that when it refuses to demux.

It is not about it using the only-verbatim-subframes flac - likely it is about frames being too big.
The attached 1.3 second flac file - good old Merzbow at it again - has 57330 samples and is created with
-0r0 --no-padding -fb57330 --lax
So one frame, both subframes are FIXED, order 1.
ffmpeg cannot decode it. Recompress it with smaller block size, and it will - 57700 is still too large though.

Fiddling around with files I found out that padding-or-not could even influence the max block size. I got a file where 53207 with default padding is OK, 53208 with default padding is not, 53208 with --no-padding is OK.


@ktf, of course there is nothing wrong with the file? The blame is squarely on ffmpeg?
Quote from: ktf on
It makes decoding much more complicated, less predictable and less stable.
You might have had a point ...
2
3rd Party Plugins - (fb2k) / Re: OpenMPT Module Decoder
Last post by LigH -
Today I noticed a post in the Discord server of the "Nectarine Demoscene Radio", they mentioned a YouTube video: Amazing AMIGA Multichannel Music - MoSeZ - NNZ Collection #1 - there is an archive of SymMOD modules as well as MP3 versions of the same tracks linked in its description.

Playing the first file (Gloomyness.SymMOD) I noticed that foobar2000 with OpenMPT module decoder 0.7.1 / 0.7.3 plays this song in mono. But the MP3 has a stereo panorama.

I don't know anything about this module format; might it be that its support is incomplete, and the decoder is unable to retrieve the position of instruments in an audio panorama? When I watch the YouTube video of an Amiga tracker it has an analyzer in the center of the screen, displaying dots on concentric rings, which looks like they should present a relation to instrument positions, I guess?
3
Support - (fb2k) / Re: Playlists Get Zero'd Out After a Library Search
Last post by Revup67 -
Quote from: Case on
The Library Viewer option has been there at the bottom of the Media Library page practically forever. It's the 'Enabled' button under the big 'Library viewer selection playlist' headline: https://wiki.hydrogenaud.io/index.php?title=File:Foobar2000-Preferences-medialibrary.png.

Does the library search not work like it should for you? It's supposed to show the results of your query in realtime as you type. If the preview dialog is empty it means there are no entries matching your query. Of course it also says how many tracks the query returns in the title bar.
I can't replicate Ctrl+Z not working. I can do multiple searches and hit enter to replace my playlist with the results. Just hit Ctrl+Z as many times as playlist results got replaced and you are back with the contents you started with.
Thanks for the rephrasing the suggestion, 'Enabled' was in fact checked.  I shall be more specific on how the Zero'ing out the Playlist occurs. I've now two different results when pressing Enter after the Search criteria string is typed.  To test on your end,
Scenario 1: create a Playlist with 5 different tracks from different Artists. Note any 'unique' keyword in any of the 5 tracks.  With that Playlist engaged (focused aka double clicked), type in your selection of a word string within those 5 tracks for Library Search and press 'enter'. The playlist now Populates with any matching criteria from the 'entire' library and wipes out the playlist as it was just prior.
Scenario 2: repeat the above with one exception, choose a word that is not within the entire Library such as 'non-sense' press Enter, the entire playlist is wiped out to Zero.
I can confirm CTRL+Z works after pressing "Enter" however the end user must refocus their mouse by clicking anywhere on screen where the Playlist results appear (even if none are shown) and Then perform a CTRL+Z. This exact sequence of events returned the Playlist to the previous list as expected. Perhaps it would be helpful to have a Right Click option on  the Playlist to perform an Undo.
Lastly, the comment you'd mentioned about the results after conducting a Search do appear in real time but for many of us, we still hit the Enter key. Hope that helps - thanks
4
Support - (fb2k) / Re: Playlists Get Zero'd Out After a Library Search
Last post by Revup67 -
I'm in compliance with your statement, pressing Enter has catastrophic results where All files in a Playlist area zero'd out and there is no form of recovery.  The "enter" key should yield "no Input" when pressed after a Search string is entered. That would solve this issue.
Anyone with doubts should try sequence (Windows not sure on a MAC):
Search the Library while any playlist is highlighted, perform a search of any key word, press enter. The Playlist now shows 0 results.  This will aid in observing the the current natural occurrence.
My sympathy goes out to anyone that has many many hours procuring their Playlist(s) to lose all of their entries when this sequence of of events occurs.
7
3rd Party Plugins - (fb2k) / Re: Playlist-Tools-SMP
Last post by Koshingg -
Well, actually you're a bit wrong here, haha :) I did read the change log at the time but I simply forgot to do those changes later when I updated, I assumed I already made those changes....I guess lately I was frustrated by so many annoyances...Foobar v2, foo_plorg, and the list is very very long...Or as you saw recently foo_skipcount....where you helped the developer with those bugs, some of them I've also noticed...When you have many components it's hard to keep track with so many changes , especially now with Foobar v2...

I solved the problem by resetting the toolbar, then I reimported the user presets for the Playlist Tools, the other buttons didn't have many settings, so nothing is lost.
8
3rd Party Plugins - (fb2k) / Re: Playlist-Manager-SMP
Last post by Koshingg -
Thanks to your tip I managed to solve this, I didn't use the package.
I remembered that I created a smart playlist , probably 2-3 months ago....I removed that smart playlist and everything seems ok now, that error doesn't appear. I'll send you a PM with the details of that smart playlist, just in case it's useful.
But there is one more issue....something that I forgot to mention last time. I also have this error:

Error: Spider Monkey Panel v1.6.1-mod (Playlist Manager: Playlist Manager v0.16.0 by regorxxx)
unknown format:

File: chroma.min.js
Line: 86, Column: 1596
Stack trace:
  g@chroma.min.js:86:1596
  m@chroma.min.js:86:1908
  getColorName@playlist_manager_menu.js:3218:36
  createMenuRightTop/<@playlist_manager_menu.js:3237:61
  createMenuRightTop@playlist_manager_menu.js:3224:13
  func@playlist_manager_list.js:7174:6
  _list/this.lbtn_up@playlist_manager_list.js:1845:14
  @playlist_manager.js:669:9
  fireEvents/</<@callbacks_xxx.js:149:37
  fireEvents/<@callbacks_xxx.js:145:30

It happens when I try to right click Action button, and also when I try to left click settings button.
Thx for your patience.
9
General - (fb2k) / Re: Lame Settings for Foobar Conversion, CBR 128
Last post by Apesbrain -
Quote from: 2zrg on
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.
10
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