OpusMetaInformation text limit

I'm struggling with the Opus usercomment field (metadata.other.usercomment). I would like to get some definitive solution if that is possible.

The problem is, I have been relying too much on usercomment. Fact is, that when I save something via usercomment, certain formats (under certain conditions) don't save it in Microsofts NTFS Alternative Data Stream (ADS) but in some other field - e.g. this is the case for many mp4 files, and movie files, etc. It is pleasant (at first sight) that DOpus gives us a handle to just store things without us having to worry which field exactly to use. It gets less pleasant that the usercomment handle may redirect your comment to a file-internal field (not ADS), and your comment may get shortened (e.g. to 255 characters - depending on the type of file you're working with). And there's no warning.

Of course, I knew that this happened. I created my own warning method (e.g. save the data, then re-read it and compare the length to the size expected to be saved). Usually, I just shortened to comment a little and saved it again. (As I said: I admit I can be lazy, I don't tackle all problems immediately, if they don't occur too often).

I can solve this by writing the string directly to ADS (enough tools out there to do it) but then I sacrifice consistency, because I have tons of stuff saved vi Opus usercomment. And writing directly to the x07OpusMetaInformation seems awkward and risky to put it mildly.

It seems like I have two reasonable options:

  • Either I no longer write via Opus usercomment, but directly to an alternative ADS field (which I could call OctopusMetaInformation just for fun and to be pretty unique).
  • Or, I still write to the Opus usercomment, test the saved text, and if it's too short I remove it again and write to the alternative field - a double action that can be automated via some central save-comment function.

I must, of course, keep reading data from both, given the truckload of saved text in older files.

If there was some option in DOpus to FORCE usercomment to write to ADS, that could also and easily solve the problem - but I did not find such an option. (This could perhaps be taken for a feature request).

But if not, then ... Any better ideas? I know that @errante has also created his own solution, but honestly I don't know what would be the most elegant way to solve my problem. Maybe there already exists some script that solves this? I am NOT particularly interested in other tags - my main use of metadata is to save certain core data (not too much, often and url, author and some other core data), without further ado - but it often includes a short description, and it quickly runs out of space in limited data fields.

We also need to consider reading comments, and that a file may come with an internal comment already.

If Opus was in a hypothetical "ADS only" mode, it'd have to either ignore those internal comments entirely or try to merge them. I could see that getting messy.

And then you'd look at a JPEG or MP4 or similar in other software, and maybe see a different comment, or change the comment and see the change reflected for some files (that don't already have ADS comments) but not others (that do). I think i would be quite confusing.

User comments are intended to be short, too. They get displayed in a column. If you're writing pages of data about a file, they're not really designed for that.

I understand that part. Still, a bit more than 255 chars is still "short" - it's not the same as writing a page. I'm not entirely sure why exactly Opus would not be able to manage an option to enforce ADS as some sort of "overflow". E.g. if the phrase does not entirely fit within a file-specific (internal) field, why not write the remainder to the ADS "usercomment"? Maybe with some signaling unicode character at the end of the internal data field - so it knows a piece of the comment sits in ADS?

Of course, I can do that sort of "overflow" via a script - but I can't write the rermainder into the standard DOpus ADS stream. It's a pity.