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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #225 –
 :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #226 –
Quote from: maikmerten on
What attribution do you like?

Perhaps the proper attribution would be the umbrella term "Hydrogenaudio members" that I proposed in the redesigned Helix screen? @john33's contribution is that he compiles builds using alternative chains (sometimes this gives more stability, compatibility with older hardware, speed), provides ad-free & hegemon-free space for uncapped downloads, and also chronicles the origins of audio tools, Helix included. Besides, the developer implements not only his own ideas, but relies on feedback, shared samples and rigorous testing, which is what local passionate users like me do.
• 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 #227 –
Okay, after some testing on Linux I now merged Case's patches to the main branch and also included John's project files. Thanks for the contributions!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #228 –
Quote from: Kraeved on
Perhaps the proper attribution would be the umbrella term "Hydrogenaudio members" that I proposed in the redesigned Helix screen? @john33's contribution is that he compiles builds using alternative chains (sometimes this gives more stability, compatibility with older hardware, speed), provides ad-free & hegemon-free space for uncapped downloads, and also chronicles the origins of audio tools, Helix included. Besides, the developer implements not only his own ideas, but relies on feedback, shared samples and rigorous testing, which is what local passionate users like me do.

There are two dimensions to "attribution". One is to satisfy the terms of the Open Source license, to ensure it is documented who came up with the actual code (and thus has the copyright to parts of the code base). The other dimension is being nice and thankful by recognizing contributors. As you pointed out, there are contributions that are not strictly lines of code and also deserve recognition. As such, I think it'd be very fair to have a "with input from HydrogenAudio contributors" message in there.

edit: Added "With contributions from HydrogenAudio members." to hmp3 welcome message.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #229 –
@maikmerten Added where and why now? The last couple of pages convince me that the development takes place here, not on Github or anywhere else: new ideas are proposed, implemented, compiled and tested daily. In particular, @Case is now double-checking float operations and considering a proposal to a long overdue redesign of Helix screen, which also includes a new way for listing contributors. Methinks, it was worth joining the discussion or waiting until the end of this iteration before migrating the code, so as not to create two points of competing edits.
• 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 #230 –
It's standard software development practice to commit source to a proper version control. In fact, the source code Case has been basing his improvements on came from that very same GitHub repository.

This is not in any way about shifting discussion over to GitHub. Discussion is here. Keeping the repository updated is about making sure that the work done here is not lost and available in a proper fashion.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #231 –
@maikmerten - Any plans on setting up your GitHub so that you get compiles of your 'own' that gets added under Releases?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #232 –
Quote from: NetRanger on
@maikmerten - Any plans on setting up your GitHub so that you get compiles of your 'own' that gets added under Releases?

That sounds like a generally good idea, just need to tinker around how this is accomplished :-)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #233 –
Quote from: marc2k3 on
Maybe look at setting up appveyor CI on github. It looks like they still support VS 2015 unlike github itself which only supports 2019/2022. It's free for open source projects.

appveyor indeed looks promising and it indeed has a VS2015 environment.

@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?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #234 –
Quote from: maikmerten on
Quote from: NetRanger on
@maikmerten - Any plans on setting up your GitHub so that you get compiles of your 'own' that gets added under Releases?

That sounds like a generally good idea, just need to tinker around how this is accomplished :-)

Think it's called github-actions or so, Just don't ask me how it's done. :D

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #236 –
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?
Not sure I follow, but the old project files (.dsp and .dsw) in /hmp3/hmp3 are redundant and that folder could be removed.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #237 –
Quote from: john33 on
Not sure I follow, but the old project files (.dsp and .dsw) in /hmp3/hmp3 are redundant and that folder could be removed.

Oh, didn't even notice the .dsp/.dsw - yeah, those look obsolete.

I was wondering why there are two .vcproj, though:

./hmp3/src/mp3enc_x86asm.vcproj
./hmp3/mp3enc_asm.vcproj

and if the one in ./hmp3/src/ is obsolete.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #238 –
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.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #239 –
Quote from: Case on
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.
Thanks, good to know. I just carried them forward without giving them any thought!!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #240 –
I took the liberty of removing outdated project files (.dsp, .dsw, .vcproj) via https://github.com/maikmerten/hmp3/commit/7b677743be5fdc8c9b3fa13e5db037ed57f3661c

On appveyor, I nearly got the automated Win32 builds working, "just" failing at the linking stage:

Code: [Select]
Build started
git clone -q --branch=main https://github.com/maikmerten/hmp3.git C:\projects\hmp3
git checkout -qf 7b677743be5fdc8c9b3fa13e5db037ed57f3661c
msbuild "C:\projects\hmp3\hmp3\mp3enc_asm.sln" /p:PlatformToolset=v140 /verbosity:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\cnt.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\emdct.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\filter2.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\hwin.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\l3math.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\pow34.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\sbt.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\xhwin.asm
  Performing Custom Build Tools
  Microsoft (R) Macro Assembler Version 14.00.24210.0
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
   Assembling: C:\projects\hmp3\hmp3\src\platform\win\i386\xsbt.asm
  amodini2.c
  cnts.c
  detect.c
  emap.c
  l3init.c
  l3pack.c
  pcmhpm.c
  setup.c
  spdsmr.c
  xhead.c
  Generating Code...
  bitallo.cpp
  bitallo1.cpp
  bitallo3.cpp
  bitalloc.cpp
  bitallos.cpp
  bitallosc.cpp
  mp3enc.cpp
  srcc.cpp
  srccf.cpp
  srccfb.cpp
  tomp3.cpp
  Generating Code...
cnt.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
emdct.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
filter2.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
hwin.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
l3math.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
pow34.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
sbt.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
xhwin.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
xsbt.obj : error LNK2026: module unsafe for SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
amodini2.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]
.\Debug\mp3enc.exe : fatal error LNK1281: Unable to generate SAFESEH image. [C:\projects\hmp3\hmp3\mp3enc_asm.vcxproj]

I guess that's some build settings thing that doesn't appear to be unsolvable...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #241 –
In VS, Project Properties, go to Linker/Advanced/Image Has Safe Exception Handlers/ and select 'No (/SAFESEH:NO)' from the dropdown.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #243 –
Insert the line:
<ImageHasSafeExceptionHandlers>false</ImageHasSafeExceptionHandlers>
beneath line 72 in mp3enc_asm.vcxproj

I'll update mp3enc_asm.vcxproj in the Rarewares download.

Edit: It's already there for the 'Release' build, but not for the 'Debug'.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #244 –
In that case, this..

Code: [Select]
msbuild "C:\projects\hmp3\hmp3\mp3enc_asm.sln" /p:PlatformToolset=v140 /verbosity:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"

probably wants to be...

Code: [Select]
msbuild "C:\projects\hmp3\hmp3\mp3enc_asm.sln" /p:PlatformToolset=v140 /p:Configuration=Release /verbosity:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #245 –
Indeed, selecting the Release profile now yields successful automated compiles. Neat!

Now I just need to set up packaging things.

edit: Okay, after some messing around, now there are automated hmp3 win32 builds over at https://ci.appveyor.com/project/maikmerten/hmp3/build/artifacts

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #247 –
Yeah, one month expiry, thus no permanent hosting solution. Deploying to GitHub releases is one possibility to keep things permanent.

In other news, I'm somewhat suspicious that the assembly code is a good fit for modern CPUs. It's 32-bit only and some of the assembly files look like slightly cleaned up compiler output of whatever ancient compilers they used.

With minimal tweaks to the Makefile, I can cross-compile 64-bit Windows executables with a somewhat modern GCC compiler.

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.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #248 –
@maikmerten

Setup: Core2Duo SSE3, HDD, Windows 7 x64.



I tested your binaries with hyperfine --warmup 3 --runs 6 "command"

01.wav, 26 494 164 bytes
02.wav, 99 423 788 bytes

Code: [Select]
---------------------------------------------------------------------------
  Command                               Mean [s]        Min [s]   Max [s]  
---------------------------------------------------------------------------
  hmp3 01.wav -V150 -HF2 -D             1.806 ± 0.008   1.797     1.819    
  hmp3 01.wav -V150 -HF2 -U2 -D         1.752 ± 0.018   1.723     1.769    
  hmp3-win64 01.wav -V150 -HF2 -D       1.516 ± 0.012   1.502     1.535    
  hmp3-win64 01.wav -V150 -HF2 -U2 -D   1.527 ± 0.010   1.515     1.540    
---------------------------------------------------------------------------

---------------------------------------------------------------------------
  Command                               Mean [s]        Min [s]   Max [s]  
---------------------------------------------------------------------------
  hmp3 02.wav -V150 -HF2 -D             6.709 ± 0.076   6.618     6.843    
  hmp3 02.wav -V150 -HF2 -U2 -D         6.459 ± 0.033   6.421     6.504    
  hmp3-win64 02.wav -V150 -HF2 -D       5.618 ± 0.045   5.548     5.675    
  hmp3-win64 02.wav -V150 -HF2 -U2 -D   5.601 ± 0.027   5.552     5.629    
---------------------------------------------------------------------------
• 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 #249 –
That is a 17 year old CPU and a 15 year old OS. What are you trying to demonstrate?