Skip to main content
Recent Posts
Opus / Re: Opus gapless and glitchness encoding
Last post by j7n -
The original implementation for replaygain in opus would not cause clicks as the album gain would be used by default. It did cause playback to be 5 dB lower outside of Foobar going against the ca. -18 dB RG standard established for over 10 years, and even earlier as it approximately matches levels on old CDs too. The header gain isn't even supposed to be at R.128, and could be chosen freely. But that is in the past as now R128_ALBUM_GAIN can be used, at the expense of compatibility with players that don't support it, which the original method gave for free – but at wrong reference level.

Opus is quite a bit worse than other codecs in gaplessness with flawed source material with low frequency osscillations or DC offset. Those are errors that should be fixed at the source, if they are noticed. But it would be nice if a fully gapless Opus encoder (in Foobar or similar GUI program) could deal with this and the same time improve the samples by filtering the DC.
Opus / Re: Opus 1.3 is out!
Last post by jmvalin -
Different optimizations -> different order of floating-point instructions -> different results.
For example, (a+b)+c usually is not the same as a+(b+c).

Actually, that's one of the few things compilers are *not* allowed to do when optimizing. OTOH, the compiler *is* allowed to use more bits than required by the program (especially on old x87 FPUs that had 80-bit float, but I think even for 32->64 bit float). Also, Opus uses transcendental math functions (sin, exp, log, ...) that are not required by the relevant standards to be accurate down to the LSB rounding. I suspect there may be a few other details that can cause differences, but the order of operations definitely must be preserved, otherwise overflows and underflows could cause massively wrong results.
Opus / Re: Opus 1.3 is out!
Last post by lvqcl -
But i really don't understand how it can impact on the result of the program (opus algorithm in this case).

Different optimizations -> different order of floating-point instructions -> different results.
For example, (a+b)+c usually is not the same as a+(b+c).
General - (fb2k) / Re: Reading codec info in some video files
Last post by wcs13 -
OK, I have been though some testing, and it's not easy as it seems :

1. First, let's all understand that I've been through hundreds of hours of painful tagging to get all my actual "!.tags" files. So just deleting their contents and starting over is out of the question

2. I would have thought that foo_tags could automatically rename the existing "!.tags" files into "[filename].tags", but that's not what happens

3. So far, on a "TEST" root folder with some subfolders, I have managed to create "[filename].tags" files for every individual video file. Of course my existing "!.tags" files remain.

4. So now, how could I safely transfer all the information from my "!.tags" files :
- To the corresponding "[filename].tags" files in the same folder, when there is only ONE video file in that folder ?
- To all the "[filename].tags" files in the same folder, when there is more than one video file in that folder ?
That looks quite impossible to me.
3rd Party Plugins - (fb2k) / Re: R128Norm
Last post by kode54 -
R128Norm is a dynamics compressor, by definition, but not the same as some compressors. For instance, it's not a multi-band compressor, so it only affects perceptible volume level to be approximately the same, using a running average that collects over a small window, and ramps the result smoothly. It won't adjust the frequency response of different frequency bands, but yes, it does try to flatten out the overall dynamics of whatever passes through it.
General - (fb2k) / Re: [Feature request] Sort DSP presets alphabetically in DSP switcher in toolbar.
Last post by kode54 -
Hence why I was wondering how he handled the sorting issues. Typically, you have to do a lot more than just enabling sorting on the Droplist control. You have to internally sort them yourself, using a qsort or similar with a proper string sort algorithm, and each string must be paired with an identifier indicating its original position in your internal list. You could use a full structure and store the full DSP GUID in there, or you could keep the GUID in an unsorted array and store just an index integer in the sorting structures.

Either way, simply using sorted Droplists is Completely Broken, because while the dialog automatically sorts your strings, it doesn't keep any sort of unique identifier to go with your strings, so they're still 0-indexed based on their actual position in the auto-sorted list. I've already had to deal with Crap Like This at least once, so that I learned how to do proper sorted associative arrays for Droplist values.

Now, if you want to look at A Complete Fracking Mess, see: foo_midi configuration for which driver to use. It has so many fracking special cases just to deal with preset indexes in the list versus in configuration option. I really should just make a string or even GUID parameter for each of those things, and overhaul the entire preferences and preset system. Yuck.
Opus / Re: Opus 1.3 is out!
Last post by ThaCrip -
I see using Foobar2000's 'Encoders Pack', which is 32bit, vs the the 64bit one the OP linked to...

-Encoders Pack version (which is 32bit) reports as... "opusenc from opus-tools 0.2"
-The x64 one the OP linked to reports as... "opusenc from opus-tools 0.2-3-gf5f571b"

but for 'Tool' they both report as... "libopus 1.3, libopusenc 0.2.1"

I assume this is a non-issue? ; I am using Foobar2000 to do the encodes. there is a 1byte difference in file size.

p.s. the Foobar2000 Encoder Pack version, which is 32bit, encodes a 64kbps Opus v1.3 file at 66-67x. the 64bit one the OP linked to does that same file encoded at 64kbps at 80x speed. I got a i3-2120 CPU. NOTE: I converted from the same FLAC level 8 file to Opus v1.3 for this quick speed test of the 32bit vs 64kbps versions I mentioned.
SimplePortal 1.0.0 RC1 © 2008-2018