Kali Bluetooth Receiver and BT Codec Quality (Video)

[amirm]

I just post the review of the Kali MV-BT Bluetooth receiver but thought I also do a video since people on YouTube had asked to learn more about lossy encoding.

Kali Review is here:
https://www.audiosciencereview.com/...-bt-review-balanced-bluetooth-receiver.21083/

 

[Blumlein 88]

AAC does have Joint Stereo encoding.
https://en.wikipedia.org/wiki/Advanced_Audio_Coding

The term joint stereo has become prominent as the Internet has allowed for the transfer of relatively low bit rate, acceptable-quality audio with modest Internet access speeds. Joint stereo refers to any number of encoding techniques used for this purpose. Two forms are described here, both of which are implemented in various ways with different codecs, such as MP3, AAC and Ogg Vorbis.

 

[amirm]

Thanks. So I assume it is on in this implementation of Android.

 

[abdo123]

It would be interesting to use an iPhone for AAC (if any of your households have one).

Apple’s iTunes is basically high bit-rate AAC and their AAC encoder is allegedly really good.

Also AAC is the only Bluetooth codec available in the Apple eco system. They never pay for licensing of codecs that add nothing to the table.

 

[GGroch]

Thanks much for this!
Bluetooth is extremely popular because it is convenient; but it is seldom measured because it is not audiophile. This is ironic because some components like DACs have become so good that the measurements do not matter so much. Differences between Bluetooth hardware and different Codex are potentially huge by comparison.

I think Bluetooth is analogous to Audio Cassettes in the 70's-80's. Cassettes are audibly inferior to LP/Reel to Reel, but they were so convenient that cassette decks were part of most home audio systems. Tape deck manufacturers put a real emphasis on improving noise reduction schemes, tape formulations, head configurations etc. because Hi-fi magazines tested them. It would be nice to see that happen with Bluetooth.

ASR could do a real service with a series testing Bluetooth Codecs, Transmitters and Receivers. These components are mostly cheap and easy to ship. Perhaps performance is almost entirely dependent on the Chipset used, but your discovery of noise issues with the Kali seems to contradict that. Another factor that would benefit from standardized testing is reliable transmission/reception distance. That said, i think it's likely a Bluetooth series would be more popular on YouTube than it is here at audiophile ASR.

 

[amirm]

I am motived to do a detailed analysis and testing of bluetooth codecs. Need to assemble the right sources and receivers with easy ability to select codecs, their profiles, etc.

And yes, the idea of testing different BT codecs came from youtube comments on previous videos.

 

[Katji]

but thought I also do a video since people on YouTube had asked to learn more about lossy encoding.

Good - if the general public learns more, then maybe it follows that DJ/producers would learn more as well. Too many just don't know that you can't really "convert" or "upsample" 128 kbps to 320.

 

[testp]

It would be interesting to use an iPhone for AAC (if any of your households have one).

Apple’s iTunes is basically high bit-rate AAC and their AAC encoder is allegedly really good.

Also AAC is the only Bluetooth codec available in the Apple eco system. They never pay for licensing of codecs that add nothing to the table.

yes, they never pay for licensing, and turns out their new macbook air's don't even have usb inputs... yuppi-yei for usb users...

 

[infinitesymphony]

yes, they never pay for licensing, and turns out their new macbook air's don't even have usb inputs... yuppi-yei for usb users...

MacBook Airs have two USB-C ports that support charging, DisplayPort, Thunderbolt 3, USB4, and USB 3.1 Gen 2 which is backwards-compatible. That's more standards than many laptops, most of which are also moving to USB-C only.

Apple pay R&D costs up-front for a number of the technologies they use (for example their collaboration with Intel on Thunderbolt), so it's not like they get everything for free.

 

[thehun]

It would be interesting to use an iPhone for AAC (if any of your households have one).

Apple’s iTunes is basically high bit-rate AAC and their AAC encoder is allegedly really good.

256KBps but yes very good quality.

Also AAC is the only Bluetooth codec available in the Apple eco system. They never pay for licensing of codecs that add nothing to the table.

You mean for IOS? Yes AAC, for Macs or Mac OS Aptx is available.

 

[diddley]

It's certainly is a good compagnion with the review this video, and it made me laugh also!

 

[JimWeir]

I am motived to do a detailed analysis and testing of bluetooth codecs. Need to assemble the right sources and receivers with easy ability to select codecs, their profiles, etc.

And yes, the idea of testing different BT codecs came from youtube comments on previous videos.

The AAC comment about preecho is false. You are looking at a frequency plot. What you are seeing is the effect of the windowing function of the frames or records of the codec. It has nothing to do with when thing occur.

 

[amirm]

The AAC comment about preecho is false. You are looking at a frequency plot. What you are seeing is the effect of the windowing function of the frames or records of the codec. It has nothing to do with when thing occur.

It is a duality. The quantization in occurs in frequency domain and hence spreads the noise throughput the frame in time domain.

 

[JimWeir]

It is a duality. The quantization in occurs in frequency domain and hence spreads the noise throughput the frame in time domain.

Using that logic wouldn’t earlier in frequency be longer in time? I just think calling it a pre-echo it misleading what you seeing in the measurement. If indeed we are seeing a widening of the effective noise bandwidth of the device in the reproduction of a tone, and not a family of side bands, then you can say the response of the device increases noise
but not before the tone cycle begins.

this performance typical of an FFT wit a windowing function that does not reach zero at the ends of the frame of record. The CODEC is probably truncating lower bits to preserve processing bandwidth.

just my two bits.