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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #475
Thanks for the update and happy to hear you got it solved. ZoomText sounds very invasive if it can cause the system to slow down. Would be fun to figure out what the problem is, but the software seems to be expensive and I don't even see demo option.

@Case  - I mentioned before that I am legally blind, so Zoomtext is a vital piece of software for me to have in order to use the computer. 

You are correct, Zoomtext is expensive.  I purchase a Home license, which is a subscription based plan.  So I buy 5 years at a time for $500.  For me, it's wroth it.

You can download a trial version of Zoomtext, but the caveat is that it doesn't expire in a certain amount of days, but instead, it can only run 40 minutes at a time, and then the system must restart to reset the activation timer.

I am not quite sure why this is happening with Zoomtext.  To be honest, I've had other issues with other things and Zoomtext, and I'm usually told I'm the only one who reports such issues, or that the program I'm having issues with (in this case Helix) is NOT officially supported by the Zoomtext software.

I do know that Zoomtext mirrors the screen and obviously enlarges it.  So I believe there may be some type of mirroring driver installed so it interfaces with windows and the screen.  I know for a fact there are services running in the background.

My guess to as to why exiting Zoomtext didn't work, is because it isn't completely unloading everything in the background, so services, etc are still running.

Anyway, if you're interested in trying Zoomtext, it can be downloaded here:
https://software.vfo.digital/ZoomText/2024/2024.2402.66.400/5082DF51-83F9-4DC5-BE8B-545B0CCC1345/ZT2024.2402.66.400-Offline-x64.exe

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #476
Thanks for the link. I installed ZoomText inside a virtualized Windows 11 and tried triggering the machine freeze, but I don't see any difference in behavior with different hmp3 compiles. Putting a conversion job running for my entire FLAC library keeps the machine fully usable and I can abort the task without issues. I tested both GCC and clang compiles for a few minutes.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #477
Thanks for the link. I installed ZoomText inside a virtualized Windows 11 and tried triggering the machine freeze, but I don't see any difference in behavior with different hmp3 compiles. Putting a conversion job running for my entire FLAC library keeps the machine fully usable and I can abort the task without issues. I tested both GCC and clang compiles for a few minutes.

@Chase - I appreciate you taking a look.  Honestly, I have no idea. 

The only builds that works are the clang versions and VS2022 helix builds from @JoshuaChang.

I also find it odd that I can encode with LAME, Vorbis, FAAC, FDKAAC, Opus, Musepack and speeds stay consistent with no system hang...it's just so weird to me.

If I want to use Helix, I guess I'm going to have to use @JoshuaChang versions if he would be willing to provide future builds.

I just love the speed and quality of Helix, but I could also use LAME in the future as well.

@Chase - Quick question, are there quality differences between the original Helix and the current 5.2.3 version?  I know LAME tags have been implemented, and gapless playback, right?  But was just curious if there are any quality/speed improvements?

Thank you again for trying to troubleshoot with Zoomtext, I am very appreciative of the time you took to try and help!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #478
I reverted my hacky "less printf" workaround on the dev branch, because a) it was implemented poorly and b) clearly wouldn't be effective if -D (displaying no progress update) doesn't alleviate the issue.

Case, do you feel that your patch is the way to proceed?


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #479
To my knowledge there are no harmful side effects from it. You could verify that it fixes the insane slowdown when using a GCC compile through wine. If it does, I think it may be worth including.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #480
Hmm. The kbhit check for encoding canceling actually slows the encoding down a lot. That was the reason my clang compile didn't reach JoshuaChang's speeds. The abort-by-key-press check makes encoding take about 22% longer here.

I wonder if anyone would mind if it was nuked entirely. I know it isn't even implemented for linux and without the patch I attached earlier it only worked on Visual Studio compiles.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #481
Removing kbhit is something I also wanted to suggest. There's CTRL+c for that, and I think that one works across platforms and doesn't involve querying input via syscall.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #482
The abort-by-key-press check makes encoding take about 22% longer here.
Removing kbhit is something I also wanted to suggest. There's CTRL+c for that.

We can replace the interrupt by any key with Ctrl-C, but I believe we should
keep the hint on the screen, separate it with an empty line, and remove < >.

Before.
Code: [Select]
  <press any key to stop encoder>
  PCM input file: in.wav
MPEG output file: out.mp3

After.
Code: [Select]
  Press Ctrl-C to stop the encoder.

  PCM input file: in.wav
MPEG output file: out.mp3
• 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 #483
If there is a help text about Ctrl+C for interrupting then the program will also need a signal handler for the interruption. Otherwise Ctrl+C will just terminate the process hard leaving the output file in invalid state with incorrect headers.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #484
If there is a help text about Ctrl+C for interrupting then the program will also need a signal handler for the interruption. Otherwise Ctrl+C will just terminate the process hard leaving the output file in invalid state with incorrect headers.

I compared the behavior of different encoders when pressing Ctrl-C combo.

Monkey Audio, WavPack and NeroAAC report it was pressed:
a) Ctrl+C: MAC has been interrupted !!!
b) creating in.wv,   7% done...^C (that ^C is something, but not user-friendly)
c) Interrupted at 27 seconds... (27 seconds of what? Not the encoding time, but the source time)

WavPack does not leave an incomplete file.

Lossy encoders.

Code: [Select]
$ exhale 9 in.wav in.m4a
exhale - ecodis extended high-efficiency and low-complexity encoder
version 1.2.1 (x64, built on Dec 20 2023) - written by C.R.Helmrich
Encoding 44-kHz 2-channel 16-bit WAVE to low-complexity xHE-AAC at 192 kbit/s
Progress: --

$ faac in.wav
Freeware Advanced Audio Coder FAAC 1.30
Initial quantization quality: 100
Average bitrate: 64 kbps/channel
Bandwidth: 19293 Hz
PNS level: 4
Object type: Low Complexity(MPEG-2) + IS + PNS
Container format: Transport Stream (ADTS)
Encoding in.wav to in.aac
   frame          | bitrate | elapsed/estim | play/CPU | ETA
 2150/24275 (  8%)|  133.6  |    0.7/8.3    |   68.11x | 7.5

$ fdkaac -m5 in.wav
[3%] 00:14.838/09:23.627 (21x), ETA 00:26.297
654336/24855936 samples processed in 00:00.711

$ fhgaacenc in.wav
Progress:   7%

$ lame in.wav
LAME 3.101 (beta 3, Dec 16 2023) 64bits
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding in.wav to in.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
   400/21578  ( 2%)|    0:00/    0:24|    0:01/    0:53|   22.864x|    0:52
--09:13------------------------------------------------------------------------
   kbps        LR    MS  %     long  %
  128.0       64.8  35.2       100.0

$ lossywav in.wav
lossyWAV 1.4.2, Copyright (C) 2007-2016 Nick Currie. Copyleft.
Filename  : in.wav
Settings  : --quality standard
File Info : 44.10kHz; 2 channel; 16 bit; 09:23.62, 94.81MiB
Progress  :  2.11%; 1.2178 bits; 15.74x; 00:00.76/00:35.81

$ mpcenc in.wav
MPC Encoder 1.30.0 --stable-- (C) 1999-2009 Buschmann/Klemm/Piecha/MDT
 encoding file 'in.wav'
       to file 'in.mpc'
 SV 8, Profile 'Standard'
    %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
  7.4  164.1 kbps 26.94x     0:41.5    9:23.6     0:01.5    0:20.9     0:19.3

$ neroaacenc -if in.wav -of in.m4a
Nero AAC Encoder
Package build date: Feb 18 2010
Package version:    1.5.4.0
Interrupted at 27 seconds...

$ oggenc in.wav
Opening with wav module: WAV file reader
Encoding "in.wav" to
         "in.ogg"
at quality 3,00
        [  2,0%] [ 0m48s remaining] \

$ opusenc in.wav in.opus
Encoding using libopus 1.5.2-2-gdfd4175 (audio)
-----------------------------------------------------
   Input: WAV, 44.1 kHz, 2 channels, stereo
  Output: Opus, 2 channels (2 coupled), stereo
          20ms packets, 96 kbit/s VBR
 Preskip: 312
[|] 10% 00:01:00.12   20x realtime, 95.94 kbit/s

$ qaac in.wav
qaac 2.82, CoreAudioToolbox 7.10.9.0
in.m4a
AAC-LC Encoder, TVBR q91, Quality 96
[2.9%] 0:16.370/9:23.626 (21.0x), ETA 0:26.075
721920/24855936 samples processed in 0:00.780
Overall bitrate: 201.654kbps
Optimizing...done

$ qoa in.wav in.qoa
in.wav: channels: 2, samplerate: 44100 hz, samples per channel: 24855936, duration: 563 sec

Lossless encoders.

Code: [Select]
$ flac -7 in.wav
flac git-d2b24410 20240309
in.wav: 9% complete, ratio=0,512

$ mac in.wav auto -c2000
--- Monkey's Audio Console Front End (v 10.61) (c) Matthew T. Ashland ---
Compressing (normal)...
Progress: 8.3% (10.7 seconds remaining, 1.0 seconds total)
Ctrl+C: MAC has been interrupted !!!

$ takc -e in.wav
in.wav                              ...

$ tta -e in.wav in.tta
TTA1 lossless audio encoder/decoder, version 2.3
Encoding: "in.wav" to "in.tta"
Progress: 20%

$ wavpack -x3m --threads in.wav
WAVPACK  Hybrid Lossless Audio Compressor  Win64 Version 5.7.0
creating in.wv,   7% done...^C
• 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 #485
Okay, so I'm tempted to a) first apply Case's patch regarding console output on Windows and then b) replace the kbhit()-cancel-encoding thing with a signal handler on CTRL+c. I think I'll try to work on this on the dev-branch.

edit: Patch by Case now on the dev-branch: https://github.com/maikmerten/hmp3/commit/99d932325944eb0d6896876c334a304c114f3bc5

Will now experiment on how to properly react on ctrl+c


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #487
The dev version is slightly, but consistently faster on my Linux machine. 
CPU: Ryzen 5850U
WAV: 1h 43m

Code: [Select]
./hmp3_main -V150 -T50 -HF2 Fragile.wav Fragile.mp3 = 13.018s
./hmp3_main -D -V150 -T50 -HF2 Fragile.wav Fragile.mp3 = 12.914s
./hmp3_dev -V150 -T50 -HF2 Fragile.wav Fragile.mp3 = 12.609s
./hmp3_dev -D -V150 -T50 -HF2 Fragile.wav Fragile.mp3 = 12.519s

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #488
Very good, should improve performance with all Windows compiles.

Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #489
I thought ^C was baked into the OS (at least with Linux/Unix OSes) and would interrupt any process.  I also never expect it to leave the output in a clean state.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #490
@Case thanks a lot for noticing and providing a fix, now pushed onto the dev-branch: https://github.com/maikmerten/hmp3/commit/4e16101b85cdd5171a85facaf3ea9be4327712da

@Replica9000 CTRL+C indeed is baked into the usual operating systems. It sends a signal to the executed program (SIGINT). Programs can choose to react in any way they deem fitting. With the recent changes, hmp3 chooses to stop encoding in a "graceful" manner.

The speed increase on the dev-branch most likely is from now compiling with link time optimizations (-lto flag).

Btw, here's hmp3 encoding my test CD album of choice:

Code: [Select]
real	0m9,585s
user 0m9,436s
sys 0m0,140s

And this is Ubuntu's Lame 3.100 binary decoding the resulting MP3 to WAV:

Code: [Select]
real	0m10,609s
user 0m9,297s
sys 0m1,288s

In real-time, hmp3 is faster *en*coding than Lame is *de*coding ;-)

(ffmpeg's MP3 decoder appears to be twice as fast)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #491
Very good, should improve performance with all Windows compiles.

Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.
Finally, the gcc's speed is identical to clang's build, thank you @Case, I do believe this patch will also solve @KevinB52379's Zoomtext compatibility issue.
Here's the dev binary(include both gcc and clang) for test purpose.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #492
The difference on my 5900x, foobar, multithreaded is still there and roughly the same as with my own compiles.
hmp3_gccdev.exe 4523.77x realtime
hmp3_clangdev.exe 4709.86x realtime
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #493
Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.

I analyzed the incomplete MP3 files created before and after this edit of yours using MP3GuessEnc. It provides a lot of information about the file, but I was disturbed by the line regarding the error in the header. What do you think about it?

Code: [Select]
 $ busybox.exe timeout -s kill 1 .\hmp3chang20240414.exe in.wav chang1.mp3
$ mp3guessenc.exe chang1.mp3
...
0 header errors.

$ busybox.exe timeout -s kill 1 .\hmp3chang20240426.exe in.wav chang2.mp3
$ mp3guessenc.exe chang2.mp3
...
1 header errors.

$ busybox.exe timeout -s kill 1 .\lame3101b3.exe -V0 in.wav lame.mp3
$ mp3guessenc.exe lame.mp3
...
0 header errors.
• 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 #494
Your timeout command sends SIGKILL, not SIGINT. This will terminate the encoder immediately, giving it no chance to update the header accordingly.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #495
Very good, should improve performance with all Windows compiles.

Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.
Finally, the gcc's speed is identical to clang's build, thank you @Case, I do believe this patch will also solve @KevinB52379's Zoomtext compatibility issue.
Here's the dev binary(include both gcc and clang) for test purpose.

@JoshuaChang - Thanks for providing the developer binary of Helix.

I tried both binaries.

The "hmp3_clangdev.exe" binary works fine.

The GCC binary causes the hang.

To be clear, the encoding process still goes on, but it's like my screen doesn't get refreshed.  So for example, foobar shows the first group of files being encoded, but then the list never refreshes.  The progress bar does keep going, but it's slower and I am unable to hit Abort.  My system becomes unresponsive, and the only way I can get it to go again is hit the power button on my computer and then windows shuts down (not the press and hold power button to force a shard shut down).

So the clang version works perfectly, and I noticed it's a little faster too this time around.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #496
Very good, should improve performance with all Windows compiles.

Now that we discussed about invalid file state with interrupted encoding I noticed that the Xing header isn't correct in that case. Here's a patch for dev branch to fix that.
Finally, the gcc's speed is identical to clang's build, thank you @Case, I do believe this patch will also solve @KevinB52379's Zoomtext compatibility issue.
Here's the dev binary(include both gcc and clang) for test purpose.

@JoshuaChang - Thanks for providing the developer binary of Helix.

I tried both binaries.

The "hmp3_clangdev.exe" binary works fine.

The GCC binary causes the hang.

To be clear, the encoding process still goes on, but it's like my screen doesn't get refreshed.  So for example, foobar shows the first group of files being encoded, but then the list never refreshes.  The progress bar does keep going, but it's slower and I am unable to hit Abort.  My system becomes unresponsive, and the only way I can get it to go again is hit the power button on my computer and then windows shuts down (not the press and hold power button to force a shard shut down).

So the clang version works perfectly, and I noticed it's a little faster too this time around.
Well, maybe the microsoft link signature(5007) is still part of the key, all the x64 binary that didn't hang you system have 5007 signature.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #497
File header flags might cause something like antivirus scanner to treat the binary differently, but ZoomText doesn't see that information. I didn't expect ZoomText to care about or see hmp3.exe at all, but Process Monitor shows that it actually does query the filename with https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-query-information during foobar2000 converter use. Details info shows only QueryNameInformationFile, which I believe translates to asking for https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_name_information. These calls take less than one millisecond.

I installed ZoomText now also in Windows 10 virtual machine, same story. Absolutely no problems visible.

I may try on real hardware if I get extra energy. I'm prepared that getting rid of the program fully will require nuking the system.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #498
So many builds! So at the end, can anyone recommend a build which should work fine and fast with any CPU made during the past 12 years ?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #499
So many builds! So at the end, can anyone recommend a build which should work fine and fast with any CPU made during the past 12 years ?
If you don't use vintage windows versions the clang builds of @JoshuaChang don't use fancy CPU extensions or fast-math and are as fast as it gets for that.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!