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
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.
2
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.
3
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by KevinB52379 -
Quote from: Case on
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.

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.
5
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Case -
Quote from: Kraeved on
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.
6
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.
8
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by JoshuaChang -
Quote from: Case on
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.
9
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     
10
Opus / Re: Opus v1.5.2
Last post by 2012 -
Quote from: jdimsa on
Is there any reason to stick to multiples of 16/32 for target bitrate in opus encoder or does it not matter? I noticed qaac/Apple AAC forces 112-128-160-192 etc.

Unless it's a special use-case which also requires hard CBR, it does not matter.