Digital Music Collection Of Many Formats

[Darius1968]

Okay, IMatch ships with the default mp3 data driven category.  Very useful!  My question is since I now have digital audio files in other formats like ogg vorbis and aac, can that mp3 data driven category now become a category for the other audio files as well?  As it is now, the id3 tags would have to be replaced by whatever is relevant to the aac file or whatever.  So, is it possible to substitute a tag that somehow considers the case for artist, genre, song, etc. of all possible audio files? 

[Mario]

This sample category is based on ID3 tags. OGG does not use ID3 metadata, it has it's own set of metadata tags. And AAC again uses it's own set of proprietary tags. If you really need to combine this into one set of categories, you will have to do some mapping/bridging between these tags...there is no common standard, and XMP metadata focuses on digital image files and has no real sections to store information about artists, albums and suchlike. There is a reason that MP3 has become the de-facto standard for digital audio files. I think there were some considerations allowing for XML/XMP metadata in OGG files at some point, but I don't keep up-to-date with such things.

Consider:

1. Setup a Attribute Set which stores Artist/Album Info. Then fill these Attributes from the metadata in your files (via the Import Metadata into Attributes import module). This allows you to unify the proprietary metadata in your files into one common set of information. Then use the Attributes (via Variables) to create your data-driven category.

2. Base your data-driven category on a variable, and use variable functions to access whatever tag contains e.g. the Artist information. This can be done with a contains function which looks at the file extension, and then decides which tag to use.

I don't have any OGG files with embedded metadata in my sample collection. If you can provide one I would be grateful. I would like to see what ExifTool can pull from such a file.

[Erik]

I'm not at my home computer at the moment but aside from photography I have an extensive amount of audio/music files in a few formats. I haven't explored using IMatch 5 for those files much, yet (I use MediaMonkey which is kind of an IMatch equivalent for audio).

But, I wanted to make some notes and suggestions as I have played with some data driven categories for audio files and I can note some things about OGG files.


First... With data-driven categories, I find it best to utilize file extensions to filter your audio files.  I create a category based on the "ext" variable and filter that variable to only show audio file types.  In my own personal collection, that consists mostly of FLAC, MP3, OGG, M4A, and WAV with my collection being 90% FLAC, 9% MP3, 1% OGG, and a negligible amount of the other.

This solves the issue of dealing with the variable metadata between the file types.   It works well in limited testing.


Second... OGG files.  I believe the OGG files have the same metadata format as FLAC files. As I've moved my audio collection to FLAC, I've also begun changing MP3 files that I don't have access to lossless versions of to OGG files to keep the metadata format consistent with my FLAC files.  My external media players and network players don't play too well with the combination of FLAC and MP3 files and the nuanced differences between the actual tags. It's kind of like the difference between IPTC and XMP (kind of).  The ID3 spec is quite fixed and rigid with inconsistencies between different versions, while the FLAC and OGG tags are a bit more flexible and customizable. 

As far as ExifTool goes.  I've not tested it with either FLAC or OGG files.  I see that ExifTool can access the FLAC Vorbis Comments (Vorbis Tags), which is the metadata for FLAC files and should be the same for OGG.  So, I would think you could try to retrieve FLAC tags from OGG files.  Looking closer at the OGG item, it seems that OGG might be able to use ID3 tags, too.  I'm not sure about that myself as I thought OGG developed the Vorbis Tag format first and FLAC adopted it for their file format. 

That's probably enough info anyway.  bottom line is that things could be made to work, but the different metadata could make cataloging off multiple file types difficult. Mario's idea of using attributes might be best, perhaps using a script to read in the metadata depending on the file type.

[Mario]

I would like to see a sample OGG and FLAC file with metadata. I have no OGG or FLAC files with metadata here so I cannot even know what data they contain. Another way would be to use xMP sidecar files, which are supported for all file formats by IMatch. I'm sure there is a namespace somewhere that allows to store audio-related XMP data. ID3 tags are a mess, which is why ExifTool still does not support ID3 for writing.

[jch2103]

I'm sure there is a namespace somewhere that allows to store audio-related XMP data.

Apparently it's the XMP Dynamic Media namespace tag, XMP xmpDM Tags. See in
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html

Also see reference in Adobe Audition Help: https://helpx.adobe.com/audition/using/viewing-editing-xmp-metadata.html

[Erik]

I'll see if I can't find a smaller OGG and FLAC file to forward your way for reference.  I'm not sure the tags are much better than ID3 although, the tags don't seem to have the variances I see between the different ID3 versions.  I think the FLAC ones are more like XML data as they allow a lot more flexibility in terms of size (ID3 will corrupt if the data exceeds some size threshold) as well as customization.  With FLAC I can create custom tags that fit my needs and are compatible with almost all software that can read FLAC files.  It's kind of like being able to create a custom namespace in XMP.  It's not something that is standard, but it works well for the individual.

I'll see what I can find tonight and likely email it to the support email.

[Mario]

I'll see what I can find tonight and likely email it to the support email.

Great, thanks. You can also upload the files to my FTP server if they are too large.

[Erik]

How large is too large?

I have two files, they are about 11 MB each.  GMail lets me attach them, and I hit send, but I suppose there is a chance you won't get the email.

If you end up not seeing anything, let me know.  I'll go by FTP or similar.

-Erik

[Mario]

I have received the files, thanks.
FLAC apparently supports only the key-value VORBIS metadata format, no XMP or other formats. And VORBIS is very different from ID3, so there has to be some bridging/mapping when a user wants to handle these metadata formats in one category hierarchy. Using Attributes or filling XMP metadata via  Metadata Template or a script seems to be the easiest way.

Since IMatch is flexible and makes ID3 and VOBIC available as regular metadata tags and also via the corresponding variables, this should be not too hard.

[Erik]

Right.  I believe OGG supports the same VORBIS tags.  I know it really has little to do with IMatch, but my own finding is that the VORBIS tags are much more reliable than ID3.  That was actually a primary driver in selecting that format over MP3's for my permanent collection.  It's kind of like storing all your files in TIFF as opposed to the various RAW formats.

I do appreciate that IMatch has the ability to handle audio files, but it'll be a long time before I ever consider IMatch as a DAM for my audio. There are too many music specific functions I expect, but it is nice that I can use it to manage potential audio files for annotating images (I've recorded audio notes with images in the past) as well as for developing slide-shows with accompanying audio. In other words, the ability to provide my own XMP, Attribute, Category type information separate from typical audio metadata is quite valuable.

[Mario]

While looking into the FLAC format, I've added support for extracting the PICTURE from FLAC files to IMatch. This means that when you force-rescan your FLAC files with the next release, IMatch will pull a suitable (preferred cover) image from the FLAC file as use it to create the thumbnail and other visuals. I have only three FLAC files with embedded images here, but these work great.

I did not look into extracting images from OGG yet. No feature request for that so far.

I do appreciate that IMatch has the ability to handle audio files, but it'll be a long time before I ever consider IMatch as a DAM for my audio.

I don't think it's the purpose of a DAM to implement all the features available in specialized audio, video, image processing, raw processing or Office applications.

The key purpose of a DAM is to manage your file collection, providing quick access to any resource. The ability to organize your FLAC files by the metadata they contain, to see the metadata, 'use it' in meaningful ways, to find any FLAC file quickly and probably even see a 'visual' is more than enough for a DAM. To edit/play/process FLAC files (or videos, images, RAW files, Office documents etc.) you just open the file from within IMatch in the associated specialized application.

[Photon]

I think, that Imatch should concentrate mainly on photos and not too much on all digital assets like audio, video or office files. One tool for all assets can never be efficient, because the workflow requirements (view, play, edit, versioning, export, drag&drop, ...)  for different digital file types are too different.

As long as IMatch can open only one database at a time, my experience is, that it is better to use multiple DAM-tools in parallel for the different media files. I am using e.g. various DAM tools in parallel on multiple monitors for efficient combination of photos, clip arts, music, sounds, speech, text and videos to presentations and digital AV shows. With just one DAM the switch between search interfaces and folders would be much too time consuming. The usage of different specialized already opened application windows is more efficient. Even with just one monitor the windows task switching (Alt-Tab) is faster than navigating in one DAM interface to search for all required media files.

Just an opinion. Please correct me, if I am wrong.
Martin

[Mario]

I'm explicitly fond of IMatch's capabilities to manage non-image files. I use that more and more. It's also very important in environments where images are just part of a project, and Office documents and other files are equally important.

IMatch will never open more than one database at a time. We had that in IMatch 3 and it over-complicated things for all users, for the benefit of a few users who ever loaded more than one database at a time (just think about scripting, apps etc). No more.