m4a tags messed up?

[Radoom]

Checklist

• I am able to reproduce the bug with the latest debug version (Android, Linux, Windows)
• I've checked that there is no open or closed issue about this bug.
• This issue contains only one bug.
• The title of this issue accurately describes the bug.

Steps to reproduce

Download any song with 0.4.2
This now gives m4a files (in 0.4.1 it gave mp4).
The Album Tag for all files now reads "spmp" , Artist etc are nothing.
This totaly breaks using files outside spmp.

Expected behavior

In a test version of 0.4.1-"debug", files were perfectly usable outside spmp after you had moved the reference info you need for spmp from the album artist field to the comment field. Can you please go back to to saving mp3 files with the same Tag handling as in that debug version?

Actual behavior

See above. Save mp3 with proper tags.

Screenshots / recordings

No response

Logs

Don't have any

SpMp version

0.4.2

SpMp platform

Android

OS version

GrapheneOS

Additional information

No response

[toasterofbread]

As stated in the release notes, v0.4.2 is just a single-patch release based on v0.4.1, so v0.4.2 doesn't include new changes such as changes to local song metadata. The next non-hotfix release will include these changes.

[Radoom]

Thanks for responding.
Sure nothing else changed from 0.4.1 regular build to 0.4.2?
I remember that artist and song and album tags metadata was okay for 0.4.1 downloaded files, only the reference string in the "album artist" field was broken.
Then you made that 0.4.1-debug version putting the ref string in the comment field which fixes the issue of all songs of one album showing as single-song-albums. Good.
However, in 0.4.2 downloaded songs, the only Tag value I see is "album" =="spmp" ... but artist/song/album are no longer there. Strange if no changes to that code was made....anyhow, let's wait for 0.4.3 then and see.

[toasterofbread]

Are you sure the behaviour you're observing is caused by switching to v0.4.2? The only differences between v0.4.1 and v0.4.2 are those listed here, none of which have to do with storing files locally, only the method used to load song streams. I tested it just to be sure, and v0.4.2 still produces .mp4 files for me.

To be clear, v0.4.2 is exactly the same as v0.4.1, just with that single specific fix applied to it. If you were using a post-v0.4.1 debug build before, there's basically no reason for you to use v0.4.2 (you would effectively be downgrading).

[Radoom]

Well...Strange.
For me, as of yesterday and today, also after complete uninstall of all versions, it is like this:

• V0.4.1 gives malformed url errors, can't download anything, but spmp creates the files with Zero bytes size and as m4a containers.
• V0.4.1-debug same as above.
• V0.4.2 dowloads successfully and creates m4a containers, too.

The above applies to my grapheneOS = Android15 phone.

Checked this now on two other phones.
On a lineageOS=Android10 phone, same as above. Getting m4a files out of 0.4.2, others fail to d/l anything.

On a Samsung-Rom=Android12 phone, also only 0.4.2 is usable, BUT it saves .mp4 files, not m4a.

The ROM (!!??) defines what files are written to storage!?

The above may explain why I had usable tags on mp4 files in the past maybe, when I also used spmp on that Samsung /A12 Phone. Now noticed the missing tag content on my new GrapheneOS/A15 phone.

Ideally, spmp should define what it saves to disc: .mp3 with proper tags; or if data obtained from Google streams would be lossless, then maybe flac or any other true-music(not-video)-format with proper tags included. But it should not be ROM dependent at all, no matter the format, right?

[toasterofbread]

File creation is handled by the OS, SpMp only provides a base name and mime type (audio/mp4). Whether the file is created with the generic mp4 extension or the audio-specific m4a extension is up to the OS, but the content (including tags) should be the same on all systems. Mp4 and m4a are both the same container type anyway, aren't they?

If you're not logged in then v0.4.1 will fail to stream/download any song, that was the issue addressed by v0.4.2.

When you say v0.4.1-debug, which specific commit/build are you referring to? Ideally you should be using the latest nightly build from the releases page (this is just the latest build on the main branch).

[Radoom]

Debug build: the one from here: #367 (comment)

I have now also tested with the Nightly 2024-10-27 22:53:22

Getting m4a files without tags. Checked with a tag editor, compared for files downloaded with 0.4.1/0.4.1.debug (as per above). Those older ones obtained as mp4 have tags. Any new m4a I get don't have any.

Mime= "music/mp4": could you change this to be "music/mp3" maybe?
Why?
I've tested with some 10-ish different music player apps now. Nearly all of them do not consider mp4 or m4a files when scanning for music. One did but was crap otherwise. What helped so far was renaming the mp4 / m4a to mp3. For the mp4 files from my earlier tries on that Samsung/A12 Phone/ROM this worked okay as the tags seem proper.
Also looking at the file info with e.g. VLC, it seems as if the obtained files are a mix of codecs really. Some files show "MPEG Audio Layer 1/2", while others show as "MPEG AAC Audio" . There might be more, only looked at a handful. Never mind that, as long as the files are called .mp3 the various audio player apps I tested could handle them.

[toasterofbread]

Getting m4a files without tags

How does the nightly build behave on your Samsung device? It would be helpful if you could make a quick list/table of how v0.4.2 and the latest nightly behave on the Samsung and non-Samsung device, the info in this thread is a little scattered.

Mime= "music/mp4": could you change this to be "music/mp3" maybe?

I'm not going to inaccurately name downloaded files so they can be used in other players. Maybe you could take this suggestion to them? An option to set a custom mime type if something I would consider though (I did see your other issue).

Overall I suspect this commit might be causing this issue. Could you also test that commit as well as the one before it on both devices?

[Radoom]

I'm totally lost now.
Table: would do in principle, but...

I've now tested the nightly on the Samsung/A12. To do that, I had to uninstall the regular 042 version.
Nightly then downloads one song(*) and stores m4a (yes, now also m4a on that Samsung which used to give mp4).

Then uninstalled the nightly again, installed the regular 042 again...downloads 4 songs (*) and stores: m4a now, too!!! Yes, that very version 042 on that very phone gave mp4 yesterday...and now gives m4a. Ffs.

And of course m4a has no tag data set.

For the commits, sorry I don't understand how to obtain versions before those commits or such after. Not familiar with this whole commit stuff. Are there specific nightly versions you want me to try? Then please help me to find them, don't know where they are.

Oh, and I don't have a Google/YT account, so if they require YT login I can't help with that.

*: Sidenote: the nightly on both devices, A10 +A15, only ever downloads one song. No matter whether I try to d/l one, wait for it to finish, select another one, or whether I multi-select several. First works, all others get 0 Byte files created but download stall forever until forcing the app to close, re-open, and then it download another one only. 042 regular build downloads multiple no matter whether single-select or multi-select.