Video and Audio Clips

[tmcgill]

IMatch is tremendous for photo management. In fact, it is getting really close to being useful as a much broader kind of digital asset manager. I look for these kinds of things, that let me organize things properly, and rarely find them (JRiver Media Center for my home music listening library, IMatch for images, and that's about all that is out there which is as powerful and flexible as these).

One thing that makes IMatch right on the verge of being useful in a much wider context is its ability to classify and categorize, and to a limited extent display, arbitrary files, not just images. I haven't quite launched into using it as a means of managing files that are associated with various personal and work projects, but it could be highly useful for that purpose.

The most obvious forms of project assets outside of photos that it could work with in a useful way are video and audio files. But there is one really big missing piece of the puzzle when it comes to audio and video, that I wonder if it is possible to accomplish now somehow, or which might be worth a feature addition: a means of managing parts of these files-- that is, clips.

Think of how a long, continuous video recording might contain numerous definable sections (scenes, moments, retakes, or the beginnings and ends of useful footage for assorted purposes). Categorizing and managing a video file as a single thing is therefore of limited use compared to what you could do if you could independently mark, classify, categorize, annotate, and search for all of the individual clips in a single file. You might have 20 minutes of video, and within that there might be dozens of useful portions that you want to mark and file to be able to locate easily later. Some of them might even overlap, or you might for some purposes want to use short clips, and for other purposes use a longer, continuous piece of video, so you don't always want to actually cut the video file up into pieces. What you want is to be able to virtually do so. This could be accomplished by having little link files that have enough info to point to a segment of the overall video, or by having those clips exist as entities only in the database, but either way, your file list then contains not just whole video recordings, but all of the clips that you've defined, which you can categorize, sort, search, or perform any other operations on, each one having a relationship to the master video file it came from in a similar way as versions work in IMatch already.

The other software I mentioned above, JRiver Media Center, does have some concept of this, which it calls "particles". These are virtual copies of an existing file but with a range (start and end times) specified. JRiver's software, however, is highly optimized for managing and organizing a library intended mainly for media playback and consumption. IMatch is a better application for categorizing things in a general-purpose way, like one might want to do for organizing and archiving all of the home video footage that with modern phones and cameras everywhere accumulates very quickly into otherwise unmanageable piles of hours and hours of who-knows-what, or for sorting out all of the video or audio (and other associated files) being used for production and management of some particular project. Just for home video alone, I'd make a ton of use of this, and then music and video projects on top of that.

(Now honestly, once we're on the topic of expanding to new usage domains, I really wish there were a way to use IMatch to manage my email-- and even better, manage emails right alongside all the files of any type that are associated with the same tasks or projects as those emails. No email client in existence comes close to IMatch in terms of multiple hierarchical categorization of items, easy search, dynamic categories, and so on. Alas, nobody who writes email software thinks very far beyond folders, flat tags, and full-text search. But that kind of thing would obviously be much, much more of a leap outside of IMatch's primary purposes.)

[Photon]

For photo, video, clipart, graphic, sound and music documents I am using different DAM (Digital Asset Management) tools. This because especially for multimedia AV productions I need multiple DAM interfaces opened to be fast and efficient. The base for this is fast search and fast drag&drop of all files from source DAM tools to the target application. I cannot imagine, that one DAM tools will ever be able to support a highly flexible and efficient workflow for all types of files. For me the support of more than photos in Imatch is nice-to-have and perhaps a marketing requirement, but has no real chance to satisfy professional needs. And finally too much support for audio, video, office and other files could make Mario and Imatch quite busy and slow.

[sinus]

Well, it depends, of what we call "professional".

What is that? And what not?

I like it very much, that IMatch offers a broad support for different files. I can find almost anything.
I found the posting of tmcgill very interesting.

I would also be interested, that IMatch would support videos a bit better, but I must say, FOR ME I like it really, that I can find with IMatch my videos. And my office-files.

I do not like using different softwares, though sometimes we cannot avoid it.
In the old ATARI-times I used an "integrated" software called STEVE, what did a lot better in sight of a database and text-editor than specialized software.

So I am glad that IMatch offers so much support for different stuff.

[Mario]

Email: You are the first person ever requesting this.
There would be probably ways to do this, by wringing some sort of "connectors" for each of the major email clients out there, plus connectes for all the web clients. Such connectors could use the, naturally different and varying APIs, to download emals, analyze them and then preset them in IMatch. But who needs that? Doing such a thing could require months of work, and if only 50 users would ever use this, it would be a great waste of time.

Video

videos are a patent minefield. Accessing video files on the level required for your feature idea would require

a)   Me purchasing video libraries to do this (maybe QuickTime can do it, but Apple is changing the license conditions so often that I've lost tack if and what of it I could use in IMatch, and how much it would cost.

b) Me paying license fees to the MPEG and other groups which manage the many patents used in video storage, processing and display. The big vendors paid their law companies a lot of money to patent even the tiniest features of video files to keep control over everything.

http://www.mpegla.com/main/default.aspx

Actually I would first need to hire a lawyer who knows about this stuff and can help me fill out the forms and license agreements. And then I will have to pay a couple of thousand € per year (at least).

There are exceptions from these license fees for certain organizations which release freeware (e.g. VLC or Kodi) but not for 'commercial' software like IMatch.

If you are a company which makes money processing video files, it may not be such a big issue. You just charge your users for the license feeds as part of the annual payment. But for a small one-person shop like me even the cost for the lawyer who tells me how much it will cost me is too high.

IMatch already processes all standard video formats, and is even able to render previews if the format is supported by Windows and you have a proper video codec installed. IMatch can also extract metadata for all standard formats supported by ExifTool (which is a lot) and and all the standard features of IMatch also work for video files.

If you want to manage individual scenes or video particles or you want to manage individual pages e.g., in Office documents, that's not possible. And at least from what I can tell from the FR board and emails, there is not much demand for this.

I manage my 10,000 files MP3 collection with IMatch though. And all my Office and PDF files.

I suggest you copy your idea into a feature request and post it in the feature request board. Link back to this thread as well. Other users can then see your idea, like it and comment on it.

Better support for this and that file format is always on my list, and since video is becoming more important these days, I may look into this again after the 5.5. is out. I had hoped that Microsoft would do the right thing and add better video support into Windows 10, available for all applications (like on Apple iOS) but so far I have not seen such a thing. But I'll keep looking.

[tmcgill]

Well, of course I'm not serious about you adding email support; that would be way outside the realm of anything you could hope to do (barring some decision to expand your company and invest massive resources in expanding into a completely new market) without taking way too much attention off of the things that currently make people love your product. (Although if you had a completely wide-open plug-in API, you might find people attempting weird use cases like this.) That concept is really more of a dream I've always had to find an client that can manage email as well as IMatch can manage images. There's never yet been anything close.

But video...I'm not sure it is as complex a notion as your first gut reaction would have it. IMatch doesn't need to know much more about video itself than it already does, and doesn't need to do any processing of it beyond what it already can do. What I'm imagining is the development of some kind of sidecar or bookmark file format that references a certain section or time range within a video file, and which can hold metadata about that specific scene; and then a means of playing only that range within the source file when it is launched through the auxiliary file reference. IMatch then just catalogs those little data files and treats them as a form of video file, and specifically as a version (or something like a version) of the original source file.

This is not a tiny project, but I don't think we're talking about actually getting into the video manipulation business, which I agree would be a tremendous drain on resources for a project that isn't really focused on video.

[Mario]

and invest massive resources in expanding into a completely new market)

This won't be a market. E-Mail is becoming a cloud thing, with many people and companies moving to cloud-based services ore G-Mail. Text searching and deep analysis is part of these products anyway. Google is now even starting to implement services which automatically answer emails based on KI technology...

(Although if you had a completely wide-open plug-in API, you might find

The scripting API in IMatch is as open as possible. You have full access to the entire database and IMatch object model, read and write.

The unique HTML and JavaScript App API also gives you access to the entire database and IMatch object model. You can consume web services, which means you can access your mail server directly from an IMatch app and then do whatever you want.

Both interfaces to IMatch are fully documented and easy to use.

[tmcgill]

Well, there are two places I disagree. First, whatever Gmail has done, it has not, and neither has anybody else, actually designed a web email client that fully organizes and catalogs messages to the degree that your software does with images. Full-text search and slapping a few labels on, with a sloppy and ugly interface having severely limited customizability, doesn't cut it when you're talking about enormous libraries of data. And...these are UI and data interface matters, and cloud vs. desktop doesn't really make much difference there interfacing with your data; that part is irrelevant.

Second, current trends aren't always and forever trends. The trend toward the cloud comes largely out of problems that are likely to go away over time-- local storage being expensive, and synchronizing all your own devices being hard. And the cloud has one really big problem that won't be solved: your data being your own. The cloud presents, for many types of data, privacy issues, control issues, and dependency-on-some-cloud-host-company-not-going-bankrupt issues.

Arguing Gmail makes local email clients irrelevant is like saying Flickr makes IMatch irrelevant. There are needs that are better solved one way than the other, and the oscillation back and forth between "everything on a local machine" and "everything on the mainframe/server/cloud" has been going on for decades, mainly because trying to apply either solution as a universal one will always be wrong.

As for the IMatch API, sure, you may have access to the object model, but is it possible to make the file window look and work like an email inbox? Or to add functionality to other windows and tools which would be specific to non-image data? Unless I'm mistaken, the scripting API doesn't let you actually alter the functionality and interface of IMatch itself. Not that I'm proposing it is necessary to do so in order to accommodate some odd imagined scenario that nobody will really make use of, just saying that I don't think it is really possible for a third-party developer to make IMatch work that way very well right now.

[Mario]

Check out some of the example apps to see what can be achieved in "new" user interfaces. Rendering a message stream or maybe an Outlook-like panel is possible - albeit it will require some work of course. If there would be demand, many other things would be possible. I could even add a full-blown HTML browser window as one layout option for the File Window some day. I have plans in that direction.

Of course the web-based mail clients don't offer the functionality of a full-blown mail client like Outlook, maybe even in conjunction with Exchange and SharePoint. But most users don't need that I guess. Business mail usage and private mail usage are also totally different things. I use almost no emails anymore for private communication, it's all WhatsApp now. Which also has replaced SMS we used for years.

I was there when everything moved from the "host" computers (big mainframes) to the PC, and now I'm here to see move it all back to the host (now: Cloud Computing). I use the cloud for various purposes, but I don't trust any of the cloud vendors. Especially not when based in the U.S. If I keep any data in the cloud, it has been encrypted on my local PC before.

IMatch is a niche product and I'm happily add what users want - if more than a handful of users wants it. That's why we have the feature request board where users can post their ideas and wishes, and other users can comment and Like. If a small number of users bothers to comment and like, that's already something and counts. Most users don't use the community, and of the ones who do, only a small fraction actively participates in things like feature requests. Often users buy IMatch, use it every day and then contact me years later when an update is due and they cannot remember their password