11–20 of 101 posts
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.
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.
The difference is that Codec2 encodes audio at 8 kHz sampling rate while this TSAC codec encodes audio at 44.1 kHz, which makes a pretty big difference in terms of audio fidelity.
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 for TSAC, which makes stereo in particular quite hard to listen to with the volume "flickering" in each channel independently.
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
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.
In a certain sense, maybe they are. Or more accurately, small fragments of samples, and just how to mix them together, is what is transmitted. It reminds me of pre-generated dictionaries with classic LZ compression. If an algorithm is going to work on mostly English text, then it might make sense to include an English dictionary with the algorithm. Brotli does this [Wikipedia]:
> Unlike most general-purpose compression algorithms, Brotli uses a predefined dictionary, roughly 120 KiB in size, in addition to the dynamically populated ("sliding window") dictionary. The predefined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents
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.
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 compression ratio as AVIF, but requires less processing power.
https://arxiv.org/abs/2206.07307 https://arxiv.org/abs/2210.13827
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 to H265/264 (the improvement of H265 compared to H264 in "transparent" encoding was pretty disappointing IMHO).
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.