thank you Linux for giving a damn about Bluetooth headphones

drwankingstein , 11 months ago (edited 11 months ago)

Ldac is not actually that good, it’s actually fairly rare that LDAC beats out something like SBC XQ let alone AAC

EDIT: for elaboration, LDAC works at 3 main data rate ranges 990/909, 660/606 and 330/303. Ldac is only high res at the 990 range, and even at that range, it still often looses when pipewire is compiled against libfdk. keep in mind that it’s hard to get real numbers on LDAC because decoding is proprietary, meaning I had to disassemble headphones and connect those for verification, but typically AAC on supported headphones beat out 990kbps LDAC (which is hilarious btw considering LDAC can rarely actually work at 990kbps anyways) and both SBC-XQ and LC3Plus (both of which are usable with pipewire) regularly beat 660kbps LDAC.

TLDR LDAC is crap and SBC-XQ is typically more accurate and lower latency, and LC3Plus is even better then that. and if you have AAC compatible headphones assuming latency isnt a major issue (which you are using LDAC so it’s not) just use AAC, both fidelity and latency is better

EDIT: I should mention, it is known that vendors will tune codecs, I believe Valdikks article in habr briefly goes over this. so it’s very possible that tuning could mean that x codec, including LDAC could be the only good codec, however with how badly LDAC maintains 990kbps, I doubt it will make much of a difference

RunAwayFrog , 11 months ago

keep in mind that it’s hard to get real numbers on LDAC because decoding is proprietary

I used to think the same. But as it turns out, a decoder exists. Maybe some people don’t want anyone to know about it to keep the myths alive ;)

EDIT: Also, as a golden rule, whenever anyone sees the words High-Res in an audio context, they should immediately realize that they are being bullshitted.

drwankingstein , 11 months ago

just because a decoder exists doesnt mean it’s good and usable, and it also doesn’t mean you are legally allowed to use it without the appropriate licensing

RunAwayFrog , 11 months ago

Lemmy instance choice does not check out ;)

marmo7ade , 11 months ago

The codec isn’t open source.

RunAwayFrog , 11 months ago

The codec is basic, uses decades-old tech, and was trivially REed.

drwankingstein , 11 months ago

the point is, it’s not something I’ve been able to test, and im not sure if this will change that, But I suppose I can at least do testing with what I have.

drwankingstein , 11 months ago

got more important things to spend my money on :D sadly, I cant just steal things from work

Gork , 11 months ago

I’m sure they won’t notice a few rolls of toilet paper going missing.

Gatsby , 11 months ago

Your skin glows quite beautifully, narc.

drwankingstein , 11 months ago

It’s my new skin care routine, got it from the asphalt last time I got hit by a car, driver must have been sleeping

marmo7ade , 11 months ago

Tell me you’re an apple fanboi without telling me you’re an apple fanboi.

LDAC is “only” high res @ 990. OK? WTF is your point? It sounds better than every other codec.

it still often looses when pipewire is compiled against libfdk

Can you explain the practical implication of this when I listen to music on my Pixel phone? (spoiler: there is none)

but typically AAC on supported headphones beat out 990kbps LDAC

100% total bullshit. Here are the tests:

soundguys.com/ldac-ultimate-bluetooth-guide-20026…

AAC does not have better fidelity. What a joke of a claim.

denissimo OP , 11 months ago

You all got a valid point… it’s just that mileage varies and x codec will sound better in y combination. If I remember right, AAC on Android is at times implemented differently than on it’s home Apple: The encoder would work with smaller bitrates to save battery. There must be a special synergy for max bitrate LDAC to sound worse than AAC, indeed. All in all my post is about being open minded and giving you the option to use a thing, rather than finding out what codec is universally the best: You virtually can’t, can you?

drwankingstein , 11 months ago

at 990/909 kbps bluetooth can hardly hold that bitrate unless you have really good conditions so much as walking down a stream will bring it down to 660kbps

and yes, AAC does have better fidelity, at 320kbps AAC and Opus are largely transparent to 90% of users keep in mind I am comparing fdkaac on Pipewire, NOT android, this is an important distinction since they were testing android, and you can see here how spotty AAC is on android soundguys.com/the-ultimate-guide-to-bluetooth-hea…

I am talking specifcally about linux in this context

EDIT: also it’s not about being an apple fanboy, Opus is largely just as good, marginally better, but no headphones support them, if you want you can even compile pipewire with higher bitrate limits on opus for stereo, (IIRC the pro profile can override it? cant remember but code is here gitlab.freedesktop.org/…/a2dp-codec-opus.c)

neo , 11 months ago

opus is transparent for all the the most intense songs by 160kbps, and for regular stuff you’d hear on the radio it’s transparent anywhere from 96kbps-128kbps

drwankingstein , 11 months ago

while this is the case for a lot of songs, a lot of instrument heavy songs can cause noticeable artifacting for some people. It’s pretty rare, but in the end, it’s not like we are storing the media so why care? we can do upto 320kbps for a stereo stream, and as far as I am aware, it’s not like there are any detriments to doing so (maybe marginally higher power usage I guess).

I wasn’t able to myself, but I did have a friend test the snug space endless lane, and they were able to fairly reliably tell the difference between 128kbps and the original rip. the In the moonlight track too has a high pitch… triangle maybe? that can exhibit artifact too.

so like, yeah, but we have the 320kbps we can work with, so like, why not?

redditcuntsz , 11 months ago

Tell me you’ve never actually tested the quality of a codex and how it’s used without saying it.