This one is hard to report and I won't be surprised if you're not able to duplicate. But I'll do my best. I am using MP3TAG version 2.50. I am a very enthousiam user and I've made my 50$ donation for sure. But here is a little slight problem that I can go over easily but now I am taking the time to report it.

Let's suppose I want to rename the filename of an entry from the modified date of the file itself. I will use ALT-1, so "TAG - FILENAME".

If I type directly "%_file_mod_datetime%", the application uses "06042012 23136 PM" for example with a sample file.

Let's suppose I am interrested to use only the YEAR in my name, I would use "MID$" and assume I need to type "$mid(%_file_mod_datetime%,5,4)" to get my 2012...



BUT NOT! When I do that, it will report simply "420"!!!
It looks like I need to type one position more than expected with one character lenght longer than expected!
If I want my "2012" reported, I need to type "$mid(%_file_mod_datetime%,6,5)" with the 5!!!

Oh! I see we can attached a file? I will attached a screenshot of what I am talking about then.

See the preview of the resulting name under in the requester.
I typed the "_" to help to see and make sure there is no annoying space inserted.

The capture I attached there shows the thing:
1st) you see the result of simply "%_file_mod_datetime%"
2nd) you see what I got with "$mid(%_file_mod_datetime%,5,4)"
3rd) you see what I got with "$mid(%_file_mod_datetime%,6,5)"

It could be nice if "%_file_mod_datetime%" would report the same thing in ALL places. When proving tag for album name for example (and it's an example), the date is reported differently...




Please try out your example and check the result using the converter "Tag-Tag" preview and come back to report.
Oh I see you did it already.
So ... what do you think ... what is the difference between a filename value and a tag-field value?

By the way ... for this example format string ...
... with System Date Time set according to ISO 8601 ...

... the result is in converter "Tag-Tag" preview ...
2012-04-05 16:26:21~~2012

... the result is in converter "Tag-Filename" preview ...
2012-04-05 162621~~2012

Both previews are correct.



Hello Sir!

I am not sure about the purpose of your reply. You've seem to have replied to 99% of all the cases I've read here so I am sure you're very good and it's my fault if I don't understand... But still, I don't. Are you asking a question? Are you explaining it's normal? Am I doing something wrong?

If your replied is to say "That's normal the expression %_file_mod_datetime% does not report the same thing when I want to use it to rename a filename then when I want to use it into a MP3 tag itself", that's fine. Even if I don't see why an expression a software would use to rename something is different from a situation to another, that's fine.

For having done many programming in the last twenty years, I know reporting the datetime is something that has been "inconsistant" for many many many reasons like DOS legacy, Windows versions, FAT versions, Windows regional settings, etc... BUT inside one software, I was expecting that when we would use an expression to report the date, it would be the same through the same software, in other words, that if "%_file_mod_datetime%" is 2012-04-05" for using it in renaming the file, it would be the same for using it in a tag. Certainly I would understand that MAYBE from a computer to another the filed would be reported differently (unfortunately...) but I was expecting that once on a specific computer, for ONE software itself the same expression would report the SAME thing from a place to another...

But that's fine. My main observation was ragarding the MID$ that seems strange used in combinaison of the %_file_mod_datetime%. I've seen that in the past a few times, I simply change the parameter to make it work and that's not a big deal. Today I had time so I took the time to report it. Me I like when my colleagues take the time to report an error or what seems to be an error in the internal application I do for us so I though I could do the same now for someone else. That's simply it.



%_file_mod_datetime% returns a text string, which contain some characters not to be allowed to be used in the file sytem.
The "Tag-Filename" preview removes such forbidden characters automatically, that's all.
I tend to say it is not a heavy bug.

But there might be a quirk in the sequence of applying the validating rule.
See there ...
Converter Tag - Filename validates part of format string before applying other functions around