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
2
Support - (fb2k) / FB2K 2.2 preview - Opus 1.5 LACE/NoLACE, DRED decoding?
Last post by Marsu42 -
The preview changelog 2024-03-08 states "Opus decoder updated to 1.5.1" https://www.foobar2000.org/changelog-win-2.2-preview

Opus 1.5 includes a new decoding feature (LACE/NoLACE) which is a postprocessing filter: https://opus-codec.org/demo/opus-1.5

However, the complexity on DECODING neets to be set to enable these - see https://hydrogenaud.io/index.php?topic=125597.msg1041651#msg1041651

There  now is a opusdec exe with the complexity set - see https://hydrogenaud.io/index.php/topic,125597.msg1041927.html#msg1041927

=> Does the libopus library in Foobar 2000 have this set to enable LACE/NoLACE decoding, and would you add an advanced option to set the decoder complexity (6 for LACE, 7+ for NoLACE)? Edit: This affects decoding the new DRED feature, too.
3
General Audio / Re: How do you test SACD audio dynamic range?
Last post by clintb -
I extract SACD ISO to .dsf then compress with WavPack in DSD mode. That goes into 32 bit foobar and is RG scanned and DR scanned. I don't use the DR component for a truthful indication of dynamic range; it's to get a sense of whether or not a particular release is similar or exact match to another.
4
Opus / Re: Opus gapless and glitchness encoding
Last post by Marsu42 -
Err, more than three years have passed.
Proof of concept by @Octocontrabass makes it gapless, official Opusenc does not.
How to get the case off the ground?

Is there a directly correspeonding bug ticket or feature request on gitgub for libopus or opustools?

I don't see anything except this one, last reply in 2020 - maybe the title "Pre-skip doesn't include extra_samples" isn't very inspiring to work on it :-) https://github.com/xiph/opus-tools/issues/55#issuecomment-641603262

The gist is that with opusenc you're out of luck except for a rather major change to encode multiple tracks at once - personally, I'm sometimes confused by features of libopus (in active development) and opus-tools (nearly no development anymore).

5
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.
9
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.