#20 Support STIL information in ".stil" co-files

[Peter Dell]

Having a single STIL.txt file becomes an issue, if I want to (mass) update STIL information .
Examples:
1) Automatically import release/compo//rank information from Demozoo
2) Have generated STIL information for saprtools conversions for hundreds of songs
3) Renaming/Moving SAP files (e.g., from Misc/Unknown to real folder)conversions.

For 1) and 2), I want to use parallel processing on all my cores. This would lead to locking issues on a single file.

My proposal would be to support the option to include a "yoursong.stil" file in the folder of the "yoursong.sap" file. The lookup logic would simply read that first (and then continue with the classical STIL.txt).

[Piotr Fusik]

I originally opted for STIL information in SAP files as extra tags. Ramos (RIP) wanted a plain text file, like HVSC did.

1) 2) I don't see what's the issue? You can mass-import to temporary storage, then merge to STIL.txt
3) tools/validate-stil.bat in ASMA repo checks if the filepaths reference to actual files

[Peter Dell]

I originally opted for STIL information in SAP files as extra tags.

Ok, then I understood this differently/wrong: https://asma.scene.pl/wiki/StilVsExtraSapTags
I thought, you were against adding that information to SAP in first place.
A huge benefit I see in having separate file/files is that they can support unicode (which is something we already use a log in the STIL.txt). We cannot have unicode inside SAP. Other than that, I'd find self-contained files the optimum.

Base on my experience of the past 6 weeks: I find editing and ever-growing file very cumbersome and error prone, esp. because there is no tool support (e.g. sorting by paths). Building filepaths by hand, finding the right lines, taking care of leading spaces. I had to do that some dozen times now it is extremely ineffecient. And that will become worse if is add comment for hundreds of files (ranking/compo infos). Not to mention adding hundreds of generated conversions that are potentionally updated often (leading to conflicts with manualy changes). I would have preferred to keep these separate ("STIL-Conversions.txt"/ or <xyz>.stil>). Plus, there is currently no libs to read/write the information reasonable in Java (yet). </xyz>

There I feel that having the option to but the STIL information into "per song" files as additional option would simplify maintenance and allow for better separation.

[Piotr Fusik]

We cannot have unicode inside SAP.

Why not? Long time ago, Jakub Husak proposed changing the whole SAP header to UTF-8.

[Peter Dell]

That would break compatibility. Having the 40 character ATASCII restriction in the Tags, file names and folder names is a good thing. ´That's why I keep a 2nd file with Unicode mappings (and more) of the composers.

So maybe for a start, could we have something like the lookup searching for "STIL*.txt"? Then I can play around the generating STIL without harming the manually edited file.