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 63949 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #250 –
Quote from: john33 on
That is a 17 year old CPU and a 15 year old OS. What are you trying to demonstrate?

Quote from: maikmerten on
Can somebody on 64 bit Windows (so a normal, modern Windows install) try the enclosed "win64" build and compare its performance to the 32-bit executable ("win32")? To enable the SSE assembly (originally for the Pentium III), one needs to pass the "-U2" hmp3 parameter.

@john33, are you paying attention or drinking gin?

• 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 #251 –
Well I'd question that meets any criteria related to 'modern'!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #252 –
I tested with otherwise similar parameters to Kraeved but I benchmarked both candidates with and without "-U2". The -U2 parameter had a tiny speed difference on 64-bit and affected the 32-bit encoder much more. My test machine is slightly newer, Core i9-12900K running on Windows 11 Pro. I combined a CD into a single 3341+ seconds long WAV file that I used as a test. Encoding was done 3 times for each test and timer64 was used to record time. I used average times to compute the speeds.

Code: [Select]
32-bit (-U2):  509x realtime
32-bit:        438x realtime
64-bit (-U2):  680x realtime, 34% faster than 32-bit
64-bit:        677x realtime, 55% faster than 32-bit

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #253 –
Quote from: Case on
Quote from: Kraeved on
@Case is now double-checking float operations and considering a proposal to a long overdue redesign of Helix screen
Not sure if you meant the float part as a joke but that doesn't need any double checking. The encoder has always worked internally with floats, the input was just artifically limited to 16-bits. Before I posted the first float-enabled version I had verified that standard 16-bit behavior was unchanged and that floats exceeding -1.0..+1.0 range are nicely preserved.
The help screen can certainly use improvements.

Quote from: maikmerten on
@john33 - in https://github.com/maikmerten/hmp3/blob/main/hmp3/src/mp3enc_x86asm.vcproj there's another project file and appveyor tries to build that and fails. I guess this can be removed now that your project files are in the repo?
The .vcproj file is ancient Visual Studio project file. Visual Studio 2010 changed the format and name to include the 'x'. Since the solution uses the newer VS2010+ format the old file is absolutely useless.

Is there a reason why this encoder was artificially limited to only 16-bits?
LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #254 –
Quote from: vina54 on
Is there a reason why this encoder was artificially limited to only 16-bits?

I asked about it a couple of pages ago. @Case shared his idea.

Quote from: Case on
Quote from: Kraeved on
* Any idea why Helix input was limited to 16 bit?
Helix encoder's history seems to date back to early 2000, several years before HD audio was even close to being popular or in wide use. It is possible offering support for higher bit depths wasn't deemed necessary. Also it may have seemed unnecessary as the quality of MP3 doesn't really exceed what 16 bit PCM can offer.

However, I see no consensus that it is better to send a signal to MP3 encoders in 32-bit float, 32-bit or 24-bit integer, because there are decoders, both software and hardware, that might truncate extra bits, causing distortion. So it seems that your choice depends on the capabilities of your target audience. Personally, I use 32-bit float for signal processing, but end up with 16-bit TPDF highpass dither if the source has more bits or effects are added (except for resampling).

a) “It's probably a safer bet to encode MP3s from a 16 bit dithered file.” (video demo by Dan Worrall, sound engineer)
b) “Tests of various decoders demonstrated that they don’t all meet the standard.” (specs and observations)
c) “MP3 encoding breaks the statistical properties of dither noise, but it still helps a bit.” (opinion of Alexey Lukin, PhD, DSP engineer at iZotope)
• 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 #255 –
Quote from: john33 on
Well I'd question that meets any criteria related to 'modern'!

Hi John, hi Kraeved,

I think I caused the confusion here by being vague about "modern". I just meant "64-bit CPU on 64-bit OS". Thus testing on an older, but 64-bit capable x86-CPU (x86_64, with at least SSE2) such as the Intel Core 2 is still valuable, so the results Kraeved generated are still interesting to me!

These results are also in alignment with what Case found out on more recent Intel gear: It appears that 64-bit compiles of the C code are more efficient than the 32-bit compiles with the old ASM routines.

As such, I do wonder if it is worth retaining the ASM parts. Thoughts on this?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #256 –
I see no reason to remove the asm code. With Visual Studio 64-bit compile isn't as fast as the asm-enabled 32-bit version.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #257 –
Quote from: Case on
I see no reason to remove the asm code. With Visual Studio 64-bit compile isn't as fast as the asm-enabled 32-bit version.
Agreed. The GCC x64 compile is way faster than the VS x64 compile. Care to share the Makefile tweaks?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #258 –
Quote from: maikmerten on
It appears that 64-bit compiles of the C code are more efficient than the 32-bit compiles with the old ASM routines. As such, I do wonder if it is worth retaining the ASM parts. Thoughts on this?

Premature optimization makes no good. By releasing x64 version now, you gain a few seconds, but double the testing burden, which sometimes runs into tens of minutes. x86 of Helix encoder should not be deprioritized anytime soon, because MP3 isn't just for the rich and privileged, other parts of the world have much more modest technical means. Personally, I even don't use Opus for audiobooks and music, because the complexity of decoding drains the battery much faster. I believe we first need to demystify all the Helix options, adjust them as necessary (for example, activate -U2 by default and remove this flag), polish the interface, agree that we are all happy with the result, and only then release x64 version like the cherry on the cake.
• 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 #259 –
Quote from: john33 on
Quote from: Case on
I see no reason to remove the asm code. With Visual Studio 64-bit compile isn't as fast as the asm-enabled 32-bit version.
Agreed. The GCC x64 compile is way faster than the VS x64 compile. Care to share the Makefile tweaks?
Don't worry, about tweaks, I just made a GCC13.2.0 64 bit compile that runs about twice as fast as the VS 64 bit compile. It's AVX2 optimised

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #260 –
Since you are already rolling out the updated version of Helix MP3 encoder for public use, I believe its number 5.2.1 should be increased in the sources, on the help screen and in the LAME tag. The changes are significant, so it is more appropriate to use 5.3 instead of 5.2.2.
• 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 #261 –
Quote from: john33 on
Agreed. The GCC x64 compile is way faster than the VS x64 compile. Care to share the Makefile tweaks?

Sure. The very minor tweaks to the Makefile to cross-compile win64 executables on Linux are:

Code: [Select]
CC=x86_64-w64-mingw32-gcc
(use the mingw cross-compile toolchain)

and

Code: [Select]
LFLAGS=-lm -lstdc++ -static
(added -static so the necessary libraries are included)

This alone is sufficient to compile a neat hmp3.exe

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #262 –
Quote from: Kraeved on
x86 of Helix encoder should not be deprioritized anytime soon

Oh, don't worry, I don't at all propose we should sacrifice decent x86 (as in 32-bit) support. I'm merely trying to gauge whether this support is best provided by the old ASM routines (which restrict upgrades to better compilers) or by letting modern compilers optimize the C routines.

All of this, of course, also doesn't prelude better documentation and more user-friendly program messages.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #263 –
For further investigation on the 32-bit builds: Here's hmp3 compiled with GCC for Win32. One build targets i586 (Pentium), another i686 with SSE (Pentium 3). Are there significant speed differences to the Win64 compiles and VS2015 32-bit builds?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #264 –
The 32-bit asm variant is 11% faster than the i686-SSE build and 53% faster than the i586 version here.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #265 –
I have no experience with this particular encoder.  In testing builds with FLAC and FDK-AAC, GCC 12.2.x produced the fastest binaries, especially with the -ffast-math option. 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #266 –
Quote from: Case on
The 32-bit asm variant is 11% faster than the i686-SSE build and 53% faster than the i586 version here.

Thanks for testing! Can you give the enclosed i686-SSE build a try? I tuned the CFLAGS to not only *allow* SSE, but do floating point math only with SSE. (In my testing with Wine on Linux on AMD Ryzen, this turned out significantly faster)

Code: [Select]
CFLAGS_REL=-O3 -march=pentium3 -mtune=pentium3 -mfpmath=sse -fno-math-errno -fno-trapping-math -c -I$(SRC_PREFIX)/pub -DIEEE_FLOAT

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #267 –
* in.wav, 99 423 788 bytes
* hmp3case.exe, SHA256: 8fa71fba6624cde0772306d09c2d922fbe36039a9f6bb126d602aeec9f0110e4

Code: [Select]
-------------------------------------------------------------------------------------
  Command                                         Mean [s]        Min [s]   Max [s]  
-------------------------------------------------------------------------------------
  hmp3case.exe in.wav -V150 -HF2 -D               7.045 ± 0.025   7.020     7.076    
  hmp3case.exe in.wav -V150 -HF2 -U2 -D           6.877 ± 0.041   6.820     6.921    
  hmp3-i586.exe in.wav -V150 -HF2 -D              6.305 ± 0.035   6.255     6.346    
  hmp3-i586.exe in.wav -V150 -HF2 -U2 -D          6.313 ± 0.039   6.266     6.378    
  hmp3-i686-sse.exe in.wav -V150 -HF2 -D          6.290 ± 0.031   6.232     6.316    
  hmp3-i686-sse.exe in.wav -V150 -HF2 -U2 -D      6.307 ± 0.055   6.201     6.354    
  hmp3-i686-sse.v2.exe in.wav -V150 -HF2 -D       5.937 ± 0.035   5.879     5.978    
  hmp3-i686-sse.v2.exe in.wav -V150 -HF2 -U2 -D   5.911 ± 0.046   5.824     5.947    
-------------------------------------------------------------------------------------
• 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 #268 –
The second SSE version managed to be 11% faster than the asm build. GCC is quite impressive.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #269 –
Kraeved, Case, thanks for testing! This means we can compile faster-than-original 32-bit binaries for legacy-systems without having to rely on the ASM bits, thanks to modern compiler optimizations. I  added MinGW-based cross-compilation targets to the Linux Makefile.

As for hmp3 documentation: Would the HydrogenAudio Knowledge base (the wiki) be a proper place to start documenting hmp3?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #270 –
Quote from: maikmerten on
As for hmp3 documentation: Would the HydrogenAudio Knowledge base (the wiki) be a proper place to start documenting hmp3?

There is a separate subforum for wiki discussion, but my $2e-2 are
* why not? ...
* ... except it may "end" up like https://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification .

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #271 –
Interesting things happen to old helix here. It compiles fine with gcc 13.2.0.
A complete album encodes in around 5 seconds and this is not even multithreaded :)
Many thanks to all involved people for your work again!
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #272 –
A quick test here - 795MB .wav file:

Code: [Select]
VS2015-win32 with MASM - 15.52sec
GCC-13.2.0-win32       - 14.05sec
GCC-13.2.0-x64         - 12.09sec

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #273 –
Hello, old timer here.
Could someone please provide a Helix command line with appropriate parameters equivalent to Lame V2 vbr for use with Foobar?
Also, I'd like to ask if Helix is safe to use regarding bugs with software and hardware playback devices.
 
Thanks in advance.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #274 –
Code: [Select]
hmp3 input.wav output.mp3 -F19000 -HF2 -V115
should be somewhat -V2-comparable, at least in terms of bitrate and lowpass. At this bitrate, I expect results to be transparent in most cases, too, but your ears be judge on that.

So far, there are no reports of hardware/software player incompatibility.