My favorite song for testing these audio compression algorithms is Adele’s hello because any changes to her voice instantly pop out.
It did a great job of reducing FLAC size from 100mb to less than 1mb using stereo 24kbps preset but audio quality suffers a lot in some places. Maybe training it with 48kbps or 64kbps would make it a feasible alternative for storing music without much quality loss.
In comparison, lame insane preset (320kbps) produces 12mb mp3 with almost indistinguishable quality from flac.
I wonder how well this would work for the basis of a FLAC-like lossless encoder. FLAC works by approximating the audio stream with a lossy linear predictive code, and then storing the LPC encoding and its residuals (i.e. the delta between the original signal and its lossy approximation). It turns out that LPC+residuals are a lot more amenable to lossless compression (via Huffman coding) than the raw audio signal itself.
If the LPC were replaced with this neural network based encoding, would the resulting encoding+residuals also be amenable to lossless compression?
I think the main difficulty is that a neural decoder is allowed to make up lots of plausible phase information, which likely leads to pretty large L2 errors while retaining perceptual quality. So then you'll end up with large residuals even though you might only barely discern the difference perceptually.
The sound of the AI encoder is distinct and probably not suited for music at that bitrate, but would probably serve fine for Facebook videos and podcasts. I'd be really interested in seeing a model optimized to compress human speech...
Same system can be applied for repo owner being pattern provider and getting notified with matches but if i had to guess only enterprise customers might get feature like this
That’s called replacing your battery. All phone batteries degrade and start underperforming over the years. What Apple did only affects those people with years old underperforming batteries.
Batteries begin to degrade the moment you start to use them. All phones do this. Apple does not have some sort of magical technology to stop it from happening. No one does.
I wouldn’t expect a device that’s likely being drained and recharged daily to retain full capacity after two years. To suggest that shows a lack of understanding in the basic physics of a battery.
No company, Samsung, Google, etc. will “recall” your phone for normal wear and tear items like a battery. If that’s what you’re expecting, you’re going to be very disappointed.
I never claimed anything like. You demonstrate dirty sophistry there.
The issue is not that battery degrades, it is that their phones could not handle it and shut off when charge still remained. 2 years is a very little time. None of the devices with batteries I had exhibited that behavior. And I have devices that are over 5 years old in regular use.
Seems like blog post author is not aware of zig being able to cross-compile c and zig to any platform (and even glibc version) out of box without any additional toolchains
This is mentioned in the first post of the blog post series that is mentioned in the first sentence of the article!
The gist is, use `wasmer create-exe --target other-target-triple` to cross-compile with zig (if available) to the targets wasmer compiler backends (llvm, cranelift, and our custom "singlepass" backend) support.
Disclaimer: I am the author of those features/git commits.
