Live data from Hacker News

TSAC: Low Bitrate Audio Compression

bellard.org

81–90 of 101 posts

Re: TSAC: Low Bitrate Audio Compression

#81
post #36

Earlier quoted context omitted.

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 don't seem to be able to access your page, so there might be error. Interesting, do you have javascript turned off? Can you access this page? https://html.non.io/TSAC-Comparisons/

The page works, earlier when I tried I got a login page. This page is good.

Also awesome to see comparison to EnCodec , which I think is one of the better ones available : https://ai.honu.io/papers/encodec/samples.html

Also, can you confirm if Opus decode is classical or with Lace or NoLace post processing filters that are available in Opus 1.5?

Re: TSAC: Low Bitrate Audio Compression

#83

Clicked the download link wanting to take a look at the source... and was a bit perplexed before quickly canceling it. 237MB, compressed , for an audio codec!? At that point one can't help but think that the samples are already in the decoder itself. I wonder how it compares to https://en.wikipedia.org/wiki/Codec2 and related codecs, which go even lower for bitrate.

But thats the point of it.

Re: TSAC: Low Bitrate Audio Compression

#85

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

The first track's corruption sounds to me a bit like the intro to "Knuckles" by The Presets.

Re: TSAC: Low Bitrate Audio Compression

#86

Are there standard-ish codec comparison processes that we can run to see how much perceived fidelity is lost in compression here?

Perceptual codecs must almost by definition be perceived. So the “standard” comparison is an ABX listening test.

Ah, so not like movie or image encoding where we have perceptual scoring algorithms that evolve over time. Thanks!

Re: TSAC: Low Bitrate Audio Compression

#87
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…

Which Opus settings did you use? Note that Opus recently got new ML features: https://opus-codec.org/demo/opus-1.5/

Re: TSAC: Low Bitrate Audio Compression

#88

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

If you use simple encoding (e.g. uncompressed bitmap), your archival capacity will be extremely limited, esp. if you use low-density medium (optimized for longevity). There's an obvious trade-off between encoding complexity and how much can you archive.

One approach would be to have a layered strategy - simple (but inefficient) encoding for an initial set of data, accompanied by a bootstrap for the next level which would unlock access to a much larger collection of efficiently stored data.

Re: TSAC: Low Bitrate Audio Compression

#89
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…

Another useful model to compare to would be DAC https://github.com/descriptinc/descript-audio-codec

This is the codec that TSAC extended, so it could be a nice comparison to see. I'd also echo Vocos (from sibling comment), it operates on the same Encodec tokens but generally has better reconstruction quality.

Re: TSAC: Low Bitrate Audio Compression

#90
post #26

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…

Opus doesn't support 44.1 kHz because compatibility and effort/benefit ratio:

https://github.com/xiph/opus/issues/43

The browser audio limitation is presumably a workaround to some bug or performance limitation that was relevant at some point in history (the site was created in 2014).

Post reply on HN