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 40520 times) previous topic - next topic
0 Members and 3 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!