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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #300 –
These changes are only style- and safety-changes.

The memset for spd_cnt1Short shouldn't change runtime-behavior at all, as both spd_cnt1Short and spd_cnt have the same size, thus memset doing the same. This is only fixing a copy&paste oversight, and I fixed this to avoid confusion.

The memset for w_spdShort is more serious, as w_spd is a *bigger* buffer than w_spdShort and thus the memset would write zeroes beyond the boundaries of the w_spdShort-buffer. However, if the encoder doesn't crash during initialization, no effect otherwise is necessarily expected.

I checked before and after the changes, and the MP3 output remained identical.

As for providing fresh builds for whatever current git-state: Well, if several people keep their build-environment fired up, even if the changes are minimal, it is beneficial to know that no breaking changes were introduced by accident. I can only test on Linux and with whatever compiler version I have installed, so having another set of compiles available can be useful to gauge whether some recent work broke things.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #301 –
As I understand it, the latest version with reasonable and properly tested changes that can run on both x86 and x64 is the @Case's build 2024-03-20. After that, you went into micro-optimization, changing the makefile and now the memsets. This has already affected the size of mp3 files, so users may have a legitimate question: if the encoding algorithm is not changed, then why mp3 files are different from each other? We need to create a stable version so that users don't wade through dozens of pages, trying out every attachment, as it happens in some other forum threads.

Code: [Select]
bytes, xxhash, filename
270150 = 71f16bfc93121db3 = out-i686.mp3
270154 = 7658cb1d84627d25 = out-i586.mp3
270227 = dad23bd189aeb6c6 = out-git-fb6f2b2.mp3
270227 = dad23bd189aeb6c6 = out-i686v2.mp3
270230 = 284a80c89cdf720b = out-case.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 #302 –
The Helix MP3 Encoder is using floating point arithmetic (and LAME does, too). It's perfectly expected that there are slight variations in output depending on compiler version, compiler flags and platform. Rearranging floating point operations (that should be mathematically equal) can result in small (and usually inconsequential) differences in floating point values.

I don't expect hmp3 to generate identical files for Visual Studio, GCC 10.x or GCC 13.x, let alone if different instruction sets are involved.

i586 uses the x87 instruction set for floating point.
i686 uses the SSE instructions for floating point.
The Visual Studio compiles with ASM use a mixture of x87 instructions and SSE.
The Win64 x86_64-builds can use SSE(2)
I think Case's builds were AVX-enabled.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #303 –
The compilles i did with GCC 13.2.0 should create the same files in size.
It is only when i use AVX or fast-math that includes -funsafe-math-optimizations the output changes.
The rarewares x64 compile for example creates the same files as when i use fast-math.
I attach a compile that has both versions with exactly the same settings but fast-math if someone wants to check.
The question is if such optimization at some point changes the sound. I am no expert here but think to remember there once was a problem with a lame compile because of some compiler option.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #304 –
Quote from: Wombat on
The compilles i did with GCC 13.2.0 should create the same files in size.
It is only when i use AVX or fast-math that includes -funsafe-math-optimizations the output changes.
The rarewares x64 compile for example creates the same files as when i use fast-math.
I attach a compile that has both versions with exactly the same settings but fast-math if someone wants to check.
The question is if such optimization at some point changes the sound. I am no expert here but think to remember there once was a problem with a lame compile because of some compiler option.
I do indeed have fast-math enabled on both x64 compiles. I too recall a lame issue, I think with a particular Intel compiler option, but I don't recall which option, and it was in any case some many years ago.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #305 –
Quote from: john33 on
I do indeed have fast-math enabled on both x64 compiles. I too recall a lame issue, I think with a particular Intel compiler option, but I don't recall which option, and it was in any case some many years ago.
Thanks John. Maybe it was even only a bug in some compiler version.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #306 –
Dear developers, I listen to your every word with great attention and I am taken aback. Why do you use compilation flags which impact on quality you find difficult to assess? Since when did chasing fractions of seconds become more important than quality? We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway. If there is even the slightest chance that the quality could deteriorate in at least one frame by at least a bit, such compilation flag should be omitted. Aren't there other projects that can be turned into a proving ground? Helix MP3 encoder should be approached with care, in the spirit of restoration, as the title of the topic suggests.

• 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 #307 –
Quote from: Kraeved on
Dear developers, I listen to your every word with great attention and I am taken aback. Why do you use compilation flags which impact on quality you find difficult to assess? Since when did chasing fractions of seconds become more important than quality? We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway. If there is even the slightest chance that the quality could deteriorate in at least one frame by at least a bit, such compilation flag should be omitted. Aren't there other projects that can be turned into a proving ground? Helix MP3 encoder should be approached with care, in the spirit of restoration, as the title of the topic suggests.
It isn't that easy. @maikmerten already explained that compilers of different origin may change the output more as setting flags inside one and the same enviroment.
We need golden eared peoplle like you to find out if there is a way to tell them apart.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #308 –
Quote from: Kraeved on
We have an ancient code here that needs to be dusted off first, whereas you are in a hurry to attach wings to it so that it flies even faster, although it is already faster than LAME anyway.

The changes done so far are exactly that: Dusting off the codebase by fixing things that are clearly bugs (uninitialized variables, wrong buffer initialization). Such bugs can very much lead to unexpected crashes or distortions.

Nobody here is messing with the core algorithms. The compiler flag explorations are in some way a means to check that the codebase behaves reliably and predictably across platforms. The default settings always will tend towards the safe and reliable, but its good to know that even aggressive compiler optimization don't outright explode.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #309 –
Quote from: Kraeved on
compilation flags which impact on quality you find difficult to assess?
Nothing says they are any wrong. Nothing says that "no compilation flags" is any more correct than "these compilation flags".

16 bits is enough if done properly.
There is a common misconception that a floating-point number is "inaccurate". A floating-point number is a sequence of 32 given bits, but 32-bit floating-point numbers are adequate for when that is accurate enough - whether that is because the actual resolution is less and they are exact, or whether it means you have to perform an "acceptable" roundoff before fitting it into the 32 bits. (Like, try 1/3.) 
Floating-point arithmetic allow operations that might require round-offs for the result to fit a 32-bit number. Maybe this direction, maybe that direction - it is adequate when it is good enough.
And if it is good enough, than this CPU's platform's roundoff is good enough, and so is that platform's roundoff - even if the end-results are rounded off to different 32-bit floating-point numbers ...

... which, in themselves, are approximations of something that in this application is an approximation of your original signal.
Even if you dropped the latter "an approximation of", it would be good enough for audio processing (DAWs can do well with 32-bit floating-point!), and now it is even used to make a lossy file, which is a "manthematically very rough but audibly good enough" approximation to the original signal.

If you encode it on your computer and play it back on your phone, the different CPUs might differ in roundoffs in precisely the same way.


And the impact is much smaller than the lossiness of the encoder - unless a particular implementation is stupid, and if so is the case, you don't even know that "your" compiler flag set is not the stupid one.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #310 –
Quote from: maikmerten on
Nobody here is messing with the core algorithms. The default settings always will tend towards the safe and reliable.

I hope so. It is important to agree that in the case of Helix, despite the digressions to try this and that, a conservative compilation strategy is prioritized so as not to damage the explicit and implicit potential of this encoder. After all, what is Helix? It is the pinnacle of the engineering thought of its time, the product of an (almost) lost school of offline-first, non-bloated, good enough to survive decades without Patch Tuesday software, just as the pigment recipes with which medieval artists created their masterpieces were (almost) lost.
• 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 #311 –
Quote from: Kraeved on
potential of this encoder

What potential? Nobody is going to use this.
LAME's last quality update was over 10 years ago. Developers squeezed everything they could from MP3.
It is mature and stable encoder, tested by many experienced members here.
If you believe people will suddenly change to Helix you are wrong.

All I can see in this thread is developers wasting their time on something useless only to get yelled at in return.

Quote from: Wombat on
We need golden eared peoplle like you to find out if there is a way to tell them apart.

lol'd :)
gold plated toslink fan

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #312 –
Who knew some random MP3 encoder could make someone beyond passionate...
LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #313 –
Quote from: Markuza97 on
LAME's last quality update was over 10 years ago. Developers squeezed everything they could from MP3.

Yeah, it's very unlikely that significant quality improvement can be squeezed out of MP3 by either LAME or Helix.

Quote from: Markuza97 on
It is mature and stable encoder, tested by many experienced members here.

Too bad the latest LAME versions apparently regressed here and there. Always nice to have another option.

Quote from: Markuza97 on
If you believe people will suddenly change to Helix you are wrong.

All I can see in this thread is developers wasting their time on something useless only to get yelled at in return.

I think your view on what motivates people to tinker with code might be a bit too focused on the number of users. I can't speak for anyone else in this thread, but for me, it's been fun to speculate about parameters, tinker with compiler flags and reviewing and applying patches.

I hope that you, too, have a fun project, no matter its usefulness or size of its user base.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #314 –
Quote from: maikmerten on
I hope that you, too, have a fun project, no matter its usefulness or size of its user base.
Amen to that, it's what's kept me sane in the last 20years! ;)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #315 –
Quote from: Markuza97 on
All I can see in this thread is developers wasting their time on something useless...
I'm sure most people have some kind of hobby which would be seen as a waste of time by others.  Nonetheless, sometimes hobbies turn into businesses, or knowledge/skills gained becomes applicable elsewhere.

Quote from: Markuza97 on
...only to get yelled at in return.
This thread is (or has become) a discussion place for those interested in this project, and I personally have been monitoring it with little practical interest but as a curious bystander.  Anyone with no practical involvement has no business to criticise, and should keep out of the conversation (as I have... until now!).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #317 –
There was a misunderstanding.
I meant no disrespect to developers - totally opposite.

By useless I meant exactly what you guys said above - small fun side project with little to no reward that will be used only by small amount of people.
Poor word choice from my side.

My post was directed to Kraeved. I got mad with this post.
Quote from: Kraeved on
What is it? @john33, are you ready to put your reputation on the line and walk out the window if this change does affect the quality...
Quote from: Markuza97 on
only to get yelled at in return.

Instead of being happy that couple of developers are using their precious time to work on small project like this you are talking about John's reputation.
Member with rock solid reputation whose encoders have been pretty much standard for years.

Again, no disrespect to actual developers. I just don't like when "acting boss" tells actuals developers what to do and not to do.
gold plated toslink fan

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #318 –
@Markuza97 People gather for a variety of reasons: from weddings and funerals to hobby groups like reenactors and submissives. To understand why, in the 21st century, against the backdrop of so-called progress, someone builds a castle without the use of modern tools or voluntarily surrenders to the will of a dominant partner, it is more far-sighted to show the humility of an indigenous researcher and unobtrusively ask questions, rather than heating up the situation with frantic cries like “who needs these remnants of the past when the world is on the verge of exploring Mars”. The latter reveals elementary communication skills, close to those of a spoiled child, who considers his limited horizons to be certain and the incomprehensible to be ridiculous and outrageous. By regularly pouring arrogance out of the cup of consciousness, you are more likely to fill the vacated space with the idea that life is a symphony of diverse forces. In particular, what we have here is not and will not be a hierarchy with profanum vulgus (mob) that begs Prometheus (developers) to share the fire (updates), but a horizontal exchange of opinions between mature enthusiasts with different priorities, which sometimes includes nitpicking and assertive pushbacks (as in the case of me and John), but ultimately it makes Helix MP3 encoder better. Focus on that, and you will feel better as well.
• 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 #319 –
Do you genuinely have no idea how arrogant and patronising your manner is? It's actually quite breathtaking. You seem to think that it is OK to behave that way and at the same time insult in a quite creepy manner. Why say what needs to be said in a few words when you can take several paragraphs and spew BS along the way? "nitpicking and assertive pushbacks" you say. I found it quite offensive, to be honest.

I, for one, have had enough of you and will not again respond to any further comment that you post on this forum.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #320 –
@john33 Sorry to see that you don't notice your own nagging manner, which I've been tolerating for a long time. In particular, you reproached me for sharing the test results, and another developer had to explain to you that these results were acceptable. Then you stated that I had not checked Github before commenting and there were no quality-related commits in the last build, after which I had to post a screenshot of the very commit, and the same developer had to explain that it was serious, although tested. And now that BS word as an assessment. So who is patronizing here? You are not involved in development, testing, writing documentation, or thinking about the future of the project, so why are you so nervous about someone who does? Rewind a few pages and look at the respectful interaction between me and @Case, then ask yourself why it didn't work out between us, because I did my best, starting with a list of your merits.
• 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 #321 –
Quote from: maikmerten on
I took the liberty of writing something regarding the -TX parameter over at https://wiki.hydrogenaud.io/index.php?title=Helix_MP3_Encoder#Magical_Mystery_Switch_-TX

Thank you, @maikmerten.

a) Wiki says that -TX6 is used by default, but -H screen is missing the word default next to TX6 and -EC screen shows ec->test1 = 0 instead of 6 when no number is specified and -1 instead of 6 when -TX is not used at all. I believe the word should be added, but what do to with the number?

b) The last TX setting (eighth in a row) has no specific number on -H screen, it just says “v5.1  2005.08.09 (see CVS log for details)”. Have you found anything interesting there?

c) When Helix is called with -TX# -EC, we see “ec->test1 = #”. It accepts 0, positive and negative integers with no validation. Since we'll probably never know the essence of the experiments of the previous team associated with this flag and the default setting (-TX6) is recommended, maybe it makes sense to put it at the bottom of -H screen within a separate section like “--- Mysterious legacy (Read wiki for details) ---” to avoid potential questions from users?

Also, I noticed that you told the user which Helix settings (-V115 -HF2 -F19000) might resemble LAME -V2. Let me clarify, which transition band does Helix use in this case? For LAME 3.99.5o and 3.101 beta 3, it is 18000 Hz - 18581 Hz.
• 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 #322 –
My guess is that the -TX flag triggered different experimental settings at different times. Right now it only influences one function, as documented in the Wiki. The help screen is not actually clarifying what's going on there. Users that feel adventurous can tweak as they like and perhaps find cases where it makes a difference.

I'd hope that perhaps someone more knowledgeable in MP3 psychoacoustics may actually know what that particular function is doing, so we can clarify what is happening there.

The transition band is from the LAME page of the very same Wiki.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #323 –
Quote from: maikmerten on
Regarding -HF2, I'm not very worried. There are listening tests with -HF2 that show that Helix is doing plenty fine.

I've seen the results of 3 listening tests: -V60 (2008), then -V146 (2013) and -V111 -HF2 (2016) by @Kamedo2. In each case, Helix receives rave reviews. But nowhere is the choice of encoding options explained. Or rather, the use of -HF2 is explained by an attempt to resemble LAME behavior. And most importantly, I haven't seen a direct comparison between the regular mode and -HF2 yet. @Destroid shared an observation about the slight difference between -HF1 and -HF2.

Personally, listening to Helix's encoded music in the background (rather than focused) over the course of this spring 2024, I still can't think of a sample where the difference would be dramatic, although the increase in size is noticeable. Even a sample of harpsichord, kindly shared by @Porcus, sounds fine. Perhaps another listening test with more sound lovers involved would help to bring out the advantage of -HF2, or there would be a conclusion that its advantage is minimal and it rather distracts this robust but lossy encoder from clearly audible content.
• 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 #324 –
Quote from: Kraeved on

Perhaps another listening test with more sound lovers involved would help to bring out the advantage of -HF2, or there would be a conclusion that its advantage is minimal and it rather distracts this robust but lossy encoder from clearly audible content.

Perhaps you could do your own ABX test to see if you can hear the difference between HF1 and HF2 setting. This way you can eliminate any dilemma you might have. After all, personal preference is what matters the most.
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)