Splitting TRACK field

I tried searching the forum and a got lot of results, but they were mostly about cases of splitting one field into two when you already have some kind of indicator in it

How about splitting a common format combining the disc and track number: >>000<<. How to split it into >>0.00<<?

I have for example track fifteen from the fourth disc written as 415 in the TRACK tag field, but I want it to look like 4.15

So the action that I am looking for should split three digits [and that is precisely only three and only digits] with a dot, that will follow the first digit [disregarding any other possibilities / characters]

It's simple with regexp.

Format: TRACK $regexp(%track%,^(\d)(\d{2})$,$1.$2)

^ anchor search from start of string
( start capture no. 1
\d one digit e.g 0-9 this can also be expressed as [0-9]
) end capture no. 1
( start capture no. 2
\d see above
{2} search \d ONLY 2 times. This includes the \d above resulting in a string with only 3 digits from beginning to end.
) end cature no. 2
$ anchor search to end of string.

The above with ONLY match 3 digits in the TRACK field. No less no more. And return 000 >> 0.00

Then your result $1 (first capture) a . then $2 (second captured string)

Yes, simple. After searching the forum I made attempts at creating what I needed. And as it turns out, I was on the same street but on the other side of it and on the opposite end of it than you

Thanks for the code and for the explaining deconstruction of that code

What about mathematics?
Format value for Track
Format string: $div(%track%,100).$mod(%track%,100)

Which, BTW, leads to a non-standard data format in TRACK. Only the / is allowed. So what's the point?

$left(%TRACK%,1)'.'$right(%TRACK%,2) ... or ... $div(%TRACK%,100)'.'$mod(%TRACK%,100) ... or ... $regexp(%TRACK%,'^(\d)(\d\d)$','$1.$2')

But I'm almost certain that you will be back immediately with an exception or change.

DD.20170803.0658.CEST

So now I see that you modified the code from

$regexp(%TRACK%,^(\d)(\d+)$,$1.$2)to
$regexp(%TRACK%,^(\d)(\d{2})$,$1.$2)But I've tested both and I can't see the difference- the act the same. Maybe if I had some precise set of characters in FILENAME then the difference would manifest itself

Allowed by whom and what?

You mean that only >>/<< is allowed in that field aside from digits? In case of for example WMA there are problems with non standard values like a single dot. But in case of FLAC, MP3, TTA, WV you can put whatever you like and things do not get messed up. For me it is the other way around- my Winamp automatically replaced the >>/<> of << which I do not like [and that is why I choose a dot as a separator]; because how would I know if there actually is not >> of << instead of >> / <<

As for the non-standard: what is standard? 000? Then how would you know if 111 means track 11 from disc 1 or track 1 from disc 11? It seems that my format is better [but suited for some formats which I do not use]. And as a docked at the top of the screen Winamp can displays only five tag fields in displays File Info Components, I put the overall number of disc for a given album at the end of it- this way I can see at a glance [without additional clicking] which track it is and from what disc

I used to use TRACK for tracks numbering and DISCNUMBER for storing information about disc [which and of how many]- and it just did not work for me. To often I had to click and scroll. Now I do not have to anymore

Does not disregard other possibilities than 000 thus creating a mess

Does not disregard other possibilities than 000 thus creating a mess

This works as it is technically the same as the second version by stevehero

No. I'm pretty much done

Although there are other values / signs they have to be decided upon and; only then put with a prepared separate action

$regexp(%TRACK%,^(\d)(\d+)$,$1.$2) doesn't account for TRACK with only 3 digits. $regexp(%TRACK%,^(\d)(\d{2})$,$1.$2) does. Less gready regexp. \d{2} = 2 digits and $ symbolises the end of the string. So it's never going to match TRACK with anything other than 3 digits.

It is the ID3 standard.
"TRCK

The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9". "

See http://id3.org/id3v2.3.0 for that. You are free to use your own field contents but don't complain when it does not work.
That other programs format their output in their own fashion does not prove that the standard does not exist - more on the contrary: if shows that you can get a nicer formatting if you have a standardized input.

I don't know how have I missed that

You are correct. Thank you

I'll save the other version just in case for future changes

+1 on what ohrenkino says. Actually what the industry standard says.

The moment you step away from that is when it causes you trouble / Corrupt data.

Not saying it's going to happen but it's better to be safe than sorry.

Sorry, I do not understand your remark ...
because your requirement was actually quite clear ...

DD.2017083.2108.CEST

This is not a common format. The correct formatting has data in the field TRACK for the number of tracks and possibly the total number of tracks and there is a field DISCNUMBER that contains the number of the disc.

And as you stated quite clearly that you onyl want to treat 3-digit-numbers, I do not understand why

the mess should come from.

In regards to the mess: I needed the code to take into consideration only 000 format and and not for example 0000, because 4 digits create often a number meaning a year, that is a part o a title

And what if it is a case of track 10 from disc 20, thus displayed as 2010 at the beginning of a newly added [tagged] file? Well for me it is very rare [way much seldom than years in titles] and as such is dealt by me manually

We talking about the field TRACK (as you said in your initial post), aren't we? And where does YEAR come in here?

The "and what if" question could have been answered by you really quickly if you just had tried it.
Apparently, you have not seen the potential of remainders and integers in divisions.
The approach with
$div(%track%,100).$mod(%track%,100)
works perfectly for 2010.

A year [or something like a telephone number] would be copied from a FILENAME, when adding new files [thus tagging a file completely clean of tags]

A year [or something like a telephone number] would be copied from a FILENAME, when adding new files [thus tagging a file completely clean of tags]

That's a long and all too boring story: /t/19095/1

Yes, I know that process.
But what does that have to do with splitting a TRACK number with more than 2 digits that resides in the field TRACK?
To me fiddling about with a filename looks like a completely different thing.

Probably nothing; probably I got confused; probably I have spent too much time reworking my actions