Live data from Hacker News

TSAC: Low Bitrate Audio Compression

bellard.org

61–70 of 101 posts

Re: TSAC: Low Bitrate Audio Compression

#61
post #13

Always love a good bellard ship. This is definitely better than some of the others out there. I threw together some comparisons here at 7kb/s for mp3/opus/aac: https://non.io/TSAC-Comparisons Happy to add other comparisons if others want any. Overall, it's FAR better at these lower bit rates, but that doesn't mean it's necessarily good. One issue I see off the bat is that volume is fairly inconsistent in the output f…

Could you add VOCOS at 1.5, 3.0 and 6.0? https://gemelo-ai.github.io/vocos/

Re: TSAC: Low Bitrate Audio Compression

#62

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.…

> phone handsets and headsets don't have the power to do it in real time.

Until quite recently my phone was the faster computer I owned.

What phone cannot decode these?

Re: TSAC: Low Bitrate Audio Compression

#63
post #20

Earlier quoted context omitted.

That’s incredible, especially the second one that kind of creates a new song. I guess that’s the danger when it’s based on a generative model.

I like how it degrades in such an analog way

Reminds me of what it sounds like to tune an old FM radio

Re: TSAC: Low Bitrate Audio Compression

#65

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.…

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 .…

The only data that survives a civilization-level collapse is that which requires as little decoding as possible; in other words, plaintext. Future archaeologists aren't going to have a working copy of your GAN-based audio decoder. Translate your data into text (in as many major languages as possible), carve it into stone, and stuff it in a cave in the desert.

Re: TSAC: Low Bitrate Audio Compression

#66
> 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 seriously difficult. The Rapier physics engine could do it [0] at the expense of disabling simd and multithreading. It also works only on platforms that strictly comply to IEEE 754-2008 which I think that GPUs usually don't qualify (regarding subnormal numbers etc). Another thing that may have issues is fused multiply-add which may give higher precision than doing multiplication and addition separately (I think some platforms don't have FMA in hardware)

For example, it seems that TSAC currently runs on CPUs and nvidia GPUs. Could porting to AMD GPUs affect determinism?

[0] https://rapier.rs/docs/user_guides/rust/determinism/

Re: TSAC: Low Bitrate Audio Compression

#67

> 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.

Re: TSAC: Low Bitrate Audio Compression

#69
post #31

Earlier quoted context omitted.

Innovation goes in steps and iterations ;) When mp3 came out, I could just barely play a song encoded from 44.1kHz/16 bit stereo on my PC, taking almost 100% CPU. Today they can be played on a cheap microcontroller. I like that they share their work, it can lead to something some day.

MP3's were playable on cheap boom box stereos, and portable CD players, 20+ years ago. Such consumer devices capable of decoding MP3's appeared within less than half a decade of MP3 itself, by my recollection.

I think you are correct on that one. How long will it take to run this neural net on cheap consumer devices? It might take more than 5 years. But if all the new AI stuff is not a hype, but continues to be used, we will probably see hardware for running it on cheap circuits in a not to distant future. Maybe using a GPU+RAM like structure. Maybe the analog circuits with analog flash will win? The future will show us :)

Maybe add this URL to the calendar on today's date in 5 years an go back and reply with the answer :-D

Re: TSAC: Low Bitrate Audio Compression

#70

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.…

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...
Post reply on HN