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.
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.
Last post by kode54 -
It does, however, mean "Potentially perfect audio", in the sense that it technically could be a high quality input, but it may not be. It just means that if the source of the file is not lying about it being high quality, then the FLAC format itself won't damage the quality any more than the original source was already damaged in production.
Correct, it isn't some mystical guarantee of quality. What you put into it is exactly what you get out of it. Like archive formats that don't throw information away, it replicates its input exactly, with no additional loss. Recompressing it with these formats will also have no additional loss, and may only have added benefit of newer algorithms better compressing the data.