Google Play Music using new audio codec on new versions. #23
Comments
|
Perhaps related to a recent Change in Play Music 7.5. which provides download size options. https://9to5google.com/2017/03/15/google-play-music-7-5-update-quality/ |
|
We should save that as an m4a file then, right? |
|
I would agree that recommending that "Settings - Download quality" to "High", would be a good idea. |
|
It would be nice to quantify what Google Music uses for Low, Medium and
High, especially now AAC is being used... As even 192k AAC is better than
320k MP3
…On Mon, 27 Mar 2017 at 08:57 LegoChicken ***@***.***> wrote:
I would agree that recommending that "Settings - Download quality" to
"High", would be a good idea.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACuadbz4YRjn4dX44bLUA16tOk5eFkVvks5rp2v4gaJpZM4MpDF8>
.
|
|
I've got Play Music 7.5.4541-1.0.3840537 and just tried a download a on "High". It is MP3. So maybe it isn't all tracks or all devices (I'm on a Nexus 5 stock ROM). |
|
Yes, this really does need some built in detection.. Maybe there is a nice little java library for ffprobe? |
|
I have some free time to look into this, if nobody else has started on it yet. |
|
No, I am currently working on #15, go ahead and help with this, if you have the time ^^ I suspect this might be some more work though, since that probably needs some rewrite of the tag writing and another library for that.. |
|
Initially I will do some investigations, work out if it's all access files,
or all files (are Google encoding MP3 uploads???), if it affects newer
titles, if it affects High, Medium, Low settings, find some all access
tracks that demonstrate this, try and flesh out the problem description
with some real world examples.
…On 28 March 2017 at 11:31, Jan Christian Grünhage ***@***.***> wrote:
No, I am currently working on #15
<#15>, go ahead
and help with this, if you have the time ^^
I suspect this might be some more work though, since that probably needs
some rewrite of the tag writing and another library for that..
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACuadfPp1QuJjHIjbY7iF1vEmNCF30Egks5rqOF2gaJpZM4MpDF8>
.
|
|
I tried doing that, but I only got MP3s on high/medium on new and old titles until now :D |
|
@Shiragasane Do you have specifics of what the track was? From the screenshot, it was Born In The USA, was this one of your uploads? Was it Google Music All Access, and if so what album? Can you link to the web version of the file, and see if we can reproduce this by adding this same track to our libraries? |
|
Someone in the IRC room reported that "Amapola" by "the Spotnicks" showed this behaviour. |
|
I just tried that one again though, still 320 kbit/s mp3 encoded.. |
|
I tried Jean-Micheal Jarre Equinoxe on Nexus 5 and also got 320 kbit/s mp3. Is it user or device specific? |
|
This could be a usw case for the analytics features that we will habe with countly (#15). |
|
@mgillespie What do you think about just implementing analytics stuff for analyzing this problem in v0.9.6, so that we have more info on when the app downloads aac versions and when it downloads mp3 versions. That way we should be able to push v0.9.6 to F-Droid sometime in the next few days and collect that data automatically to help us understand when it happens. The only problem with that is, that I don't know how to determine what file type it is on android, since ffmpeg for android does not include ffprobe. |
|
Thanks to @Shiragasane I now know how to do this, and I also realise that it is very easy for us to determine if the tags were written successfully: The PME logs that, since MP3Agic throws an Exception, when it gets passed a non MP3 file. I've just added that to countly, so that we know what device and android version is used, when this happens. |
|
I've just seen that v0.9.6.0 has been released. F-Droid only has 0.9.5.2. Could you update it. Thanks. |
|
Well, F-Droid builds the APK themselves, and that might take some days (or longer, if they need to update their library versions first again.) Edit: They need to update the server again, I've just sent them a PR for the server to use the new library versions, but it could take some time again. Last time it took a while until they redeployed the server too. Another edit: As expected, the build currently fails. A third edit: They've merged my PR, so as soon as their server is redeployed, the application should build fine. |
|
Oh, I didn't know how it worked. Could you publish a binary then in github or XDA. Unfortunately I'm not setup to build (or have the time). Thanks |
|
Everyone's time is precious. Your options are really to wait for FDroid,
or build it yourself.
…On 29 March 2017 at 11:15, LegoChicken ***@***.***> wrote:
Oh, I didn't know how it worked. Could you publish a binary then in github
or XDA. Unfortunately I'm not setup to build (or have the time). Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACuadUjMNIwUBsuLiUt7L0-IE2ySrhARks5rqi9OgaJpZM4MpDF8>
.
|
|
@LegoChicken v0.9.6 doesn't contain new features for users anyway, so you don't loose anything by waiting. It just contains some crash reporting (Which we should make an encouraged opt-in as soon as possible, instead of that being active by default with no way to change that). About uploading binaries elsewhere, I just use the binaries built by F-Droid for that too. That has the advantage that I don't have to maintain signing keys for building releases. |
|
v0.9.6.0 has now been built by F-Droid, and so far there have been no reports of tagging issues among the ~500 songs that have been exportet so far. |
As visible in the screenshot, Google Play Music seems to be using AAC instead of MP3 on newer versions of the app. This breaks tagging and the ability to play the files on some/most(?) audio players. The screenshot shows the result of ffprobe used to analyze an older version of the song from Google Play Music compared to a new one.
The text was updated successfully, but these errors were encountered: