![]() StartingPoints Referenced by
|
SGFWishlist
This page discusses new proposals for SGF.
PropertiesSGF allows applications to freely define its own properties. However, discussing new properties helps achieve standardization. VO - Voice
DiscussionCheyenne: 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... This is a copy of the living page "SGFWishlist" at Sensei's Library. ![]() |