MQA and DRM

[Fokus]

We'll be forced to if there's no other choice. And that's entirely possible.

 

And let's not forget that MQA also supports 16 bit channels. Some of the ultrasonic content carrying bits are scrambled into the upper 16 bits of the container, allowing them to survive, say, Airplay.

 

It is conceivable that labels in the future only offer one source at root, an MQA file, from which are derived all distribution forms (standard or hi-res streaming, downloads, CD, and MP3).

 

 

My eyes need deblurring when I think of this.

[audiventory]

It is conceivable that labels in the future only offer one source at root, an MQA file, from which are derived all distribution forms (standard or hi-res streaming, downloads, CD, and MP3).

 

Studio projects may be finalized in traditional PCM master. Theoretically the master may be released as DSD after post-production.

 

From the master may be derived MQA, DSD, PCM, mp3 in end-user resolutions.

 

Sound engeneers don't consider MQA as internal studio format, as far as I know.

[Fokus]

Sound engeneers don't consider MQA as internal studio format, as far as I know.

 

Probably not. But don't forget that the business is run by suits, not engineers.

[audiventory]

Probably not. But don't forget that the business is run by suits, not engineers.

 

Traditionally in audio many formats. If market will demand certain native resolution, there will the resolution, I suppose.

[PeterSt]

How that? Can you show how one could perform equalisation at full hi-res rate on an

MQA signal

 

a. Decode -> DSP -> Render (with software decoding player)

or

b. Decode -> Render -> DSP (can not be done by consumer)

or

c. Decode -> DSP (with software decoding player)

 

outside of a completely MQA-controlled system?

I am not sure how to interpret that phrase unless you refer to my b option above.

[Fokus]

a. Decode -> DSP -> Render (with software decoding player)

b. Decode -> Render -> DSP (can not be done by consumer)

c. Decode -> DSP (with software decoding player)

I am not sure how to interpret that phrase unless you refer to my b option above.

 

a: the DSP would break the subcode that instructs the renderer => not

b: as you say, cannot be done by the consumer => not

c: this is incomplete => not

 

What I meant with an MQA controlled system is how MQA themselves explained it: a system where the DSP is part of the components that themselves are MQA-certified, and which outputs a valid MQA stream after the DSP has been applied.

[PeterSt]

c: this is incomplete => not

 

True. So ditch ALL the software players then. Those from today and those for the future.

So, true but not practical to approach it like that.

 

a: the DSP would break the subcode that instructs the renderer => not

 

You are incorrect. See below.

 

b: as you say, cannot be done by the consumer => not

 

Correct in itself. Still, as a manufacturer I can do it. So apparently it is about how we define DSP. But things like room correction per the software of choice is a no-go.

 

Anyway :

 

What I meant with an MQA controlled system is how MQA themselves explained it: a system where the DSP is part of the components that themselves are MQA-certified, and which outputs a valid MQA stream after the DSP has been applied.

 

This is again correct. One thing : the software core decoder is allowed to have user code.

It would be true that the whole of that is to be certified, but there is no reason not to, unless the output breaks the renderer if present. When not present ©, nothing can break. What's kind of crucial here is that the software player developer is not the one who determines whether there's a renderer (always hardware) behind it; this is up to the consumer (who also determines whether he uses software decode next to the hardware renderer). So the software has to be certified regardless.

[mansr]

True. So ditch ALL the software players then. Those from today and those for the future.

So, true but not practical to approach it like that.

 

You are incorrect. See below.

 

Correct in itself. Still, as a manufacturer I can do it. So apparently it is about how we define DSP. But things like room correction per the software of choice is a no-go.

 

This is again correct. One thing : the software core decoder is allowed to have user code.

It would be true that the whole of that is to be certified, but there is no reason not to, unless the output breaks the renderer if present. When not present ©, nothing can break. What's kind of crucial here is that the software player developer is not the one who determines whether there's a renderer (always hardware) behind it; this is up to the consumer (who also determines whether he uses software decode next to the hardware renderer). So the software has to be certified regardless.

 

Thank you for refuting your own assertion. DSP between decoder and renderer is possible, but only if you're authorised by MQA. Only the major players (pardon the pun) will have the resources to obtain this authorisation.

[PeterSt]

Only the major players (pardon the pun) will have the resources to obtain this authorisation.

 

And if your resources for this "information" are as valid as your determination of DRM being in there, then there's no DRM in there.

[mansr]

And if your resources for this "information" are as valid as your determination of DRM being in there, then there's no DRM in there.

 

So where's the public, royalty-free spec for how to do DSP in conjunction with MQA?

[wklie]

a. Decode -> DSP -> Render (with software decoding player)

or

b. Decode -> Render -> DSP (can not be done by consumer)

or

c. Decode -> DSP (with software decoding player)

a. is correct, but the DSP needs to comply with MQA, as shown in A65 from Chris' article:

[crenca]

Yes, this is what Prodigy was getting at in his latest release: "Hegelian Dialectic: The Book Of Revelations."

 

 

Lol! Indeed, he really said it better than I did...

[audiventory]

a. is correct, but the DSP needs to comply with MQA, as shown in A65 from Chris' article:

.

 

As I understand:

 

1. Decoder 2 is hardware unit only.

 

2. Optimal intermediate processing made impossible work of Decoder 2.

[cbee]

As I understand:

 

1. Decoder 2 is hardware unit only.

 

2. Optimal intermediate processing made impossible work of Decoder 2.

 

Negative, below the figure in the Q&A is this " The top diagram shows the ideal implementation of an all-in-one MQA decoder. It is fairly self- explanatory. Note that the decoder has a control for gain, optimised for the DAC. Remembering that the MQA decoder is tightly bound to the DAC, the lower diagram shows how to implement additional processing"

[mansr]

Negative, below the figure in the Q&A is this " The top diagram shows the ideal implementation of an all-in-one MQA decoder. It is fairly self- explanatory. Note that the decoder has a control for gain, optimised for the DAC. Remembering that the MQA decoder is tightly bound to the DAC, the lower diagram shows how to implement additional processing"

 

The gain control is a trivial multiplication. I don't see how you could possibly do it in a DAC-specific way.

[cbee]

The gain control is a trivial multiplication. I don't see how you could possibly do it in a DAC-specific way.

 

I agree but I was addressing audiventorys second point. You can insert DSP without nullifying Decode 2. Well in theory you can, but are there any MQA DACS set up with the ability for the user to inject DSP?

[mansr]

I agree but I was addressing audiventorys second point. You can insert DSP without nullifying Decode 2. Well in theory you can, but are there any MQA DACS set up with the ability for the user to inject DSP?

 

User-supplied, no. The Bluesound applies bass/treble controls between decode and render. This involves sending the data another round through the MQA-provided software library to restore the control bitstream needed by the renderer.

[audiventory]

User-supplied, no. The Bluesound applies bass/treble controls between decode and render. This involves sending the data another round through the MQA-provided software library to restore the control bitstream needed by the renderer.

 

As I understand, render is second stage of decoding (unfolding upper 88/96 kHz), isn't it?

[mansr]

As I understand, render is second stage of decoding (unfolding upper 88/96 kHz), isn't it?

 

Render is upsampling with a terribly leaky filter.

[firedog]

I would be skeptical myself of a claim that what MQA wants to do isn't possible without hardware. Have the MQA folks made such a claim?

 

The opposite. They say it is possible in SW, but they are restricting full unfolding and deblurring to HW. Apparently so they can charge royalties for the privilege.

[firedog]

And if your resources for this "information" are as valid as your determination of DRM being in there, then there's no DRM in there.

 

I've already read of small producers of equipment saying MQA certification was expensive enough that they decided it isn't worthwhile for them.

[smartin]

I've already read of small producers of equipment saying MQA certification was expensive enough that they decided it isn't worthwhile for them.

 

Not doubting you, but could you link where you read this?

[Nikhil]

Jim Collinson of Linn weighs in on the topic via an article just released online.

I am glad that he has taken the trouble to point out the obvious.

 

https://www.linn.co.uk/blog/mqa-is-bad-for-music

 

"MQA is an attempt to not (just) simply sell the same content again at a higher margin, or to maintain audio quality in streaming ecosystems: it is an outright land grab. It’s an attempt to control and extract revenue from every part of the supply chain, and not just over content that they hold the rights for."

 

Read the article for more.

[realhifi]

Jim Collinson of Linn weighs in on the topic via an article just released online.

I am glad that he has taken the trouble to point out the obvious.

 

https://www.linn.co.uk/blog/mqa-is-bad-for-music

 

"MQA is an attempt to not (just) simply sell the same content again at a higher margin, or to maintain audio quality in streaming ecosystems: it is an outright land grab. It’s an attempt to control and extract revenue from every part of the supply chain, and not just over content that they hold the rights for."

 

Read the article for more.

 

The article has been sited here a number of times.

 

I Especially like the quote; "End customers, having paid a premium for MQA music via licensed content providers, will also have to buy MQA certified players at increased cost, with a license paid for each unit shipped". Not sure of you priced a Linn networked product lately but the DS streamers start at $3500. Compared to something like a MQA enabled device like a Bluesound Node2 at $499 or a MQA enabled Dac such as a Meridian Explorer2 at $200, you can see why one could take much of what Linn has to say on this with a grain of salt.

 

I happen to like Linn products. I do however think their cost has always been a barrier to their overall success in the marketplace and especially today with so many companies bringing better and better music streaming solutions to the market. For them to be that concerned about the profit stream that may or may not come to Meridian through MQA frankly feels a bit disingenuous as their brand has long espoused a closed "system" starting and ending with their products from source to loudspeaker even including the cables that tie the system together. Honestly, I think their just jealous that they weren't the ones that thought of this.

[Cebolla]

I happen to like Linn products. I do however think their cost has always been a barrier to their overall success in the marketplace and especially today with so many companies bringing better and better music streaming solutions to the market. For them to be that concerned about the profit stream that may or may not come to Meridian through MQA frankly feels a bit disingenuous as their brand has long espoused a closed "system" starting and ending with their products from source to loudspeaker even including the cables that tie the system together. Honestly, I think their just jealous that they weren't the ones that thought of this.

Absolute twaddle - have you actually never heard of the OpenHome Software Platform, aka UPnP with Linn extensions, nor even Linn Open Source Software?

OpenHome Platform

Linn Open Source Software