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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #500
After getting rid of the slow printing GCC compile seems to be faster here on Intel CPU.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #501
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.
Define vintage Windows versions. The build will be used on PCs running Windows 7, 8.1 and 10 with Intel CPUs from 4th gen up to 9th gen. Mainly Windows 8.1 and 10, I must say.


After getting rid of the slow printing GCC compile seems to be faster here on Intel CPU.
So this one ? : https://hydrogenaud.io/index.php/topic,123331.msg1043493.html#msg1043493

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #502
Define vintage Windows versions. The build will be used on PCs running Windows 7, 8.1 and 10 with Intel CPUs from 4th gen up to 9th gen. Mainly Windows 8.1 and 10, I must say.
The clang UCRT may run under 8.1 but not on 7.

After getting rid of the slow printing GCC compile seems to be faster here on Intel CPU.
So this one ? : https://hydrogenaud.io/index.php/topic,123331.msg1043493.html#msg1043493
Since on my AMD Ryzen it is the other way around you better speedtest your individual CPUs for best results.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #503
So this one ? : https://hydrogenaud.io/index.php/topic,123331.msg1043493.html#msg1043493
That was a test build for trying to hunt down the problem with KevinB's system, don't use that. It links against Universal CRT so it won't work without extra support libraries on anything older than Windows 10. Same is true with Clang compiles created in MSYS environment, so everything posted in this topic.

The GCC compile included in JoshuaChang this post: https://hydrogenaud.io/index.php/topic,123331.msg1043667.html#msg1043667 is proper one.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #504
Btw. to build a complete static binary under the clang64/UCRT enviroment it needs another "-static" in line 37 of the makefile.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #505
Thanks to you all :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #506
Btw. to build a complete static binary under the clang64/UCRT enviroment it needs another "-static" in line 37 of the makefile.
That statically links the MSYS environment libraries. It will still need Universal CRT dlls. I can build fully static clang compile with Visual Studio though.

Previously I had only benchmarked the compiles standalone encoding a single file. In that use GCC compile wins. But when used with foobar2000 in multiple threads, clang compile is faster here too. The difference is small but I may have to investigate at some point what causes it.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #507
Besides wanting to chime in to say thanks for all the hard work in bringing such a lightning-fast MP3 encoder back to life, just out of curiosity, I went about doing encoder identification of one of the newly generated files by using ancient audio-identifying programs (abandonware Audio Identifier and EncSpot): the earlier identifies it as 'Xing', while the latter says 'Gogo (after 3.0)' .

While I understand the Xing tag (Real Networks had acquired Xing Tech back in the day), is EncSpot simply showing its age by not yielding the right result or what?

PS: the psychoacoustic model employed by Helix is nspsytune, right?
Listen to the music, not the media it's on.
União e reconstrução

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #508
EncSpot might say "Gogo" because it sees a lame-kind header (in the Xing header if VBR) but not have the specific information that LAME has, so might asssume it was the Gogo version.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #509
I see. Thanks a bunch, @[JAZ]
Listen to the music, not the media it's on.
União e reconstrução

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #510
oh, I forgot to reply to your second question.

No. nspsytune means "Naoki shibata psychoacoustics tuning", and it's one of the tunings of LAME. Although currently I don't remember if they are used in the most recent versions of LAME or not.

Helix is a descendant of the Xing MP3 encoder. As you said, RealNetworks bought Xing, so it also got the encoder.
The changes that have been done to this encoder here in this topic are mostly about preserving and improving the user experience, not about sound quality (other than, maybe fixing bugs due to uninitialized variables or similar).

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #511
Maybe GCC 14 has changed something. @KevinB52379 may check the binary compiled with MINGW/GCC 14.1.0 i attached.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #512
Rough estimate without specific numbers.. this binary (GCC14.1) achieves on my particular Intel CPU 8.gen for encoding the wav file (24/44, length 1:20 hour) same speed as both Joshua's latest dev binaries (GCC13.2, Clang). The binary from the post #377 (from Wombat, GCC13.2) is with encoding of this particular file about 1/3 slower (ca. 185x vs ca. 122x).

At this point, I would like to thank Maikmerten, Case and the other programmers who contributed with their builds in this thread to the resurrection of this mp3 encoder, you guys are awesome!!

One note... I know that there have been various modifications and changes leading up to the current git version, so it's possible that this has been discussed in some part of this thread and is therefore known.. i didn't proven, if this "behavior" is consistent with every file, but converting the file with hmp3 causes an offset of approx. 24 samples at the beginning of given mp3 file while maintaining the overall length. In comparison, Flac and Lame encoders in their latest versions are completely identical to the original wav file.
In case I'm not "kicking the opened door" here, I'd ask for confirmation of this.. 
I'll just add that I noticed it accidentally when manipulating the file in the wav editor. Limiting the parameters for the encoder has no effect on this.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #513
There should be no offset difference. But most audio editors can't take the padding information in LAME tag into account to get the offsets and file lengths right. You can use at least current version of ffmpeg, lame or foobar2000 to decode MP3s correctly and verify the problem that way. With foobar2000 you can also use its Binary Comparator feature, it will automatically detect offset error in compared files and report it.
If there's an offset even with known good decoder, can you share what parameters you used to encode and what kind of source file? It's possible some exotic combination has gone untested and is bugged.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #514
Thanks for the reply, Case. To verify the problem, i did it previously partially as you described it. I compared original wav file to files encoded  using FB2K converter with flac and lame encoders from free encoder pack, that is under your maintenance. The given flac and mp3 files have an exact length and "shift" relative to beginning of the file as original wav file. The file given by hmp3 encoder (i tried 4 different binaries from last month, all give relative to each other exact same length and "shift", individually with FB2K converter or as standalone cmd encoding) is consistently with every wav file i tried, shifted approx. 25ms "to the right", though the file has exact same length as original wav file. As i write, this shift is consistent with every file i tried, therefore i doubt that this is a result of some exotic combination. Parameters are "basic":
- for FB2K converter;  -F18500 -HF2 -V150 - %d
- standalone cmd; hmp3 input ouput -V150 -HF2 -F18500
So  relative to each other, these two files are exactly the same and relative to original wav file they have exact same length, but at the beginning there are approx. 25ms "added".

I tried previously the binary comparator as well. Interesting is, it reports 0 offset!.. and of course with differencies found, as lame and hmp3 cannot give same results.
May be, that the tag info causes this, but i won't speculate here. To be true, i can't imagine, this cannot be confirmed by somebody else. And yeah, the binary comparator doesn't detect this shift of 25ms, so this may have specific explanation.. feature by design or bug.    

Edit: i'd like to correct my previous reply, where i mentioned "samples" instead of miliseconds, apologize for that.. my mistake.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #515
I verified your settings, they do not cause any offset issues. And sounds like you also saw that foobar2000 decoder reports there is no offset.
You don't mention what you use to see the offset. I'm not familiar with all audio editors in the world, but for example Adobe Audition / Cool Edit / Audacity can't open MP3s with the gapless info taken into account. You need to decode the mp3 first with a proper decoder like I mentioned in the previous post.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #516
It's indeed as you wrote. I also apologize for the "false alarm".
For viewing was used Isotope RX editor trial and when loading the file encoded via hmp3 the whole file is shifted 25ms to the right with the length being the same and thus the last 25ms was missing. I was misled by this. When converting the hmp3 file back to a wav file (as you wrote) the length and shift again corresponded to the original wav file. I didn't check this previously, sorry again and thank you! Somehow hmp3 is not recognized by this specific editor the same way as Lame mp3 is.. this misled me as well. Therefore, I did not see a possible problem at this point (Lame tag, gapless info etc.).

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #517
Maybe GCC 14 has changed something. @KevinB52379 may check the binary compiled with MINGW/GCC 14.1.0 i attached.

Thank you for the binary, i suppose it is generic build without "fast math" code. I do not want to compare here apples with oranges, but after trying the latest generic flac binaries from NetRanger (GCC14.1 & Clang18.1.4), the Clang version gives me consistently faster results for files 16-24/44 against GCC14.1 (5-8% speedup with Intel 8.gen CPU). I do not want to speculate about the reason, as i didn't done that much tests with various builds, so maybe Clang is rather constant through different versions, while GCC14.1 slowed down the performance slightly because of more complex changes..?
Can you please compile a generic Clang 18.1.4 binary of hmp3 with latest source code changes as well?     

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #518
No fast-math, no AVX and there were no changes to the code since last clang version from @JoshuaChang afaik.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #519
No fast-math, no AVX and there were no changes to the code since last clang version from @JoshuaChang afaik.

I was just unsure, which Clang version did Joshua used for his binary and if there would be a noticeable difference at all, if it was older..
Anyway, thanks for your reply!  

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #520
No fast-math, no AVX and there were no changes to the code since last clang version from @JoshuaChang afaik.

I was just unsure, which Clang version did Joshua used for his binary and if there would be a noticeable difference at all, if it was older..
Anyway, thanks for your reply!  

My lastest dev clang build was using clang 18.1.4; gcc build was using gcc 13.2, no additional compile flag.
All other clang builds have mentioned version on their name.

 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #521
Maybe GCC 14 has changed something. @KevinB52379 may check the binary compiled with MINGW/GCC 14.1.0 i attached.

I appreciate the effort....but no.  I was excited to try this new build with a recent update to Zoomtext, but no dice.

Only 3 versions successfully work and don't hang the system:
1.  Case's 32 bit build
2.  Joshua Chang's 2 builds he shared (clang and visual studio compile, I think?)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #522
In case no further fixes or optimizations in the code are planned in the near future, is it possible to consider the latest binaries (GCC13 and Clang by Joshua, GCC14 by Wombat) as current stable versions, or are there still some minor changes in the pipeline? I think that in the case of Kevin's Zoomtext issue, Joshua's Clang version is usable for him at the moment.
Good or bad.. till now i can't contribute with any, widely accepted bug report.

In regard the above, an additional, but offtopic (sorry) question for Case.. how likely is it according to you, that hmp3 will appear in the Free Encoder Pack some day? I think, Peter has to confirm it at the end..?

From user's perspective, i want to once again express my gratitude to Maikmerten, Case and the guys who contributed with their builds. From my subjective perspective and not least because of the encoder's performance, thanks to you guys is hmp3 IMHO definitely an alternative to the current version of the Lame encoder. Depending on preferences and priorities, hmp3 is better than Lame for someone, worse for another..

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #523
As far as I'm concerned, those builds should be plenty fine and can be called "stable".

There are further patches on the dev branch (Case's reworked progress printing, improved help messages, some safeguards against negative array indices in the encoder math), but nothing that invalidates the current builds.

edit: For those wondering why the dev branch isn't yet merged to the main/stable branch: I'm still trying to figure out why *downsampling* doesn't appear to work (in either main or dev). For instance, when requesting downsampling a 44.1 kHz input file to 32 kHz (hmp3 -A32000 test.wav test.mp3), the encoder goes haywire and crashes/segfaults. That's because when computing some array indices in l3math.c, the indices can get negative (the dev-branch guards against those negative array indices). However, that's most likely because the encoder is fed invalid audio data (with the negative-indices guards in place, I get silent mp3 files) and I haven't properly investigated out what's going on there.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #524
As far as I'm concerned, those builds should be plenty fine and can be called "stable".

There are further patches on the dev branch (Case's reworked progress printing, improved help messages, some safeguards against negative array indices in the encoder math), but nothing that invalidates the current builds.

edit: For those wondering why the dev branch isn't yet merged to the main/stable branch: I'm still trying to figure out why *downsampling* doesn't appear to work (in either main or dev). For instance, when requesting downsampling a 44.1 kHz input file to 32 kHz (hmp3 -A32000 test.wav test.mp3), the encoder goes haywire and crashes/segfaults. That's because when computing some array indices in l3math.c, the indices can get negative (the dev-branch guards against those negative array indices). However, that's most likely because the encoder is fed invalid audio data (with the negative-indices guards in place, I get silent mp3 files) and I haven't properly investigated out what's going on there.

Thanks for clarifying and for putting your and Case's effort into this project!