What I like and hate most in MP3TAG

General Discussion
1

No misunderstanding, MP3TAG is great, powerful, no doubt about that.

But, what I use at most are the Convert actions with very complex actions, an example :

..\\%artist%\\%artist%$if($eql(%year%,),, - %year%)$if($eql(%album%,),, - %album%)\$if($eql(%discnumber%,),,CD%discnumber%)\\%artist%$if($eql(%album%,),, - %album%)$if($eql(%discnumber%,),, CD%discnumber%) - $if($eql(%track%,),,$num(%track%,2) - )%title% '['$div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2)-%_bitrate%']'

The pain is that the history is stored in a non-editeable MP3TAG.CFG file.

Storing the history in sort of HISTORY.INI would make the use of the Convert Actions much easier :

    to change actions in a real editor cleanup easely unneeded actions backup sets of actions

I really hope this (or another equivalent solution) will be taken into consideration !

Thx

2

I do not know what you mean by "real editor" but it is possible to edit the mta-files with a plain-text-editor like Notepad. You would have to do the housekeeping, though with ascending numbers and stuff. This then would be much easier be done with the internal means of MP3tag.

You can easily save certain setups in the Actions dialogue with the functions of the button "Utils".
All actions are stored in a folder as individual files, so you can delete them with the means of the OS or use the "Delete" button in the Actions dialogue.

If you want to get rid of certain converter-masks, then you may use the arrow-button of the converter-dialogue to delete a certain or all masks.

3

He is not talking about actions using the action-menue but actions using the converter-menue. Letter are not stored in text-files which you can edit with a editor.

Deleting converter-masks with the arrow-fields is possible but a pain in the ass to do with more than 1 at a time.

Because of the length of the input field in actions and converters the string is hard to overlook at some times.

4

The actions under "Convert/...." are not stored in a plain-text MTA-file, but they are stored in MP3TAG.CFG which is (unfortunately) not an editable file

Managing those Conversion (action) strings in MP3TAG is really a pain, especially when they become complex and there is no easy (other than one-by-one) way to clean the history up, nor to set them out-of-sight for later reuse.

If they would be in sort of editable history.ini it would be really flexible

5

Yes, converter settings are not stored in plain text files.
But they are distinct from "Actions" which can be accessed via the menu "Actions" (vs. menu "Convert") so it is a little puzzling if you talk about "actions" while you actually mean "Convert".
But I think I got the point.
Yet, the list of features for actions that I mentioned is still valid.

As a workaround: nobody hinders you to create a plain text file yourself where you store all your convert masks.
There you edit them as you like. And you can even add comments that explain what you used it for.
If you need one these masks, you simply copy and paste them into MP3tag.
If the history list in MP3tag becomes too long, you can easily clear it as the master for all your converter masks is your text file.

6

That is a common workaround which I use because Mp3Tag stores this in the Mp3Tag.cfg-file which is not edible.
But a better solution would be not to need such workarounds and to store all this in INI-Files.

7

In my original post is pointed that out 3 times :

    But, what I use at most are the Convert actions with very complex actions, an example : The pain is that the history is stored in a non-editable MP3TAG.CFG file. Storing the history in sort of HISTORY.INI would make the use of the Convert Actions much easier

Further I fully agree with , I have exactly the same opinion.

Copy/paste is a workaround which might be useful once a Convert string is tested, but during testing even that isn't really a solution, resulting we have to stick with the too small input-string.

As 90% of my/the MP3TAG usage are the Convert Actions

    an larger autowrap input area instead of the input-line and a history stored in an editable ini-file
would be up to the quality of the rest of the program, which is outstanding

I really regret the Florian isn't picking this up, as from development point of view it's not comparable with the difficulty of the rest of the MP3TAG functionality, but for the user it's makes really a big difference in ease of use.

8

IMO, it's foolish to create such complex convert statements. That's a very poor use of the power of Mp3tag. You could do the same thing with a saved action group consisting of several much simpler actions. The saved action group could then be used as the basis for future action groups and will be infinitely easier to both understand and to edit.

Better yet, break that statement up into not just several actions within one group, but several action groups. Then in the future you can pick and choose which parts you wish to apply in a given situation.

9

Let's see how you would do a TAG-FILENAME (which is the example I gave) in an Action Group

    with the same result in ONE go without intermediate invalid Path/FileName situations

Then we'll see

    how foolish it is how poor the use of the power is

But anyway, the functionality is there and offers the functions to the user to use it, but not in a user-friendly way.

10

You can easily build up the file path in a temporary field, rename the file, remove the temp field. I would set up each component of the path as a separate action, and also make the part that appends the time and bitrate separate. With something like the following, you could easily duplicate the action group and then edit individual pieces as needed from within Mp3tag.

Action type: Format value
Field: TEMP
Format string: ..\%artist%

Action type: Format value
Field: TEMP
Format string: %temp%\%artist%$if($eql(%year%,),, - %year%)$if($eql(%album%,),, - %album%)

Action type: Format value
Field: TEMP
Format string: %temp%$if($eql(%discnumber%,),,\CD%discnumber%)

Action type: Format value
Field: TEMP
Format string: %temp%\%artist%$if($eql(%album%,),, - %album%)$if($eql(%discnumber%,),, CD%discnumber%) - $if($eql(%track%,),,$num(%track%,2) - )%title%

Action type: Format value
Field: TEMP
Format string: %temp% '['$div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2)-%_bitrate%']'

Action type: Format value
Field: _FILENAME
Format string: %temp%

Action type: Remove fields
Fields to remove: TEMP

11

If you're a masochist, the above appears to be doable in a single action. I wouldn't recommend it, due to how difficult it is to edit such a long format string, but it's no different than using the tag to filename converter. I'm not sure what situations give you invalid paths, but one additional thing that I would recommend is removing any invalid filename characters from the artist, album and title.

Action type: Format value
Field: _FILENAME
Format string: ..\%artist%\%artist%$if($eql(%year%,),, - %year%)$if($eql(%album%,),, - %album%)$if($eql(%discnumber%,),,\CD%discnumber%)\%artist%$if($eql(%album%,),, - %album%)$if($eql(%discnumber%,),, CD%discnumber%) - $if($eql(%track%,),,$num(%track%,2) - )%title% '['$div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2)-%_bitrate%']'

I don't know exactly what you work flow looks like, but typically you would know the root folder where you're placing your artist and album folders. I would avoid the use of relative paths ("..\%artst%") and use an absolute path to avoid any unexpected results. Something like "D:\Music\%artist%... etc.".

12

You are quite right: there are many ways that lead to Rome - the format value action for _FILENAME has the same result s the converter tag-filename .... as would have the converter tag-tag.

Yet, the basic problem of the OP was a different one, I think:
The concept that the strings for converters are not stored in an editable file.
This problem remains.
Although your idea to put the whole manipulation into actions might improve editablity it then lacks the preview function - as would the editing in a text file.
So, we probably have to be content the way it is.

13

You can shorten this expression ...

From:

$if($eql(%YEAR%,),,' - '%YEAR%)

To:

[' - '%YEAR%]

You can shorten the tape worm format string from above ...

'..\'%ARTIST% '\'%ARTIST% [' - '%YEAR%] [' - '%ALBUM%] ['\CD'%DISCNUMBER%] '\'%ARTIST% [' - '%ALBUM%] [' CD'%DISCNUMBER%] [' - '$num(%TRACK%,2)] ' - '%TITLE% ' ['$div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2)'-'%_bitrate%']'

... write all expressions into one line.

And even this ...

From: $div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2) To: $trimLeft($replace(%_length%,':',''),'0')

From (%_length%):
00:08
04:05
02:03:16
To:
'08
4'05
2'03'16

You can put all steps into an action group ...

Begin Action Group Test_2014#20140407.wquatan

Action #1
Actiontype 5: Format value
Field ______: TEMP
Formatstring: '..'%ARTIST%

Action #2
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%''%ARTIST%

Action #3
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%[' - '%YEAR%]

Action #4
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%[' - '%ALBUM%]

Action #5
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%['\CD'%DISCNUMBER%]

Action #6
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%''%ARTIST%

Action #7
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%[' - '%ALBUM%]

Action #8
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%[' CD'%DISCNUMBER%]

Action #9
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%[' - '$num(%TRACK%,2)]

Action #10
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%' - '%TITLE%

Action #11
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%' ['$trimLeft($replace(%_length%,':',''),'0')

Action #12
Actiontype 5: Format value
Field ______: TEMP
Formatstring: %TEMP%'-'%_bitrate%']'

Action #13
Actiontype 5: Format value
Field ______: _FILENAME
Formatstring: %TEMP%

Action #14
Actiontype 9: Remove fields
Fields to remove (semicolon separated): TEMP

End Action Group Test_2014#20140407.wquatan (14 Actions)

DD.20140407.0010.CEST
14

Thanks for the suggestion, I wasn't aware of the "[...]" trick for testing empty results. This is a real improvement !

With $replace(%_length%,':','') there is the problem when the track is <1min (and if I remember well also when >60min), reason why I'm using $div(%_length_seconds%,60)''$num($mod(%_length_seconds%,60),2)

As wrote, the disadvantage of Action groups is the lack of preview, which I consider as essential for the TAG-FILENAME functionality. I don't want to take any risk when renaming (and moving) the files.

Thanks to the "[...]" trick the example is really smaller, but this doesn't change anything to the original reason of this topic, namely

  • an larger autowrap input area instead of the input-line
  • and a history stored in an editable ini-file
15

Then I don't understand your original request to be able to edit a saved formatting string within a saved text file somewhere. If you want to preview the results as you edit, you can only do that within the converter dialog.

Preview is only essential if you're moving files (writing paths) with the functionality, and using many different filenaming conventions. If you have just one or just several filenamiing conventions (as most people do, I would think) then keeping the renaming actions in well-tested action groups would seem to make a lot more sense to me.

16

I understand his suggestion in that way, that you don't only rely upon a one lined scrolling window but editing a convert-string should be inside a multilined editor and you can overlook the whole string.
That does not neccesarily prevent from previewing the result.

I personally often use the converter for previewing and testing strings that I later use in action-groups and these are not always limited to filenaming.
Anyway, in the action menue you have a similar problem with editing because you have a very small scrolling one line window and only after saving you can overlook the whole action-code.

17

Exactly, that's the reason of the topic. 4 years later still the same issue, the text-editor (ini-file) option being a workaround for the one lined scrolling line (not window).

Actually I have everything in a text-file, where I prepare/maintain/create/edit the convert-strings and copy/paste them into MP3TAG when I need one. Silly, silly and very unhandy, but better than the one lined scrolling line (not window).

Fully agree

I really don't understand why nothing is done about it. I think a multilined editor or having the strings in an ini-file can't be difficult to implement.

For those not needing this, no problem, for the others a solution / relief

18

Please note that you can enter only a single line - any linebreak or end-of-line would be interpreted as end-of-format-string.
A multi-line-editor might suggest that you can select more than one line for a single conversion. This is not the case.

The ini-file would not be any different from your private text file:

  • you would not have a preview and immediate feedback what your last modification would lead to - which I consider a huge benefit in the convert dialogue,
  • you would not have auto-completion or incremental search, which I also consider a nice feature as it usually saves me a lot of typing.

Did you know that you can adapt the size of the convert dialog so that it is as wide as your screen? So perhaps you do not need line wrapping or scrolling.

And to make it totally clear: I do not judge your suggestion. I only try to show you options that are there today already and that might help you to overcome your problem.

19

Sure, with multi-line-editor I referred to an editing box in which one line wraps over multiple lines. So only one line edited at a time (no change except the wrapping)

Not necessarely. Then the ini-file could be edited and saved by an external program and reloaded by MP3TAG

I do, but that's limited too

Having a editing box (multi-line window) wherein the actual line is wrapping for editing purposes would be the best possible solution