jacekiwaszko1
commented
1 year ago Hi Craig, I was thinking about how to solve that problem too. Some time ago I sent you an email with the proposal of creating file ids and file extensions in the spreadsheet.
Here's the test spreadsheet with 16xx copied: https://docs.google.com/spreadsheets/d/1TBolzOIATVjpMmeX6NoICvKCEcznD5UimRPquQplw0s/edit?usp=sharing
I created two formulas - one generating file ID according to the rules, and the other one for file extensions. The formula is based on three functions defined in the Apps Script tool. I also added conditional formatting that would help to find the duplicates.
What do you think about this? If that's a good idea, I can work on it a bit more and move everything to the script. Then we would only need two function calls: =FILEID() and =FILEEXTENSION(). But I will have to read more about google sheets programming to do that.
craigsapp
Not all entries in the
FILE_ID(column P) andFILE_EXTENSION(column Q) fields in the POPC2 metadata spreadsheet are filled in. TheFILE_IDis needed as a preferred way to link to scans on the PMS website (currently only cenids can be used to link between the scans and the transcriptions)Here is an example for cenid
18xx:0001on the spreadsheet https://docs.google.com/spreadsheets/d/1cEE6zs7u3g9mjUsr7jcUusnbp2eIkYyqsMFastC78-c/edit#gid=979339889In this case the first entry should be:
The file names (particularly the "file extensions" field) should be consistent across all files. Some discrepancies include:
(1) Sometimes the titles include a second double dash inside of the FILE_EXTENSION. The original design is one double dash to separate the composer from the title, and there was no intent to separate the title from the subtitle/movement or group title from the title. While this logically makes sense, it unnecessarily complicates the filenames in my opinion (but you can discuss why it could be useful). The purpose of the title is to be able to identify it for humans, and double dashes are intended to separate components for computer parsing of the file names, so there is not a great need to separate the title and subtitle in the filename extensions. The basic structure of a filename is currently:
Adding a separator between the title/subtitle would be:
Some files that go through the pipeline have these filenames with an altered naming convention, which I usually revert to the original system for consistency.
the current system without the subtitle separation from the title is:
And separating the title and subtitle would be needed for mass sections:
Also there is a consideration of non 7-bit ASCII characters. Non UTF-7 characters are reduced to their UTF-7 base character, such as
ątoa, but there is a convention ofłbeing expanded toll. I do not think that this is consistent in all file names. It is not necessary to expand tollunless that makes more sense, and converting to a singlelis fine unless you likellexpansions.The file naming convention should be consistent with German umlauted characters which are typically written out as
ö→oeand alsoß→ss. There is also potential consideration of expanding non UTF-7 characters in Swedish to UTF-7 equivalents (and perhaps Czech, etc.). So you see, giving a mapping to a double UTF-7 equivalent for certain letters can cause complications that are better to avoid and using single UTF-7 equivalents instead.Ideallly the source MusicXML files should use the same filenames as the final Humdrum files. These are currently different in
Nazwa pliku(column AE):Notice the capital letter, for example which is not allowed in the Humdrum filenames.
Once the file ids and extensions are added to columns P and Q, I will go through the existing files to identify files whose names need to change. I can also adjust the MusicXML filenames to have them match the Humdrum filenames.