91–100 of 101 posts
One of the DAC authors here (the codec that this builds off of). Very cool work! Would love to see some more detail on the modifications to DAC. Boosting the capacity with a transformer makes sense to me. Makes me happy to see DAC getting built on! Thanks!
An Nvidia GPU is necessary for fast operation. Compression is getting so heavy that soon it isn't possible to perform it on normal hardware. AV1 already proved that, the future audio/video codecs will be even heavier. Decompression is also getting heavier. Poor mobile devices. I'm starting to appreciate well written algorithms which don't require massive computing power. JPEG XL is a good example. It has the same com…
One of the DAC authors here (the codec that this builds off of). Very cool work! Would love to see some more detail on the modifications to DAC. Boosting the capacity with a transformer makes sense to me. Makes me happy to see DAC getting built on! Thanks!
Digital-Analog-Converter?
Earlier quoted context omitted.
I think the big use case is satellite telephony and satellite radio/audio/podcast play. You could do all audio applications off a 3KBit/s connection - that’s completely insane. It would probably have to be optimized a bit further though, both in terms of computing as well as size. Goal would probably be real time encoding on an iPhone SE without breaking too much of a sweat, and a encoder/decoder perhaps less than 20…
How does satellite telephony work? Alice calls Bob over satellite. Alice's telephone is on AC power, and contains a GPU cluster, and Bob's is the same?
This doesn't have much of a use case. - Can't use it in telephony (obvious application for low bitrates); phone handsets and headsets don't have the power to do it in real time. - Very small files of good quality would be useful in tiny embedded systems that have low flash space: but what systems of that type have the processing power for decoding? Very low storage more or less goes hand in hand with weak processing.…
> Can't use it in telephony (obvious application for low bitrates); phone handsets and headsets don't have the power to do it in real time. Not now but in another 5 years they will start to and in 10 years all new ones will probably have the power for this. I find it really exciting although it will consume more battery to run that; but if that is less than the radio antenna requires then it might make sense.
Earlier quoted context omitted.
> are there codecs that have much better (perceptible) quality than Apple AAC 256kbps (or achieving similar quality at, say, 160kbps?) Opus achieves ABX transparency at around 128kbps (as in, the threshold where the vast majority of users taking a fidelity test are unable to tell the difference between the opus-encoded and lossless version). https://abx.digitalfeed.net/opus.html
Thank you! The note there: > NOTE:Opus doesn't support 44.1kHz sample rates, so encodes to 48kHz sample rate. As this causes browser playback issues, it has been resampled back to 44.1kHz. This may affect the sound quality, so this test should be taken with caution. Is very surprising to me, in two ways. Firstly I knew 44100 is a relic due to historical reasons, but it's still a quite widely used sample rate in audio…
Earlier quoted context omitted.
Archiving over a long period of time might be a use case. I often wonder, how much of the data currently in circulation will be lost at some point? HDD/SSD last a couple of years. Most of the data in the cloud will be copied over, but some will be lost. If you extrapolate to a 1000, 1 000 000 years, how much will remain? Will something survive the civilization collapse? I guess most people don't care, but some will .…
No. Historical archives shouldn't use overly clever compression algorithms. Remember the JBIG2 fiasco. https://en.wikipedia.org/wiki/JBIG2#Character_substitution_e...
> The Transformer model is evaluated in a deterministic and reproducible way. Hence the result does not depend on the exact GPU or CPU model nor on the number of configured threads. This key point ensures that a compressed file can be decompressed using a different hardware or software configuration. How is this possible? Does it use floating point and concurrency? Cross-platform floating point determinism is serious…
It's possible but you have to make sure that floating point operations always happen in the same order (for example you could operate on blocks concurrently then merge them serially). You also have to be careful with optimizations like FMA because they produce a different result than multiply then add.
Reminds me of the old IBM 'RECOVC' codec from around 2000 where they compressed Mel-bank speech. https://ieeexplore.ieee.org/document/7075313 All the patents around that are long-dead so good time to do an updated version I guess. If you wanted to do something similar but with way lower bitrates (e.g. 300bps), then look at the NRV codec: https://www.researchgate.net/publication/224209493_300_bps_n...
Earlier quoted context omitted.
Am I missing something in thinking that this could be alleviated like every other compression algorithm by implementing it via a hardware codec?
It's a neural network, not a traditional compression algorithm. It would be difficult to implement this efficiently in an ASIC AFAIK, but if there are any hardware designers that disagree please chime in.
I think this codec could be optimized to run relatively efficiently on the various AI accelerator chips modern phones have, which is “kind-of” doing it in hardware.