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.
Recent Posts
12
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by ktf -
I didn't quite get the change, but is it so that the code checks that the residual fits a signed short, and when it does ... much faster?

When adding the 32bit PCM part of the encoder, I've amended the FLAC spec to include that all residuals must fit a 32 bit signed int. This is to keep decoding simple. The encoder must make sure this is done.

It is possible to calculate that for certain predictors, checking each residual sample separately is not necessary. When this is not possible, each residual sample must be checked, which is slower of course. This calculation was improved, so the slow process of checking all residual samples is needed less often.

I didn't know at the time 24-bit encoding would be affected, but it turns out that for signals with very little noise in the upper frequencies (= smooth signal) the predictor can be of a very high quality, which can lead to the residual spiking for parts of the signal where the predictor doesn't fit. This doesn't normally happen, but it needs to be checked anyway.
14
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
-5p from 105 to 36 seconds ...  ;D
I didn't quite get the change, but is it so that the code checks that the residual fits a signed short, and when it does ... much faster?
Has it made changes as to when it can select the 4-bit method?

How does -5e work? And with sizes for -5, -5e, -5p? Never mind whether there is any change in -5e, I am curious about the bang for the buck, and the comparison between -5e and -5p must have been tilted right now.
15
FLAC / Re: FLAC encoder for arm cortex m4f with limited memory
Last post by bryant -
Unless your tied to FLAC, WavPack might work for you. I created a tiny encoder a long time ago that should still be usable. It's used in Rockbox to this day (in fact I may have created it for that application) and encodes CD quality on far slower ARM processors than yours.

If that's still too much (the tiny encoder uses about 100 KBytes or so for code and data) I created another lossless compressor called SLAC that is very lightweight. The disadvantage of that is the files are not compatible with anything (there's not even really a file format, per se) but depending on your application that might not be an issue (it's lossless, so conversion could be done later off your device to something universal).
20
FLAC / Re: FLAC encoder for arm cortex m4f with limited memory
Last post by ktf -
There are a lot of FLAC decoders available, but only a few encoders.

How have you tried to get the reference encoder working? It is possible to strip quite a lot of parts, maybe that way it'll fit? Stripping the floating point parts is going to save a lot of memory for example.