[Bill O]

I wonder whether a csv file, similar to those used for pdf books, might be useful in allowing the import of multi-tune abc files.
From the user's perspective creating such a file could be, if not trivial, fairly easy.  A python (or other) script could generate a csv from the abc.  
This could have another benefit in that it allows the user to specify the assignment of metadata to database fields.  For example, I notice that that MS by default seems to map the abc S:, "source" to Type which I use to distinguish contents (e.g. sheet music) or file type (abc, pdf etc.) whereas many who use abc for traditional music use S: to identify the artist or event from whom or which that version of the tune was collected.

Just an idea.
Good luck and thanks

[Zubersoft]

It's not something I'm opposed to once I support importing multiple files through a CSV instead of just one (like it does at the moment). Once I support that, it wouldn't be too difficult to allow any type of file to be listed in the CSV, but the page order would obviously be ignored for abc files. So I'll give it some thought.

Mike

[itsme]

Combining CSV with ABC doesn't make sense.

By now splitting multi-song ABC files into separate files is the way to go.
I described here https://www.zubersoft.com/mobilesheets/f...14122.html
how I used Michael Eskin's ABC Tools to split Paul Hardy's Session Tunebook as an example.

Batch importing a bunch of single song ABC files already populates the MobileSheets database, so there's no improvement in using a CSV file.

Anyway it might make sense to improve MobileSheets' support of multiple-song ABC files.
The UI could look somehow similar to CSV import (selecting songs, displaying given data and so on) and could allow certain songs out of such an ABC file while keeping it unchanged. That doesn't require creating a separate CSV file. Every song starts with X: and ends at the next empty line. All the required information is already available within the ABC file. The MobileSheets database could be populated directly with the song data in the ABC file as it is already the case when single songs are imported. Title is in T:, Keys is in K:, Composers is in C: and so on. Mapping S: to (Source) Type might be questionable. I'm not familiar enough with what is common in the ABC community to decide that.
There's no page number. To avoid the need to search the whole ABC file for a given title to be displayed, the line number could be stored and needs to be updated whenever the ABC file has been changed, be it inside MobileSheets with the internal editor or outside of MS with whatever editor or tool.

[Bill O]

Let me clarify my suggestion.
I did not mean to suggest using a .csv as an alternative to splitting files, but rather as a way to implement importing split files without the need for a flexible parser to map information in abc to fields in the MS database.
Perhaps more important (in getting the metadata usefully imported) is that a csv, or a short configuration file specifying the mapping, could be implemented  without the need for writing a UI to let the user accomplish the same task wholly insider MS.

I agree that direct support of multi-tune files is the ideal, but may be more than MS can offer in the short term.
Better use of the metadata already contained in the abc files is a very good second choice

BUT. In either case, I think improved and flexible mapping of metadata fields would be a big step up in utility..  

As far as I can tell, batch import now does only K: ->  key and C: -> composer.  

Single file import adds G: -> collection and S: -> Type

Missing are M: -> signature;  O:  -> genre; R:-> rhythm (which I think may be a custom).  

As mentioned above S:-> type whereas the abc standard suggests that its info more closely resembles artist (though others may use it differently)
Title comes from filename, which is understandable given the other tasks that MS has to accomplish. 
A number of traditional tunes are known under several titles so it would be nice to have several titles linked to a single tune, but I suspect that is a can of worms that should not be opened yet.  

Thanks all, an I hope this clarified my suggestion