# Definition for \_FORMAT requires property variable as value

**URL:** https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947
**Category:** General Discussion
**Created:** [October 11, 2026, 8:42am UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947 "2026-10-11T08:42:14Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 11, 2026, 8:42am UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/1 "2026-10-11T08:42:14Z")

</div>

I grind my teeth a little bit over the current implementation of \_FORMAT elements in the tag panel.  
I stumbled over the way to tell that function which property should be displayed - right now it has to be entered as value.  
I found this puzzling - so far it was only possible to enter either a fixed string or choose the options `<keep>` or `<blank>` when customizing the tag panel. It was not possible to enter a variable to become a value.

I would have assumed that the list of selectable fields would have been expanded by the variables for properties - this in addition to the already existing \_DIRECTORY.  
As soon as a field starting with an underscore would be selected, `Value` would be disabled - also the option to Manage ... custom values should not be accessible.  
I know that the list of selectable fields would become rather long if the current implementation would prevail.  
Yet, I think there is already a solution in the filter field selection and also in Customize columns which divides the lists into extended fields and informational fields.  
Something similar might be appropriate for the tag panel field selection as well. It looks to me like the options for the file list and the tag panel have become more and more equal.  
So I would prefer field names only to appear in the "Field" list and not as free text variable in "Value" (with all the possibilities of typos and other errors).  
Just my thoughts. It could be that I am just not flexible enought, mindwise.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 11, 2026, 9:25am UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/2 "2026-10-11T09:25:49Z")

</div>

Thank you for the feedback!

First of all, I'd like you to notice that field you enter the value changes its label from "Default value" to "Value". So it's a different configuration setting for `_FORMAT` fields.

> [@ohrenkino](#):
>
> I would have assumed that the list of selectable fields would have been expanded by the variables for properties - this in addition to the already existing \_DIRECTORY.

This was my initial implementation, but I soon noticed that many users would probably like to combine different placeholders to complex format strings. I wanted to offer a flexible solution and also didn't want to code myself into a corner, where offering a flexible solution like what's available in the file list wouldn't be possible.

> [@ohrenkino](#):
>
> As soon as a field starting with an underscore would be selected, `Value` would be disabled - also the option to Manage ... custom values should not be accessible.

It's already behaving similar to that: you select `_FORMAT` and "Default value" changes to "Value". Also, the "Manage..." button for custom field values is disabled.

From what I'm getting from your feedback, concerns are discoverability and possible mistakes when entering information field placeholders. I think removing the existing values (\< keep \>, \< blank \>, and \< enter \>) from the Value list is one step in making it less ambigous. Also, adding a button for a [format string helper menu](https://docs.mp3tag.de/menus/format-strings/) would probably improve discoverability and reduce possible mistakes.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 11, 2026, 9:36am UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/3 "2026-10-11T09:36:58Z")

</div>

Indeed, I did not think of the use-case to have a list of properties in 1 element - but that should be possible for read-only values.

I got my qualms with this thread

> [@Use placeholders in MP3tag to enter data in the tag fields](https://community.mp3tag.de/t/use-placeholders-in-mp3tag-to-enter-data-in-the-tag-fields/71940/):
>
> Hi. I've been using MP3tag for a long time and now I have a question. For use in a jukebox software I need to give my mp3s an album. I would like to use the artist name so all songs of an artist are grouped together in one 'album'. Is it possible to read in alle the files, then enter the placeholder %artist% in the album field, so that the files all get the specific artist name as album? I tried to simply put %artist% in the album field but then they all have %artist% as album....not the act…

in the back of my head where there was an attempt to set the value for a new field with the value from an old one.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 11, 2026, 9:41am UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/4 "2026-10-11T09:41:20Z")

</div>

The question from the topic you linked to covers a different problem and is unrelated to the new configuration options.

Also, in case you're afraid that I'm going in this direction: I'm not planning on adding this, we have **Convert → Tag - Tag** and action **Format value** for that.

---

<div class="post-metadata">

### Author: ![Sergius](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/ebca7d/32.png) [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [October 11, 2026, 6:36pm UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/5 "2026-10-11T18:36:37Z")

</div>

Hello @Florian,

Many thanks again for adding the `_FORMAT` data to the Tag Panel; this paves the way for various on-screen data configurations that were previously impossible...

I notice that, for the moment, we cannot write directly to the `_FORMAT` field.

Frank and I spent several hours yesterday working on the new features he has added to the Tag Panel. As he explained to me, the formulas programmable in Mp3tag aren't unique to it—programs like Foobar2000 and others use them too. There are variations in data formatting between programs, so the data just needs to be adjusted accordingly, as you know...

He’s achieved something remarkable: we can now see data like Intro, Segue, Hook Start, and Hook End in the Tag Panel. He even programmed "Hook Length" for me—something I thought impossible to include in the Tag Panel. He explained that while it isn't technically a "tag," it is a programming formula that BSI included in its Info Editor...

I can now use Mp3tag to program the Intro and Segue tags—which is easy to do. The Hooks are a bit more complex; when I save the changes, I immediately see the minutes, seconds, and tenths of a second in the Tag Panel—the exact values ​​BSI Info Editor receives. It’s incredible; as I always say, it’s the best tagging program out there...

My question is: do you plan to eventually allow us to program this `_FORMAT` field directly?

For example: changing my Intro tag from `00:06.5` to `00:07.0`...

...instead of having to change the value in milliseconds (e.g., from `6500` to `7000`).

Here is an image showing the incredible new additions to my Tag Panel...

Congratulations again on these new features! 👍

 ![09- Mp3tag v3.37-beta.1 –place the _Customize... Columns_ features in the tag panel... Real BSI Intro, Segue etc copy](https://community.mp3tag.de/uploads/default/original/3X/e/c/ecd45ea799ab3e0c06fd56d9771a6ccb0a1efb6b.jpeg)

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 11, 2026, 7:02pm UTC](https://community.mp3tag.de/t/definition-for-format-requires-property-variable-as-value/71947/6 "2026-10-11T19:02:10Z")

</div>

> [@Sergius](#):
>
> My question is: do you plan to eventually allow us to program this `_FORMAT` field directly?

No, unfortunately this is not planned. The underlying data is the value `6500` in milliseconds and converting it back from the rendered `00:06.5` would require an inverse transformation.

Also, I'd like to keep the `_FORMAT` fields read-only. I can think of a few exceptions (e.g., `%_filename_ext%`), but I don't want to add even more complexity at the moment, even for those.

There are plenty of _imaginable_ features, but not every feature is worth adding and maintaining indefinitely. Once something has been added, it's almost impossible to remove it.
