Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Recent Posts
3
Listening Tests / Re: Personal blind comparison of the Bluetooth codecs, AAC vs LC3, re-encoding
Last post by Brand -
1. Opus 128kbps being the Source. I think 256Kbps AAC or Opus would have been a better representation. Or straight up using lossless as original. Unless you are using the Web version on a free tier, subscription Music or even YouTube offers 256Kbps AAC files if not higher.
I kinda agree. I think using a lossless source would make the most sense.

I am assuming LC3 will have mandatory pass through on BT 5.2.
What makes you think so? Passing through a lossy stream directly is a significant technical and usability challenge, mainly because you can't mix OS sounds (you'd need parallel streams...). I doubt it's going to be a thing outside of hacky 3rd party implementations. The target audience for this feature is just too small.
4
Other Lossy Codecs / Re: exhale - Open Source USAC encoder
Last post by 1337Rainboom -
Exhale seems to be adding "scratchy" sounds to this section
Even by preset c it's still quite audible...
Especially at about 0:09... for a split second it has massive artifacting
wait, I hear the same sound in the uncompressed audio... but it seems to be amplifying it?
It seems to be duplicating it... even by preset d it's quite audible, albeit a bit less
Although most of the really audible scratchy sounds disappear by preset d... it's pretty faint by that point to where you really have to listen
6
Listening Tests / Re: Personal blind comparison of the Bluetooth codecs, AAC vs LC3, re-encoding
Last post by iwod -
It has been a few years since I looked into it but I *think* there are a few nit-picks with this test.

1. Opus 128kbps being the Source. I think 256Kbps AAC or Opus would have been a better representation. Or straight up using lossless as original. Unless you are using the Web version on a free tier, subscription Music or even YouTube offers 256Kbps AAC files if not higher.

2. Most bluetooth earphones dont do AAC pass through, contrary to popular believe despite the devices itself support AAC like the Apple AirPod. i.e If you are listening an AAC files it will still get (Hardware) re-encoded if you are listening on AirPod. I am assuming LC3 will have mandatory pass through on BT 5.2. But I never had time to check on it. That means testing AAC software encoder against LC3 wouldn't be an accurate use cases, especially with CoreAudio.

3. Would have been nice if the test was on LC3 256kbps, which is sort of the sweet spot for this codec. And again contrary to popular belief having a consistent low latency 256kbps connection in modern bluetooth isn't unattainable.
8
General Audio / Re: 16 bits is more than enough
Last post by doccolinni -
Yes, and that's a very rudimentary form of lossy compression. I don't understand which part of this is controversial.

But a mp3 encoder, PNG or GIF encoders,  or gzip, xz, zstd, etc.. Don't work by truncating numbers.

All of those you've listed besides MP3 perform lossless compression, so not comparable.

As for MP3: yes, it does work by truncating (usually referred to as "quantising") numbers. What do you think lossy compression is?