Article: Apple Music's Lossless and Hi-Res Mess

[wklie]

3 hours ago, keeper said:

Strange LUMIN confirm it’s lossless and it sounds very good.

 

The protocol can be lossless ALAC 44.1kHz, but it still depends on the apps and the OS to do everything in a manner that avoids harming bit perfect transmission.

[wklie]

3 hours ago, Marco Klobas said:

Yes, usually LUMIN handles AirPlay in lossless and works fine.

 

In this specific case is Apple Music that converts to AAC before sending the AirPlay stream.

 

Current firmware for all models of Lumin network streamers only supports ALAC and does not accept AAC in the current implementation of AirPlay 1.

[wklie]

35 minutes ago, firedog said:

So, can someone give me the short "for dummies" version - is there a reasonable way to get lossless and/or losslossless hi-res to your stereo system from this service?

 

For stereo tracks, at this time you get the best (neither claiming nor denying it is lossless delivery) results from having a USB DAC connected to an iOS device (via an appropriate adapter) but not a Mac.

[wklie]

My speculation is that in this scenario you're getting an AAC stream from the service, then it gets converted to ALAC and is sent to Lumin.  Perhaps watching a network traffic monitor may prove or disprove this speculation.

 

So it's best to choose the system wide AirPlay instead, such that the app shows it's lossless.  In this usage, please set the Mac to 44.1kHz since Lumin AirPlay is currently fixed at 44.1kHz.

[wklie]

24/48 is lossless (not Hi-Res) by Apple definition.

 

24/48 (or anything above 16/44.1) is Hi-Res by Qobuz definition, and is generally accepted in the audio community (I believe).

[wklie]

Branding lossy as Premium does not make much sense to me either.  From time to time there were users who subscribed to the wrong tier because of this misleading word.

[wklie]

On iPhone and iPad, after enabling lossless in settings, and use the built-in iOS device speaker to play, we can see Lossless logo in the list of tracks for an album.

 

My question is, when you bring up the playing screen where you see a larger album art, and only the current playing track name is shown (instead of a list of tracks), do you see the Lossless logo?  I cannot for most of the albums I tried (over a dozen, including Taylor Swift).  I suspect this is a regional thing, or perhaps I did something wrong.

 

Thanks.

[wklie]

10 hours ago, R1200CL said:

https://content.abt.com/documents/61707/MDR1ADACS_manual.pdf

https://www.digitaltrends.com/music/what-is-high-resolution-audio/

 

https://audiophilereview.com/audiophile/the-truth-about-high-resolution-audio-facts-fiction-and-findings/
 

Many opinions what is hi res.

 

Summary:

 

First link: anything over 16/44.1 is Hi-Res (matches Qobuz definition)

 

Second link: Hi-Res must be 24-bit and must be 48kHz or higher

 

Third link: my interpretation is that the author prefers 24/96 for Hi-Res, and dismisses 24/48 as not Hi-Res (matches Apple definition)

 

[wklie]

On 6/10/2021 at 12:36 AM, Marco Klobas said:

Here's the link of Naim's forum where the software director Steve Harris confirms that lossless Apple Music via AirPlay is sent in AAC (lossy):

 

https://community.naimaudio.com/t/apple-music-hifi-tier-incoming/16445/437

 

Same evidence is found on Roon's forum:

 

https://community.roonlabs.com/t/apple-music-high-res/159869/646

 

My AirPlay testing results from iPadOS 14.6 playing Taylor Swift folklore Lossless:

 

• AirPlay2 to a competitor streamer: shows AAC on the front panel
• AirPlay2 to reference AirPlay2 code: shows AAC in log messages
• AirPlay1 to Lumin AirPlay1 implementation: goes through the lossless ALAC decoder in log messages (Lumin AirPlay1 implementation does not accept AAC)

 

[wklie]

That's debug logs from self compiled non-public (NDA) source code with root access to hardware, so it is not reproducible by anyone else.

 

At least for AirPlay1, I imagine someone using one of the many Open Source distributions with shairport-sync (but we're not using it) could retest it.

[wklie]

I checked shairport-sync, found over 300 references to alac, but 0 reference to aac.

 

I believe it only supports ALAC and PCM only, not AAC.

 

[wklie]

17 hours ago, Marco Klobas said:

Basically, shairport-sync (which uses AirPlay 1 protocol) handles the stream in ALAC mode, similarly as LUMIN streamers do like @wklie pointed out recently many times.

 

If Apple Music playing a lossless track from its catalogue provides an AAC stream to the AirPlay receiver – thus, "degrading" the whole lossless thing – then it's another story. The culprit is the Music app itself – the sender, not the receiver.

 

By streaming Fairytales (MQA) from iPadOS 14.6 Apple Music → AirPlay1 Lumin (at max volume) USB output → Full MQA DAC shows MQA. (successfully authenticated MQA, not possible with lossy encoding)

 

This is good enough for me in that I can tell customers that they can at least get 16/44.1 lossless from Apple Music using our products, and in this use case, neither Apple Music source is downgrading to AAC nor AirPlay1 delivery is downgrading to AAC.

[wklie]

On 6/13/2021 at 11:57 AM, Electroecstatic said:

From an engineering point of view, a sensible thing for Apple to do with HDCD files it may have as masters provided by a record label on their servers would be to get the best possible software renderer to 'decompress' the HDCD files into 24 bit ALAC files at the original sampling rate for streaming.

 

If this really happened, the HDCD indicator would be always off (which is different from the test results that found it occasionally turned on in the article).

[wklie]

@The Computer Audiophile In another forum there was a test of USB output of Apple Music Fairytales MQA CD  getting a MQA light initially but then turned off (somewhat similar to your HDCD results), but I have no problem with MQA light on an external USB MQA DAC staying on via AirPlay1 to Lumin USB output.

 

Could you retest HDCD using iOS 14.6 AirPlay1 to any streamer or Pi running the open source shairport-sync, which I checked that it accepts ALAC (and PCM only), not AAC.  Then USB output to your HDCD DAC.

[wklie]

I assume everyone but me knows this already, I just discovered that "Sound Check" setting means volume leveling that would destroy bit perfect delivery.

 

For anyone who wants to repeat the bit perfect tests, please disable Sound Check, EQ, and Dolby Atmos.  Enable Do Not Disturb.  Set Volume to Max.  On Mac, the output sample rate needs to be set manually.

 

If there are any other settings that would destroy bit perfect delivery, please let me know.  I recall a customer used an audio switching software on Mac that he thought was merely routing audio signals, but it actually destroyed the bit perfect delivery too.

[wklie]

29 minutes ago, jjdnyc said:

does anyone know whether the ATV will stream lossless when using the native Apple Music app on the ATV? There doesn’t appear to be anyway to tell what it is doing. 

Does it have a lossless or HiRes lossless setting?  Does it show the lossless icon?

 

[wklie]

On 6/20/2021 at 12:02 AM, vortecjr said:

1. Apple Lossless at 24/44.1 streamed via Apple Music App to Rendu in Shairport output mode. 

 

I suggest using Apple Music Lossless 16/44.1 for testing bit perfect delivery for now.  Some versions of, if not all, shairport works only at 16/44.1 for the AirPlay1 delivery.  Even if one changes the implementation to allow for 24 bit, it's still up to the sender to decide whether it wants to send 24 bit over AirPlay1.  I also have a suspicion that iOS 24-bit to 16-bit is dithered, not truncated.

 

I have not read all of mikebrady's post (will try to catch up), but at least one post linked from here specifically stated 16 bit.

[wklie]

15 hours ago, Marco Klobas said:

Run shairport-sync in writing mode (shairport-sync -u -o stdout > 'file-name.wav')

 

This looks really useful.  I'll see if I can make use of this technique and do further tests that are better than Apple Music MQA CD authentication, in order to further prove Apple Music Lossless 16/44.1 can be bit perfect over AirPlay1.

[wklie]

I did inspect the MQA light for the whole duration for a few tracks in Fairytales MQA CD AirPlay1 test, but of course this is a much weaker test than binary file diff.

[wklie]

3 hours ago, The Computer Audiophile said:

Would be interesting to start turning the digital volume in Apple Music app down as it plays. This cuts bits of course and should remove any mQa light immediately. 

 

Tested with expected results.

 

Test setup: iPadOS 14.6 Apple Music Fairytales MQA CD AirPlay1 to Lumin USB output to a third party Full decoder MQA DAC.

 

At max volume, MQA indication is shown on the DAC front panel.

Decrease the volume, MQA indication is lost within 1 second.

Increase the volume back to max, MQA indication is regained within 4 seconds.

This process is repeated many times for the first three tracks.

 

Since Lumin is used as the AirPlay1 receiver, iPadOS sends the desired volume metadata to Lumin, which then applies Leedh Processing Volume (if not at max volume) to digitally change the bits, thereby destroying MQA integrity.

[wklie]

12 hours ago, vortecjr said:

I’m going to test Shairport-sync with stdout in the next couple days.

 

Yes, please do.

 

stdout avoids the feature of stuffing in shairport-sync.  Related settings including disable synchronization, drift tolerance, etc. may impact bit perfect delivery.

[wklie]

3 hours ago, new_media said:

I'm particularly concerned about the AirPlay 2 issue. I had assumed that if I downloaded lossless files to my phone, I could then stream them over AirPlay losslessly, but I keep reading that maybe they are getting converted to AAC by the app before they are streamed?

I suspect the deliberate choice to use 256kbps instead of lossless delivery is a feature, not a bug, to enhance buffering for multi room playback, especially considering many consumers have really poor WiFi networks.  If the company standpoint is that lossless superiority is not audible to the 98% majority, any means to reduce support calls about audio breaking up is advantageous.  That actually makes perfect logical sense if one assumes quality degradation is inaudible, improved functionality becomes the primary factor that deserves optimization (by decreasing bitrate).

 

In WWDC 2017 it was presented that AirPlay2 enhanced buffering allows you to take out the trash (leave the WiFi network) without music being interrupted.  At 256kbps I calculate this to allow for several minutes.  With lossless compression, this duration may roughly become one third only, which would not be sufficient for taking out the trash.  Audiophiles may ask why would they would want to take out the trash when they are enjoying the music, if you need to ask this question, this feature is not meant for you.  :)

 

Again I stress that this is my speculation only.

[wklie]

7 hours ago, Marco Klobas said:

My USB loopback test on Mac doesn’t match with Chris’s test. In my case the tracks are nulled.

 

Album/track, sample rate, bit depth, other settings, etc.  There may also be other factors such as presence of certain apps like BitPerfect, integer mode, etc.

[wklie]

Thanks for the details.

 

I'm not familiar with these software or how they are normally professionally used, so I'm a bit surprised to see 32-bit float.  I wonder if there is any virtual soundcard driver to capture the 24-bit or 16-bit integer data to make the setup simpler.

[wklie]

When I mentioned virtual soundcard driver I assumed it will somehow allow directly capturing of the bits (i.e. performs like stdout from shairport-sync), but I don't know whether this makes sense or not as I have not looked into this, and I'm not familiar with Mac OS.