I was looking at this article about the aptX Lossless audio codec.

The article claims that this iteration of the aptX codec can stream CD quality audio losslessly. At the beginning of the article, it states:

aptX Lossless is two things really: it is the first and only Bluetooth codec capable of losslessly (that's important) {emphasis mine} streaming CD-quality audio, and it is part of a package of Qualcomm audio technologies called Snapdragon Sound that will feature in a number of next year's Android phones and wireless earbuds and speakers.

The article initially emphasizes it is talking about being able to transmit losslessly. A CD with 16-bit stereo audio at 44.1kHz sample rate generates \$44100 \times 16 \times 2 = 1,411,200\$ bits per second i.e. 1.4112 Mbps of data.

My layman understanding is that:

  • Any transmission system should be able to transmit 1,411,200 bits in 1 sec to transmit this data without any losses.
  • If it a lossless transmission system, all the 1,411,200 bits in the source side should be available in the receiver side by the end of the transmission.

However, the article later on says:

Qualcomm told What Hi-Fi? that CD-quality (16-bit/44.1kHz) audio transmission is achieved between 1.1Mbps and 1.2Mbps (1,100 and 1,200kbps) with aptX Lossless. As a rough reference, aptX Adaptive's maximum bitrate is 420kbps, (the older and less efficient) aptX HD can stream at 576kbps, and LDAC's is 990kbps. A CD audio file is 1,411kbps so you're always losing something here, though these claimed aptX Lossless figures are very close. Qualcomm says that 'no data is lost when audio is encoded and decoded with aptX Lossless'.

Here, Qualcomm says that the audio transmission is achieved between 1.1 Mbps and 1.2 Mbps, which is less than the 1.4112 Mbps calculated above. How is this possible?

Does this mean that Qualcomm is admitting this is not a lossless codec? Is the implication here that at the receiver side, the audio sounds like a lossless CD quality audio, but the actual transmission is not loss less?

Or to put it another another way, is it saying that those 1,411,200 bits in the source side will not be available at the receiver side when the transmission is complete?

Edit: The below text is from publicity info later found on a Qualcomm webpage:

Hear your music in stunning lossless quality. Many Bluetooth techniques for compressing and decompressing audio can destruct parts of the data and reduce the quality of the output. Snapdragon Sound with aptX Lossless technology retains all of the original content, bit for bit, resulting in music identical to the original recording. It’s designed to scale to up to deliver 16-bit 44.1kHz Lossless CD-quality when users are listening to lossless streaming source content, like Amazon HD, and it can scale back the bit-rate in busy RF environments to ensure no drop-outs or audio glitches.

  • 4
    \$\begingroup\$ They're probably just losslessly compressing the data. A compression ratio of 78-85% is entirely feasible and sounds about right for a low-latency lossless streaming codec. For comparison, FLAC typically achieves 50-70% compression and is also lossless. \$\endgroup\$
    – Polynomial
    Commented Jan 30, 2023 at 3:14
  • \$\begingroup\$ @Polynomial I see, that entirely possible. And they do say loss less and not low latency, so the latency is probably where the compromise comes in. \$\endgroup\$
    – user13267
    Commented Jan 30, 2023 at 3:38
  • 1
    \$\begingroup\$ When I say "low latency" I don't necessarily mean that in the same sense as you might talk about low latency with ASIO, but rather in the sense that the compression can be done in realtime without a large buffer/window for compression and decompression. That's in contrast to something like FLAC, where the compression is generally not done in realtime. \$\endgroup\$
    – Polynomial
    Commented Jan 30, 2023 at 3:44
  • 2
    \$\begingroup\$ You can compress data into ZIP file and decompress it losslessly. Transferring the ZIPped data is smaller in size than transferring original data. How is this any different? Too bad if the article writers don't understand the basics and think that maybe something gets lost even if it is said to be lossless. \$\endgroup\$
    – Justme
    Commented Jan 30, 2023 at 7:02
  • \$\begingroup\$ You're very welcome, glad it helped. If it's OK, I'll add the linked text from my comment into your question then deleted all my comments. If you also delete your comment to me, it'll tidy up the answer. Please do edit your question to show this new info as you want it to, including deleting it if you want. \$\endgroup\$
    – TonyM
    Commented Jan 30, 2023 at 15:01

2 Answers 2


There are plenty of lossless compression codecs like zip, rar, zstd, etc. They have to be lossless because computer files won't tolerate bit errors.

A generic codec like zip can't assume anything about the data, it has to work with every file. It won't parse the file structure. Most of these are based on detecting repetitions in the data stream then using efficient Huffman coding to encode frequent values with fewer bits to save space.

For example, a codec specialized for 2D images can compress images much better, because it can understand that it is processing an image, which is a 2D array of pixels. A generic codec which only sees a stream of bytes and has no notion of "width" or "height", so it can only detect repetitions and a sequence of identical bytes in a 1-dimensional universe. But an image codec can encode things like "all the pixels in this square are white" or "this letter over here is about the same as this other letter over there so just copy it and only change this pixel which is different". So it has the potential to be much better at detecting repetitions.

So, more knowledge about the data being compressed allows more specialized algorithms to offer better compression. For example there are codecs specialized for executable code, or 1-bit images (CCITT group 4 for fax), etc.

It is possible to compress any data with a generic codec like zip including audio, but you usually won't get good compression ratio, because the codec doesn't know it's audio.

On the contrary, a lossless codec like flac understands it's processing audio, so it can do more interesting things, like exploit the correlation between stereo channels, or use predictive algorithms.

The important difference between a lossy codec like MP3 and a lossless one is the lossy codec is allowed to modify the audio samples in ways that "shouldn't" be noticeable according to a perceptual algorith, whereas a lossless codec will decompress exactly to the original data.

Most lossless codecs work with:

original signal = approximation + difference

First it builds an approximation of the audio waveform with polynomials, splines, or any other process which can represent a lot of samples with few bytes. This achieves good compression, but it is lossy. So it then calculates the difference between the original waveform and this approximation. The important thing is this difference is of much smaller amplitude than the original waveform, so it can be encoded with less bits. In the end, the encoded approximation and difference use less space than the original waveform, and during decompression the original waveform can be reconstructed identical to the original.

Real time codecs like AptX face another challenge: all lossless codecs are variable bitrate. It will always take less space to encode silence than a high entropy signal like a burst of noise (ie, percussion). If you simply compress a WAV file to FLAC this does not matter, you end up with a file size that is determined by the average compression ratio. But if it has to be encoded, transmitted, and decoded to earphones in real time with low latency then what matters is not average bitrate over the whole song, but over the guaranteed latency period, and that's going to be higher. I guess that's why the compression ratio quoted in your question is much worse than FLAC's average ratio.


It's a little tricky to find a precise description of aptx. Here's a history by the author, but other than a couple of diagrams it doesn't explain detail. Here's another summary with a block diagram. It appears to be predictive: maintain a model which tells us what the next "expected" bits are, then record only the difference, which most of the time can be done in fewer bits.

The pigeonhole principle tells us that for any compression algorithm there must be a set of input bits that it can't compress. Therefore something has to give: bitrate or losslessness?

The secret is probably that the incompressible waveforms are those with a very high random entropy that is outside the range of the "predictive" part of the predictive codec. But those will sound like high-frequency noise. So anything incompressible will also be vulnerable to not being properly captured by the microphone/speaker setup anyway, as well as not being readily intelligible.

As long as it puts out a similar sounding noise spectrum, you won't notice.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.