Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TSAC: Low Bitrate Audio Compression

bellard.org

Post reply on HN
Print view View original

41–50 of 101 posts

Re: TSAC: Low Bitrate Audio Compression

#41

Post by phoboslab »

thrdbndndn wrote: post #19

New advancement of media compression seems always focusing on low bitrate, be it audio, video or image. Which is totally fair given their applications, but I always wonder how much improvement they bring in high bitrate scenario. For example, are there codecs that have much better (perceptible) quality than Apple AAC 256kbps (or achieving similar quality at, say, 160kbps?) How much better are AV1 at 10Mbps compared t…

Kinda related, I was exploring how much complexity you really need with https://qoaformat.org/ - compresses at 278 kbits/s, but is much simpler than even MP2.

Re: TSAC: Low Bitrate Audio Compression

#42

Post by jjcm »

adamzochowski wrote: post #22
jjcm wrote: 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…

Since Ballard's codec is "AI" based, can you add google's lyrav2 ( https://github.com/google/lyra ) and Facebook's/meta EnCodec ( https://github.com/facebookresearch/encodec ). Also I don't seem to be able to access your page, so there might be error. Finally, when doing opus comparison it's good now to denote if it is using Lace or NoLace decoder post processing filters that became available in opus 1.5 (note, this…

Also I added EnCodec, but wasn't able to get the prereqs working for lyra2.

Re: TSAC: Low Bitrate Audio Compression

#43

Post by eternityforest »

kazinator wrote: post #25

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

Ham Radio enthusiasts love to do stuff with $1000 radios. If this can run on any reasonable laptop it could be amazing.

They're putting neural accelerators in everything these days, I wouldn't be surprised if they got it to where it could work on a phone, in which case you could do voice over Meshtastic.

Re: TSAC: Low Bitrate Audio Compression

#44

Post by ghusbands »

azinman2 wrote: post #14
XMPPwocky wrote: post #6

if you patch out the CRC check in the binary with echo -ne "\x90\x90" | dd if=/dev/stdin of=tsac bs=1 seek=23914 conv=notrunc you can corrupt the compressed files with very interesting results: https://meow.social/@mimir/112238998609778334 the fast mode (you don't have to patch the binary for this one, it seems to not do the CRC check?) and the normal (non-fast) mode sound different, but both quite interesting

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.

Note that the second one is actually a mix of different parts/songs.

Re: TSAC: Low Bitrate Audio Compression

#46

Post by kazinator »

Agingcoder wrote: post #38
kazinator wrote: post #25

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

Storage of large amounts of voice conversations for regulatory purposes ? ( say, a trading floor )

Since music quality / stereo are not required, a speech codec could be used. I think this TSAC outperforms most of them on raw bit rate, but not energy efficiency and speed. E.g. SILK goes down to 6 kbps; that could be a contender.

Or maybe you do want really good quality in order to fingerprint the voices. Vocoder artifacts can give parties plausible deniability (that's not my voice).

Re: TSAC: Low Bitrate Audio Compression

#47

Post by heavyset_go »

kazinator wrote: post #25

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

Am I missing something in thinking that this could be alleviated like every other compression algorithm by implementing it via a hardware codec?

Re: TSAC: Low Bitrate Audio Compression

#49

Post by vardump »

Max-q wrote: post #31
shvedsky wrote: post #28

Earlier quoted context omitted.

don't be such a debbie downer! celebrate it, and we'll find a use for that some day

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

#50

Post by ajsnigrutin »

kazinator wrote: post #25

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

Sometimes you have enough cpu and not enough bandwidth. Remote expeditions, rural schools in underdeveloped parts of the world, etc. You can stream a bunch of stuff (news, audiobooks, daily lectures, etc.) via (otherwise pricy) satellite links, and then a raspberrypi or whatever solar powered device can decode the audio without having to be real-time.

It's not a use for "everybody", but it might reduce the costs for those people who need this (or make new things viable).

Post reply on HN