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 66180 times) previous topic - next topic
rutra80 and 6 Guests 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 –
Quote from: Wombat on
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.


Quote from: Case on
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 –
Quote from: Brazil2 on
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.

Quote from: Brazil2 on
Quote from: Case on
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 –
Quote from: Brazil2 on
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 –
Quote from: Wombat on
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 –
Quote from: Wombat on
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 –
Quote from: Wombat on
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!