Skip to main content ↑ ↓

Notice

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.
Topic: LossyWAV + Flake? (Read 931 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LossyWAV + Flake?

Hi all. Did anyone here have success in using LossyWAV with Flake? (to be more precise, the version in ffmpeg). Last time I tried it didn't give me any space reduction. Is there an ffmpeg flag that I'm missing?

Re: LossyWAV + Flake?

Reply #1 –
Quote from: kurumigaming on
Last time I tried it didn't give me any space reduction. Is there an ffmpeg flag that I'm missing?
-blocksize <same as LossyWAV, normally 512>
maybe?

Don't expect wonders, the reference encoder has pretty much caught up with ffmpeg compression-wise. But then, neither were tuned for block size 512, so nice surprises might come up. ffmpeg slows down at those blocksizes, but if you are willing to wait for LossyWAV it shouldn't bother you.

(I don't remember precisely when you need LossyWAV's WAVE metadata to be stored (the reference implementation's --keep-foreign-metadata-if-present), but as far as I know you cannot get that with ffmpeg.)

Re: LossyWAV + Flake?

Reply #2 –
I just insert an extra metadata field into the final FLAC file, and then check for it in my batch processing script to prevent going over that file again. It works well enough for my purpose.
Good to hear that I'm not missing out on compression with libFLAC, but how about speed? Is Flake still faster than libFLAC? (ignoring flaccl since my server doesn't have a GPU)
 

Re: LossyWAV + Flake?

Reply #3 –
Quote from: kurumigaming on
I just insert an extra metadata field into the final FLAC file, and then check for it in my batch processing script to prevent going over that file again. It works well enough for my purpose.
It is not about tags. It is about the non-audio chunks in the WAVE files. You need that --keep-foreign-metadata switch (the --keep-foreign-metadata-if-present will not throw error if none are found) to get them stored as an APPLICATION block (not as Vorbis comment tags), and that is specific to the reference implementation. But it depends on whether you need it to recover LossyWAV's WAVE files with not only audio, but also these chunks. If you don't ... forget about it. If you do ...
* FLAC with --keep-foreign-metadata-if-present is "kind of a hack", you need to use it both upon encoding and decoding, and only with the reference software.
* WavPack will by default restore the WAVE file completely, so that is safer if you need it (use --blocksize=512); but, for hybrid lossy+correction file, you might as well use WavPack lossy (the -c switch on current version, -cb on previous) rather than LossyWAV.
* TAK will by default restore the WAVE file completely. Use -fsl512 for block size.


Quote from: kurumigaming on
Good to hear that I'm not missing out on compression with libFLAC, but how about speed? Is Flake still faster than libFLAC? (ignoring flaccl since my server doesn't have a GPU)
First: LossyWAV takes more time, at least if you tell it to put a decent effort into noise shaping. So I wouldn't worry about the subsequent compression time.
Second: ffmpeg 7 will multithread, using as many CPU cores/treads as it can find. That isn't always the best when you DEcode ( https://hydrogenaud.io/index.php/topic,125791.msg1044102.html#msg1044102 ) but upon ENcoding one can read a fixed number of bytes and get a fixed number of samples, so the overhead loss is less. If you use e.g. foobar2000 (which will spawn one thread per file), you do not want multithreading for each file. If you still want multithreading, you can use a git version of FLAC with the -j switch, https://hydrogenaud.io/index.php/topic,123176.msg1047701.html#msg1047701