4 ms·
Short answer is no. I'm not really sure why so many try to hate on bluetooth audio. But don't take my word for it, hear for yourself. You can first read up some
by esaym 6y ago
Short answer is no. I'm not really sure why so many try to hate on bluetooth audio. But don't take my word for it, hear for yourself. You can first read up some on it[0] Then get the needed tools to encode audio into the exact same format that your headphones would see [1]
Hopefully, you have an uncompressed wav file to test with. Unfortunately, the sbcenc command wants the wav in the uncommon big-endian format. Not worries, just do: "ffmpeg -i test.wav test.au" and it will convert it for you. Now feed that .au file into sbcenc:
"sbcenc -B 16 -s 8 -j -b 51 test.au >test.sbc"
That is the default scheme for "bluetooth high quality". Personally I have not found a difference in the sound. Of course note that the audio encoding is adaptive, so if you put on your bluetooth headphones and walk 50 ft away, yea it might sound bad...
[0]: https://en.wikipedia.org/wiki/SBC_(codec) https://en.wikipedia.org/wiki/SBC_(codec)
[1]: https://packages.debian.org/buster/sbc-tools https://packages.debian.org/buster/sbc-tools
- jldugger 6y agoSBC is also not the only BT codec; BT headphones often offer direct mp3 support so that there is no extra loss in quality
- esaym 6y agoThe bluetooth stack on linux only supports SBC due to license issues.
- microcolonel 6y agoThere is a fork of the PulseAudio Bluetooth modules that supports LDAC, AAC, AptX, and AptX-HD. LDAC should be supportable upstream, I think it's coming. On a side note, LDAC is so laughable. I have to imagine the engineers working on it had a lot of laughs. It has all the "high resolution audio" mumbo jumbo that Sony has marketed to audiophools for decades, and it is hilariously inefficient.
- ComputerGuru 6y agoLC3 is the new audio standard for Bluetooth 5.2 and up, but when I read the Bluetooth SIG claims it provides better quality at comparable bitrates to a long list of codecs that ended with "and Opus," I had to laugh and close the tab. For those that don't know, Opus is pretty much the current gold standard for freely available audio formats that are at least partially designed to operate at the very lowest end of the bitrate spectrum while delivering comprehensible audio; unless LC3 is also using SILK but just under a different name, I'd be extremely shocked to find it actually beats Opus.
- marcan_42 6y ago"LC3 outperformed Opus at 32 kbps in their tests. But they used an old version (1.1.4) with encoding complexity set to 0." So yeah, it seems they did one test at a low bitrate with an old encoder and poor settings and proclaimed it "better than Opus".
- microcolonel 6y agoOn that topic, when I get fully set up after my move, I'll have more time to devote to my A2DP Opus mode. I think it's actually not crazy to decode Opus on Bluetooth chipset DSPs, even all the way up to the maximum bitrates. One nice thing about this as well is that adding surround sound modes shouldn't be that hard, I think it would be the first surround sound A2DP configuration. That test is indeed laughable, I read their materials, and it looks like they crippled the Opus encoder, which was already on old release before they used it. Opus 1.3 at an ordinary complexity is doubtless better than LC3, and there are actual encoders and decoders that you can just download and port yourself.
- Renaud 6y agoMy real problem with BT is how unreliable it is. I'd like to find someone who never had an issue pairing some earphones or headphones and had it working flawlessly every time. There are many variants of BT audio and they don't all work the way you would expect. It's still not rare to end up with lag if your combination of hardware, software and receivers don't have compatible technologies like aptX. For me the unreliable and lengthy pairing process is the major pain. Takes out the earbuds, wait at least 10-20s to get them connected, then wait another 10s for the phone to realize it needs to output to the earbuds. More often than I'd like, I have to put back the buds in their case and take them out again to force a reconnection because the phone or one of the buds said it was connected but isn't getting any sound... And I'm not talking about a cheap Chinese Android phone with a pair of crap $20 earbuds. I'm talking about iPhone 11 Pro with Sony 1000XM3. It's not the equipment, had similar issues with an iPhone 8 and Bose headsets, and with various dongles and computers. A friend recently thought his new Sony WH-1000XM4 headphones were not working and asked me to have a look. Took me 15 minutes to hook them to Windows properly. Turns out there are multiple devices that appear (but not at the same time) during the pairing process and if you connect to the BLE stack, you don't get the headphone functionality... (what functionality you get is a mystery) and of course, no mention of that in the documentation. Wireless audio is important enough that we shouldn't have to settle for these subpar experiences. Although BT has made progress on the audio front by providing protocols with lighter overhead and latency, it's still not particularly suited for audio (no high quality transmission, mono/stereo only, no multicast, lengthy connection, ...) It is what is is, but it's not what it should be.
- aetherspawn 6y agoIt’s gotten a lot better recently. But you do have to remember to unpair the last device before trying to use a new device because you can only connect one thing at a time.
- Kaze404 6y agoIn case that wasn't a rhetorical question, I use a Sennheiser 4.50BTNC every day and it works flawlessly, both on my phone and on my Linux computer (through a generic USB adapter).
- ComputerGuru 6y agoIf you want to skip the intermediate file and do it all in one go, you can pipe directly to stdout with ffmpeg if you give it sufficient information to make up for the loss of file name hints. I’ve never used sbcenc, but .au defaults to signed 16-bit big endian which you can specify and pipe (so as to skip the intermediate file) as follows: ffmpeg -i input.foo -f s16be - | sbcenc ... EDIT: gstreamer supports encoding to SBC directly, from whatever input format you have (its sbcenc plugin takes signed 16-bit LE PCM, but it can losslessly convert between audio/video formats on-the-fly): gst-launch-1.0 filesrc location=input.foo ! decodebin ! sbcenc ! filesink location=out.sbc
- marcan_42 6y agoThis. I've noticed Bluetooth quality issues, and they are always either - The source is using low bitrates. SBC is a poor codec, but at the high bitrates (bitpool values) it should be used at it sounds perfectly fine. - Just shitty hardware/DSP. If your Bluetooth speakers sound different over bluetooth than over line in, then the DSP/DAC processing going on in them is what is screwing up the audio, not the codec. "High quality" Bluetooth audio codecs are largely a marketing scam to get patent royalties, because it seems that when a standard actually manages to mandate a royalty free codec (a rarity these days!) companies just can't help but try to jam patented nonsense down people's throats anyway. I'm sure some products even deliberately gimp SBC just to make proprietary alternatives sound better.
- TylerE 6y agoand of course it doesn’t help that the Bluetooth devices themselves, even so-called high end ones, have speakers/drivers that are just laughably bad. The protocol and encoding doesn’t really matter, you could feed in 192/32 way and it would still sound bad.