I want my Export script to write a file reference being the track's filepath relative to the output filepath e.g.
track file: c:\Music\album\disc\track.WMA
output file: c:\Music\index.htm
file reference: album\disc\track.WMA
How, please?
Failing which, how else can I export an HTML file to the root foolder of a library, referencing tracks within in a way that survives library relocation? Thanks.
I do not quite understand what you mean.
But look there http://www.w3schools.com/TAGS/tag_base.asp
DD.20090801.1815.CEST
But look there http://www.w3schools.com/TAGS/tag_base.asp
Thank, but I'm OK with the HTML side... just not with the Mp3tag script side.
But actualy the script for using that BASE HTML would show me what I need to know. Can you tell me the script to generate:
but instead of http://www.w3schools.com/images/, the folderpath of my Export output file?
This works for me ...
<head>
<base href="file:///M:/MUSIK/">
</head>
<body>
<a href=".\ROCK\A\Air\2004 - Talkie Walkie\01_Venus_Air_TW_2004.mp3">Music</a>
</body>
</html>
DD.20090801.2000.CEST
That will break if the htm+tracks are moved.
Ok, you have two choices.
Update the base reference when moving to another root.
Remove the base reference and let the href anchor completely relative.
Then the index.html will work always in any specific root folder.
DD.20090801.2014.CEST
- Update the base reference when moving to another root.
Not an option sadly, because it may not be me doing the moving. In the most geenral case, the library may be on a removable drive and hence get a different drive letter each time.
- Remove the base reference and let the href anchor completely relative.
It for that that I asked the original question. If you can show me how to do that in Mp3tag script, I would be grateful.
See /c/export
Search for html scripts from user "mp3rix" or user "milka". I think they have rather good examples how to code relative href's.
I cannot see where the problem is for you.
See this small example ... where is the problem?
$filename(O:\Test.html,UTF-8)
'<html>'
'<head>'
'</head>'
'<body>'
'<a href="'%_PATH%'" title="'%TITLE%'" type="audio/x-mpeg">'%TITLE%'</a>'
'
'
'<a href="'$replace(%_PATH%,'O:\TEST\','.\')'" title="'%TITLE%'" type="audio/x-mpeg">'%TITLE%'</a>'
'</body>'
'</html>'
DD.20090802.1107.CEST
I cannot see where the problem is for you.
See this small example ... where is the problem?
The problem is that the track filepath comes out as e.g.
<a href="S:\Music\album\disc\track.mp3"
which is not relative to the output file. Causing the link to break if the output file and tracks are moved to another drive or folder.
Try something out to compose a relative folderpath ...
_volume .................: %_volume%
_parent_directory .......: %_parent_directory%
_workingdir .............: %_workingdir%
_workingpath ............: %_workingpath%
_path ...................: %_path%
_folderpath .............: %_folderpath%
depth_path .............: $folderdepth(%_folderpath%)
_folderpath_rel .........: %_folderpath_rel%
depth_path_rel .........: $folderdepth(%_folderpath_rel%)
_directory ..............: %_directory%
DD.20090802.1415.CEST
Try something out to compose a relative folderpath ...
Thanks, but none of those placeholders help compose a path relative to the Export output file.
Back to your entry example ...
track file: c:\Music\album\disc\track.WMA
output file: c:\Music\index.htm
file reference: album\disc\track.WMA
The file "index.htm" and the folderpath beginning at folder "album" share the same root, it is their home folder "Music".
It is obvious that all files in the folderpath down under "album" are located relative to the "index.htm" which can be referenced from within the "index.htm" by a relative filepath e. g. ".\album..."
This is a relative path starting from the current location of the "index.htm".
In case you move the foldertree to another place you have to move "index.htm" accordingly.
DD.20090802.1857.CEST
It is obvious that all files in the folderpath down under "album" are located relative
to the "index.htm" which can be referenced from within the "index.htm" by a
relative filepath e. g. ".\album..."
This is a relative path starting from the current location of the "index.htm".
Agreed, and I am indeed able to code a script for that specific example, but it would fail for others e.g.
track file: c:\Music\album\disc\track.WMA
output file: c:\index.htm
or
track file: c:\Music\album\disc\track.WMA
output file: c:\Music\subfolder\index.htm
That's why I said "I want my Export script to write a file reference being the track's filepath relative to the output filepath"
In case you move the foldertree to another place you have to move "index.htm" accordingly.
Accepted. I am asking only for a solution that works when index and tracks are moved together.
This is the same case as before. Common root folder is "C:".
From the same point of view you can access the file by relative reference ".\Music\album\disc\track.WMA"
Relative means that there is a relation between the two items.
In this case the relative path starting from the location where the file "index.htm" resides to the target file "track.WMA" is:
"......\Music\album\disc\track.WMA"
It has somewhat to do with the behaviour of apes in a djungle tree:
up, up, up, jump over to the other branch, down, down, catch the banana.
The html "control" file and all other involved "connected" files are united by a fix binding relation, which is not to be allowed to be broken up in order to work correctly, even after moving or mapping the file/folder structure to another root folder or drive.
When you code your export script you know this relation.
You always create a report of a known file/folder structure.
Your report file may be created somewhere else, but you know where it is, and therefore the relation is known while design time.
You can reach each file in your music base structure by using the fitting relative path to this file.
chrisjj, we are discussing a basic file system navigation method.
I don't believe that you know nothing of it.
I have a feeling of a great misunderstanding.
DD.20090802.2225.CEST
This is the same case as before.
Similar but not the same. There is a different relative relation between index and track files.
Relative means that there is a relation between the two items.
In this case the relative path starting from the location where the file
"index.htm" resides to the target file "track.WMA" is:
"......\Music\album\disc\track.WMA"
Agreed, and because the relation is different, the script solution that ahrd-codes the relation for the first example would not work on this example.
The html "control" file and all other involved "connected" files are united by a fix
binding relation, which is not to be allowed to be broken up in order to work correctly,
even after moving or mapping the file/folder structure to another root folder or drive.
Agreed.
When you code your export script you know this relation.
Not agreed! The two examples have different relations and hence no script of the type that you suggested, ahrdcoding a relation using %_folder% etc. will work for both.
Your report file may be created somewhere else, but you
know where it is, and therefore the relation is known while design time.
Unfortunately the report file location is not known at scrip design time. It is known only at script execution time - the user sets the report file location by entering iot in "Export file name" (actually Export file path), just before execution.
A script could probably meet the requirement if the script language had placeholders to access the Export file name.
chrisjj, we are discussing a basic file system navigation method.
I don't believe that you know nothing of it.
I believe you are right!
I have a feeling of a great misunderstanding.
I hope my points above in this message has resolved the misunderstanding.
From the viewpoint of the index file I would say no.
Maybe ..., but I never have driven me into such indifferent situation, maybe by incorporated programming style I always try to find a common anchor point.
Oh yes, you are right! Using the dialog edit field a Mp3tag user can only define a different output location for the new report file. To use a different music database folder as a new starting location the internal code has to be updated.
To handle such a situation in a good manner we need a scriptable Open/SaveAs user dialog module.
Yes. That's the point!
DD.20090803.0005.CEST
Oh yes, you are right! Using the dialog edit field a Mp3tag user can only define a different
output location for the new report file.
That is no problem at all. What is a problem is that this script cannot be coded to accomodate necessarily different output locations.
To use a different music database folder as a new
starting location the internal code has to be updated.
I'm not asking to use a different music database folder. And I am not clear what you mean by "starting location".
A script could probably meet the requirement if the script language had
placeholders to access the Export file name. .
Yes. That's the point!
So, do we agree that if Mp3tag development was to solve this, it should be by addition of a placeholder e.g.:
%_exportfolderpath% folderpath of the export output file
?
Erroneous mistake by me, because the "starting location" or "starting folder" simply does not exist because the base of an export routine is always the currently selected tracklist. The input list is a collection of tracks which can be located elsewhere on the local or net drives.
Even better ...
%_export_path%
... that means all path components (drive, folderpath, filename, extension) of the current export file.
... maybe splitted into its subcomponents too ...
%_export_folderpath%
%_export_filename_ext%
Those placeholder should carry a value in both cases (for user defined filename and hard coded filename).
DD.20090803.0141.CEST
Even better ...
%_export_path%
... that means all path components
"path" does not generally mean all path components. %_export_filepath% solves the ambiguity.
Thanks D. I shall file a wish.
I wrote:
What is a problem is that this script cannot be coded to
accomodate necessarily different output locations.
I now find that
https://docs.mp3tag.de/format/#export
%_filename_rel% Relative file name
%_folderpath_rel% Relative path without file name
solves my requirement at least when the output file is in a parent folder of all track files. EDIT ... and also in all teste other cases that can be relativised e.g. ..\