Metadata on unsupported files

[meyersoft]

Hi,
I have a question on Metadata on unsupported files:
When adding metadata (f.e. Title, Author) to unsupported files (f.e. mp3), imatch accepts these and indicates the unwritten metadata via yellow pen.
I have configured imatch to not write sidecar files.
When trying to clear this yellow pen by writing back metadata, I get an error.
The logfile indicates "Cannot create XMP for unsupported file".
The metadata is written to the database - after restart of imatch, the metadata is still there.
The yellow pen is cleared.
That's exactly what I wanted - metadata only in database - but I did not expect an error.

Is there a possibility to avoid this error or do I have the wrong workflow and/or settings?

[Mario]

ExifTool cannot write-back to MP3 files (unfortunately, I would really like to have that).
When you change metadata for an MP3 file, IMatch puts that data into the database, and them marks the file as pending.
When you write back the data, does IMatch create an XML file? What does the ExifTool output panel show?
I have really not yet handled all special cases, e.g., this one. Plenty of time for such things in later builds (after the initial release).

[meyersoft]

There is no XML file created.
The mp3 file stays unaffected.
The ExifTool output panel stays blank.
Only the errormessage occurs and the imatch logfile shows "PTMetabase::Write-back Cannot create XMP for unsupported file xx".

Is there a setting / possibility to keep all Metadata (for all files or per file type) only in the database?

[Mario]

Is there a setting / possibility to keep all Metadata (for all files or per file type) only in the database?

This is implicit. IMatch always writes the data into the database first.

I've made a test:

1. For a MP3 file I added a title and some keywords in the "Default" metadata panel (XMP data).
2. Files goes pending.
3. I trigger Write-back.
4. IMatch creates an XMP file for the MP3 via ExifTOol.
5. No error message. Output written by ExifTool. No error.
6. Yellow pen removed. File is current.

Which tags did you change? Tags which have to go back into the MP3 file?

[meyersoft]

I have changed some tags from the Core data (title, Author, Author title).
Tags from the mp3 panel are locked and cannot be changed.
But as stated above - I have configured imatch to not write sidecar files (Allow to create XMP file = No).
When setting this to Yes, an XMP is generated, pen icon disappears and everything is fine.

But I would like to avoid XMP files, write tags into database and also avoid errors when trying to write back.
Maybe the yellow pen should not appear when "Allow to create XMP file = No" since tags are stored in the database immediately?

[Mario]

But as stated above - I have configured imatch to not write sidecar files (Allow to create XMP file = No).
But I would like to avoid XMP files, write tags into database and also avoid errors when trying to write back.
Maybe the yellow pen should not appear when "Allow to create XMP file = No" since tags are stored in the database immediately?

That's such a special case:

1. You change XMP data
2. You use a file format which does not allow for embedded XMP data.
3. You also force IMatch to not write XMP data.
4. You perform a write-back.

IMatch correctly tells you that it cannot write-back data.
Trying to figure all this out, especially in context with mixed updates (the user has not changed only XMP data) and file relations can create a lot of headaches and subtle problems. You can file a feature request but don't hold your breath. There are over 100 already.

[Erik]

Isn't this a case where attributes could be used? 

While IM writes XMP to its database, isn't XMP by definition something that should be part of the file via XMP file or embedding? 

I'm not sure what I would do in the same situation as I can understand not wanting an XMP file with an mp3 file or probably any audio file, but most my audio files have their own embedded tags, and I have yet to test this aspect of IM5 out. 

[Mario]

The problem here is that the user updates XMP data, but wants to disable the normal IMatch behavior of storing the XMP data where it belongs.
Attributes, as a database-only concept are indeed a good alternative. That's why I invented them and implemented them.

[meyersoft]

Okay, I will look for attributes instead of metadata.