New custom tagging interface (feedback request)

[jiri]

Hi,

since there have been several request for scripting access to tagging functions that would allow scripters to write custom fields to tags, I decided that we could try to implement a pretty generic scripting interface for this purpose. I have proposed a simple interface in http://www.ventismedia.com/mantis/view.php?id=6218 that would handle all the tag reading and writing. I'd be interested in feedback from the developers who would like to use such a feature...

Thanks,
Jiri

[trixmoto]

Thank you for this Jiri. Can you please give an example of how I could read and write an custom tag at some point during my script process?

[jiri]

The events would be called during standard MM operations, e.g. when you scan tracks, TagRead event would be called for the scanned tracks, when you update track properties, TagWrite event would be called. In these events you can manage which fields are read/written and where are stored (comments, custom fields, standard fields) - see the example in Mantis. In case you'd need to start e.g. tag writing manually, you could use the already existing methods of SDBSongData. Is it what you asked for?

Jiri

[booblers]

This proposal might work in some situations but here are some things to think about:

Creating the equivalent of a new MM field would have to be done at a lower level and on an individual script basis. ie: there is no way to map custom tags in FLAC to the same custom tag in ID3v2 except with if-then statements, etc. This isn't a problem for me as I don't mind doing the work but someone else might have another view of the matter. I actually probably would prefer the method you outline as it is more powerful and would be less likely to require you to revisit this feature in the future. One alternative is the type of scenario I PMd you before wherein a new "internal" tag is created which is then mapped to actual tags in the files depending on tag format and etc. These fields are then available in SongData or in an object linked to SongData without having to account for the filetype/tagtype.

Making the capability available only as an event seems like it could have potential side effects. If Trix's MusicIP script registers an event and takes action because the user wants to tag 10 selected files with the MusicIP audio fingerprint - what happens when another script running in the background also tries to read/write from tags? Or what happens when the currently playing track ends and the tags/database are updated with the playcount? Won't that track also be run through the same event even if the user doesn't want it to be? In other words: it seems like making it event-based is an all or nothing situation. Unless I misunderstand something this seems like it has the potential to cause all sorts of problems?

I would take the functionality you describe over no functionality in a heartbeat.

[jiri]

As for alternative solution - I think that this is the only solution that can cover most of possible needs. Anything else, where MM would try to do more specific things would probably help only in some particular cases.

re. problems - there shouldn't be any, it's prepared for multi-script usage.

Trixmoto, does it make sense to you from your scripter's perspective?

Jiri

[trixmoto]

It does make sense, I can store the values in a Dictionary object in SDB.Objects and then pull the value out of here when the event fires - seems like an odd way of doing it, but I can see that it would work. I'd be a bit worried about performance I guess, if a few of my scripts register this event then it's going to be firing constantly - won't it slow down the reading/writing of tags quite a bit?

[jiri]

Which values would need to store in SDB.Objects? I was thinking mostly about things that could be handled directly with the SDBSongData object, e.g. reading/writing of iTunNORM, removal of unvanted tag items, etc.

As for performance, no, I don't think there would be any measurable impact.

Jiri

[Lowlander]

To extend the database fields (ie more Custom fields for users and Custom fields added by addons) they shouldn't be stored in the songs table which would just increase bloat of the DB. Instead they should have their own table with SongID, FieldID and Value. DB optimization isn't my thing, but I have seen others use this model.

[trixmoto]

Well if I'm storing PUID then I might not want to put that in any of the current MM fields, I could just put it in the relevant tags. Of course it's probably a good idea to put them in an MM field as well, but I'm sure they would be occasions when this wasn't appropriate.

[booblers]

Am I missing something?

As described it looks like for your PUID script Trix you would have to calculate the PUIDs and then, as you say, store them in an object temporarily. No problem.

So you do that. Then you register an event OnTagWrite(). In this event handler you write your new PUIDs that you've calculated and stored in an object.

Now you have to generate the event manually for each file with, eg, a SongData.WriteTags() so that your event handler can fire and actually write the tags.

But in this scenario you can't control what is firing the WriteTags() event. You are firing it manually, sure, but there is nothing to stop the event from firing from other places as well, correct? So when tags are written when the player is finished playing a track you might also fire the event - even if you didn't want to.

This means that any attempt to read/write custom tags has to take into account events coming from other places. In other words - your object now has to keep a list of songs the event will apply to and etc. Is this what you meant by a performance issue?

Making the events available would be good for some scenarios but in other scenarios wouldn't one prefer having the TaggedFile object linked to SongData and available outside of the events?

Then scripts like yours would just look like:
Calculate PUID
SongData.TaggedFile.SetFieldValue( field: string; value: string)
SongData.WriteTags()

Is that not better in many scenarios?

Again, I note that any functionality is better than none. But having the ability to modify tags outside of events seems like makes the most sense to me.

[jiri]

No, really, there isn't any performance problem, the event gives scripts a chance to do anything on tag read or write, there isn't any mandatory action, script can just ignore events in case it isn't interested in them.

Jiri

[trixmoto]

I think the way that my script would work is the same as it does currently, calculating and storing the PUID in the designated field (eg. Custom1). It would also register this event, so that when I stored the tags I could then copy the value from Custom1 into the other tags as well. It is designed to allow us to access the extra tags, but at the end of the day, they will still want to be in an MM field for them to be useful for sorting/filtering/searching/etc.

[booblers]

Will null characters be allowed?

I note that in the proposal you say that binary data won't be allowed. Will null characters be allowed in the strings? These are necessary in ID3v2 TXXX frames (user-defined tags) The TXXX frame consists of a field/value pair and the field is null-terminated.

[Thanasis]

Hi Jiri,

That would be cool, to be able to write to custom tags every time a tag is read or written by MM.

I am coding a lot with MM, but I haven't come to this need yet.

But now new ideas come to mind of how I could use your new proposal !!!

Writing plug-ins for Media Monkey is a niche, only few people are involved with it.

I haven't found a better alternative to MM for writing custom plug-ins.

Very easy interface and Wiki documentation make MM 4.0 indispensable

Take care