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.
I've now moved my entire MP3 library over to ID3v2.4 and also used the 'optimize file layout' function
Hello, can I do the same thing for mp3 files in mp3tag and what do I have to do? I need the ability to create tag with decoded audio MD5 in foo_audiomd5 and then the possibility of error-free reconciliation so that tag editing does not affect this checksum
I can't speak for MP3Tag, but it's achievable within Foobar. Right click on the tracks -> tagging -> MP3 tag types. Also within the right click menu is the optimize command.
When I edit tags, the checksum remains the same. The only times this won't work are:
1. Monkey's Audio format. 2. Where an MP3 file has lyrics embedded.
With (2), you may need to use a tool like MP3tag to properly remove them. I recall using the strip tags keyboard shortcut, followed by control-z to undo, and this rewrote the tags without lyrics.
One option that seems to make encoding painfully slow is the --analysis-apod option. [...] --analysis-apod tukey(5e-1);subdivide_tukey(47/1);gauss(5e-1);welch;connes
Forty-seven!? That's "hardly inexpensive" whether it is in analysis or in computation?
I threw a higher number in for the stress test. The previous test used almost identical command, without --analysis-apod and subdivde_tukey was at 37 instead of 47. That test only took 3½ hours to complete.
Are those flac builds actually using avx512? I only see source code for axv2, sse2, sse3 and sse4
One option that seems to make encoding painfully slow is the --analysis-apod option. [...] --analysis-apod tukey(5e-1);subdivide_tukey(47/1);gauss(5e-1);welch;connes
Forty-seven!? That's "hardly inexpensive" whether it is in analysis or in computation?
The OP seems to only want command line solutions, but I'll mention anyway that several resampler DSPs for foobar2000, including SoX Resampler, will extrapolate the signal at track transitions which pretty much fully eliminates all glitching. Faster option than the "Do not reset DSP" option mentioned by Bogozo. Also Advanced Limiter DSP will eliminate any potential clipping in a smart way without messing up loudness.
After some thinking and testing, I found that I like a CD release instead of a Vinyl one (more clear, no clicks nor noise and save me a headache of resampling) as long as they have the same mastering as for those which exist in Vinyl only I will download them locally and follow your advice. Also thank you for updating the Sox component for 64bit Foobar2000, I'm currently using it.
Last post by Piotr Fusik -
Thanks! I'd prefer to not setup a VM (and purchase an extra Windows license) just to test my foobar2000 components, which are decoders.
Wine claims The ARM64EC architecture is fully supported. WINEDEBUG=+relay tells me the installer is calling GetVersionExW. I found a way to make a step forward. winecfg opens a window where I can choose Windows 11. Now I get "Windows on ARM64 is required to run foobar2000 (ARM64EC)". Can you tell me how that is determined?
Last post by hat3k -
I would like to reopen this thread to highlight an ongoing issue. FLAC still copies the attributes of the original file to the output file, and this behavior has remained unresolved for years. In my opinion, it is inappropriate to propagate the "read-only" attribute to the output file since there seems to be no practical reason for this. We could implement minimal code changes to address this specific behavior (https://github.com/hat3k/flac/commit/32d70cf4144a4bbdb513c118ef90e544a2a64e25 ). However, should we consider a broader revision of this behavior?
I see two key tasks:
1. Stop copying the "read-only" attribute in all operations. 2. Introduce a command-line option "--ignore-read-only" to allow overwriting read-only output files (including when using the "-f", "--force" or "--delete-input-file" parameters).
Currently, FLAC behaves slightly differently depending on whether encoding or decoding is being performed, but in all cases, if the output file is read-only, FLAC cannot overwrite it.
This does not seem logical but for now this option copies "read-only" attribute and is on by default: