I think that a collective approach towards fakebook indices is very good, and I appreciate you taking initiatives!
However, looking at your CSVs I think they're too limited. They contain just a starting and ending page, not page ranges. If two pages were swapped in your copy of the book --and this happens-- this cannot be dealt with.
Also, there's no provision for information like key, composer, artist. Columns are fixed.
Another potential trap of these indices is "The final page number is optional, because it can often be automatically inferred by the starting page of the next tune, ...".
In NewReal1.csv I see:
This would mean that song "Airegin" runs from page 17 thru 433, and "All or nothing at all" will probably crash the program .
It would be great to employ a more generic data standard for these indices. With a headings row, it would already be more flexible. For example, an index entry could use either "startpage" and "endpage", or a more powerful "pagerange". And it allows for additional, optional information without affecting tools that to do not understand this.
A final remark: the github page reads "... it's the very well-known CSV (or Comma-Separated Values) format". I'm sorry to disappoint you, but although well-known, there is no such thing as a standard for CSV formatted data files. The de facto standard defined in RFC 4180 is a good starting point.
However, looking at your CSVs I think they're too limited. They contain just a starting and ending page, not page ranges. If two pages were swapped in your copy of the book --and this happens-- this cannot be dealt with.
Also, there's no provision for information like key, composer, artist. Columns are fixed.
Another potential trap of these indices is "The final page number is optional, because it can often be automatically inferred by the starting page of the next tune, ...".
In NewReal1.csv I see:
Code:
Airegin,17,
# ...
All Or Nothing At All,444,
Always There,18,
This would mean that song "Airegin" runs from page 17 thru 433, and "All or nothing at all" will probably crash the program .
It would be great to employ a more generic data standard for these indices. With a headings row, it would already be more flexible. For example, an index entry could use either "startpage" and "endpage", or a more powerful "pagerange". And it allows for additional, optional information without affecting tools that to do not understand this.
A final remark: the github page reads "... it's the very well-known CSV (or Comma-Separated Values) format". I'm sorry to disappoint you, but although well-known, there is no such thing as a standard for CSV formatted data files. The de facto standard defined in RFC 4180 is a good starting point.
Johan
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).
johanvromans.nl — hetgeluidvanseptember.nl — mojore.nl -- howsagoin.nl
Samsung Galaxy Note S7FE (T733) 12.4", Android 13.0, AirTurn Duo & Digit (Gigs).
Samsung Galaxy Note S4 (T830) 10.5", Android 10.0 (maintenance and backup).
Samsung A3 (A320FL), Android 8.0.0 (emergency).