Macos – OSX: assign extension to content kind

file associationfindermacos

Here I have a folder containing a bunch of *.mkv files (video, obviously) and *.srt files (subtitles, obviously). I want to keep them within one folder but I don’t want them to be mixed together. It looks like a good idea to visually arrange them into two separate groups.

However, neither extensions are recognised by the system, and they are still put under one group ‘Documents’, which is clearly not what I want.

The question: how to tell the system that all *.mkv file should be treated as ‘Media’ (or ‘Videos’, or whatever the name of the file kind group for video files)?

Thanks.enter image description here

EDIT:

@Daniel, the associated program is MPlayerX and the output of that command is as follows:

imac:Game of Thrones arnold$ mdls "Game of Thrones 1×2.mkv"
kMDItemContentCreationDate     = 2011-12-15 10:31:20 +0000
kMDItemContentModificationDate = 2011-12-27 09:09:55 +0000
kMDItemContentType             = "dyn.ah62d4rv4ge804450"
kMDItemContentTypeTree         = (
    "public.data",
    "public.item"
)
kMDItemDateAdded               = 2011-12-27 09:22:55 +0000
kMDItemDisplayName             = "Game Of Thrones 1×2.mkv"
kMDItemFSContentChangeDate     = 2011-12-27 09:09:55 +0000
kMDItemFSCreationDate          = 2011-12-15 10:31:20 +0000
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = 0
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = 0
kMDItemFSLabel                 = 0
kMDItemFSName                  = "Game of Thrones 1×2.mkv"
kMDItemFSNodeCount             = 220877659
kMDItemFSOwnerGroupID          = 99
kMDItemFSOwnerUserID           = 99
kMDItemFSSize                  = 220877659
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Video Media"
kMDItemLogicalSize             = 220877659
kMDItemPhysicalSize            = 220880896
imac:Game of Thrones arnold$

Weirdly enough, the ‘Item Kind’ does show up as ‘Video Media’. And for a subtitle file is is ‘Subtitle’. Still, it doesn’t help Finder arrange those files correctly for some reason…

Best Answer

You need to use an application that declares the correct file type association for e.g. the .mkv file name extension.

For example, the system-defined file types in /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist declare the following in the Exported Type UTIs section:

enter image description here enter image description here

This allows the system to associate the UTI public.jpeg with the "UTI group" public.image, which is (very likely) what Finder uses for the Images group; the public.filename-extensions equivalent type maps to the file extension.

This allows OS X to determine, that .jpg file has the UTI public.jpeg, and that is a sub-UTI of public.image (and so on, with public.item and public.data). Finder then takes all the files that are (also) public.image and puts them in the same Images group.

The same applies to public.mpeg-4 and public.movie and the filename mapping there.

Unfortunately, the author of MPlayerX didn't bother mapping the UTIs.

He didn't even bother creating proper file types for all the extensions the program supports. That's why in Finder's list view, all .mkv files aren't called e.g. Matroska Video, and have a matching MKV label on their icon, but simply Video Media with a generic Video label. All supported file types are listed by file extension for this "file format", so MPlayerX can open them:

enter image description here

That means, for example, if you prefer playing .m4a files in MPlayerX to iTunes, you lose the descriptive Apple MPEG-4 audio in the Finder's Kind column and get Audio Media instead.

You can fix the grouping by editing the /Applications/MPlayerX.app/Contents/Info.plist file and properly declaring e.g. a mplayerx.video UTI that conforms to public.movie and adding the proper filename extension mapping.

You can fix the Kind column by editing the same file, and properly declaring file types with a better description, and creating an icon file for each.

Just use the Core Types Info.plist file as template, replacing e.g. public.jpeg with your own custom identifier (e.g. mplayerx.video if you don't want proper Kind columns and icons, or mplayerx.mkv if you want them). You need Xcode to edit these files, or convert them to XML editable in any text editor by using plutil -convert xml1 <filename>.

Your changes, which are rather easy to get wrong, will be overridden with every application update.

Alternatively, at least for the Finder Arrange By Kind, you can edit the core types definitions and add your own to it. Make sure to edit a copy of the file and replace it after editing to circumvent permissions issues. Be aware that you'll be editing and replacing core system files (i.e. asking for trouble) by doing this.

A saner solution would be to create a new "dummy" application that simply declares the file type UTIs as Exported Type UTIs. This will be used by OS X's file type database and you can update both OS X and MPlayerX without losing the content type associations. Even if you change e.g. .m4a to MPlayerX, only the Kind column is changed, it's still in the Movie category, due to the declarations in another application independent of the associated application.

So, create a new application e.g. using Automator that doesn't actually do anything when launched, and add the following to its Contents/Info.plist file:

enter image description here

Save in /Applications or so, and restart Finder.

enter image description here

Partial mdls output of the .mkv file, content type provided by the "helper app", item kind provided by the associated player (MPlayerX):

kMDItemContentType             = "superuser.371939.mkv"
kMDItemContentTypeTree         = (
    "superuser.371939.mkv",
    "public.movie",
    "public.audiovisual-content",
    "public.data",
    "public.item",
    "public.content"
)
...
kMDItemKind                    = "Video Media"

Since this is just sloppy platform integration by the developer, you should probably file a bug.

Related Question