MQair new from MQA

Ideally yes but if Bluetooth is incapable of delivering that, I would like the next best thing.

I will add that the laundry list of Bluetooth focused audio codecs already is far too long. Tacking on MQair to that list as well as expecting widespread adoption is a bit much.

AJ

1 Like

The first option is to use MQA. It lowers the rate down from 1400 into something that Bluetooth can handle. Not bit perfect lossless but better than what we have now.

Second option is a new transmission mechanism (WiFi based ? Some other new method). Would require new gear but would be full fat lossless.

1 Like

I am also sceptical however the fact that the codec can be delivered via a firmware update to existing phones and headphones is a major advantage. Qualcomm is launching the main competition to this codec and they require you to buy a new phone (chipset) and new headphones.

Not having to worry about what device a consumer is using to reap the benefits of your shiny new headphones will be a draw and companies that have sold expensive headphones can gain some consumer trust in their brand by offering the update.

Someone like Bose can also shift more of their old models by saying ā€œwe now support this new codecā€.

If you give up lossless, you have to rely on some kind of psychoacoustic compression. I seriously doubt we need yet another such compression scheme besides MP3 or AAC for red book.

Given the data rate of those compression techniques, clearly we could benefit from another. Whatever vendetta you have against MQA, I sincerely doubt youā€™d argue that it compresses the music to the same degree that AAC does ?

The level of compression matters, 160k MP3 is not the same as 320. A 1.2MB MQA Vs 320k MP3 would surely be preferable?

Didnā€™t you say Bluetooth caps at 990kbps? And didnā€™t I say that lossless compression like FLAC can reduce it below 1.2Mbps?

If thereā€™s any audiophile out there pursuing development of new lossy red book codecs, please chime in.

LDAC caps at that.

FLAC can compress some files down and in which case this codec can stream the PCM lossless file. Iā€™m suggesting that where the FLAC compression cannot get it below the threshold, MQA can step in.

Iā€™ve just checked all my local red book FLACs and I got this:

  • max compression ratio: 4.4%
  • min compression ratio: 83.8%
  • average compression ratio: 51.2%

This gives an average bandwidth of about 723kbps and an maximum of 1.2Mbps. I think that would be totally feasible to use with Bluetooth. (Although, in all honesty, I doubt anyone is able to reliably pick red book from 320kbps MP3 in a blind test).

BTW, the honors for minimum compression ratio go to this track:

1 Like

I think the maximum is part of the problem.

Taking LDAC as an example (as it has been released), Sony struggle to keep the transmission at 900kbps. The average delivered is at the 660kbps rate. So LDAC canā€™t deliver your tracks.

MQair does support PCM so if they can keep the transmission rate at 1.2Mbps then the codec could deliver lossless flac.

My understanding is that itā€™s extremely difficult to average that rate, Qualcomm has said that the maximum rate for their brand new codec is 1Mbps which would fall short of delivering lossless via FLAC.

Assuming MQair faces the same issues, that is where MQA comes in. You can pull that maximum down and matain a stable wireless connection.

If MQair averages higher then they can deliver the full lossless, that is where we will need to see the actual rates and delivery mechanism.

As WiWavelength accurately pointed out, Bluetooth has been pretty poor at delivering high rates consistently and may need a new protocol to break this barrier.

If going to the trouble of replacing the Bluetooth physical later to add bandwidth and robustness, then no MQair or other supposedly clever new codec needed. Because to be worth the Bluetooth overhaul, the bandwidth/robustness increase would not be just incremental. It would have to be exponential. And extant FLAC, for example, would fit comfortably in the newly available bandwidth.

AJ

2 Likes

Very good point, MQA only makes sense in the existing Bluetooth spec.

Do not confuse moving files around with streaming an audio bitstream. Two completely different things that cannot be compared. Itā€™s why CODECs exist and you canā€™t simply move a raw FLAC into your headphones and listen to it.

Few things I really like with this announcement:

  1. MQA holds some really good patents / technology on audio compression. Mr. Stuart has been doing this a long time and can back-up his research with decades of listening tests. If he thinks this can compete with other CODECs I believe him.
  2. The whole MQA ā€œtime domainā€ thing is an example of one of those technologies. MQA believes very strongly on how pre-ringing and other artifacts should be handled. Itā€™s one of the reasons a lot of people like MQA. If they can preserve that under the heavy compression needed for BT I think they have an advantage here.
  3. Iā€™m surprised they can do this with a firmware update. Thatā€™s huge. But, Iā€™m skeptical. Low latency requires predictable or fixed latency and that normally requires a hardware solution. Although, latency isnā€™t super important for music, this will be used for more than music.
  4. This isnā€™t MQA. This isnā€™t the folding origami thing that you normally think of as MQA. Although, the compression they use to create those folds, Iā€™m sure some of that is shared.

I look forward to hearing it. I kind of hope this is successful. If this distracts them from trying to make MQA ā€œa thingā€ Iā€™m all for it. MQA needs to go away :slight_smile:

Rumor? Some people are predicting Apple will use this since they donā€™t have a friendly relationship with Qualcom. However, I still think Apple will develop their own CODEC (hardware based in the w chips). Honestly, I have no idea who will license this. I just donā€™t really see who in the market needs this. But, Iā€™ll probably be wrong. Whatā€™s your guess on when we see products? Strange they announce the CODEC with no partner isnā€™t it?

1 Like

FLAC is designed to be streamable:

  • Streamable: Each FLAC frame contains enough data to decode that frame. FLAC does not even rely on previous or following frames. FLAC uses sync codes and CRCs (similar to MPEG and other formats), which, along with framing, allow decoders to pick up in the middle of a stream with a minimum of delay.

As for the rest of your post touting the benefits of MQA, Iā€™m not going to start another argument, but Iā€™ll say this: there was enough deceit around MQA to make me not want anything coming from them.

And again, do we really need yet another lossy compression algorithm?

1 Like

I should have been clearerā€¦ FLAC isnā€™t designed for real timeā€¦ thatā€™s what OPUS is for.

FLAC streaming works with lots of bandwidth, low jitter, and no packet loss. Thatā€™s not BT. BT is low bandwidth and high loss. The loss comes from the fact its very low power and therefore speed drops quickly the further you move away. Ever be on a crowded bus and turn your head the wrong way with your phone in your pocket? If you lose a bit with FLAC its a gap in the playback.

I use Opus as example because its opensource and well documented so if you want to dig into the source code go ahead. But the big difference with streaming lossy codecs is they can be dynamically lossy. The ability to ā€œpredictā€ what should be there when bits are lost is part of the codec. Additionally, the ability to dynamically adjust the bitrate / compression against changing conditions means you donā€™t have gaps in the playback and only minimal degradation in the sound quality. BT CODECs do the same thing but they often use / always use patented (therefore licensed) algorithms for their code / decode (compression).

For Bluetooth? Absolutely. Ever forced to listen to SBC because its the only common CODEC between a device and the headphones / speaker? It sounds like garbage. AAC is marginally better. Bring me something that has better universal adoption and Iā€™ll be much happier to go wireless.

3 Likes

As far as I know, packet loss should be handled at the transport layer, not at the application layer (codec). If you permanently lose packets, youā€™ll have dropouts, no matter what codec you use. You can mitigate the effects, but that should not be the norm.
Regardless, as I said before, it seems to me Bluetooth should already have enough bandwidth to accommodate a lossless red book stream.

Essentially MQA is already lossy sitting on top of a lossy Bluetooth carrier. I canā€™t imagine how music is going to sound likešŸ¤£ Another revenue for MQA?

1 Like

This will help

And hereā€™s one I found that nicely outlines how this applies to audio:

1 Like

You probably care about time smear in music. Thatā€™s what MQA deals withā€¦ That doesnā€™t need to be high res at allā€¦

I donā€™t care about non-existent problems. Thatā€™s all Iā€™m going to say about MQA.

1 Like