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
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Case -
If you don't mind, you could install Windows Performance Toolkit and use Windows Performance Recorder to record what goes on with the machine when encoding. You can enable all options under Resource Analysis and you can stop recording when the system goes slow. If you share the recording it should reveal why your machine acts so badly.

@Kraeved - I already tried to reply in the related topic why VSTs aren't smooth. But let me clarify. The VSTs are given big blobs of audio data to process at once, the exact size depends on design of decoder components and what other DSPs may be before them. The janky VSTs apparently have trouble updating their UIs when dealing with such data. All buffers in foobar2000 are big to support smooth and glitchless audio playback. DAWs have tiny buffers to work as realtime as possible.
2
General - (fb2k) / Re: Multivalue tag - help needed
Last post by ojdo -
It should work (entering ; as a separator), but only if you add RELEASECOUNTRY to the list of "Multivalue fields", found in
Preferences > Advanced: Display / Properties dialog / Multivalue fields.
3
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
@KevinB52379, what if you discard Foobar2000 as an intermediary for a while and encode right in the terminal using Hyperfine, a cross-platform tool for warming up the system and measuring the execution time of the binaries? For example, @misio discovered and I verified that visualization via VST plug-ins works much slower in Foobar2000 than the same plug-ins in audio editors (DAWs), and surprisingly, interaction with WavPack files turned out to be the slowest.
4
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by KevinB52379 -
I did some benchmarking and GCC's fprintf takes 100 times longer even here compared to MSVC's or clang's function.
Attached is a patch that changes progress printing to use WriteConsole on Windows when stderr isn't redirected to file. That gives consistently fast progress display on all compilers. I also noticed that stopping encoding by keyboard press didn't work when not compiled on Visual Studio, fixed that too.

I also changed the progress printing to happen 4 times less often than originally. I think maikmerten's progress update happened too seldom, it looked buggy when it was so sluggish.

I hope @KevinB52379 can test this and report if things now work correctly.

Edit: replaced with static compile.

EDIT:  I tried the -D switch and that didn't improve anything.

Also, please note, I am able to use FAAC, LAME, Vorbis, Opus from rarewares with all thrads going with foobar2000 and I have fast encoding speeds and no system hang.  Yes, I know there are slowdowns because all the cores are being used, but this system hang I'm experiencing with Helix is totally different.
I tried this version.

At first it started off promising, encoding started at around 1300x, but then about 20 seconds or so in, things started to slow down.  They system started to hang, things became very unresponsive.

When encoding first started with foobar it started about 1400x to 1500x and then slowed down drastically.

In fact, in foobar the file list of what was currently being encoded stopped updating, the time elapsed stopped updating, the estimated time complete incrased and then stopped updating.  The only thing that was changing, although very slowly was the progress bar of the encoding task.
6
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Case -
Hmmm.
[...]
Code: [Select]
  hmp3.case.x64    6.860 ± 0.051   1.41 ± 0.01  
  hmp3.chang.x64   4.850 ± 0.019   1.00     
Note that the intention is to find and solve the abnormal system slowdown KevinB reported. His problem is in no way related to relative performance of different compiles.

Though I do wonder how JoshuaChang's clang compile is so fast. Usually GCC has been able to produce faster binaries. And if I compile a clang build with joshua's makefile, I get a slower binary than my GCC compile.
7
General - (fb2k) / Re: Free Encoder Pack
Last post by Case -
Updated 2024-04-23 with Opus 1.5.2, qaac 2.82 and refalac 1.82.
Installer also changed - now no longer asks for admin credentials for regular users. And can query default install dir from the browse dialog for portable install users.
9
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by JoshuaChang -
I did some benchmarking and GCC's fprintf takes 100 times longer even here compared to MSVC's or clang's function.
Attached is a patch that changes progress printing to use WriteConsole on Windows when stderr isn't redirected to file. That gives consistently fast progress display on all compilers. I also noticed that stopping encoding by keyboard press didn't work when not compiled on Visual Studio, fixed that too.

I also changed the progress printing to happen 4 times less often than originally. I think maikmerten's progress update happened too seldom, it looked buggy when it was so sluggish.

I hope @KevinB52379 can test this and report if things now work correctly.


I think you might forgot to add -static in the LFLAGS since it ask for libstdc++-6.dll in my env.
10
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
Hmmm.

* in.wav, 99 423 788 bytes
* hmp3.case.x64, 513 024 bytes, xxhash 820182a208834328
* hmp3.chang.x64, 839 680 bytes, xxhash 4080008cf88453e9

Code: [Select]
$ hyperfine --warmup 3 --runs 3 -L encoder hmp3.case.x64,hmp3.chang.x64 "{encoder} -V150 -HF2 -F20000 in.wav out.mp3"

  Command          Mean [s]        Relative    
 ---------------- --------------- -------------
  hmp3.case.x64    6.860 ± 0.051   1.41 ± 0.01 
  hmp3.chang.x64   4.850 ± 0.019   1.00