J7N

Maybe 7-Zip could try to apply a delta filter on all data, with a switch. Compute something like a "histogram" and check if the distribution of values became more favorable after delta, with small values around 0. Also a simple 16-bit delta would further improve compression. Plain WAV files are uncommon in archives. But sound and graphics data occurs within games, part of bigger files. Old games still exist; sometimes DDS is uncompressed even today. Competing archivers can generally handle this without...

One can use "MakeMKV". The process is a bit tedious, and involves a few copies. Matroska here serves as a vehicle for timing and cutting. You get a big Matroska file with chapters, which likely need to be adjusted so that they lie precisely before the start of a 'track', and not somewhere in the decay of the previous one. Then I'd remux with MkvToolNix. The resulting file can be kept that way, or split by chapters using MkvToolNix, and extracted with MkvExtractGUI to obtain MLP files. Currently Foobar...

The extension given by Dolby Encoding Engine is ".MLP". It is supported by your plug-in, but only if the data doesn't contain an atmos extension. I only expect the "core bed" to be playable. I've cut an 8 second sample. One stream is 7.1+atmos (does not play) and the other is 7.1 only (plays) http://j7n.sytes.net/temp/thd71/

TrueHD files with the Atmos extension are not recognized by Foobar. They do play after being reduced to the "core" using FFMPEG, except the estimated duration is way off. It is possible that the streams were not cut ideally to start with a valid frame, but I do not understand their structure. Could such files be supported? Alternatively, could the TrueHD codec in Matroska be supported? Keeping the format as MLP allows to retain the Atmos channels for the future.

Zstandard is needed to fill the speed gap between Fast and Store for temporary backups, and to provide fast decompression with a slow machine / large archive. The support should be in SFX to allow for distribution of this format. Other formats do not serve an immediate purpose. LZMA is already slow and high compression. Bandwidth and storage today are cheap, and data is more often "disposable" with software updating very often.

I did not know this option. I'm surprised to still learn something new about the basic cmd application. This will allow me to make a batch file. But it would still be nice to be able to use a generic file converter frontend with no/fixed piping options. The other request for Json output sounds nice, but any format is okay as I want to read the report by eye.

I would like a way of outputting the detection results to a file, which can be read after processing a batch of audio files, and searched for keywords like "resync" or "incomplete", instead of looking at the output of one file at a time. The text should be appended to this file, not like the ">" operator does, which overwrites. I have a frontend program that shows error messages output to stderr. (where "-b: unknown option" is written). Perhaps a command line option could send the normal output ...

Remember history of last entered Parameters