The topic is going more mainstream
I keep thinking about the “backward compatibility” claim and the state of current audio stream containers. I am beginning to imagine how Meridian could come through on the claim that players without MQA decoders could still play the 16 bit version of the PCM stream. If you look at the world’s simplest “container” the WAV file, it immediately becomes clear that there is little way to “game” a WAV stream such that current generation WAV parsers would be fooled into skipping extraneous data. The same is largely true for FLAC. FLAC defined it’s own container structure and allows application metadata but provides no way to marry it easily to the stream data which has a fixed format. FLAC works with the OGG container but virtually no one uses that these days. Encoding the 16-bit PCM stream using ALAC, however, has more promise. ALAC uses the MP4 audio container which natively supports private vendor streams interwoven into the traditional audio streams. A current generation M4A container with ALAC streams as well as MQA proprietary streams would, in theory, import into iTunes and play as a 16/48 PCM file without any additional decoding software.
Did you look at the MQA at CES? what did you think? How did it sound?
Unfortunately I never got outside the room.
I have been to a Meridian MQA demonstration and all I can say is WOW! demoed a regular 96/24 bit file and a 96/24 bit file encoded with MQA.
MQA corrects the timing of the sound that comes out from the speaker and the time when we hear the sound.
The regular file sounded ok, but when compared to the MQA file the sound stage just opened up into a live performance! Greater dynamics.Every musical instrument had more pop and punch. The vocals were perfect. you could just envision where each performer was on the stage
Listened to Aretha Franklin, Dire Straights, Steely Dan,Take 5
The equipment was an Meridian 818v3, Meridian 7200SE speakers Meridian media core 200
henry1224 said I have been to a Meridian MQA demonstration and all I can say is WOW! demoed a regular 96/24 bit file and a 96/24 bit file encoded with MQA.Did you get any info on how this might roll out into the industry, I am wondering how it will show up in the market?
Well, that’s 100% (4 from 4, so far) :
Henry1224 - above;
TAS / Harley;
JA / Stereophile + JVS / Stereophile
and from the comments section, the reviewer classified :
As is true of any reviewer for Stereophile, who does not see JA’s test results before submitting their review, all I had seen was Meridian’s very basic press release, and their even more basic MQA website (link above). John had told me that he and Kal had been “very impressed” by the MQA demo in NYC, but I had no idea that he considered MQA a fundamental sonic breakthrough 'as important to the quality of sound recording and playback as digital was 40 years ago."
JA went even further, saying he rated it as third in the following sequence of audio advances : CD (1979) & DSP (1982) for Room Correction.
Very clever to encode the signal in a way that is 100% backwards compatible with existing PCM systems, including nearly current DACs and CD players.
Two Youtube videos that provide one person’s interpretation of MQA :
Unfortunately, how they capture these ‘timing’ differences isn’t as clear.
It would be super interesting to see some analysis that highlighted the difference between DSD and MQA !
It might be ‘perfect’ (nothing is) if the MQA hi-rez file unpacked could also be re-arranged into DSD format.
I’m starting to see the Digital part of the Audio industry as being - PS Audio and a few others excluded - a bit backward. Always fixing one particular ‘algorithm’ as the DAC and fixing a stack of hardware around this “current state of the art”.
Fitting Paul’s recent upgrading of the description of the FPGA code in a DirectStream to Operating System, the digital part and the DAC in particular would seem particularly appropriate to be treated as such - an upgradeable platform capable of supporting any algorithm. A key part of this platform would of course be a generalised solution to the problem of timing.
Then we’d all be buying a Directstream capable of putting anyone’s algorithm into it.
Of course, having a standard reference would be necessary for any ‘debugging’ of a system. But, just like I put alternate software on a PC, I cannot see why an alternate DAC (or the component that alters the various perceived factors; warmth, harshness, transparency, whatever) could not be overlaid.
Indeed, so a layer could be overlaid the original process. On handled on the server-side with pre-processing (very little different here to the concept of pre-compiling software vs compiling a program on the fly).
How great would be it be if the FPGA themselves were upgradeable ? Does the DirectStream use a surface mounted technology, fusing it into place. Intel used to supply CPU’s that could be upgraded. Xilinx and Altera are escalating their FPGA technology also using Moore’s Law, and within a six year product cycle, the processing power of FPGA’s might double 4 times; or up to 16 times as large.
perhaps enough space to handle multi-channel or MQA or anything else, in terms of Logic Gates, alone.
Then I would be looking for two things.
- the best localised amplification chain for the analog signal. any ideas ? BHK 300 Monoblocks + P10’s… + ??
Basically : Power Supply + Power Cord + Power Conditioner + Pre-amp + DAC + Power-Amplifier, as the amplification line.
- an external bridge that handled all my data streams, whether sourced from analog or digital sources, prior to sending to the DAC for conversion into Analog. An updated Phono Stage with FPGA to handle all the various tone-arms out there (my tip for Ted’s next product, referenced elsewhere) + Directstream DAC + External Bridge II with access to pre-processed sound files on a server would seem to handle the digital chain,
as the information signal line.
- putting aside a personal desire to locate the sister warehouse to the one where Paul located his Infinity system. I’m surprised that more people (than 1 / week) don’t travel to Boulder just to visit PS Audio and understand what sound could be. It’s on my “bucket” list.
MQA have a 200 pound explorer 2 product with MQA that is 100% backwards compatible with PCM, so people with Headphones and access to source material can have a go for relatively little money / little risk.
Hope the FPGA on the Directstream DAC is large enough to accommodate MQA processing ?
Hope PS Audio are developing a Directstream “Platform” that will be invariant to various encoding methodologies; perhaps multi-channel; perhaps more FPGA’s or FPGA with more gates ?
Some quantification of the Timing Difference aspect of MQA :
Purportedly by Bob Stuart, and from weblink:
The inset upper right shows the impulse response of the entire chain (not just a converter), comparing MQA to a high-performance studio ADC/DAC at 192/24 delivering the output of a microphone feed. We can quantify this in a number of ways:
- Uncertainty of leading edge: MQA = 4µs compared to 250µs
- Total impulse duration: MQA = 50µs compared to 500µs
- MQA has no post-ring
- Perceptual smear (relating to the perceived envelope and loudness) MQA at under 10us is at least 10x better.
And it can be transmitted at a lower data rate, but that’s efficiency gain in part from the end-end nature of the coding and the other innovations.
The problem comes if the graph is taken out of context without the words I was using the the time.
Ted Smith said I believe it's a container, so then it's the player/decoder that needs to know about it: e.g. the bridge, not the DS@tedsmith
One part of it does look like a container, the smart encoding looks close to free lunch, even if strictly “TANSTAAFL”.
However, once unpacked, only by an MQA ‘aware’ “DAC” (decoder), I don’t think it has been stated anywhere that the fully unpacked information necessarily remains PCM or DSD or standard format.
I’m beyond my limitation in knowledge, but a MQA compatible DAC may interpret that “176kHz / 24-bit” “PCM” however it likes, according to the decoder ???
So, even if 100% backwards compatible in the 44.1kHz / 16-bit PCM (CD Redbook) space doesn’t necessarily imply 100% backwards compatible in the 176 / 192 kHz + 24-bit PCM space. ?
Not being familiar with the precise topology and division of labour b/w the Bridge and the DS, I have no idea where MQA unpacking & decoding work would need to be done.
Any additional technical resources (links, etc) and an indication of PS Audio’s Point of View about MQA (given the Harley / Atkinson comments) would be generous. e.g. incorporation into future External Bridge products; decoding at the Disk Level in a future Memory Player; possibility of using an MQA DAC in the DS.
Tho we’ve asked we don’t have any more technical info than is already out there.
A few clarifications about transients and PCM:
Contrary to popular belief a sampled system doesn’t have uncertainty about the position of the leading edge - With an unquantized amplitude a sampled system with a proper reconstruction filter gives perfect accuracy in the positions of edges of a bandlimited input signal, the sampling rate only restricts the maximum frequency that can be passed thru the system, not the positions of the edges… I.e. not the sample rate alone that sets the possible leading edge positions, the bit width of each sample also matters and with a proper reconstruction filter the positions of the leading edge are very accurate.
Also, even tho an impulse response thru a particular DAC may have pre and post ringing, a bandlimited signal (which an impulse isn’t!) thru a sampled system doesn’t necessarily have pre and/or post ringing for sharp edges. With a bandlimited input you get back the exact signal thru a sampled system (once again assuming unquantized amplitudes).
Back to the DS:
If they “unpack” to some other format than PCM (or DSD) then they would be incompatible with all existing DACs, not likely. In any case there’s software on both sides between the bridge and the FPGA in the DirectStream DAC so in principle we can get all information that’s in MQA to the FPGA thru the bridge. Having software in the DS doesn’t make the DS less able to deal with MQA than DACs that don’t have software
When we have accurate technical information about MQA we’ll be able to figure out the best strategy for handling it. With the information at hand I suspect that player software, e.g. JRiver MC or foobar2000 and streamers will be doing the MQA decoding, just like they do MP3, flac or alac.
And I guess when the license is in place it is just a matter of upgrading the DS software, in a retrofitting perspective?
In principle yes - I doubt that they need too much processing to deal with MQA, but without details we don’t know…
Ted Smith said ...With the information at hand I suspect that player software, e.g. JRiver MC or foobar2000 and streamers will be doing the MQA decoding, just like they do MP3, flac or alac.If the player software could do the required MQA decoding, would that imply that there would be no modification required for an existing DAC which could fully benefit from MQA decoding by just updating the player software? If possible that would be an awesome solution!
I’m just speculating, but if they insist that they you need to replace your DAC chips to use MQA they’ll have a hard time getting any market penetration. Having to add another chip to do MQA processing is an easier sell, still I doubt that that’s a great solution for most DAC builders. Having it be a pure software solution seems to be the way to get the market - their target is streaming and that’s a much smaller set of players than DAC builders. But I repeat I’m just speculating.
A very interesting story on MQA by Hans Beekhuyzen:
adriaan said A very interesting story on MQA by Hans Beekhuyzen:To avoid forming a circular time loop, see Post #27 in April.
[Elk addition: click here for post #27)
I found this on the musicischanging.com website which confirms the MQA encoded output at 1.5 Mbps.
I have 2 questions.
How could such vast input information; in this case increase in sampling frequency can be ‘compressed’ into a fixed bandwidth of 1.5Mbps?
If the encoded MQA with a bit rate of 1.5Mbps get decoded using a MQA decoder, what is the expected bit depth/sampling of the final output to a DAC? In this case will the output follows the input bit depth/sampling frequency or simply output a fixed 24/44.1 or 24/48?
I was eager to try out MQA file and I saw 2L music store:
that shows MQA file in ‘Original Resolution’ while the rest are quoted with their respective bit depth and sample. The recording is mastered on a DXD 352.8/24. It is a bit strange why 2L quoted as ‘Original Resolution’ and not 352.8/24 or 44.1/24? If someone here have MQA playback device can confirm what is final output file resolution displayed on it? Thank you
MQA’s assumption is that the ear has finite bandwidth therefor using vastly more bandwidth when sending music around is a waste. Clearly (NPI) the perceived differences between, say, 24/192 and 24/96 isn’t a factor of two - in fact for the “average” listener, especially on a portable player, there’s no audio quality difference except maybe in favor of 24/96 since it requires fewer resources to deliver the sound.
Further not all bits carry the same amount of info in PCM - the lower bits, especially in a 24 bit word, carry almost nothing - if you flipped a few at random no one would notice. On the other hand the high order bits matter a great deal more - flipping just one probably couldn’t be missed by anybody, except perhaps in particularly loud and dense music.
You could interpret the graph as saying that they don’t think any frequency in the signal above 44.1k or 48k is worth encoding at all.
I think it’s probable that 2L is merely stating that MQA’s input was the original DXD. A “feature” of MQA is that you can play it back in what ever resolution you have available. I don’t know how various MQA players will use/display that.
It is my understanding that the MQA implementation on the DAC side is dependent on the DAC itself (e.g. filter settings), however there also exist a ‘generic/common’ setting for interfacing most DACS. I believe this might complicate things on the sub-optimal side of it.
As a retired financial/CPA guy, I can understand any audio company taking a ‘wait-n-see’ posture regarding MQA, at least for an initial period. But sooner than later, it may begin to have an adverse impact on sales when your product is not MQA-capable. My wife and I have a couple hundred CDs sitting in the closet. I didn’t rip and store them as they’ll all available on TIDAL. We stream 99% of the time. If PS Audio equips the next Nuwave with MQA, I’ll look seriously at upgrading. If not, I’ll look elsewhere.