Fallback for when setting a tag natively fails

[FLAGEL]

Unfortunately, not all media formats support tags natively. Due to lack of reliability for inclusion/exclusion, tags have for me lost much of their allure. I personally have resorted to keeping duplicate directories which also use "n" times the storage space.

Would it be possible to implement a fallback for when setting a tag natively fails? One suggestion would be to create a foobar.tags-file in the same directory as foobar.ext. An alternative would be to have Aves create a central database for the aforementioned files, and match tags by way of hash sums. A third alternative would be letting users create virtual albums, much like "Favorites" works currently (which in essence is the same as the previous suggestion but in a different packaging).

Thanks for creating this excellent app and sharing it with us all as FOSS. I hope you do not take offence to the rather small sponsorship sum - I prefer to spread out the funds over many projects instead of only supporting a few.

[deckerst]

Unfortunately, not all media formats support tags natively. Due to lack of reliability for inclusion/exclusion, tags have for me lost much of their allure. I personally have resorted to keeping duplicate directories which also use "n" times the storage space.

What unsupported format do you use?

Would it be possible to implement a fallback for when setting a tag natively fails? One suggestion would be to create a foobar.tags-file in the same directory as foobar.ext.

Using sidecar files is a common solution to add XMP metadata to any file. I personally dislike the solution, because the metadata is no longer tied to the original file. But more importantly on Android, media files are segregated from other files, so that gallery apps can access media items without having access to all files. In practice it means that gallery apps respecting users privacy, like Aves, don't even see non-media files.

An alternative would be to have Aves create a central database for the aforementioned files, and match tags by way of hash sums.

Having an internal database is also a solution I do not want to use, because it locks users in. Recently a reviewer said they appreciated the way Aves uses standard metadata, after having used for years the Samsung Gallery, tagging their collection without realizing the tags where stored only inside Samsung Gallery's database and were not transferable.

A third alternative would be letting users create virtual albums, much like "Favorites" works currently (which in essence is the same as the previous suggestion but in a different packaging).

This could be a thing. The main hassle would be to integrate the concept and UX without drowning users in confusingly similar features. For example "virtual albums" are already a possible name for a pending feature which would handle filter sets as one custom filter/album.

Thanks for creating this excellent app and sharing it with us all as FOSS. I hope you do not take offence to the rather small sponsorship sum - I prefer to spread out the funds over many projects instead of only supporting a few.

Glad you enjoy it. I certainly do not take offence, quite the contrary. I am grateful to all supporters. There's no minimum, and if you feel good donating, that's great!

[FLAGEL]

What unsupported format do you use?

Concrete examples I can share show the following data under "MEDIA":

Example one (files I have received through WhatsApp)
Compatible Brands: MP4 v2, MP4 Base Media v1
Format: MOV, MP4, M4A, 3GP, 3G2, MJ2
Major Brand: MP4 v2

Example two (source unknown)
Encoder: Lavf58.76.100
Format: Matroska, WebM

Using sidecar files is a common solution to add XMP metadata to any file. I personally dislike the solution, because the metadata is no longer tied to the original file. But more importantly on Android, media files are segregated from other files, so that gallery apps can access media items without having access to all files. In practice it means that gallery apps respecting users privacy, like Aves, don't even see non-media files.

Understood and reasonable.

Having an internal database is also a solution I do not want to use, because it locks users in. Recently a reviewer said they appreciated the way Aves uses standard metadata, after having used for years the Samsung Gallery, tagging their collection without realizing the tags where stored only inside Samsung Gallery's database and were not transferable.

The issue with using non-standards is real, but if the choice is between nothing (requiring an tedious manual process) or a solution that is not optimal, I personally would have the latter.

This could be a thing. The main hassle would be to integrate the concept and UX without drowning users in confusingly similar features. For example "virtual albums" are already a possible name for a pending feature which would handle filter sets as one custom filter/album.

I very much like the idea of being able to create "virtual albums". I too found the concept/layout a bit confusing, and I did not want to entangle a structure change into this GitHub issue, but while we are here, have you considered renaming today's:
1. "Album" as "Folder" (or Directory, or whatever is the AOSP nomenclature) corresponding to a real object on the filesystem.
2. "Virtual Albums" as "Albums", much like Google Photos a media item can be in several albums at once, regardless of which "Folder" it is stored in on the filesystem (as "Favorites" work today).
2.1. Make an "Album" be a filter that includes/excludes based on "Folder" name/regex, "Tag" name/regex, "File" name/regex, file time range, etc.
2.2. Make "Favorites" an out-of-the-box "Album". It would make sense if "Favorites" was just a native tag in the media item, so it retains its status as a "Favorite" when exporting and its status as a "Favorite" can be used to include/exclude items from another "Album". In fact, maybe it would make sense if every "Album" was a collection of tagged media items applied by an "Album" filter (2.1 above).
4. "Collection" as "Workdesk" (or "Workspace"). With "Albums" being filters the "Workdesk" could be argued to no longer serve a need, but it could be a space to test/apply/change filters before saving the final filter into an "Album" and tagging the associated media items.

I think the above concept would be more inline with how other software works, keep it simple for the people who do not want to get into the details, yet be powerful for those with complex sorting processes. It also seems like you already have much of the code in place to enable the above workflow.

Edit: Striked part moved into #1274 (comment)

[FLAGEL]

Maybe a work-around would be to introduce an Untaggable option under Metadata (along Undated, Unlocated, Unrated, etc) in the Search view. At least that would make it possible to easily find items that should be tagged but are not. Right now if you tag a large selection of items, of which a few cannot be tagged, information is limed to "N files failed", without further details.

[deckerst]

Sometimes, whether a file can be tagged is not known in advance. For example MP4 are generally supported, but some MP4 have a special inner structure which is not supported yet.