Bellard strikes again... Are we almost converting music to MIDI at this point? As I understand it the model is learning the landscape of sound combinations that are interesting to humans and as such there will be no combination of raw bytes in the recorded file that will result in white noise (for example) being heard because this is never trained for. What if it was though?
TSAC: Low Bitrate Audio Compression
71–80 of 101 posts
Re: TSAC: Low Bitrate Audio Compression
#72Earlier 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
Re: TSAC: Low Bitrate Audio Compression
#73Earlier 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.
When MP2 came out, my computer was barely able to play a song in 44.1 kHz 16 bit mono. I think bitrate was 192 kbps, but not sure. (Later on I was so surprised MP4 didn't replace MP3!)
Re: TSAC: Low Bitrate Audio Compression
#74Always 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…
Re: TSAC: Low Bitrate Audio Compression
#75Re: TSAC: Low Bitrate Audio Compression
#76Always 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…
I've encoded xHE-AAC at 6 kbit/s mono, which is the closest match I could get. It performs much better and is widely supported (Android 9/iOS 13/macOS 10.15/Windows 11), although there are no free low bitrate encoders available yet. I used the Fraunhofer IIS Pro with EZ CD Audio Converter. It would be great if you could add it: https://filebin.net/x46m1x7n6d2t7e6b
Re: TSAC: Low Bitrate Audio Compression
#77Earlier quoted context omitted.
When MP2 came out, my computer was barely able to play a song in 44.1 kHz 16 bit mono. I think bitrate was 192 kbps, but not sure. (Later on I was so surprised MP4 didn't replace MP3!)
If you thought it was weird that they went to video with MP4, imagine my shock that the next generation they got into firearms.
Re: TSAC: Low Bitrate Audio Compression
#78Earlier 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 .…
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
#79Earlier quoted context omitted.
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
#80Separately:
>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.
That's neat. So even though it's "AI-based" its output is guaranteed to be the same for a given input?