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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #475 –
Quote from: Case on
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 –
Quote from: Case on
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 –
Quote from: Case on
The abort-by-key-press check makes encoding take about 22% longer here.
Quote from: maikmerten on
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 –
Quote from: Case on
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 –
Quote from: Case on
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.