On a file dragged into mp3tag, %path% returns the expected value e.g.
S:!DJ DAP\3 ZEN\Dance\GW w-a.wma
but on the same file loaded by
start "Mp3tag Dance" "%PROGRAMFILES%\Mp3tag\Mp3tag.exe" /fp:"%~dp0\3 ZEN"
%path% includes an extra \
S:!DJ DAP\\3 ZEN\Dance\GW w-a.wma
Workaround: at every reference, have script to remove the extra \ 
Is there an easier workaround? Please let there be a secret %unmessedpath% 
Hi,
looks like you are using a batch for calling mp3tag, which resides in your
S:!DJ DAP directory.
The issue depends on the variable-expansion of the shell (cmd.exe):
%~dp0 expands to S:!DJ DAP</b> with the trailing backslash
So, simply remove the backslash in front of 3 ZEN (or behind %~dp0 )
and you are fine.
simply remove the backslash in front of 3 ZEN
/fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.
Hi crissjj,
please let me give some clarification:
simply remove the backslash in front of 3 ZEN
/fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.
This is not a workaround; it's a bugfix for your environment!
I think it's important to clarify that there was no issue with mp3tag.
Nevertheless I'm happy that I could help you.
Kind regards
Despite this "work around" (better named as "work to the point") the situation of having a non canonicalized folder/file path within the Mp3tag application should not happen (user errors should be handled as smart as possible).
To make a file path valid there are numerous system based functions avaliable, e. g. Microsoft Windows Shell lightweight utility functions, e. g.
PathCanonicalize Function
http://msdn.microsoft.com/en-us/library/bb773569(VS.85).aspx
PathSearchAndQualify Function
http://msdn.microsoft.com/en-us/library/bb773751(VS.85).aspx
... and surely thousands of similar validation tools built by programmers from all over the world.
DD.20090629.2026.CEST
This is not a workaround; it's a bugfix for your environment!
I'd say it is both.
I think it's important to clarify that there was no issue with mp3tag.
Disagreed. I consider Mp3tag's failure to canonicalise the path to be a bug.
"bug" being "deficiency causing failure to meet reasonable user expectation". I accept your definition of "bug" may differ.
Florian, I do hope you'll address this.
Oh, some action here.
I want to give some explanation on my hint.
I found the existence of the /fp: command line option throught the registered
shell extension (right-klick on a directory) and thought, it could be
usefull to differentiate the working dirctory - where default filesystem
opperations reside - from the scan path (/fp:) - which the program uses
as root to find audio files.
This all was an assumption about the behaviour of the program.
As I run into similar problems with /fp: like chrisjj do (see also this thread),
I unsportsmanlike reviewed the html documentation:
Nothing about /fp: or the role of a working directory or a scan path root is
documented!
So I have to conclude that the assumption about the behaviour of the program
as I stated before is faulty, it seems that it is quite different from the
authors program design, where the role of /fp: parameter is intended to
implement the shell extension functionality - Fabian, please correct me,
if i'm wrong.
In this context, the program always can be sure to get well-formed,
canonicalized string representations of an existing directory - the
operating system itself takes care of this.
In my opinion it has to be indisputable that:
The faulty usage of an undocumented "fictional feature" can not lead into a
bug report situation.
At the other hand - and I agree 100% with the contents of DetlevDs post here:
It's a good idea to prevent a user from smuggling funny strings into
%_path%, for instance something like "D:\\///\\mp3/////\tagged" is posible
and the usage of an relative path leads in confusion or program hang.
Now, I want to stop with laberrababer and
close with my respect to Fabians work:
The usability of mp3tag is great for me.
If a feature is undocumented, how can anyone know a use of it is faulty? 
Sadly Mp3tag's documentation is somewhat dispersed. The HTML docs are known to be incomplete and are not held as a definition of program behaviour. If there had been complete docs, they would no doubt have defined acceptable usage and presumably excluded the usage I made. Hence I wouldn't have made the usage I guessed. Yes, it would be better if we didn't have to guess. But we do.
I'll try to canonicalize the incoming paths with the next release. In the meantime I made the command line interface an official feature: Mp3tag Help - Command Line Interface.
Kind regards,
Florian
I'll try to canonicalize the incoming paths with the next release.
Thanks.
In the meantime I made the command line interface an official feature:
Mp3tag Help - Command Line Interface.
Excellent. May I suggest this page also cover the method for Add directory: Loading multiple folders on launch .
PS
Starts Mp3tag with the specfified audio file
s/specfified/specified/
Verified
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.