Forums » Troubleshooting

Request for more mime types

(5 posts)
  • Started 2 months ago by bjesiek
  • Latest reply from KrisKelly
  • This topic is not a support question
  1. 2 months ago # | |

    Hi all,

    As we continue to work on upgrading our April 16 Archive to Omeka, we've identified what seems to be a problem with the mime_types in the file_lookup table. In our current database/archive, we have files representing the following mime_types, but these don't yet exist in the new file_lookup table:

    application/msword
    audio/mpeg
    text/pdf
    application/octet-stream
    application/vnd.ms-powerpoint
    application/pdf
    audio/x-ms-wma

    We could obviously add these ourselves, but it seems this would be a common need for Omeka users. In the interest of standardization, can the file_lookup table be expanded to include additional mime types, including these?

    (Incidentally, I'm not sure why we have text/pdf and application/pdf - it seems we could easily standardize on one or the other.)

    Thanks again for your continued efforts!

    Brent

  2. 2 months ago # | |

    Hi Brent,
    Thanks for pointing this out. We will look into this soon and get back to you.
    Sheila

  3. 2 months ago # | |

    Brent,

    The long and short of it is, it would be great to add these mime_types, but it probably won't happen anytime soon.

    The mime_types that are included in the file_lookup table are ones that we know how to automatically cull information from. The ones we have included are ones that can pull in various sorts of metadata. So while we could add them to the table, it ultimately wouldn't serve much purpose until we learn how to pull in information for the types you list.

  4. 2 months ago # | |

    Could you help clarify what happens when an object/item is uploaded that does not match one of the existing mime_types? It seems our solution would be to either: a) replicate this outcome for the existing items in our database, or b) maintain our own customized list of mime_types. But, if we did the latter (b), are there system implications related to not knowing how to automatically handle them?

  5. 2 months ago # | |

    Hi, the MIME types that are currently stored in the file_meta_lookup table are primarily there for convenience sake. What happens is that we use a 3rd party library (getID3) to automatically extract extra metadata from these files and into the database (currently files_video, files_images tables). That extra metadata can be useful to have for display purposes, but it is always stored in the file regardless of whether or not it has been extracted into the database.

    An example would be the width or bit depth of an image, which is useful to have available but is also coded into the file itself. If a certain image mime type was not in that file_meta_lookup table, then it just wouldn't extract any image-specific metadata for that type of file.

    I see audio, pdf and MSWord MIME types on your list. Currently, Omeka doesn't know how to extract metadata from those kinds of files, so it won't make a difference if you put them in the file_meta_lookup table.

    In conclusion, having more mime types in that table won't change the way Omeka works. getID3 is pretty versatile in terms of extracting metadata from files, so if you want to tinker with how it might work on audio files, feel free and let me know how it goes. I hope that helps. If this continues to be confusing, please let me know.

RSS feed for this topic

Reply

You must log in to post.