MQA on all iFi devices. AND on ANDROID!

[AMR/iFi audio]

Extra Ordinary MQA Easter Egg

Introduction

With Easter just around the corner, iFi audio has delivered an eagerly anticipated upgrade option as a very special Easter gift.

iFi first introduced MQA into its product mix with the nano iDSD Black Label in November 2017. Since then, iFi customers across the globe have been asking when this option would be available in other iFi products. The good news is that the latest improvements to the nano Black Label firmware version 5.30, ‘Cookies & Cream’, does just that.

Mqa for all

This latest firmware flavour not only adds the latest scoop to the nano iDSD Black Label sundae but it also dishes out MQA (Master Quality Authenticated) audio to the full range* of iFi audio products going back to 2013!

 

This ‘legacy’ update means that you can now download the MQA upgrade (PC and Mac) straight from the Support section of iFi’s website at no extra cost.

Mqa optimised

Firmware version 5.30 will optimise your device for MQA and can handle up to DSD256 and PCM384. Enjoy the MQA magic like never before.


 

And Finally…

None of the above would have been possible without the MQA software engineers who worked tirelessly alongside the iFi software team to make this unique opportunity happen. Thank you.

Go to https://ifi-audio.com/audio_blog/mqa-firmware/ to enjoy your upgrade.

This firmware provides MQA rendering as this is the ideal solution for portable products and those with power considerations. This means the workload is shared between the host (the computer) and the client (the DAC). The listener will still enjoy full MQA experience.

For more information on MQA, go to http://www.mqa.co.uk/customer/how-it-works

Legacy

*The only exception is the original iDAC.

[AMR/iFi audio]

58 minutes ago, firedog said:

In your MQA implementation, are the MQA specific filters activated just for MQA file playback, or do they stay on (once activated) even with non-MQA playback?

 

The MQA filters are in use ONLY run when MQA files are passed through and vice versa.

 

This is WHY the LEDs correspond to the different Sample rates when one switches between different types of music files. This is the easy reference for our customers. On newer machines MQA which be Magenta.

 

Older machines - will indicate 384k decoded colour. White/Yellow (dependent upon the model).

 

58 minutes ago, firedog said:

Can your devices switch back and forth from MQA filters to non MQA filters as necessary on a per track basis?

 

Yes. As per above. So just one uses Tidal (on a PC) for MQA versus non-MQA music, the LED will alternate accordingly. We do recommend the above video for Tidal config to enable MQA to run.

[AMR/iFi audio]

9 hours ago, lmitche said:

Hi Rick,

 

I just "upgraded" my silver label microIDSD to firmware 5.3 and can confirm that DSD512 no longer plays.  Looks like it drops down to DSD256. Seems that IFI ran out of colors and stole the magenta slot from DSD512 for MQA. Restoring the 5.2 firmware release restores DSD512 playback with all other settings the same.

 

Typical IFI move. Kill the most distinguishing and competitive feature of your product for an unwanted and unnecessary capability.  Genius!

 

Please understand that MQA was initially designed to work on nano iDSD BL and later products only. It was initially exclusive for this device and was to be used for devices still in development. Still, we took the plunge due to feedback from our customers, and we were able to add MQA support to a whole host of other iFi products, some already several years old, and we did that totally free of charge. We could have said 'no' but that's not our way, we went the extra mile even though it took a lot of time and resources. And to implement MQA on machines already out there (some since 2013) is not easy. Besides, MQA is there for those who want it. Those that don't, don't have to have it and can still roll with DSD512. There are TWO firmware options.

[AMR/iFi audio]

Just now, rickca said:

OK but why did implementation of MQA renderer force iFi to drop DSD512 in the 5.3 firmware?

 

Because that's what it takes.

[AMR/iFi audio]

16 minutes ago, rickca said:

DSD512 is much more important to me than MQA.  Are you saying most of your customers prioritize MQA over DSD512?

 

We're saying that you have two firmwares to choose from. You have options and the MQA one was very difficult to deliver but now it's here. Free of charge. 

[AMR/iFi audio]

22 minutes ago, Em2016 said:

 

Kudos. I’m personally not interested in MQA but this is a great gesture for those that do want to try it.

 

 

Thank you, we believe so as well. 

[AMR/iFi audio]

Easter ‘Bug Bounty’ Hunt

Hunt 'em, wherever they are...

 

 

Introduction

Our just announced firmware v5.30 is MQA capable and in one fell swoop, elevates legacy iFi products* with MQA capability for even more sonic enjoyment.

 

The MQA integration was a little difficult. It involved:

• Totally replacing the customised core code
• Re-apply tuning/core loading and
• Further fine tuning the firmware for even more precise allocated resource use in order to allow us to support MQA and384kHz.

 

To bring all this to fruition required the combined efforts of the MQA and iFi software developers or a total of +1,000 programming hours to deliver firmware v5.30 (excluding testing on all iFi legacy units).

 

Notwithstanding, there may still be one or two software bugs we have not quashed – hence we would like to involveyou, the customer – in the Easter Bug Hunt.

 

More details are to be found in this thread:

 

[AMR/iFi audio]

35 minutes ago, crenca said:

 

Soooo, "1st unfold" or "rendering" only - no full decode correct?

 

@AMR/iFi audio, can you answer this in a definitive way?

 

Correct. Full decoding is implemented in our upcoming Pro iDSD.

[AMR/iFi audio]

16 hours ago, listas_fede said:

 

What still bugs my mind is how it is possible that machines with a double-core DAC (micro iDSD and micro iDSD BL) are now exactly as capable as their smaller siblings (nano iDSD and nano iDSD BL) which have just a single-core DAC. What are we getting in exchange for all that extra horsepower? As far as the DAC department goes, I perceive we get ZERO differentiating features, which is just crazy. I hope we can get some kind of differentiating feature, maybe get back DSD512/PCM768 (which would get us Mac users DSD256/PCM768 playback, remember that), or MQA full unfolding, decoding and rendering, since these units are more capable (MQA implementation on the whole iFi lineup as of today is just rendering; you still need the first unfolding to be done by the playback software).

 

 

Here's a little more insight about our approach. We do not do things by halves. We write our own software code so our customers receive two specialised XMOS firmware versions: 

• v5.30 – optimised for MQA
• v5.20 – optimised for music file formats up to DSD512/PCM768 (non-MQA)

Each firmware version squeezes that last ounce of sonic performance to suit each customer's preferences.

 

Just as car enthusiasts load different ‘remaps’ into the ECU (Electronic Control Unit) for their preferred driving experience, we let our customers load their preferred ‘file format remap’ for their own music torque curve.

 

Hopefully this is all clear now.

 

Also, micro iDSD BL isn't the same as its nano version. It goes further than formats supported. The bigger one does things its smaller sibling won't, their functionality isn't the same.  
 

[AMR/iFi audio]

1 hour ago, luchoh said:

@AMR/iFi audio 

 

Sorry it somewhat backfired on you.

 

Once in a while it happens, we take it on the chin and then get back to do our thing. All good!  

[AMR/iFi audio]

18 minutes ago, lmitche said:

More like shot yourselves in the foot. LOL

 

After considering positive feedback we get (after the release of MQA related firmware and in general), we can't agree with you on this one, sorry . 

[AMR/iFi audio]

11 hours ago, rickca said:

The iFi DACs (other than iDSD Pro) provide only MQA renderer support, so you need TIDAL to decode MQA.  MQA passthrough in TIDAL should only be used if you have a DAC like iDSD Pro that does both decode/render.

 

That is correct.

[AMR/iFi audio]

11 hours ago, rickca said:

The iFi DACs (other than iDSD Pro) provide only MQA renderer support, so you need TIDAL to decode MQA.  MQA passthrough in TIDAL should only be used if you have a DAC like iDSD Pro that does both decode/render.

 

That is correct.

 

2 hours ago, macuniverse said:

@iFi Audio, many thanks for making this alternative update available on the older gen devices. Most appreciated.

 

First time I was able to sample some Tidal MQA tracks in their native format and, through iDSD silver, they sound really good. 

 

PS. I agree with some other posters that the loss of functionality after the (alternative) update needs to be made clear on the download page.

 

 

First of all, you're welcome. 

 

And secondly, we are very open about each firmware's supported formats, please take a look here:

 

https://ifi-audio.com/audio_blog/mqa-firmware/

[AMR/iFi audio]

17 hours ago, gabeg said:

 

 

Any idea about this?

 

Yup, feel free to take a look at this photo.

 

 

In case of micro iDSD Black Label, yellow colour indicates MQA playback. Magenta coloured LEDs are mounted since nano iDSD Black Label machines, hence later.

[AMR/iFi audio]

11 hours ago, rickca said:

iFi will probably announce another $50 gadget just to give you a magenta LED.

 

We appreciate your ideas, but that's not how we do things. To give you some additional insight, iONE can be sent to our place for its MCU flash procedure as early as in June to have magenta LED operational. 

[AMR/iFi audio]

30 minutes ago, rickca said:

Umm, it was a joke.

 

And we were just a wee bit sarcastic 

 

But joking aside, $50 gadgets which would include magenta LEDs aren't going to happen.

[AMR/iFi audio]

Folks, just a quick update. In the not too distant future we'll have something MQA&measurements related. Stay tuned!

[AMR/iFi audio]

10 hours ago, firedog said:

Are the non MQA firmware versions like 5,2 going to continue to be developed? Or will those that don’t want MQA or would rather have DSD 512 going to be felt behind in firmware terms?

 

If you look at the history of iFi firmware updates, because we do this in-house, we have always and will continue to provide customers with different versions to suit. We expect to eventually release 5.3A and 5.3B to mirror the previous 5.XX releases. These are being actively developed.  But the 'if' and 'when' an unknowns at this stage.

[AMR/iFi audio]

On 2.04.2018 at 8:35 PM, mansr said:

As mud. The only rational explanation I can think of is that a firmware including both DSD512 and MQA support wouldn't fit in the XMOS flash memory. If that is the case, why not just say so?

 

Sorry, not the XMOS flash memory, which is copious. Please allow us to offer a brief technical explanation. While in many ways visionary (multi-threaded software with hardware-like guaranteed response times), the XMOS architecture like everything in life, is finite. And in this case, specifically available resources and MIPS are limited. The actual reason is that to implement MQA, digital processing is implemented as well and this consumes resources during runtime even in bypass mode (read: no MQA stream playing). While we would love so to speak, to feed 5,000 with two fish and five loafs of bread and have 12 baskets of leftovers (*), the joint software teams managed with the possible rather than the improbable . This is why we have offered our customers a choice MQA (v5.30) or non-MQA (v5.20).

 

(*) Mark 6:31-44

[AMR/iFi audio]

Measuring time!

MQA vs non-MQA streams – how iFi does it

 

This official iFi audio tech release is here to explain one thing and one thing only:

MQA and non-MQA streams are very much alike!

 

We’re here to show that firmware 5.3 does not change behavior of a DAC with non-MQA signals.

And we like our non-MQA signals unchanged.

The marketing department requested measurements to illustrate that for non-MQA signals there is no audible difference in audio signals output between firmware versions 5.20 and 5.30. Currently there is no agreed standard measurement that has been correlated with audible differences. Hence we elected to perform a set of basic tests as described below.

 

We feel our work below illustrates that electrically the test signals used are handled identically by both firmware versions; 5.20 and 5.30. As we also have access to internal firmware test versions that implement upsampling for all sample rates, though not actually using an MQA filter but our own proprietary experimental filter, we elected to show what the result WOULD BE, if (as has been queried) MQA processing was applied to all audio signals.

 

Methodology:

1. We selected a random micro iDSD Black Label from the units available in R&D.
2. The unit was set to Eco Mode, Positive Polarity and direct output.
3. The unit’s RCA outputs were connected to our Audio Precision System 2 model 2322.
4. Rigol DS2302A 300MHz oscilloscope was connected to the System 2’s monitoring outputs to capture a precise waveform reading to digital files.
5. The USB input was connected to the PC hosting the System 2.
6. The iFi Driver Version 2.26 was used, in order to support the System 2 this PC operates Windows XP SP3.
7. Wavegene V1.5 by efu was used as digital signal generator, using ASIO sound subsystem.
8. White noise at 44.1kHz sample rate and 24Bit word length was used as test signals. This clearly illustrates the actual shapes of the digital filters. This method was popularised by John Atkinson of Stereophile and originates with Jürgen Reis of MBL, in which the device under test decodes 44.1kHz data representing white noise. Additionally, an FFT of a -3dB 1kHz sinewave was performed. For contrast and to minimize time spent testing only standard and Bitperfect digital filters were tested.
9. All settings in System 2 were unchanged, the only change was which version firmware was flashed onto the micro iDSD Black Label.

Below we present each set of graphs side by side, version 5.2 (left screen) and version 5.3 (right screen).

 

• BitPerfect

    

•   Filter response: Standard vs Bitperfect

       

• Standard

 

No measurements for MQA streams are presented as we have no MQA encoded test signals available to us.

It can be observed that the audio output for non-MQA signals is identical between 5.20 and 5.30 firmware within the limits of the test setup. We conclude that there is no measurable difference between the ways audio signals are handled in case of both versions. There are no differences in levels, noise-floor, distortion or digital filter responses.

 

 

Separately we present the “What if the experimental firmware is applied?!?” scenario, in which oversampling to 352.8/384kHz is performed and an experimental set of digital filter coefficients is used.

It is clearly observable that the filter response using white noise is dramatically different from any of those presented for 5.20 & 5.30. Other than the precise waveform and filter response differing if MQA processing is engaged, these results parallel those expected if MQA processing was engaged for non-MQA streams.

 

Summary

1. No measurable difference between the ways audio signals are handled in case of both version firmware v5.20 and v5.30.
2. There are no differences in levels, noise-floor, distortion or digital filter responses.

We hope you do not mind this ‘super dry’ technical measurement note as we have been short-staffed over Easter and we have been responding to a small rise in customer enquiries.

 

[AMR/iFi audio]

13 hours ago, rickca said:

What is the nature of this required digital processing?  It's hard to imagine that it is so resource intensive that you had to drop DSD512.

 

We explained before that v5.30 is almost a complete re-write of the firmware (compared to v5.20). As such, this was not a trivial task - resource allocation, core loading etc.

 

If it was, then most audio companies would do the same as us and write their own customised XMOS code for their own machines.

[AMR/iFi audio]

On 6.04.2018 at 9:42 PM, mansr said:

Would it not be possible to disable all MQA related processing at the highest rates?

 

No, this is not how MQA works on a firmware level in XMOS. Not at all.

[AMR/iFi audio]

On 7.04.2018 at 3:57 PM, rickca said:

That doesn't answer my question.  

 

Please review MQA's website for more details.

 

On 7.04.2018 at 8:15 AM, Norton said:

It's good that you are providing the option of MQA, but as a potential customer, I'd feel more reassured if the engineering department had deemed measurements necessary, prior to release.

 

 

R&D does not divulge all their measurements to the Marketing Dept. and even if they did, not all measurements are for public consumption. So rest assured we do conduct measurements - the Audio Precision 2 is not cheap so we do like to amortise the heck out of it!

 

But the fact that we are one of very few audio companies that write our own XMOS code should suggest we have knowledge of what we are doing rather than just implementing a turnkey solution. Few offer a steady stream of multiple firmware versions for a range of products spanning several years.

 

Last and not least, one cannot measure pleasure. Hence AMR/iFi always audition, internally and externally extensively prior to release. For us, measurements are useful but not the end all and be all. It's a little akin to one buying a car based upon the fastest 0-60 and not taking it for a test drive.

 

[AMR/iFi audio]

On 8.04.2018 at 3:03 PM, mansr said:

That's terrible. Either they're plain incompetent, or they've intentionally made it as difficult as possible to avoid their meddling.

 

Dear mansr, before judging competence or incompetence of anyone, it would probably be a good idea for you to learn how to write software for Xcore processors and how audio and MQA integration works on these. 

 

As a software developer you can sign up with MQA to integrate this into your sample rate conversion libraries.

Past that MQA are quite open about how their system works and what it does. There are multiple patents filed and extensive material available on the MQA website. 

 

It is true that specific details are not made publicly available, however these affect neither the understanding of the operation principles nor the relative impact on software including MQA, it's merely an insurance that it is not possible to build an MQA decoder/renderer or MQA renderer without obtaining these details from MQA. 

 

Past that, given all the information available freely about MQA, the amount of disinformation presented as fact is surprising to us. We do wonder if there is truth after all in the 'those who know the least talk the most' truism.

[AMR/iFi audio]

13 hours ago, mansr said:

Ugh, the MQA impulse response clips for several of the filters.

 

This has nothing to do with MQA.

 

99% of DAC's out there using digital filters will clip when presented with a full scale signal that does not conform to the strictures of the Nyquist–Shannon sampling theorem. 

 

This holds specifically true of square-wave signals and one sample long impulses used as test signals. This has been known for many decades and isn,t actually a problem, except for test-signals that are not in compliance with the strictures of the Nyquist–Shannon sampling theorem. This sort of thing is usually covered in year one or two EE Courses. 
 
Real musical recoding's are low-pass filtered before the analogue to digital recording process in order to comply with the strictures of the Nyquist–Shannon sampling theorem. 

 

Thus, unless severely clipped in the digital domain to start with (in which case what sort of fidelity are we talking about in the first place), they do not contain any signal components that can trigger these "digital filter" overs.

 

So just to recap, this has nothing to do with MQA and is not an issue outside the lab.

 

13 hours ago, mansr said:

There are, however, some slight differences, probably unrelated to MQA, in the configuration sequence sent to the DAC chip. 

 

The end-result of how the chip is configured is the same.

 

13 hours ago, mansr said:

 Watch out for pops when starting DSD playback.

 

We did.