gbs format

[RiedleroD]

So I think the gbs format is severely limited in its usability - no looping points, no song length, no … well, that's it, actually.

So I propose creating a gbs format v1.03 - although someone should check if the original author (presumably @scottwcpg, but I haven't confirmed that) has anything to say about this, I don't think this work would be seen as just a dialect if done properly.

To address the issues of looping points and song length - this could be solved in a few different ways:

• expand the header to intro and loop length in seconds (easiest overall, but not very precise)
• add a field in the header that points to a value in RAM which is to be replaced by gbsplay with the amount of loops the ROM should play. (more work for whoever is making a gbs file, but most precise, plus it allows the ROM to play an outro if applicable)
• add a field in the header that points to a value in RAM which contains the amount of loops that have passed (moderate amounts of work overall, still very precise)
• add a special instruction that is to be executed whenever a looping point has passed - therefore allowing gbs to limit the amount of loops itself (more work for the person who implements this, but pretty easy on gbs rippers, and still very precise)

All of these variants are backwards-compatible, except for the custom instruction, which might cause a crash in interpreters that crash on unknown instructions.

[mmitch]

Can you find out the relevant RAM locations programmatically?
Or would someone have to do this manually for every .gbs file that is out there?

If you had the information and would update existing .gbs files with it, how would you distribute the new .gbs files?
Would existing GBS archives be happy to include new versions of old files?
IANAL but I think hosting .gbs files is already a gray area and editing other peoples' copyrighted work will be even worse. That's why ROM translator groups mostly publish patches instead of patched files.

Creating a patch for every existing .gbs file sound like a lot of resources to juggle, but perhaps you could just combine all patches into a single database and then distribute the database. That idea already came up in the context of song lengths (see this comment in issue #8).
I still stand by my reply to that comment: That looks like a new project.

Putting the metadata in an extra database removes the need for a new version of the GBS spec.
You'd want to have support in multiple players to gain traction for this database, so using the database should not be confined to gbsplay.

So my take on this in very broad strokes:

1. start a new project
2. collect metadata info for gbs files (loop points, song lengths, whatnot) to fill the database (either manually or tool-assisted)
3. provide code for others to connect to that database (C library, Python module, …) that provides methods like look_up_this_gbs(), get_subsong_length() or get_ram_location_containing_repeat_counter()
4. get back to us so we can see how to include the library into gbsplay (displaying song lengths should be straight-forward; integrating repeat-counters will be harder)

personal disclaimer: I already don't have enough time for gbsplay so I certainly would not join that new project. The same goes for dissecting GBS player routines – I don't even speak Z80 assembly.

[RiedleroD]

Or would someone have to do this manually for every .gbs file that is out there?

It's not possible to get this kind of information programmatically (at least not reliably), that's why I want to make this format. It's for people making new gbs files, mostly. Ofc people can still upgrade old files if they want.

Would existing GBS archives be happy to include new versions of old files?

That's not for me to decide, but e.g. Zophar's domain would probably benefit from upgrading some.

Putting the metadata in an extra database removes the need for a new version of the GBS spec.

fair, but who will host that database? How will data be added? etc. I dislike such a centralized approach.

You'd want to have support in multiple players to gain traction

Absolutely!

[…] the context of song lengths […]

So… I realized that the 'home-grown' extended header mentioned there is basically very similar to what I'm proposing here. Not sure what that tells me.

[mmitch]

It's for people making new gbs files, mostly.

Oh, I did not think about that. That saves a lot of work ;-)

who will host that database? How will data be added? etc. I dislike such a centralized approach.

I'd say "just host it on GitHub (or GitLab or …) and wait for pull requests".

So… I realized that the 'home-grown' extended header mentioned there is basically very similar to what I'm proposing here. Not sure what that tells me.

:-D