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.
Recent Posts
1
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
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.
5
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Porcus -
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.
7
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
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.
10
Support - (fb2k) / Re: foobar2000 for Mac: bugs & wishes
Last post by Guildencrantz -
Great features in today’s preview version, but:

Buttons in the redesigned properties window are slightly cut off at the top.

Saving Accurate Rip logs is fantastic, though I have two minor gripes:
1) it suggests .txt extention instead of .log
2) it uses Windows CRLF instead of Unix LF.