how to get the space after the track number be deleted


#1

i have filenames such as

101 pari malar

i want to delete the space after the track number.

so it should look like > 101pari malar

how can i achieve this?


#2

why do you such strange things to your file names?
however:

Action: Format Value
or
Converter: Tag-Tag

Field: _FILENAME
Formatstring: $regexp(%_filename%,^(\d+)\s+,$1)


#3

Use the converter "Tag - Filename", or an action "Format value" on the field _FILENAME, with the following scripting expression ...

$left(%_filename%,$sub($strchr(%_filename%,' '),1))$cutLeft(%_filename%,$strchr(%_filename%,' '))

Use the converter "Filename - Filename" ...

Convert | Filename - Filename | ALT+3

Select format string

Old filename pattern:
%1 %2

New filename pattern:
%1%2

Preview
From:
101 pari malar.mp3
To:
101pari malar.mp3

Be aware, if you later want to extract the track number from those merged file names, you might get into trouble.

DD.20120423.0707.CEST


#4

Why use such a complicated exp for such a simple task?


#5

thanks a lot for the suggestions. as to your qtn why i need such strange things. well. i think i should explain so that you may suggest another thing to get it sort out.

when i see the filenames in the explorer, some files with longer filenames comes in two lines. as a result. all the three tag fields are not visible. i should see all the three viz filename(line1), album(line2) and the artist(line3) . so i searched for a solution to cut short the filename, good people like you suggested how to cut short the filenames . i understand most of the filenames with 25 characters comes in a single line. so i restricted all filenames to 25 characters. even then a few filenames though they have only 25 characters including space between words come in double line. then i thought if i cut the space after the track number i could get them in a single line. as Deltaev suggested i am not going to delete the space after the track number. it does not look nice also. if you have any suggestion, please.


#6

Hm, this expression is written in the Mp3tag Scripting Language on the basic beginner level.
All used functions are documented in the manual and easy to understand.
Well stevehero, you can show a less complicated expression, without using the expert function $regexp ... :wink: ... wanted to say ... without using the power of a regular expression.

DD.20120423.1518.CEST


#7

True, but for new user's browsing this forum they may find it a little daunting to see that looooong exp to do what can be done with the same very simple action below. But I suppose its all about the option you choose to take.

Action type: Replace with regular expression
Field: _FILENAME
Regular expression: ^(\d+)\s+
Replace matches with: $1

[ ] case-sensitive comparison DONE :wink:

While were on the matter, I see a lot of users pone, yourself etc using the format option with the $regexp function. Why choose this instead of using replace with regexp? Is it handled quicker inside of mp3tag?


#8

Most people do not understand the cryptic Regular Expression Language and how a regular expression will be read or written.
But there is a good chance that those people can understand a basic scripting language like the one, which Mp3tag provides.
$sub, $left, $cutLeft are self explaining function names.

The result of the function $regexp can be prooved in the converter's preview.

DD.20120423.1606.CEST


#9

As DetlevD says, the preview function is a great advantage.

And the new Tag-Tag Converter, where you can use this, is quicker than actions.

And the $regexp function can be combined with all other mp3tag scripting functions, making it much more adaptative.

And it isn't so complicated if you know the basic syntax: $regexp(string,expession,relpace)
Only escaping scriting characters is more complicated here than in the action you prefer.

But in the end, it's a matter of personal taste.


#10

+1

I bought a program called Regexp Buddy so I use that for the function of previewing my regexp.


#11

Not only a matter of taste, but surely a matter of capabilities and skills.

DD.20120423.1848.CEST


#12

expecting an answer for the second para of this post. thanks for all .