I will discontinue local file detection support, and reasons why. 路 vincentneo/LosslessSwitcher 路 Discussion #74 路 GitHub 您所在的位置:网站首页 Losslessswitcher I will discontinue local file detection support, and reasons why. 路 vincentneo/LosslessSwitcher 路 Discussion #74 路 GitHub

I will discontinue local file detection support, and reasons why. 路 vincentneo/LosslessSwitcher 路 Discussion #74 路 GitHub

2024-01-10 19:50| 来源: 网络整理| 查看: 265

In future versions and builds of LosslessSwitcher, AppleScript-based, local file detection support will be removed. That also means that issue #15 will ignored.

If you have no time to read the following, here's the TL;DR: It has been proven that local file detection is meaningless due to how Music app handles sample rate, but thankfully does not impact Apple Music Lossless streams.

Background

Back in May of 2022, a user of LosslessSwitcher sent me an email, detailing a bug pertaining to sample rate conversion, that existed all the way back from 2007's iTunes.

Quoting an essential part of the email, of an example of the bug:

Instead, iTunes converts the 96k music to the sample rate configured when iTunes was launched (44.1), then Core Audio converts it back to the sample rate of the audio output device (96)!

Basically speaking, iTunes converts the sample rate captured on app launch, and first converts it to that rate, up or down as necessary, and then convert it again, to the current sample rate set on the device.

The user stated that an Apple engineer even confirmed this as a bug, publicly. I've googled and found that it appears to be with this: https://lists.apple.com/archives/coreaudio-api/2008/Jan/msg00273.html

I had tried testing out on this theory before, but my overall lack of such knowledge on such matter had proven that me doing the testing would lead to nowhere. With that, this issue was left alone for so long, as I thought an issue of such long history, especially one that is from the current app's predecessor, is highly unlikely to still persist.

Just last month, another user send an email explaining about the issues surrounding the recent bit depth update, in his professional opinion as an audio engineer.

I saw this conversation as a chance to test out the above theory, so I asked if it could be done, and the results proved that the contents of the May 2022 email, was indeed correct, but only relevant to local files.

Let's look at the evidence here:

Local File Playback via Apple Music

The Apple Music app was first launched when the output device was set to 44.1kHz on the system. Before playback, the output device was set to 96kHz. A local 96kHz audio track was then played.

The red line denotes 96kHz local content playback from the Apple Music app. The orange line, should have been what a proper 96kHz without resampling should look like.

Quoting from the email:

If there was no conversion both would be identical, frequency response and impulse response.

image image

Apple Music streaming vs local file playback

Testing for this case was harder, due to the nature of requiring a testable track that is consistent on the streaming service. Testing for this case was made possible by a 44.1kHz noise track on Apple Music (via streaming), compared to a local 44.1kHz noise track.

Case 1

Apple Music app was launched when the output device was set to 48kHz on the system. Before playback, the output device was set to 44.1kHz.

The green line denotes the 44.1kHz local test noise track playback from the Apple Music app. The blue line denotes the 44.1kHz noise track found from Apple Music streaming.

image

Case 2

Apple Music app was closed, and relaunched when the output device was set to 44.1kHz on the system. Before playback, nothing was changed.

The yellow line denotes the 44.1kHz local test noise track playback from the Apple Music app. The blue line denotes the 44.1kHz noise track found from Apple Music streaming.

image

What the results show

The results conclusively showed that, in order for local playbacks to avoid sample rate conversion, while switching sample rates after the app was launched (could be iTunes or Apple Music), is impossible. The app would have to stop playback and be relaunched every time there's a need to change sample rates.

On the other hand, the issue does not impact Apple Music streaming users, as we can see in the above cases 1 and 2, that the integrity of the audio signal remains, regardless of the initial sample rate from which the Apple Music app was launched.

Impact

Since there has always been user reports on whether if the local sample rate detection via AppleScript, even worked at all (or even resulted in regressions), in the first place, such as issue #30, I believe this decision will not largely impact users.

The core and initial purpose was to serve Apple Music Lossless users anyway, and I am glad to know that the bug does not impact this group of users.

To end, I would like to thank the two users that informed and tested regarding this issue, and that I would like to apologise for the fact that had failed to test on the issue when it was raised.

Thank you for using LosslessSwitcher as always, and please do comment your thoughts below. Thank you.



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有