Apple Music's Lossless and Hi-Res Mess

My previous purchases (before the Apple Music lossless) show:

kind: Purchased AAC audio file

cloud status: Uploaded

Sorry if this has already been asked and answered, but I'm curious and would appreciate knowing whether or to what extent Apple Music is lossless if played via the ITunes App in Windows 10? 

I have been streaming ITunes in Windows 10 through JRiver MC's WDM driver to my DAC via WASPI in ITunes
using the Windows Audio Session setting (Edit/Preferences/Playback/Play Audio Using Windows Audio Setting). I set the sample rate to 192 kHz and the bit depth to 24-bit in the ITunes App (Edit/Preferences/Playback/Sample Rate For Audio, Bits Per Sample For Audio).

A related question is whether or to what extent Apple Music is lossless if played through a browser via music.apple.com, and whether or not it is better, worse or the same as via the ITunes Windows App.

On Apple Support Communities forum, where the AirPlay issue is debated as well, a user replyied to me with an interesting post:

https://discussions.apple.com/thread/252848734?answerId=255437882022#255437882022

28 minutes ago, The Computer Audiophile said:

I did a ton of testing today. Will have an updated article Thursday. 

Really interested to read what you have been testing, Chris.

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?

Have you compared streaming music directly from the Apple servers vs. streaming local files downloaded to an iPhone or a Mac?

1 hour ago, Mayfair said:

Sorry if this has already been asked and answered, but I'm curious and would appreciate knowing whether or to what extent Apple Music is lossless if played via the ITunes App in Windows 10? 

 

I have been streaming ITunes in Windows 10 through JRiver MC's WDM driver to my DAC via WASPI in ITunes
using the Windows Audio Session setting (Edit/Preferences/Playback/Play Audio Using Windows Audio Setting). I set the sample rate to 192 kHz and the bit depth to 24-bit in the ITunes App (Edit/Preferences/Playback/Sample Rate For Audio, Bits Per Sample For Audio).

 

A related question is whether or to what extent Apple Music is lossless if played through a browser via music.apple.com, and whether or not it is better, worse or the same as via the ITunes Windows App.

I don't think the Windows app has been upgraded to support lossless yet? So you are probably just upsampling an AAC stream. I don't think the Apple Music browser player supports lossless, either.

3 minutes ago, new_media said:

 

Really interested to read what you have been testing, Chris.

 

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?

 

Have you compared streaming music directly from the Apple servers vs. streaming local files downloaded to an iPhone or a Mac?

Yes :~)

10 minutes ago, new_media said:

 

I don't think the Windows app has been upgraded to support lossless yet? So you are probably just upsampling an AAC stream. I don't think the Apple Music browser player supports lossless, either.

Thanks for the speedy response!  I hope they will upgrade the iTunes Windows app and the browser app to support lossless. But I’m  not holding my breath. 

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.

Well, I think that I have finally come up with a solution that is (for sure) a fully lossless playback chain, but definitely not bit perfect.

I posted a few pages back that when I stream from an iPhone to an Apple TV 4K, the Apple TV shows that it is playing either lossless or hi-res. I attached the Apple TV to an HDMI splitter with a digital display that gives you information on the audio and video streams, and the Apple TV consistently puts out 24/48 over HDMI.

Using an AmazonBasics HDMI Audio Extractor, I can output the audio over SPDIF. I haven't been able to find tech specs on the audio extractor, but if it can handle 4K video, I assume it can handle 2-channel 24/48 audio.

Right now I have SPDIF into a Sonos Amp via the Sonos optical to HDMI Arc adapter. For as kludgy a solution as this is, it sounds pretty good, and I can use the Apple TV 4K headless.

So, everything is getting resampled to 24/48 and I am running HDMI to optical SPDIF to HDMI Arc, but I think I finally confidently have a lossless playback chain.

Thanks, Apple, for making everything so clear and simple. 🙄

My question to myself (which I am sharing with everyone else) is can I tell the difference between Amazon lossless (non bit perfect) FLAC and AIFF CD's which I ripped to my NAS and play through Audrivana in WASAPI exclusive mode which must be bit perfect?

To make the comparison to my ears equal- I did not play amazon FLAC direct from my network but rather downloaded the FLAC files to my NAS which has a linear power supply.  Ripped CD's are also played from my NAS.

Now I have an extremely revealing system with a Mutec Ref 10 se-120 clock attached to my DDC, DAC, SOTM usb-tx ultra, and two etherregens.  I have a superb linear power supplies throughout my system as well.  I even have a topaz balanced  isolation transformer on my entire system which reduced noise by -165.  Point being- this is about the best it gets- so I should be able to detect differences as well as anyone out there.

Bottom line, FLAC played from amazon in "semi exclusive mode" and AIFF from Audrivana in WASAPI exclusive mode when comparing the exact same songs from the exact same CD's sounds very very close to EXACTLY the SAME.  Perhaps the AIFF is ever so slightly fuller and the FLAC is ever so slightly more dynamic sounding, but the difference is very very very slight.  The music is nearly indistinguishable.  I would have enormous difficulty knowing which option was playing if I did a blind test.  Streaming FLAC on amazon direct from the network and not from my NAS does sound one step below the ripped CD's AIFF files from Audrivana, but it is only fair that if the AIFF is downloaded to my NAS, that the FLAC also be downloaded to the NAS for equal comparison; and to my ears- it is 99% the same.......

I know this bit perfect stuff is big in our world- but my ears cannot tell the difference on a very high quality system.

By the way, on my Audio-gd R-7HE DAC, I have the option for NOS or up-sampling.  To my ears and to the ears of so so many people who report their findings with this world class DAC, up-sample is preferable.  Yet up sample certainly ruins bit-perfect playback; that is non arguable.  Many more technically minded people say all DACs in their processing ruin bit-perfect playback even if it is bit perfect when leaving the computer even in NOS.  

SO- it is fun to talk about this bit perfect stuff- and from a purist viewpoint- I prefer it, but my ears really cannot tell the difference.

Therefore, for me, the biggest deciding factor between all the streaming services is which has the best library for my musical tastes.  $10, or $20 a month isn't making a difference to me.  Spotify and Apple are the best at suggesting the type of music I like- and that is worth something to me as well.  I am not crazy about the Amazon interface either.  But sound quality, amazon FLAC and AIFF from Audrivana are nearly indistinguishable.

New article is up, with video examples.

Hi Chris, really appreciate your work on this. I haven't seen other attempts to actually validate AM lossless (yet), and your transparency is stellar.

I have to say relying on HDCD in the methodology is, to me, a massive, inherent flaw. We know from long-published investigations[1][2] that HDCD is, at best, flaky, unreliable, poorly implemented, not actually 24bit, and ultimately a failed attempt at pushing beyond 16bit with a format that is, shall we say, unsupportive – and probably a good way to collect royalties for Pacific Microsonic and, later, Microsoft. (If there are proper refutations of these articles I linked, I haven't seen them, and would very much appreciate links. Same for any insight on why we have access to purchasable 24bit audio with the HDCD control packet shifted to the 24th bit instead of the 16th – if we do?)

It's also very generous to assume AM was supplied the same HDCD-flagged masters as Qobuz or any other service/release. I realize, of course, many artists and labels use distributors for streaming and download stores, and distributors typically will only differentiate sources in the case of Apple Digital Masters, otherwise sending the same source files everywhere. The likelihood that Qobuz received properly HDCD-flagged files but AM did not is probably small, but it's there, and nothing short of confirmation from an artist or label source can settle the matter, sadly. That the HDCD lights up at all from AM clearly indicates presence on some level, but cannot be taken at face value, making HDCD's use in these tests even more problematic.

There is only one proper, fully trustable, most-likely-to-be-foolproof methodology for this, and it is null testing. Completely remove HDCD from the equation, buy or find the files likely to be the same lossless/uncompressed source given to AM, digitally record AM's output stream, match timing and peak levels as close as possible between the originals and AM recordings, then flip the phase of one of them and examine the differential left behind. And film the tests! That was an excellent addition to the Airplay tests to help verify what was going on and not just 'take your word for it'.

Note that I have no skin in the game here: you seem invested in finding the reality of the situation without bias, as shown in the article updating; and I'm no Apple/AM fanboy, though you obviously only have my word to go on for that. I work in audio professionally (production/events) and I'm afraid these tests currently have too many red flags for me to consider them anything more than curious results definitely raising an eyebrow and inviting further testing. (I'm sure a common question will be why I haven't done these myself, and the answer is simply that I'm not running Big Sur in order to maintain stability of my production setup, so I cannot investigate the Music app's output stream until I eventually update. The iOS app is indeed available to me, but I'd have to investigate just how to grab the Music output without converting to analog, since that would skew the null test. Open to suggestions there!)

1 hour ago, seasonsinthesky said:

Hi Chris, really appreciate your work on this. I haven't seen other attempts to actually validate AM lossless (yet), and your transparency is stellar.

I have to say relying on HDCD in the methodology is, to me, a massive, inherent flaw. We know from long-published investigations[1][2] that HDCD is, at best, flaky, unreliable, poorly implemented, not actually 24bit, and ultimately a failed attempt at pushing beyond 16bit with a format that is, shall we say, unsupportive – and probably a good way to collect royalties for Pacific Microsonic and, later, Microsoft. (If there are proper refutations of these articles I linked, I haven't seen them, and would very much appreciate links. Same for any insight on why we have access to purchasable 24bit audio with the HDCD control packet shifted to the 24th bit instead of the 16th – if we do?)

It's also very generous to assume AM was supplied the same HDCD-flagged masters as Qobuz or any other service/release. I realize, of course, many artists and labels use distributors for streaming and download stores, and distributors typically will only differentiate sources in the case of Apple Digital Masters, otherwise sending the same source files everywhere. The likelihood that Qobuz received properly HDCD-flagged files but AM did not is probably small, but it's there, and nothing short of confirmation from an artist or label source can settle the matter, sadly. That the HDCD lights up at all from AM clearly indicates presence on some level, but cannot be taken at face value, making HDCD's use in these tests even more problematic.

 

There is only one proper, fully trustable, most-likely-to-be-foolproof methodology for this, and it is null testing. Completely remove HDCD from the equation, buy or find the files likely to be the same lossless/uncompressed source given to AM, digitally record AM's output stream, match timing and peak levels as close as possible between the originals and AM recordings, then flip the phase of one of them and examine the differential left behind. And film the tests! That was an excellent addition to the Airplay tests to help verify what was going on and not just 'take your word for it'.

Note that I have no skin in the game here: you seem invested in finding the reality of the situation without bias, as shown in the article updating; and I'm no Apple/AM fanboy, though you obviously only have my word to go on for that. I work in audio professionally (production/events) and I'm afraid these tests currently have too many red flags for me to consider them anything more than curious results definitely raising an eyebrow and inviting further testing. (I'm sure a common question will be why I haven't done these myself, and the answer is simply that I'm not running Big Sur in order to maintain stability of my production setup, so I cannot investigate the Music app's output stream until I eventually update. The iOS app is indeed available to me, but I'd have to investigate just how to grab the Music output without converting to analog, since that would skew the null test. Open to suggestions there!)

This has been brought up every time I use the HDCD test, but it has yet to be proven faulty. 
 

If Apple Music plays an album and the HDCD light goes off and on throughout the track, it’s safe to assume this is an HDCD master. Otherwise, the HDCD light would remain off at all times. 
 

The reality of doing a null test is less accurate actually because you can’t guarantee which master AM has compared to the baseline / control master. 
 

HDCD is perfect for this because we know the master is HDCD if the light even flickers once. Plus, investigating masters by talking to the owner of the record label, recording engineering who made the recording, and person responsible for delivering it to Apple, is conclusive in my book. 

2 hours ago, seasonsinthesky said:

Hi Chris, really appreciate your work on this. I haven't seen other attempts to actually validate AM lossless (yet), and your transparency is stellar.

I have to say relying on HDCD in the methodology is, to me, a massive, inherent flaw. We know from long-published investigations[1][2] that HDCD is, at best, flaky, unreliable, poorly implemented, not actually 24bit, and ultimately a failed attempt at pushing beyond 16bit with a format that is, shall we say, unsupportive – and probably a good way to collect royalties for Pacific Microsonic and, later, Microsoft. (If there are proper refutations of these articles I linked, I haven't seen them, and would very much appreciate links. Same for any insight on why we have access to purchasable 24bit audio with the HDCD control packet shifted to the 24th bit instead of the 16th – if we do?)

It's also very generous to assume AM was supplied the same HDCD-flagged masters as Qobuz or any other service/release. I realize, of course, many artists and labels use distributors for streaming and download stores, and distributors typically will only differentiate sources in the case of Apple Digital Masters, otherwise sending the same source files everywhere. The likelihood that Qobuz received properly HDCD-flagged files but AM did not is probably small, but it's there, and nothing short of confirmation from an artist or label source can settle the matter, sadly. That the HDCD lights up at all from AM clearly indicates presence on some level, but cannot be taken at face value, making HDCD's use in these tests even more problematic.

 

There is only one proper, fully trustable, most-likely-to-be-foolproof methodology for this, and it is null testing. Completely remove HDCD from the equation, buy or find the files likely to be the same lossless/uncompressed source given to AM, digitally record AM's output stream, match timing and peak levels as close as possible between the originals and AM recordings, then flip the phase of one of them and examine the differential left behind. And film the tests! That was an excellent addition to the Airplay tests to help verify what was going on and not just 'take your word for it'.

Note that I have no skin in the game here: you seem invested in finding the reality of the situation without bias, as shown in the article updating; and I'm no Apple/AM fanboy, though you obviously only have my word to go on for that. I work in audio professionally (production/events) and I'm afraid these tests currently have too many red flags for me to consider them anything more than curious results definitely raising an eyebrow and inviting further testing. (I'm sure a common question will be why I haven't done these myself, and the answer is simply that I'm not running Big Sur in order to maintain stability of my production setup, so I cannot investigate the Music app's output stream until I eventually update. The iOS app is indeed available to me, but I'd have to investigate just how to grab the Music output without converting to analog, since that would skew the null test. Open to suggestions there!)

Let’s leave the general discussion about HDCD for another day. 
 

The test methodology Chris is using is simple and very effective. In fact, the LED lights up and stays on as expected when it appears the stream is bit perfect and does not light on and stay on when it appears the stream is not bit perfect. Chris went above and beyond in using the specific content he did with the approach strengthening the use case. FYI I spoke with R.R. about their 24 bit HDCD content and they told me the flagging is only used for checking bit perfect playback. I’m not certain all HDCD DACs can be used with 24 bit HDCD content, but Alpha DAC appears to support it. 
 

I don’t agree with your assessment of null testing. It’s great at comparing pristine files. However, capturing the output of hardware means you are capturing the signal and any inherent noise from the playback scheme. Also, keep in mind that the noise changes with time. As such, you can generally forget about a full null when comparing files with playback recordings through a system. 
 

So if Chris is using HDCD content for testing I’m going to take his word for it. 
 

@seasonsinthesky 

For what is worth, I made some tests using the null method, recording the stream and comparing it with an original counterpart track.

I could’t test AirPlay 2 because I don’t own an AirPlay 2 device. Actually I own two of them: an Apple TV and a HomePod. They simply aren’t suitable for testing for obvious reasons: Apple TV’s output resamples everyting at 48kHz and with the HomePod is impossible to know what it is receiving and, besides, it doesn’t support Apple Music lossless yet.

My AirPlay 1 tests (iOS/iPad OS -> Mac and Mac -> Mac) confirm what Chris found out. I couldn’t test the system-wide AirPlay 1 on Mac, only within Music app.

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

I even managed to make a loopback USB test with iPad. I haven’t shared it publicly yet because I find it quite convoluted and so prone to variables that could ruin the reliability.

I will share it, in case. Anyway, for the record, even in this case the tracks don’t null.

Basically, with the exception of the USB test on Mac and excluding what I couldn’t do, almost everything matches Chris’s tests.

I find the HDCD test quite interesting and definitely worth to be considered. The null test is theoretically very valid. Unfortunately certain crucial conditions have to be met: the recording has to be “pure”, without any alteration and the original file used for comparison has to be exactly the same file provided by the streaming service. The former is somehow possible to keep under control, the latter … well not really.

1 hour ago, Marco Klobas said:

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

We should look into this one further. 

Hi, I have done a null test on AM with ipad to dac to pc via spdif.

There is definitely a small amount of noise added to 16bit material and it shows as 24bit on a bit meter.

I show the evidence in my video 

anyone can replicate this test you just need a control source like qobuz to verify 16bit on the meter then send the same track on AM

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.

15 hours ago, The Computer Audiophile said:

We should look into this one further. 

8 hours ago, wklie said:

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.

I redid the test.

I'm using the same album over and over again because it's the only album I bought after the introduction of Apple Music. Every previously matched album is unfortunately still provided by Apple's servers in AAC. It's a common issue.

This time, at least, I changed the track. 🙂

I tried to provide as much informations as possible, documenting every step. My obsession with graphic produced a tall image. I divided it in three pieces. I hope they are usable (download it, in case).

Part 1/3:

Part 2/3:

Part 3/3:

I even tried a second "hardware loopback" test:

😀 I speak for myself: no. At least, not in a relaxed way, as it should be.

I do listen without all these bit perfect/lossless/whatever distracting thoughts between the tests, though.

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 Do you mean something like BlackHole or Loopback?