[Welcome to Sensei's Library!]

StartingPoints
ReferenceSection
About


Referenced by
KGSStatus
KGSWishlist

 

SGFWishlist
   

This page discusses new proposals for SGF.

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.



This is a copy of the living page "SGFWishlist" at Sensei's Library.
(OC) 2004 the Authors, published under the OpenContent License V1.0.