Hi ohrenkino, I'm working on it! I was out most of yesterday so didn't do much keyboard-clattering.
I'm sure somebody somewhere said the use of the tab character [(chr(09)] was ok, but its easy enough to change so I'll do that shortly. I am using a text file which is the output from a Word table, the Raspberry Pi program inserts tabs between the field data items, so all I need to do is tell it to insert something else, probably |. Aside - | (shift-backslash) is two vertical bars, one above the other, on my keyboard. It took me ages to discover that it appeared as one full-height vertical bar on the screen...
This leads me to a new question. Originally I was leaving the field data out completely if there was none, relying as usual upon the logic that if there were two tabs together a program like Excel would automatically leave a blank field. So, assuming for the moment that the Mp3tag fields are ordered Title, Performer, and Album: Help!|The Beatles|Please Please Me (etc) would fill the first three fields in Mp3tag in that order. But if the Performer field in the text file was empty, as in: Help!||Please Please Me (etc) I have assumed that Mp3tag would fill in the Title and Album fields correctly, leaving the Performer field blank.
The question is, do I need to use a placeholder to fill a blank field, as in: Help!|%Performer%|Please Please Me (etc)
The program also lines-up the data items to suit the default field labels in Mp3tag, so I don't have to shift them around manually. The original field list came from the column headers of the Word file, but I came across something that told me that leaving them in the text file was a bad thing to do, so I made the program discard them.
(I'm hoping that the exclamation mark is acceptable to Mp3tag...)
Good news! Quite by chance I found a load of useful Mp3tag info in my Junk Mail folder late last night. So, two jobs to be done before altering the Pi program - 1. Read it, and 2. Find the ASCII for |
Thanks again for all your help,
33-45-78
Would be OK if you do not have any data for ARTIST (and it is ARTIST and not PERFORMER, I think)
I wonder what you do all the time. Don't you have a sample data text file and a test file or a set of test files for which you try the various suggestions?
Because if you did then most of the questions would have been answered by now.
Some further comments
I do not think that you need to use a Raspberry to replace the tab character with the bar character - Word should be capable to do that.
(it is Ctrl-H, Search for: ^t Replace with |)
It is not necessary to use the bar character as separator. The only properties of the character are: is printable and is unique (i.e. not part of the data). So if you have the ° as unique character, take that.
Hello again ohrenkino, sorry if I didn't explain some things too well. First, ok on the column headings, I was typing from memory at the time and it failed me... No, I don't have any sample data files that work, and believe me when I get one I will keep it in a safe place and make multiple backups!
The Raspberry Pi program does a lot more than just replace the tabs with another character, and I have a feeling that if I did that then subsequent parts of the programmed alterations might not work 100% of the time. I originally decided not to use the asterisk as there might just be some in the data - which again I could find in Word, but if there are any they will be there for a reason so I'd rather use something else. I don't remember ever using the vertical bar character so I feel pretty safe to do so now.
I've done the programming on a Raspberry Pi because I don't have a decent programming language on the PC (I used to use Turbo-Pascal, Modula-2, H-P Rocky Mountain BASIC, and Epson assembler at work, PIC assembler on the PIC chips and BBC BASIC almost from the day that the BBC Microcomputer first became available at home, plus a few others now and again). I would have used BBC BASIC 6 on the RISC-PC but the disk filing system is fundamentally different and it hasn't got USB on it.
With the info that landed in my Junk Mail folder and with your help I feel I am getting closer now. I've been a bit tied up today too, so perhaps tomorrow I will be successful!
Thanks again,
33-45-78
That has the tab character as separator so it should be easy to replace that with the bar.
But what it also shows: it does not feature the filename as a "column" of its own, instead it reads 7XCA.27256, C2/Ikey_019.WAV, C2iKey_019.mp3
for one field ("column").
If you use the filename addressing scheme, then it should be |7XCA.27256, C2/Ikey_019.WAV|C2iKey_019.mp3
Also, if you use the data file for files that are distributed over several folders, the filename should contain the full path.
So the first record in that file could look like: Watch What You Do With My Baby|Cliff Richard and The Shadows|Giant/Baum/Kaye|1964|B|B||7XCA.27256, C2/Ikey_019.WAV|C2iKey_019.mp3
(i removed the double-bars, except 1)
Which probably could be imported with %title%|%artist%|%composer%|%year%|%initialkey%|%genre%|%dummy%|%comment%|%_filename_ext%
Hello, and guess who? You're right, its 'im again! And for my next merry quip, guess what? I've now successfully converted two of the ten tunes in the temporary test directory, and that's made my day!
It took a little experimentation, e.g. I found that the text between two |'s needed a space either side of it, so data entries look like Title | Artist | etc and not Title|Artist| etc, and %filename% | %name% | etc not %filename%|%name$| etc, an easy mod to my Pi program. I finally got the field string to match the on-screen fields and the incoming data, and suddenly without any warning Bob was my uncle! I've attached a copy of the Preview, only two lines out of the ten worked but that's ok because I only changed those two.
I will let you know how it all goes, I'm anticipating pretty well now I've got a working template to mimic. Mp3tag certainly looks like a very useful program and I can't thank you enough for helping me out during these early stages. At 72 I guess I'm not as quick as I used to be!
Bye for now,
33-45-78 preview 210417.txt (903 Bytes) TAGinfo.txt (1.3 KB)
Hi again ohrenkino, 33-45-78 again, still having problems. I am now getting an error message every time I try to run the Text-Tag action and it won't go away. Mp3tag crashed a couple of times so I have used the uninstall file and then re-installed it.
I have been using a directory with only two tunes in it for experimental purposes, a tag info file containing two lines of data, and a matching format string. I've tried using space-forwardslash-space, space-backslash-space, and the vertical bar (shown as vertical broken bar on the key) as seperators, along with several other things that looked reasonable, but nothing has prevented this error. I have also looked deeply into the manual, especially the bits about using text files.
The error reads 'Cannot parse line n' where I assume 'n' is a line number from the data file, although it could equally well be a line number from the tag field lines in the main window, i.e. the ones I am trying to change and/or add to.
If I select All Files then the tag panel fields all change from being empty to less-than,keep,greater-than*. I have tried manually changing them to show less-than,blank,greater-than* but that didn't help.
If I select a single file then all the current tag data shows up in the tag data panel at the left of the main window, and I have tried changing fields manually. This seems to work, so it looks as if something is going wrong in between reading the text data file and applying the data to the columns in the main window - which is where the inability to parse the lines comes in. I'm thinking that without parsing, nothing is going to change.
One thing that seems to have gone missing is a data entry box with the caption 'Enter the seperator character' or something like that, which is what I was using to change it to the vertical broken bar. That seems to have gone missing, and I can't find where it is supposed to be by referring to the manual. However, now that I have tried using both the slash characters with no success I don't think that's the problem.
*Hmmm, apparently this editor doesn't like some mathematical symbols...
I'm going to attach my text files, one of which is a cut-and-paste of the error message. I'd be eternally grateful if you could have a glance at them and tell me where I am going wrong. ErrorReport.txt (160 Bytes) FormatString.txt (133 Bytes) preview.txt (216 Bytes) TAGinfo.txt (411 Bytes)
This is the format string: %title% | %artist% | %composer% | %year% | %filename% | %path% ! %tag% | %albumartist% | %album% | %track% | %comment% | %modified%
The first thing that hits the eye: there is an exclamation mark between path and tag: %path% ! %tag%
Then: you do not use the correct field names: its
%_filename%
%_path%
%_tag%
Otherwise you create user-defined fields.
This is the first line of the data file: Your Eyes Tell On You | Cliff Richard and The Shadows | Giant/Baum/Kaye | 1964 | %filename% | %path% | %tag% | Columbia | Cliff Still Lives! | B | 7XCA.27256, C2/Ikey_015.WAV, C2iKey_015.mp3, 02-015 | %modified%
As you do not have the exclamation mark in the data, but in the format string, the line cannot be parsed.
Then I think that you will run into trouble as you fill the user-defined field PATH (not to be mistaken for the file property _PATH) with the text "%path%". That may one do as one likes but I wonder whether this was intended. I would have assumed that real file path was supposed to be the data.
For any data that you do not need (_TAG cannot be written, so why import it?) or that you do not know, leave it blank in the data and add the dummy field %dummy% in the format string.
The format string may look like this: %title% | %artist% | %composer% | %year% | %dummy% | %dummy% ! %dummy% | %albumartist% | %album% | %track% | %comment% | %dummy%
So the data may look like this: Your Eyes Tell On You | Cliff Richard and The Shadows | Giant/Baum/Kaye | 1964 | | | | Columbia | Cliff Still Lives! | B | 7XCA.27256, C2/Ikey_015.WAV, C2iKey_015.mp3, 02-015 |
Are we using the same program? There is no way to enter wildcards or logic operators in the tag panel - all these strings are taken literally, except the ones supplied by MP3tag: <keep> and <delete>.
Hi ohrenkino, 33-45-78 again. Great news! All is well! Tags applied to 50 .mp3 files in about 3 seconds, all showing sensible data on two car radios. Great fun! I read somewhere on here that Mp3tag will take just over 50 files in one go which is why I ran it with 50. I will do the rest in batches of 50.
The exclamation mark was entirely my fault as the format string is not computer-generated - no point really as it is so small. Only the text files are computer-generated, from the original Word table. That only takes seconds too, the only problems now are the odd typos in the table, some of which are undesirable Return characters. However, as each record is of nine fields, I can put the cursor right at the end to get the total number of lines, then divide it by nine on a calculator. So long as the result is an integer I'm fairly confident that the file is ok.
I think I was getting a bit mixed up in places as the instructions are not always crystal clear. Things like "the file has to be (this that and the other)" have occasionally made me ask myself "Does that mean the format string, the tag data file, or the .mp3 file I want to update?", maybe I should have taken a little more time to work it out. I think some of the examples could be added-to, and a typical format string with explanations of how the various parts work would be incredibly useful to novices such as myself. At the same time I appreciate that the program is a free download and that therefore compromises have to be made. It occurs to me that the examples of how my format string and how each record in the data file should look could almost slot straight into the instructions.
Ah, now, the logic operators. The 'greater-than' and 'less-than' symbols often get used in instruction manuals for industrial equipment to indicate that whatever is enclosed within a pair of them is a key to be pressed (e.g. CR) or a piece of data to be supplied by the operator (e.g. either 'Y' or 'N'). I found that those characters were unacceptable to these messages, they just got deleted. So I had to type e.g. 'less-than' in full instead of using Shift-comma. There was no intention for them to be read as logic functions, so yes, we were both using the same program!
I did try using things that looked something like %_filename_ext% and %_path% as outlined in the instructions but they didn't help in this case possibly due to the spurious exclamation mark. I can't remember in which order I tried various things but I'm pretty sure I would have corrected that early on in the proceedings so still a bit of a mystery.
Thanks again for all your invaluable assistance and infinite patience,
33-45-78
Would be interesting to see where you read about this restriction - there is no such thing.
The only thing that I could think of as reason: if you import the data without the reference to a filename then it could be easier to check just 50 odd files than 1,000 or so whether the data ended up in the correct file.
Anyway: I am glad it finally worked out.
Hi ohrenkino, 33-45-78 again. I've scrolled through the Community entries and cannot now find the one that mentioned only about 50 files being allowed in one go. Perhaps I saw it on another forum or in the FAQ somewhere, but anyway its not really important.
I have discovered some 'shortcuts' in my original Word file that can upset Mp3tag, and they can be quite difficult to find. For instance there were a lot of CR's within fields, originally used to prevent word-splitting - not good when CR is used by Mp3tag to signify the end of a record! Reading the headings of some of the bug reports made me think that they too could be the result of inappropriate characters within text files.
Cheers, 33-45-78
If you have a word file, then convert the text into a table and then sort sequentially by every column. Like that you will find the pieces of data where the rule "one line per record" is broken.
Preferably, you do this check on a backup file.
Thanks, I'll try that. The Word file was a table from the start, the gramophone records were (and still are) stored in alphabetical order of artist. I've used the table in the past to sort in order of 'year' or to find out how many copies of Rolling Stones songs there are, etc. From the singles, the LPs, the single-artist CDs and some Various Artist CDs I think there are about 12 copies of Satisfaction. Playing the tunes at random, I've only ever heard two instances of the same song played sequentially on one occasion - the difference was that one of them didn't have any pops or crackles on it.
I export the table as a text file for the Raspberry Pi to use because I don't know how to, or even whether it is possible, for a program to obtain data from a Word file directly. Unless the program is another member of the Office family e.g. Access. But I've never used the sorting of the table to find spurious carriage returns before. I will investigate that possibility - using copies of the files on a USB Flash RAM drive plugged into an old laptop which I think of as 'sacrificial' these days. But first - I've got over a thousand anonymous MP3 tracks to tag...
Thanks again, 33-45-78
While it is an easy text editor, I don't think Word is ideal for other programs to get the data you are looking to share. So exporting the info to .CSV or similar will help make this sharing process more similar as a data set.
If you happen to also have Excel, you can import that same .CSV file and use a find/replace action for any of the CR or other odd characters (find CR/replace ""). You can then save that back into the same .CSV format and keep the file contents needed to share with mp3tag.
This may also help you identify any lines missing a field with data if you use the filter feature of Excel to check for any that have a "blank" in the list. This would usually be in the last field or two, depending on what data is missing.
It may seem like a bit of extra work up front. But once you have it formatted to suit the needs for your import to mp3tag, it will make the rest of the process very fast.
And you can apply this action to all files at once, no need to break it into batches of 50 or any other smaller set. Except to test of course.
Hi MotleyG, 33-45-78 here, and thanks for your reply. The original Word file consisted of just one table, 42 pages long. I exported it as a text (.TXT) file because I find text files easy to manipulate and, far more importantly, easy for other computers to manipulate and use - bearing in mind that some of the 'other' computers are definitely not IBM-compatible PCs and don't use microsoft operating systems. Over the years I have never had any trouble using text files to pass information from one computer to another no matter what either of them might be. A Word file would be far from ideal for such tasks to the point of being totally useless.
I have written a program in Python, both to do the job and to provide me with a useful period of self-training because until a few months ago I had never programmed in Python. It does more than just translate a table into a suitable form for Mp3tag, e.g. it combines three of the original table fields into one data item which is then applied to the 'comment' field in the tag. It also adds the word 'Side ' in front of what would otherwise be just a bare and fairly meaningless letter 'A' or 'B'. That's ok for the singles, but will need modifying slightly for the LPs, cassettes, and 0.25" tapes when I get round to them! Any blank fields get a programmer-defined default applied to them even if it is only 'Unknown'.
One error that my program didn't deal with very well was a suffix that should have been .WAV in the table had been entered as .7WAV for some reason. I never liked the keyboard on the old netbook! No harm was done, my program just stopped with no error messages. Luckily there havn't been many typos so far.
So far I've managed fairly well with the spurious CRs as follows - there are nine fields per record to be applied as a tag to each .MP3 file. So I look at the line number of the last line in each text file and divide it by nine. If the result is an integer then there's a good chance that it is ok. The system fails if the number of spurious CRs also divides by nine to give an integer result! As time went on I became more confident in the system - first I decided that the guy who had said there was a 50-file limit in Mp3tag was wrong as I had exceeded that once as an experiment, and so started increasing the number of files per run. I'm up to about 150 so far with no signs of any limitations.
I tagged all the 45rpm singles this afternoon, about 700 of them. Without Mp3tag I might have completed 20 if I'd been lucky. And I'd still need some software to read and write the tags. Although I've looked at how the various tag systems work I decided that downloading Mp3tag would be far quicker and easier.
It has indeed caused a bit of extra work up front, but the time spent has been well worth it. The tags look really good on the car radio, which I have found to be the best of my available equipment for testing. The production of the tag data file for use by Mp3tag takes seconds and the addition of the tags to the files by Mp3tag takes about the same number of seconds. The longest part of the job is copying the .MP3 files from one computer to the other via a USB Flash RAM drive (they are not networked). The format string is always the same, and I have saved it as a short text file that can be cut-and-pasted into Mp3tag if necessary.
That's a good idea about using Excel to find spurious CRs, and it would only need doing once for the singles list, once for the LPs list, and so on. Maybe tomorrow, its getting late...
Thanks again for your help and interest,
33-45-78
