There’s no functional issue here, since MQA decoding can currently only occur at the DAC and I do believe that Roon is delivering these bits to the DAC unmolested, but since Roon has been so good at identifying MQA tracks since back when that functionality was added, I thought I should point out an instance where it’s apparently failed.
It occurs with this album:
…which I bought in the MQA flavor, and which I believe was actually delivered to me as MQA - because when I have Roon play tracks from this album to a Meridian Prime’s USB input, the Prime’s “2x” and “MQA” LEDs light up.
Roon, however, identifies the album as “FLAC 48kHz 24bit 2ch” which is indeed what I’d expect the encapsulating format to be. Given that the album is also available as a non-MQA 96k-sampling-rate FLAC, it makes sense that the Prime’s “2x” light would light, indicating that the stream was being unfolded to 96k in the DAC.
I also note that this album is being listen in Roon based on the tracks’ included metadata, because it hasn’t yet been matched to metadata from Roon; but am I correct in assuming that a metadata match should not be necessary for recognizing MQA?
This is happening with Roon 1.2 (build 165) stable (64 bit) on Linux.
This happens when the file tags do not meet MQA’s specifications. Either the publisher made a mistake when tagging the file, or something else modified the tags in a way that caused them to go awry of the standard.
According to MQA’s specifications, an MQA FLAC file should have a tag called “ENCODER” that contains the string “MQAEncode”, as well as a tag called “ORIGINALSAMPLERATE” which contains the original sample rate. This is the pattern that Roon is looking for when identifying MQA files.
1.3 is going to pick up a few variations that 1.2 didn’t–particularly in cases where “ENCODER” has been mis-spelled as or re-written to “ENCODEDBY”. I know of at least one tag editor that performs this re-write silently whenever tags are saved, and despite MQA’s current documentation continuing to indicate “ENCODER” as the tag name, the horse is already out of the barn, so we’re going to have to help clean up the mess by respecting some of these variations.
Ah. Thanks for the clarification! I hadn’t realized that identification of MQA tracks depended on tags, I guess I’d assumed some sort of examination of the least significant bits of the audio data for magic patterns was what had to happen.
Given that clue, yes, somebody clearly whiffed on this one with respect to adding the correct tags. Here are the tags in one of the tracks which isn’t being identified:
-- 01 The Mystic Chord.flac
- FLAC, 405.66 seconds, 48000 Hz (audio/x-flac)
title=The Mystic Chord
artist=Michael Blanco
albumartist=Michael Blanco
album=Spirit Forward (feat. John Ellis, Kevin Hays & Clarence Penn)
tracknumber=1
date=2016
composer=Michael Blanco
genre=Jazz
copyright=2016 Michael Blanco
label=Brooklyn Jazz Underground Records
isrc=USLKM1600020
official_audio_source_url=http://www.highresaudio.com
tracktotal=8
comment=Processed by Highresaudio.com
…whereas these are the tags in a track from the same retailer which is being identified properly as MQA:
-- 01 Andante Allegro.flac
- FLAC, 80.45 seconds, 44100 Hz (audio/x-flac)
title=Fantaisie op. 54bis - Andante Allegro
artist=LEncouragement Guitar Duo
albumartist=LEncouragement Guitar Duo
album=LEncouragement - 19th Century Guitar Duos
tracknumber=1
discnumber=1
date=2016
composer=Fernando Sor
genre=Classical
label=Eudora Records
isrc=ES25S1600072
official_audio_source_url=www.highresaudio.com
catalognumber=8436551170213
tracktotal=16
comment=Processed by Highresaudio
barcode=8436551170213
encodedby=Merging Technologies Album Publishing
encoder=MQAEncode v1.1, 2.2.0+388 (082e9c0), DF77A107-A71F-4E57-A322-872C6D0E99C8, Aug 04 2016 15:35:19
mqaencoder=MQAEncode v1.1, 2.2.0+388 (082e9c0), DF77A107-A71F-4E57-A322-872C6D0E99C8, Aug 04 2016 15:35:19
originalsamplerate=352800
I’ll drop Highresaudio a note about this problem. If they don’t offer a re-download of properly tagged files, can I fix up the Spirit Forward tracks on my end just by inserting these tags, and not worry about having that cause breakage later?
Interestingly, I had this exact problem. I’ve gone back and forth with HighRESaudio a number of times, and they seem quite reluctant to acknowledge the problem because the files do, of course, reflect proper MQA status when played.
I’ve provided them with the information from my own collection, and also pointed them to this thread since we’ve had the same problem. Whether they’ll actually do anything about the problem, though, is unknown (and, based on their replies, unlikely).
When I contacted Highresaudio about this issue, the response I got was cordial and to the point. The respondent said that encoding and associated tagging were handled by MQA, that they’d be contacting MQA about this issue, and that Highresaudio would send me an update when they had an answer.
While the whole thing hasn’t finished playing out yet - only a couple of days have elapsed since that correspondence - my initial impression is positive and I am hopeful. Maybe I got a different support person than you did, or maybe you’d already softened them up.
