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.
Topic: Resurrecting/Preserving the Helix MP3 encoder (Read 53086 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #375 –
Weird issue, @KevinB52379. Here's a fresh compile of the current git sources.
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #376 –
@Case - This fresh compile works perfectly!  Nice and fast again and cpu utilization is near 100%
Thank you very much.
I'm still not sure why John's builds aren't working right for me though...I find that odd since his binaries are so reliable.
Thanks again!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #377 –
When helix was updated the last time on git to version 5.2.3 i did my x64 compile.
One simple and one with fast-math + AVX2 that doesn't do much for speed on my Ryzen 5900x.
You may give it a try.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #378 –
@Wombat  - I appreciate you sharing your compile with the forum, but alas, your version, like John's version, slows my system down to a crawl, and the system hangs and becomes very slow to respond to input.  CPU utilization registers about 50% or less.

When I try @Case version he kindly uploaded for me, it encodes at about 1,000x real time, where as your version encodes about 250x and slower (with the system slow down and hangs).

I tried both the regular x64 version and the fast math x64 version, same results...
I'm really not sure what the issue is. 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #379 –
Did you try to set different Thread Counts or priority in foobars converter settings? Even non multithreaded my x64 compile is ~490x here while Case win32 is only ~280x speed.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #380 –
Where do I look at those settings?  I didn't change any priority settings, so whatever Foobar2000's default settings are, that's what it's set to. 

 My foobar2000 encoder settings are:- %d -F18000 -HF2 -V85 -X2

I have lossy selected, multi threading is enabled, 24 bit is selected.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #381 –
File -> Preferences
X
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #382 –
Quote from: KevinB52379 on
If you want me to test something, let me know, I'd be happy to try and troubleshoot for you!
@KevinB52379 A few hours ago, I sent you a private message with the Helix build to test. Do you have any feedback?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #383 –
Quote from: Kraeved on
Quote from: KevinB52379 on
If you want me to test something, let me know, I'd be happy to try and troubleshoot for you!
@KevinB52379 A few hours ago, I sent you a private message with the Helix build to test. Do you have any feedback?


I'm sorry, I missed your message.  I tried your build and I get about 259x realtime with Foobar2000 default converter options set for thread count and thread priority.  I appreciate the effor though.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #384 –
I guess all x64 gcc builds are pretty much the same in speed since hmp3 is not really to optmize with additional flags.
The high speed may overtake your io system.
Can you try a thread count of 4 only for testing?
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #385 –
Quote from: Case on
Quote from: Kraeved on
a) gudki.11khz.mono.mp3 and gudki.22khz.mono.mp3 are malformed files (24 293 bytes), apps refuse to open them
The file is outside specs, also called "freeformat". There are some decoders with freeformat support, but of course it makes no sense to use such formats anywhere. I think the best option is to disallow incorrect settings, what do you think?

I believe non-spec stuff should be removed, After all, we are no longer at the beginning of the MP3 journey, when they tried all sorts of outlandish things, but proceed from what has been recognized. I tried to open a free-formatted audio file with a couple of dozen players on Windows 7 x64, and only MPV (probably with the help of mpg123 decoder) was able to read it. Even FFplay failed.

Quote from: maikmerten on
Helix has a few checks to discourage settings that are deemed non-recommended. For instance, for 44.1 kHz files, it won't go below -B48 and will just barf "ENCODER INIT FAIL" at the user. When taking away those checks, Helix can, e.g., create "passable" 80 kbps 44.1 kHz CBR files with intensity stereo, but I so far refrained from relaxing those checks in fear that the encoder might explode in unexpected ways.

It's no coincidence that almost a month ago, when I proposed a prototype of the simplified interface of Helix MP3 encoder, there were question marks instead of valid values for each of the encoding modes. If it is more or less clear with VBR — you can enter from 0 to 150, then what is acceptable with CBR? We should be clear about that both on the screen and on the wiki.

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #386 –
Quote from: KevinB52379 on
@Case - I hate to bother you, but could you please post the latest binary of Helix to this thread?  I try using the latest version from Rarewares (both 32 bit and 64 bit) and they both run really slow, and slow down my system...yet CPU utilization isn't near full when encoding using foobar2000.

Quote from: Kraeved on
There is something wrong about Lancer mod 2021-05-11 hosted on RareWares. It is unable to correctly encode WAV when its sampling rate is less or equal to 11025 Hz: SSE2 version outputs silence, SSE3 outputs heavily distorted sound.

Quote from: john33 on
I'm off to Spain for 2 weeks tomorrow so my mind is elsewhere!! I don't think I will get to look at this until I return so please feel free to remind me if I should appear to have forgotten about it.

I was thinking about this the other day, expecting some trouble to happen. We have a few developers who release binaries here. And if the old-timers of our forum can still keep an eye on them, then what will we see if we just type "Helix MP3 encoder" in the search engine? A scattering of sites offering a version back from 2005 and some abandoned repositories. Unlike LAME, Helix MP3 encoder does not have its own page, a single point of entry. This issue cannot be solved immediately, but I see the light at the end of the tunnel. Dear @maikmerten, is it possible to compile Helix binaries automatically for x86 and x64 (two separate archives) on Github when the version is bumped, or could you update the front page by adding links to RareWares (downloads) and HA Wiki (documentation)?

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #387 –
@Wombat - OK I tried your build again with foobar2000, and set the thread count to 4, and I tried again.

This time I get about 250x to 320x realtime, and the encoding time is about 1 hr 15 mins.  The system is more responsive....

With Case's version with these same settings I get 530x to 600x realtime with about 35 minutes to encode my library

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #388 –
Really no more idea at my site why you have only good results with the win32 binary.
Tested on Ryzen 5900x, Win11, foobar 2.1.4 x64, Thread Count auto, hmp3 5.2.3 x64 simple:
~4100x speed with temporary file (%s) and
~4400x speed stdin/stdout (-)
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #389 –
Here is a Clang build for comparison testing.  This does not have AVX optimizations.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #390 –
Nice idea to try clang. Last time i tried with hmp3 it was clearly slower as gcc.
I have a feeling there is some different thing at play. Maybe something hardware or even simply driver related.
@KevinB52379 has an 8 core Zen 3 5700G that does 600-1000x speed multi-threaded while my 12 core Zen 3 does ~3100x speed with the win32 binary by Case encoding mp3s from flac.

Edit: Clang version eaches ~4200x speed stdin/stdout
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #391 –
Hello!  I did try the Clang version because quite honestly I was curious and was hopeful it would fix it.  Alas it does not.  I get about 250x to 300x realtime encoding from FLAC to mp3.  The files are on an external ahrd drive and encoding to my internal NVME SSD.  I get similar results with everyone's build of Helix, and my system slows down (even more so than normal).  I even tried disabling AVG thinking that was somehow interfering, but no dice. 

When I use Case's version of Helix Win32 build, I get about 1000x to 1300x realtime encoding those same files.

I've tried everyone's 64 bit builds and 32 bit builds with the same results....

Except for Case.  Does he put some magic in his compile?? LOL

You are correct, I have a Zen3 8 core processor that can handle 16 threads (AMD Ryzen 7 5700g @ 3.8ghz base...it has integrated graphics and the system has 32GB of DDR4 RAM and 1tb nvme gen3 SSD (Samsung 980 1tb).

I'm willing to try any other builds if anyone wants me to, but so far, Case's version is the only one that seems to work properly with fast encoding speeds and doesn't cause the system to basically hang...with his version the system does slow down, but it still responds.  And encoding speed remains fast and consistent with full cup utilization.  With everyone else's builds the cpu utilization never reaches 100% even though I have foobar encoding settings set to automatic for thread count and default priority.

Oh, I have the latest chipset drivers and graphics drivers from AMD.
Sorry to be so wordy but just trying to provide info.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #392 –
Might be useful if you post a screen-grab of your system info.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #393 –
I still wonder what happens here and the following idea may be far fetched.
Together with my B550 chipset for AMD i had several USB problems until some AGESA BIOS update fixed it.
It may be worth to check for the latest BIOS update.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #394 –
I'll look for a BIOS update.  The one I currently have installed is from October 2023.  It's an HP system.  But, I feel that if it was a USB problem, wouldn't it be happening with Case's version as well? 

I'll search on HP's website for a newer BIOS offering for my model.

Thanks!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #395 –
Here is an x64 compile that is built with the slower compiler option -O1 that is only minimal faster as the win32 by Case.
The idea is that something overpaces your config.
Also a test with files encoded from the local SSD without USB in play can help to get an idea.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #396 –
I tried that build and I get about 300x from the external hard drive where my FLACs are and converting to mp3 to the internal SSD using foobar2000 and Helix. 

I am copying the FLACs over to the internal SSD and I'm going to try using foobar2000 to convert totally from internal SSD drive...so the source will be the internal SSD and the destination will be the same internal SSD.

My system is a PCIe Gen 3x so I didn't bother paying more for a PCIE gen 4 drive.

There were no BIOS updates.  The latest is from October 2023 and that is what I have installed.

I'll let you know how this conversion fares.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #397 –
EDIT:  OK I found a compile of Helix MP3 encoder on my external hard drive , the zip file is called helix_mp3enc_r11_x64.zip and the exe is called hmp3enc.exe.
I tried this version (I know it's one of the original Helix versions) but I was curious to see hwo this 64 bit version worked.

I did the test from my SSD and got 1300x to 1800x.

So what is different between Case's build, this old version and all newer compiles?

I believe I got that version of Helix from Rarewares or ReallyRareWares.

OK I tried copying my FLACS to the internal SSD and tried converting with foobar2000 from there.

I still average about 220x to 300x using your slow compile 64 bit version of Helix. 

Same speeds I got when converting from external hard drive...so I don't think USB is the issue.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #398 –
Quote from: Kraeved on
Dear @maikmerten, is it possible to compile Helix binaries automatically for x86 and x64 (two separate archives) on Github when the version is bumped, or could you update the front page by adding links to RareWares (downloads) and HA Wiki (documentation)?

Yeah, I probably should link to the Wiki documentation and then point to a proper download location for Windows builds. I'd of course like RandomWares to be the official download location, if john agrees.

As to building the Windows binaries, I think perhaps we should find out which builds work best and how they are generated. I'm a Linux guy and am hesitant to weigh in too much on Windows things, but am hopeful that it may become apparent what works best on Windows.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #399 –
Quote from: 145dBSPL on
This is an interesting insight. Thank you for your research. To visualize this, I created and encoded a pink noise file.
Settings used are -V110 -HF[1|2]. For both encoded files, an mp3 analysis shows 18.0 % Simple stereo frame
and 82.0 % Mid-side stereo frames.

Sorry for the late reaction, but thanks for illustrating this. Mind if I steal your images for the Wiki documentation?