-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sometimes incorrect sample rate chosen #10
Comments
Oh no 😰 I don't remember seeing any messages in logs that corresponds to the playing track, immediately before the sample rate data. In fact, development kinda stalled as I am having trouble trying to find more time-accurate ways to accurately set the correct sample rate for the right track at the right time. (Like the 48kHz issue for 192kHz tracks, and occasional not switching or switching back and forth issues) Thanks for reporting about this issue though! |
I am seeing something similar. On Apple Music, it often changes the bit rate to match the next song in the middle of playing the current song. This causes dropouts in the middle of the song. |
same problem on me. |
what Apple Music sometimes does when It sees in my experience is that it switches to lossless and then goes to high res lossless when you have enough bandwidth. maybe that is causing it. |
if this is the case, it would be a big problem, since:
|
Why i am telling this is that i saw on my phone that it was at 48 kHz and it said higher available and then it switched which was on an iPhone. After it went higher it did stay there for the rest of the album so i would guess it wouldn't be that bad. I was on atrocious wifi at that point. So yeah it could switch around. but it didn't after the 1 song did shift around from lossless to high-res lossless in a playlist. |
I've been running v1.1 build 8 for a few weeks now so I thought I'd post an update. It has changed the behaviour of this bug but the issue still remains. It is still sometimes selecting the sample rate of the next song in the playlist due to the log line issue raised originally. It does not always occur on every track and I have not worked out the exact combination of things that lead to these log lines being logged. But it is very consistent, always occurring in the same places in certain playlists. With build 8 now when I skip ahead in the track it seems to reevaluate the sample rate and sets it correctly. However once this occurs, if I let the song play it will eventually set the sample rate back to the next song before the current one finishes. Skipping ahead in the track always causes the correct sample rate to be selected. I haven't dug into the logic that is working out the sample rate when I skip around the track but it seems to be much more reliable compared to the log scanning method. Is it feasible to drop the log scanning method all together? By the way I have most of my playlists downloaded so I do not believe my issue is related to low quality files being streamed initially. I do also experience the switching to 48 kHz when a track first plays issue reported elsewhere while streaming, so I believe there are two seperate issues here that may require different solutions. |
Hi @BenSayers I am confused when you say that you have most of your playlists downloaded, as I thought this service only works with streams from Apple Music, and not the local library!? |
@ashafai you can download any song, album or playlist. See this apple doc for details: |
On some of my playlists LosslessSwitcher chooses the sample rate of the next track rather than the current track. I found the same behaviour on both the current stable version (v1.0.0) as well as the current beta (v1.1 build 5).
Mac OS 12.3.1 (21E258)
Apple Music 1.2.3.56
Looking at the Console for the Apple Music log lines, it appears that both the current track and next track are being logged:
The first line is associated with the current track playing, the second line with the next track in the queue. To deal with this case the approach for determining the sample rate would need to be updated from just taking the most recent log line containing a sample rate to something more sophisticated. I'm not sure if there is enough metadata in the log lines to work out which one is associated with the current playing track?
Interestingly not all my playlists log the next track in this way. I have yet to work out what conditions cause Apple Music to do this.
Thanks for writing this by the way!
The text was updated successfully, but these errors were encountered: