I am in the process of getting edited track data on 12000 tracks back into Media Monkey, and want to use MP3Tag as the means of populating custom fields.
Can you confirm for me how MP3Tag's "text file - tag" process proceeds? As in, does the importer apply each new text line in the source file to the next track in the navigation window? Or is there some checking of track tag value (eg filename) against existing tracks in the MP3Tag database? If the latter, that's good. If the former, that's not as good and I'll have to be REALLY sure of that the 11,997th track in the navigation window matches the 11,997th line of the file. I imagine that a sort by file path (I am careful about valid identification data in file paths) would get me a reliable sort sequence.
Could you advise on how the program selects which track to apply the tags to?
Thanks very much, exactly what I needed to know. I tried hard to find this informaion in the help files and forum but couldn't see it. If it isn't in the help files, can I suggest that it be added to the sections on "Text File - Tag", it would help newcomers.
You advised that "The binding relation is the absolute filepath", and "Import tag mask must have a "%_path%" entry".
I notice that in MP3Tag, the Path column does not include a filename, and so a value in "%_path%% returned from an updated export would not identify a specific file.
Does "absolute filepath" in this instance means the combination of path and filename, thus specifying a specific file in the folder identified by Path?
If so, wouldn't an import file and import tag mask also need to have Filename as well as Path?
Maybe the path column displays the content of %_folderpath%?
Yes, you have to make sure to work with a fully qualified filename.
The Mp3tag system variable %_path% contains a complete folderpath\filename_ext string.
DD.20090318.1448.CET
Edit. Changed %path% to %_path%
DD.20090801.1155.CEST
Thanks, I had separately (belatedly) come to the conclusion that the variable %_PATH% did contain the filename as well as the folder path.
I had been confused by thinking that the column name "Path" would have the same as the variable "_Path", and did not understand that the leading underscore would make all the difference. I'll have to get my organic text parser upgraded .
Could I make a plea for an updated list of variables with somewhat more explicit descriptions, with lots of pointers to it from lots of places in the help file.
I now have my test imports from text file accurately homing to all of the paths, except for those with a comma in the file title. I am importing from a text file, not a CSV, and am using semicolons for field delimeters in the format string. Is there something else I have to be wary of to get it to successfully match _PATH with filenames containing commas?
Here are some example _PATHs:
Does get matched --> C:\Users..PATH..\Chad Morgan - The Best Of Chad Morgan - 04 - The Dinkum Dill.mp3
Doesn't get matched --> C:\Users..PATH..\Chad Morgan - The Best Of Chad Morgan - 02 - You Can Have Your Women, I'll Stick To My Booze.mp3
Anyone with a knowledge of outback Austaralian comedy would suggest that MP3Tag is simply showing good judgement in being wary of Chad Morgan, but I'm going to have the same problem with hundreds of real music tracks in the rest of the collection.
You can go the safe way by using a delimiter character which is not allowed to build a filename in the underlying filesystem, e. g. the star * or the pipe |, and which is not used in some tagfield's data itself. A backquote ` should be rather good too.
Found the problem, self inflicted . Because I have 12,000 lines of updated metadata I am testing it carefully with a subset of test mp3 files and associated metadata. I am mastering that test metadata in Excel and writing text lines of data to a text file.
It seems that Excel places double quotes around lines containing commas when writing a text file. WTF?? Anyway, found and removed all double quotes and the import to MP3Tag worked just fine.
BTW, I'll probably change delimiter to a Pipe anyway for your reasons, and it's easier to see!
Some more steps required. I have imported a set of updated data to my "production" music files. All worked well except for 740 of the 13600 files, where MP3Tag's "tag from file" process failed to find a match for the 740 files and then proceeded to overwrite the "title" field of those files with one title value.
Fixed that now by re-importing fresh data for the mangled files, but I can't see how it should have happened in the first place.
I couldn't see any character or form pattern to the lines that were missed. The subsequent fix-up import did find exactly the same _PATH values as it had missed first time around.
Did I break some capacity constraint in the system or the import process?
I had the exact same questions: how to build a text file and format it to work. Thanks to this thread, I was able to successfully add tags to a small sample of files. Like you, I was hoping the program would act like a database, but it apparently does not. Instead the text file records have to line up with the selected mp3 files. I have to decide whether editing my data sources to match my folder structure or change my folder structure is worth it in time and effort to make this method work. With thousands of files (many with tags but many with no tags) in hundreds of folders, I have to be V-E-R-Y careful.
If I read you right, you have a body of data about your files but don't have a key value which would let you match each description to each file. MP3Tag uses _PATH for that purpose (NOTE the crucial leading underscore), which contains the absolute folder path and the filename. Am I right in thinking that your problem could be solved if you could add the _PATH value to your body of data?
If so, a sufficiently informative export from MP3Tag should give you enough information for matching _PATH in your body of data. You can do this by using MP3Tag's Filename-Tag (in the Convert menu) to fill in the missing basic tag values, and then exporting that for matching in your body of data. I use Excel to form my text files, with one row per file and the _PATH attribute in the first column. Concatenating albumartist/album/trackname gives me a reliable match to _PATH.
The functionality in Filename-Tag is powerful and flexible, and I have found easy to get what I wanted, after the necessary experimentation . If your folders are organised consistently in a manner that encodes track metadata (eg .../Artistname/Album/tracktitle.mp3), you should be able to use filname-tag to get those tag values into your files. Then, you can use those values as the basis for a comprehensive CSV export and go from there. Saves a lot of typing.
If you do this process, it will be necessary to NOT move your files and folders around before the next import. If you do move files before the import, MP3Tag will refresh its internal _PATH value when you next open it, and your data file's _PATH keys will be invalid. As long as the files are where you left them when you re-import, the _PATH attribute will work. The process has worked reliably enough for me (noting the apparent capacity issue). You can import lots of fields for each file or just one, as long as your data layout matches your format string.
I am reviving an old thread, but my question seems trivial, so not sure it warrants a new post.
And maybe the info I have found only apply to older versions (before v2.62??), and things have changed in the meantime.
Having said that, I just want to make sure ...
Regarding import from text file, I had read this :
But until now, I have always used a much simpler way. I just selected a bunch of songs in the navigation window, and I changed tags based on a text file:
with the same number of lines as the songs selected
the order of the lines/info in the text file is the same as the the order you see in the navigation window
Are there any other conditions I have to be aware of ?
Is it still better / more stable / more robust to use "%_path%" to match records?
Please say "no", because in my personal, not-too-technically-inclined, opinion, it seems a lot simpler and less error-prone to just use navigation window ...
Maybe I'll quickly explain what I want to do, and you can advise whether my workflow will work.
I need excel to do some re-naming that MP3Tag apparently cannot do (thread), but not just for a few songs, but an entire subset of my library (about 10k songs).
So what I want to do is :
select all songs in the navigation window (and I make sure that MP3Tag points to the directory that contains only the songs I want to change);
export to CSV (actually I'll use pipe | character instead of , or ; as I am sure it is easy, visible, well supported by Excel and MP3Tag)
import in Excel (check of course that # of rows correspond with # of songs in navigation window of MP3Tag)
do my hocus-pocus in Excel, delete all stuff I don't need, and export (the two columns I changed) again as a CSV (with | delimiter), and check with Notepad++ that the output file still has the same number of lines
txt>tag conversion in MP3Tag (%album%|%compilation%)
For the last step, my MP3Tag still has the same navigation window as before (I did not touch MP3Tag between the export and txt>tag actions), and all songs are still selected.
So I don't see the need to work with a %_path% entry in export and import. But maybe I am wrong, and my method will not work because there are too many files or other constraints that I am not aware of?
So, in the other case (I want to make sure that I understand) ...
If I put %_path% as the first (? or can it be anywhere?) placeholder in the format string, MP3Tag will not try to rename the file with the corresponding value in the text file (which is the behavior in the other use case), but will take the value in the text file, and search for a file on that location (most probably your hard drive), and if the file exists, the tags will be updated with the corresponding values in the text file, and if the file does not exist, nothing will happen and the next line in the txt file will be processed (so the file does not need to be shown in the navigation window of MP3Tag.
Thanks, it is very clear to explain it with mode 1 and mode 2.
I am not sure who decides on these things, but it would be very useful to add such explanation in the online help ... !
Mode 1 is very intuitive (and my preferred ...), and mode 2 could use maybe still a bit more explanation. In some topics they only talk about %path_%, and in others about %filename_% or %filename_ext% (I might have the syntax wrong). A power user probably can explain it in a few sentences and give a few examples in the online help, and that would help the novices or not-so-experienced users (like me) a lot !!!
I have posted a number of entries regarding moving data between different metadata formats. Example: using MP3 metadata to populate extended fields in say LINK or RIFF (for broadcast). Don't seem to be able to specify the recipient metadata variety.
.
. Because I have 12,000 lines of updated metadata I am testing it carefully with a subset of test mp3 files and associated metadata. I am mastering that test metadata in Excel and writing text lines of data to a text file.
. If your folders are organised consistently in a manner that encodes track metadata (eg .../Artistname/Album/tracktitle.mp3), you should be able to use filname-tag to get those tag values into your files. Then, you can use those values as the basis for a comprehensive CSV export and go from there. Saves a lot of typing.