Feature request: index value formatting

[ruckmann]

Dear Simon,

I am a big fan of minim server for a long while, and I highly appreciate all the nice features available to organize my large classical music collection (actually roundabout 60.000 items) in a very structured way and with little tag information redundancy.

One of the nicest features is tag formatting available for display items and for Artist as index item. However, I miss such a functionality available for item values and index values in general. Such a function would allow me to derive and to compose new index values and new item values from given ones, e.g.

- workbytitle from title, tonality, opus number, subtitle
- workbyopus from opus number, title, tonality, subtitle

Both tag values would allow to navigate through titles alternatively sorted by it's title name and alternatively sorted by opus number. It would be very helpful to have both navigation options.

I potentially see other derivations also making sense, e.g.

- composerwithlifetime derived from composer, composerlifetime

I think, all the basic functionality needed to provide such a functionality is already in (tag formatting). I would highly appreciate if you could manage to provide such an extended and general tag formatting functionality as part of a new release.

If you need more information about my ideas or my request or if you want to discuss my request, please let me know.

[simoncn]

Thanks for this suggestion. I understand your request and how it would be used.

In simple cases, this should be reasonably straightforward. The complexities arise when an index tag created by one formatting operation is used as input to another formatting operation, or if an index formatting operation were to modify a tag value that is referenced in an index formatting string.

These complexities don't arise with display value formatting because this doesn't create any new tags or modify any tag values. The results of display formatting are sent to the control point and don't affect the internal state of the server library.

Creating new index tags does affect the internal state of the server library and this is why it raises some complex issues that would need to be considered very carefully.

[ruckmann]

Hi Simon, thanks for your quick reply. I do not fully understand the complexity issues raised in your answer. If it would be defined that consecutive tag formatting are going to happen from the left to the right (first formatting first, last formatting last), I do not see the problem. The formatting sequence would be evaluated step by step and each tag formatting would take current values from referenced tags and would assign the new tag value to the tag defined as tag to be formatted. Trade off would be, that minim server would need additional internal storage space in order to keep all the tags introduced for formatting purposes. On the other hand, if I would generate all derived tags using mp3tag etc. introducing highly redundant tag values, this would increase storage space need as well.

[simoncn]

(26-11-2015 21:22)ruckmann Wrote:  Hi Simon, thanks for your quick reply. I do not fully understand the complexity issues raised in your answer. If it would be defined that consecutive tag formatting are going to happen from the left to the right (first formatting first, last formatting last), I do not see the problem. The formatting sequence would be evaluated step by step and each tag formatting would take current values from referenced tags and would assign the new tag value to the tag defined as tag to be formatted. Trade off would be, that minim server would need additional internal storage space in order to keep all the tags introduced for formatting purposes. On the other hand, if I would generate all derived tags using mp3tag etc. introducing highly redundant tag values, this would increase storage space need as well.

This left-to-right approach is similar to how the tagValue property works. It is not similar to how the tagFormat property works. It has proven very difficult to get the tagValue property to work correctly in all cases and I am still working on fixes for this. I will keep your proposal under consideration and I will post any more thoughts on this topic here.

[simoncn]

I should be able to extend the current support for the indexFormat option in the tagFormat property to enable indexFormat to be used for other tags as well as Artist.

These indexFormat options would be applied from left to right to each item (track or group) and would not replace any existing tags in the item. For example, if you specify

workbytitle.indexFormat={$title$tonality$opusnumber$subtitle}

this would add a workbytitle tag if it doesn't exist in this item. No tag would be added if the item already has a workbytitle tag.

The processing of indexFormat would occur later than the processing of tagOptions and tagValue, so any new tags created by indexFormat would not have tagOptions or tagValue customizations applied to them.

When processing the tags in the format string, the index values of these tags will be used.

If a custom sort value has been applied to the first tag that is processed by the format string, this custom sort value will be applied to the new tag that is created by indexFormat.

The processing of indexFormat would take place while scanning the library. This is unlike displayFormat processing, which takes place during browsing. If you have a large library, the overhead of doing indexFormat processing might increase scanning time significantly.

Would this enable you to do what you want?

[ruckmann]

(27-11-2015 12:20)simoncn Wrote:  I should be able to extend the current support for the indexFormat option in the tagFormat property to enable indexFormat to be used for other tags as well as Artist.

These indexFormat options would be applied from left to right to each item (track or group) and would not replace any existing tags in the item. For example, if you specify

workbytitle.indexFormat={$title$tonality$opusnumber$subtitle}

this would add a workbytitle tag if it doesn't exist in this item. No tag would be added if the item already has a workbytitle tag.

The processing of indexFormat would occur later than the processing of tagOptions and tagValue, so any new tags created by indexFormat would not have tagOptions or tagValue customizations applied to them.

When processing the tags in the format string, the index values of these tags will be used.

If a custom sort value has been applied to the first tag that is processed by the format string, this custom sort value will be applied to the new tag that is created by indexFormat.

The processing of indexFormat would take place while scanning the library. This is unlike displayFormat processing, which takes place during browsing. If you have a large library, the overhead of doing indexFormat processing might increase scanning time significantly.

Would this enable you to do what you want?

First of all, many thanks to come up with a concrete and very detailed design proposal. I had to think a little bit about it. From all what I see, your proposal would satisfy all my needs.

If it would simplify implementation, special handling of customized sorting could be left away. Default sorting (alphabetical, numerical) would be sufficient - at least for my concerns.

I would be very happy seeing it implemented in one of your next releases. Thanks a lot in advance!

[ruckmann]

Dear Simon,

late but very enthusiastic feed back from my side: I have just started a reorganization of my music collection. Making use of the IndexFormat feature, I am now able to structure my collection in a much better way eliminating lot of redundancy currently in. From all what I see, it works pretty fine. I am very happy benefitting from this feature and I am totally impressed about your speed coming up providing it. Thanks a lot!!!

[ruckmann]

Hi Simon,

I am still on the way to restructure my music collection using the new indexValue functionality. Just discovered the following limitation:
indexValue applicable to index tags only: No chance to format auxiliary tag (re-used as IndexValue format input, but not listed as index tag)

Of course, there is a simple workaround: Move needed tags to the index tag list. However, index tag list blows up with additional tags really useful for navigation purposes.

I would be happy, if you would see a chance to remove this limitation.
B.t.w. Extending the functionality would change its meaning from IndexFormat to a general TagFormat functionality (but still working differently to displayFormat). But, why not?

I am looking forward to hearing from you

[simoncn]

(02-05-2016 10:10)ruckmann Wrote:  Hi Simon,

I am still on the way to restructure my music collection using the new indexValue functionality. Just discovered the following limitation:
indexValue applicable to index tags only: No chance to format auxiliary tag (re-used as IndexValue format input, but not listed as index tag)

Of course, there is a simple workaround: Move needed tags to the index tag list. However, index tag list blows up with additional tags really useful for navigation purposes.

I would be happy, if you would see a chance to remove this limitation.
B.t.w. Extending the functionality would change its meaning from IndexFormat to a general TagFormat functionality (but still working differently to displayFormat). But, why not?

I am looking forward to hearing from you

I understand what you are suggesting but I think it would add too much complexity. Also, I think you could achieve the same effect (perhaps with a little more work) by replacing "auxiliary tags" in your indexFormat strings with lower-level format instructions.

[ruckmann]

(02-05-2016 18:25)simoncn Wrote:  

(02-05-2016 10:10)ruckmann Wrote:  Hi Simon,

I am still on the way to restructure my music collection using the new indexValue functionality. Just discovered the following limitation:
indexValue applicable to index tags only: No chance to format auxiliary tag (re-used as IndexValue format input, but not listed as index tag)

Of course, there is a simple workaround: Move needed tags to the index tag list. However, index tag list blows up with additional tags really useful for navigation purposes.

I would be happy, if you would see a chance to remove this limitation.
B.t.w. Extending the functionality would change its meaning from IndexFormat to a general TagFormat functionality (but still working differently to displayFormat). But, why not?

I am looking forward to hearing from you

I understand what you are suggesting but I think it would add too much complexity. Also, I think you could achieve the same effect (perhaps with a little more work) by replacing "auxiliary tags" in your indexFormat strings with lower-level format instructions.

Simon, that's ok.

Just discovered another issue: in case of indexTags a, b b.indexFormat($a) works fine, but a.indexFormat($b) does not work. I do not understand why indexTags influences indexFormat sequence elaboration.