Support for m4a (and maybe editing metadata)

[OneEyedTiamat]

Is your feature request related to a problem? Please describe.

It's not a problem, it's just features that were present in the app I used before and that I'd like to know if it's possible to implement them here.
As per the title, I'd like to know if the m4a format could be supported, and if it's possible to implement a way to edit metadata in the app (not that important, it'd be nice but I think I can do it on PC).

Describe the solution you'd like

I'd like the ability to read m4a format files in Mucke, and possibly to edit metadata (song name, artist, album, etc) within the app.

Describe alternatives you've considered

I could just get supported file formats and edit the metadata on my computer I guess.

Additional context

I don't have any additional context. Of course I completely understand if either or both of my requested features can't happen in Mucke and I'm taking appropriate measures (getting compatible files), I just wanted to know if an already great app could get slightly better.

[ildar]

1st you are supposed to clean all the descriptive text like "A clear and concise description of what the problem is. Ex. I'm always frustrated when" 2nd m4a is supported. You just need to add it to the file extensions list

[OneEyedTiamat]

1st you are supposed to clean all the descriptive text like "A clear and concise description of what the problem is. Ex. I'm always frustrated when" 2nd m4a is supported. You just need to add it to the file extensions list

My bad, I didn't know either of these things. Thank you for the reply.

[Matthieu-LAURENT39]

It would however be pretty nice to have m4a be in the file extension list by default.
Or is there a specific reason it's not there?

[moritz-weber]

If I remember correctly, some users reported issues with m4a files. The thing is that m4a is only the container, and the files might be encoded with AAC or some other codec that Android does not support natively (and thus mucke does not support). The app might be able to find the files and even read the metadata, but playback might not work.

Thus, I would prefer not to include these files by default. I think, if one adds more extensions and then finds that playback doesn't work for these files, the disappointment is probably smaller than if the playback of files with a default extension doesn't work. It has more of a "use at your own risk" character to me.

Does that make sense?

[OneEyedTiamat]

If I remember correctly, some users reported issues with m4a files. The thing is that m4a is only the container, and the files might be encoded with AAC or some other codec that Android does not support natively (and thus mucke does not support). The app might be able to find the files and even read the metadata, but playback might not work.

Thus, I would prefer not to include these files by default. I think, if one adds more extensions and then finds that playback doesn't work for these files, the disappointment is probably smaller than if the playback of files with a default extension doesn't work. It has more of a "use at your own risk" character to me.

Does that make sense?

It does make sense, thank you for explaining.

[ildar]

On Wed, Oct 25, 2023 at 6:27 AM Moritz Weber wrote: <...> the files might be encoded with AAC or some other codec that Android does not support natively

That may well depend on the Android version. Mine supports AAC.

[Matthieu-LAURENT39]

If I remember correctly, some users reported issues with m4a files. The thing is that m4a is only the container, and the files might be encoded with AAC or some other codec that Android does not support natively (and thus mucke does not support). The app might be able to find the files and even read the metadata, but playback might not work.

Thus, I would prefer not to include these files by default. I think, if one adds more extensions and then finds that playback doesn't work for these files, the disappointment is probably smaller than if the playback of files with a default extension doesn't work. It has more of a "use at your own risk" character to me.

Does that make sense?

Makes sense indeed, although it would be nice to at least have some indications of what extensions may or may not work.
I remember converting all my library to mp3 before switching to mucke before i wasn't sure it would support mp4, but looking back, maybe it did support it and you just needed to add the extension to the list.
I guess that would be a different issue, but adding a small description under the file extension list naming extensions that are likely to work, with a warning they may not work, could be nice.

[ildar]

actually an app can find it out from system properties. Like https://f-droid.org/en/packages/com.oF2pks.kalturadeviceinfos/ does