[aspiers]

Yes; that's what my code does.  Do you envisage any problems with that?

Mostly that it is a total unneccessary complication.

I would suggest it's necessary in order to provide a more convenient experience to the user (i.e. the person building the CSV indices), because it optimizes the most common case which is that rows in the index correspond to the order in the fakebook, and that songs appear on contiguous pages within the fakebook.

Yes, but I would argue that the usual interpretation is less useful in this scenario than the meaning I am proposing.  Otherwise you manually have to go through every single song and provide its last page.
...
Another approach might be to provide a simple Ruby / Python script which automatically calculates the last pages via the same algorithm and then outputs an updated version of the CSV file with those numbers included. ... But this two-phase approach is less convenient for the end user and I don't see any real advantage to it. Am I missing something?

A rule of thumb is that when you generate data once, and process it often, it is better to put the overhead in the generating phase.

For performance optimizations on huge data sets, I entirely agree. However such optimizations are entirely unnecessary here, and they come at the cost of a smoother UX.