[x] [2694] can't read cover arts from M4A files

[PAMattey]

I have many m4a files containing FLAC audio, and AIMP does't seem to be able to read the cover art.
Please advise.

[Artem]

Please, share one of these files

[PAMattey]

sure, here it is...
I had to split it due to the upload size limits.
The cover is shown in other players like foobar and others. Everything shows up in mp3Tag as well.
I just noticed that AIMP doesn't recognize the lyrics neither (in this case, it is unsynced lyrics). I checked in file info through AIMP and they're nowhere to be found.
I forgot to mention I'm using the windows version, AIMP v5.40.2694, 64 bit.

[Artem]

Thanks! Fixed.

[PAMattey]

Awesome!
Thank you very much 

[sveakul]

I have many m4a files containing FLAC audio, and AIMP does't seem to be able to read the cover art.
Please advise.

If it has a .M4A extension, it's supposed to be AAC audio, which uses MP4 tags, not FLAC, which uses Vorbis tags  No wonder AIMP is confused.

This is a file problem--wrong extension or container for the actual codec--not an AIMP problem.

Artem, I hope the "fix" you made to the player so it displays tags from these misformed files wasn't at the expense of compromising standards adherence.

[CkopoxoD]

If it has a .M4A extension, it's supposed to be AAC audio

And what about ALAC?
In general, m4a stands for MP4 Audio. The mp4 container in such a file can contain an audio stream in any registered format.
Are you sure those files were misformed? Encapsulation of FLAC in ISO Base Media File Format.

[sveakul]

And what about ALAC?
In general, m4a stands for MP4 Audio. The mp4 container in such a file can contain an audio stream in any registered format.
Are you sure those files were misformed? Encapsulation of FLAC in ISO Base Media File Format.

By "misformed" I should have said mis-tagged. Most music players assume an audio file is going to conform to the documented standards for that tag type, like Vorbis for FLAC instead of MP4, and look for the metadata content accordingly..  MusicBee had a heck of a time a while back with supposed "MP3" extension files that had AAC content, and visa-versa, from some shady download site.  It would be interesting to know what had to be fixed for AIMP to display the art and lyrics of the problem files.

[PAMattey]

If it has a .M4A extension, it's supposed to be AAC audio, which uses MP4 tags, not FLAC, which uses Vorbis tags  No wonder AIMP is confused.

This is a file problem--wrong extension or container for the actual codec--not an AIMP problem.

Artem, I hope the "fix" you made to the player so it displays tags from these misformed files wasn't at the expense of compromising standards adherence.

Absolutely false. If that was the case, none or few of all the other players i've used would've recognized the tags.
Even Windows Media Player recognizes the info, like c'mon     but i obviously prefer AIMP over any others on PC.
So it's not "mis-tagged", everything is in order and I'm sure Artem noticed that, otherwise there wouldn't be a fix.
Also, as a container, M4A can have many types of audio formats.

There really is no need to discuss anything else here on this topic unless there's a problem with the fix once it's released.
I'm happy for Artem's support   

[sveakul]

Also, as a container, M4A can have many types of audio formats.

There really is no need to discuss anything else here on this topic unless there's a problem with the fix once it's released.
I'm happy for Artem's support   

I'm happy too and glad he fixed your problem, but defining what may continue to be discussed here or anywhere else is Artem's or a moderator's decision.

My final comment is that surely FLAC codec audio is "best" contained in the container format designed specifically for it, with its metadata tags conforming to the type defined for them, Vorbis comment, as defined in section 8.6 of the RFC 9639 doc (https://datatracker.ietf.org/doc/rfc9639/).  You can plug content into various containers and have it played, but by conforming to one standard all players know how/what they are dealing with and avoid confusion.  Here is an incident that points this out: https://hydrogenaudio.org/index.php/topic,125673.0.html

The RFC 9639 doc in the #10 Container Mapping section, points out some facts with potential for problems when non-FLAC containers are used:

   "The FLAC format can be used without any container, as it already
   provides for the most basic features normally associated with a
   container.  However, the functionality this basic container provides
   is rather limited, and for more advanced features (such as combining
   FLAC audio with video), it needs to be encapsulated by a more capable
   container.  This presents a problem: because of these container
   features, the FLAC format mixes data that belongs to the encoded data
   (like block size and sample rate) with data that belongs to the
   container (like checksum and timecode).  The choice was made to
   encapsulate FLAC frames as they are, which means some data will be
   duplicated and potentially deviating between the FLAC frames and the
   encapsulating container."

[PAMattey]

... defining what may continue to be discussed here or anywhere else is Artem's or a moderator's decision.

i just don't see how your intial comment contributed to the issue at hand    🤷‍♂️  i thought Artem's reply about the fix was enough to close this topic, but since the discussion exists now, then i guess i'll comment once more.

My final comment is that surely FLAC codec audio is "best" contained in the container format designed specifically for it, with its metadata tags conforming to the type defined for them, Vorbis comment, as defined in section 8.6 of the RFC 9639 doc (https://datatracker.ietf.org/doc/rfc9639/).  You can plug content into various containers and have it played, but by conforming to one standard all players know how/what they are dealing with and avoid confusion.  Here is an incident that points this out: https://hydrogenaudio.org/index.php/topic,125673.0.html
The RFC 9639 doc in the #10 Container Mapping section, points out some facts with potential for problems when non-FLAC containers are used:
_{...etc etc...}

Just because FLAC or any other format can work on its own, doesn't mean that a software dedicated to audio shoudn't be able to read a container properly, like all M4A variations in this case as well as other audio containers. It's normal to expect a good music app like this one to read all audio formats, or at least the most common ones with their variations. It is desirable, doable, and while it represents challenges to developers, it provides a better user experience.
In other words, these things don't always have to conform into one single set of standards. Choosing what languange to use when coding an app is already somewhat of a standard, but what you do with it depends on your abilities more than the code itself, even with its apparent restrictions.
I understand standardization has its purpose and value, but it can also affect creativity negatively and thus hindering the development of problem solving skills. That's the difference between "avoiding confusion" and "understanding it to resolve it".

And again: if other players (including mainstream and basic ones) are able to read the tags of my files, it means that the issue is not within the files, but the app.

Looking forward to the next update 

[Artem]

So, issue has been fixed. You can try the solution in an actual nightly build