SGF Wishlist

    Keywords: Software

This page discusses new proposals for SGF.

Table of contents

Properties

SGF allows applications to freely define its own properties. However, discussing new properties helps achieve standardization.

VO - Voice

Property
VO
Propvalue
simple text
Propertytype
game-info, move
Function
contains URL or relative address of sound file to be played when game is opened or the move is displayed respectively.
Related
GC, C
Comment
Voice-over-IP is already supporded by some Go Servers. This property would allow to save it.
Proposed by
Sebastian

Discussion

Cheyenne: I have a concern about increasing the size of the SGF file (think of trying to download the SGF from say KGS and then importing into PilotGOne). A suggestion that this facility use two parts. The first part is handle for the sound file. The second part would be indexes into the sound file (start/end times). There could be provisions to handle multiple segment sound files (say within a variation branch). So you would have initial specification of where to find the sound file and then at each point you would only have a small index value to be used to indicate where to start and end the sound clip.

The sgf viewer resolves the connection between the handle for the sound file and the external file (that is either local or online). This should keep the size of the SGF down.

The way that I could see this functioning under say KGS would be that if you downloaded the SGF file you would be prompted if you wished to also download the corresponding sound file for the SGF. The file name would match the file name of the SGF and the file extension would be different (foo.sgf & foo.wav for example)

(Sebastian:) You're raising a good point. The standard could certainly include this in the form

 VO[relative\path\voicefile.wav#60-95]

In order for it to become an accepted standard, it should be really easy to implement. I'm not sure yet how easy or hard it is to implement start/end times.

Another way to reduce the size of the SGF file would be to use smart defaults. E.g. an empty property VO[] could be interpreted as sgffilename\movenumber.wav. This would however require that each move description be kept in an individual file, which will certainly create more overhead.

Cheyenne: I think having the actual file name within the sgf file is bad. It makes an assumption that the path to the file will never change. What happens if I transfer the file from one platform to another, or from where the path to the file is a URL to where it is now a local file? who or what is going to keep it in sync. I think what would be better is to simply create a tag that the viewer/player then associates with the sound file (with external hints maybe). For example:

  VO[A#60-96] ... VO[B#0-90]

Then let the viewer create the association between A and /relative/path/to/the/file.wav

Zarlan: I would be nice to have some sort of record of when what happens i.e. record if you go back a few nodes and say something there, it will be recorded that that happened. An alternative is having that recorded on a separate file.

This would of course only be useful for reviews and lessons and a format such as this is going to be made for KGS.

(Sebastian:) I'm not sure I understand what you mean. This seems to repeat the wish you just discussed on KGSStatus. If this comment is not an issue of the SGF format then it should be deleted from here.

Juan An alternative is to include the actual sound binary, not just a pointer. Of course it would increase the size of the sgf file, even if encoded as MP3 and depicted as base64 chunks in the file...

Format

Compression

A standardized compression scheme for SGF files would be useful, especially for programs making liberal use of flash media (Palm pilot, etc).

Compression scheme should maximize (in order of preference)

  1. (Minimize) Processor requirement
  2. Speed
  3. Size

Malweth

AshleyF: You seem to be talking about compression of some binary data (voice, player photos, etc.) but I thought I'd mention that Anders Kierulf (creator of SGF) has implemented a simple compression scheme in SmartGo that applies to game records. It greatly reduces file size for large collections while still maintaining an SGF-like syntax. For example, 40.1MB for all of GoGoD as a single SGF collection compresses down to 15.7MB as an SGC. Check out: [ext] http://www.smartgo.com/HTML/index.html?compressedgamecollections.htm

Malweth: I was talking about compression of the text data. Text such as an SGF can be compressed by 60-80% using RAR or ZIP algorithms. I wasn't aware of the simple method being used by Smartgo (I did realize there was a different file format used by this program). I do see problems with this, however - instead of a bulky compression (complete file) that is done and un-done by a compression scheme - once variations are added in the middle of the SGC sequences, the group must be split - a simple variation could actually end up adding more to the file size than the variation sequence actually requires. In any case, some type of method would be useful if added to the specification (not just as a recommendation).

Collection

A standardized SGF collection file would help put multiple SGF files into a single SGF collection. These files should contain a table of contents.

Such a standardization would be useful for SGF databases and collections. The (optional) compression scheme should also apply to SGF Collection files.

Malweth

AshleyF: The SGF spec already includes the idea of collections; just by including multiple game trees in one file (see [ext] http://www.red-bean.com/sgf/sgf4.html#ebnf-def). Not all clients support it though. SmartGo, to name one, has nice support for it and builds a 'table of contents' view as you suggest above: [ext] http://www.smartgo.com/HTML/index.html?gamecollections.htm.


This is a copy of the living page "SGF Wishlist" at Sensei's Library.
(OC) 2004 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About