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 88008 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #400
Oh, that's perfectly fine. Thank you for asking.
Let me know if you need higher resolution images.

Some more details if required:
Pink noise, stereo, 16 bits, 44.1 kHz, -10 dB, uniform distribution
Used spectrum analyzer is Spek.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #401
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.

I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.
here's the binary, you can try it.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #402
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.

I think i have the same problem, my cpu is zen2 4650g(6c12t), i got around 280~300x under command line @ single thread with autodidact's clang build or rarewares' gcc build, I also compiled helix myself with clang plus linktime optimization, my version got around 480x. maybe that's the key.
here's the binary, you can try it.


Thanks for contributing your compile.  I tried it, but for some reason it isn't creating mp3s on my end.  I kept the settings the same as I used previously for successful encodes, but literally just replaced the hmp3.exe file.

Also when using it with foobar, the system did hang again, and I saw the conversion dialog, but the "pause" and "abort" buttons never showed up and the file progress never continued.  What I mean is the progress bar was moving, but it was still showing that it was converting the first file still.  Weird.

Thanks for trying!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #403
That's really weird, i've tried both cmd and foobar2000, everything is ok, foobar2000 2.1.4 x64 with minimal convert parameter:" - %d"

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #404
Also not working here "An error occurred while writing to file (The encoder has terminated prematurely with code -1073741515 (0xC0000135); please re-check parameters"
Btw. did you just set the flag -flto? I could do one with gcc.

Edit:  Did one with gcc flto. Roughly the same speed here as without.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #405
Also not working here "An error occurred while writing to file (The encoder has terminated prematurely with code -1073741515 (0xC0000135); please re-check parameters"
Btw. did you just set the flag -flto? I could do one with gcc.

Edit:  Did one with gcc flto. Roughly the same speed here as without.

I've managed to reproduce the problem under my vm env, my fault for not including the -static in LDFLAGS, here's the re-complied version.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #406
This version compiled with clang is the fastest in the test, followed by gcc avx2. This is just the result of my test.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #407
If anyone is interested

Linux amd64/x86_64 Glibc 2.39
Clang 18, O3 LTO PGO

Code: [Select]
CC=clang # was gcc

#CFLAGS_COMMON=-O3 -fprofile-generate=/tmp/ -c -I$(SRC_PREFIX)/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 # 1st run
CFLAGS_COMMON=-O3 -flto -fprofile-use=/tmp/profile.profdata -c -I$(SRC_PREFIX)/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 # 2nd run

#LFLAGS=-lm -lstdc++ -O3 -fprofile-generate=/tmp/ # 1st run
LFLAGS=-lm -lstdc++ -O3 -flto -fprofile-use=/tmp/profile.profdata # 2nd run

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #408
Also not working here "An error occurred while writing to file (The encoder has terminated prematurely with code -1073741515 (0xC0000135); please re-check parameters"
Btw. did you just set the flag -flto? I could do one with gcc.

Edit:  Did one with gcc flto. Roughly the same speed here as without.

I've managed to reproduce the problem under my vm env, my fault for not including the -static in LDFLAGS, here's the re-complied version.

FINALLY!  A version of Helix MP3 that converts fast besides Case's version!

This version DOES NOT hang up my system in a weird way and cause foobar to be basically nonresponsive!

ALSO - FASTEST encoding speed yet converting from internal SSD to internal SSD at 2500x encoding speed!

This version works, yay!


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #410
ALSO - FASTEST encoding speed yet converting from internal SSD to internal SSD at 2500x encoding speed!
How many cores/threads?

My system has an AMD Ryzen 7 5700g - Zen3 architecture.  8 cores 16 threads.  I have foobar running at full thread count during conversion.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #411
Fascinating stuff is that the "g" variants behave so different and a profiled 2pass compile fixes it.
The speed gain is nice also :)
Thanks to @punkrockdude for the insight!
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #413
Amazing to convert a 38min album in 8 seconds. I think Deadbeef is single threaded but I am not sure.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #414
Yeah single threaded a normal album well encodes below 10 seconds.
@JoshuaChang binary is ~4600x speed here on the 5900x :)
The problem is what exactly causes the faulty behaviour with the "g" variants and how to fix it.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #415
The problem is what exactly causes the faulty behaviour with the "g" variants and how to fix it.
Like Ryzen 5600G (what I am using) etc or the builds using Og? I now tried a 1h audio (44.1kHz/16bit/2ch) encoded with no parameters and it took 06s. It was using only one logical core.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #416
The Windows x64 compiles using makefile don't work properly on at least the 2 "g" variants reported here.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #417
I wonder if I can get up to 7200x if I can encode using all my logical cores at the same time, somehow. Let the speed competition begin! :) I might try adding OpenMP or OpenACC...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #418
For me (AMD Ryzen 7 5700g variant) ALL compiles of 32 bit and 64 bit cause this weird system hang and slowdown and slow encoding speed...except for the 64 bit version I quoted above in an earlier post, and Chase's 32 bit compile.


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #419
Oh, that's perfectly fine. Thank you for asking.
Let me know if you need higher resolution images.

Some more details if required:
Pink noise, stereo, 16 bits, 44.1 kHz, -10 dB, uniform distribution
Used spectrum analyzer is Spek.

Thank you, I uploaded the images with attribution and the details you provided to the Wiki and embedded them in the Helix MP3 Encoder page.

As for the various reports of the different Win32/Win64 compiles behaving vastly differently, I currently don't have a good hypothesis on what's going on there. I wouldn't, e.g., expect builds with different optimizations (e.g., PGO or no PGO) to make the difference between a machine getting unresponsive or working properly. Also, doing static builds (-static linker flag) only means that the required system libraries are included in the build - I don't quite see how this should have a meaningful performance impact (unless the system libraries are somehow misbehaving).

So I guess it might be a good idea to somehow collect data on the various build options and find a Windows build solution that works reliably.

Other than that, I'm pleased that apparently some people are getting results that indicate it's now possible to encode hours of audio in mere seconds. I remember working on machines where this used to be the other way around...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #420
@KevinB52379 maybe you have cooling problems and AVX(2) compiles cause throttling?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #421
In the Wiki, I also documented the -T parameter, which isn't part of the normal user documentation. This biasses the normal VBR quality setting (-V) and can be used to reach lower or higher VBR qualities/bitrates. The -T parameter ranges from -40 (lowest quality bias) to 50 (highest quality bias).

Examples:

This generates 44.1 kHz stereo encodings with roughly ~96 kbps (-V0 usually targets ~112 kbps) with a lowpass of 16 kHz:
Code: [Select]
hmp3 -F16000 -V0 -T-20 input.wav output.mp3

This allows encoding high-frequency content (> 16 kHz) even at low VBR bitrates such as ~128kbps:
Code: [Select]
hmp3 -V80 -T-40 -HF2 input.wav output.mp3

This increases the VBR quality target beyond what's usually possible (~310 kbps VBR instead of ~260 kbps VBR):
Code: [Select]
hmp3 -V150 -T50 -HF2 input.wav output.mp3

So that's a parameter for fun experiments.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #422
@KevinB52379 maybe you have cooling problems and AVX(2) compiles cause throttling?
The problem occures also without the use of AVX versions.
I think we have a problem only with some AMD APUs. At least @KevinB52379 and @JoshuaChang use a Ryzen 4650g and a 5700g.
I already offered a x64 compile with a uncommon low optimization level -O1 and this didn't help.
So we must find out if it is maybe a system problem with for example a special version of the AMD chipset/graphics driver and why it does not happen with a lto compile that also uses the high optimization level -O3.
This may be something for coding experts and not for a noob like me.
I fear only @KevinB52379 and @JoshuaChang can find out directly at their PCs.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #423
I have a Ryzen 7 5850U.   I can do some testing with hmp3 on Linux.  I cloned @maikmerten's github and built hmp3. 

With the default Makefile, I can encode a 1h 43m wave file in 12.42s average

Adding -march=x86-64-v3, the file encodes an average of 13.10s.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #424
@maikmerten Right now the build of @Case is the most relevant for 32-bit systems, and the build of @JoshuaChang delights HA users of 64-bit systems. In both cases, we still have no idea how their binaries are compiled from the code because the makefiles are not shared. Why? Err… Please? But new posts are coming and links to these builds will soon be lost among a dozen other testing, non-optimal, raw builds. I can't help but feel that it is not the order that is growing, but the mess. How can we trumpet the good news of the resurrection among our neighbors if we can't really point out where Helix MP3 encoder, this eighth wonder of the audio world, is? Even established search engines find it difficult to help here. Let's at least mention these builds on the HA wiki for a while, as it is done on the FhG AAC encoder page.


Fyodor Bronnikov — Pythagoreans celebrate the sunrise (1869)
• 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