What does this -90db mean anyway? Does it take 100db as default value and anything below 10db gets cut away? Really wonder.
The reference level is digital fullscale. -90 dB means anything with absolute sample value of about 0.0000316 (on a scale from 0...+1) is considered silence. With 16 bit material the lowest sample value that isn't silence is -90.31 dBFS.
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.
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.
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.
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.
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.