This is a very interesting project.

1) Is there any chance you might be releaseing the code?
2) Do you care to go into any detail about the file format you use to store the game reviews? Is there any hope of other applications being able to support the format?

Inside the .zip file there is a ogg-vorbis encoded audiofile and a textfile in my own format containing the replay.

1) Yes I'll release to code at some point in the future. But I need to choose a licence, check the licence of the libraries,... so it might take some time. If somebody is interested I can share the code with him now, I just don't want to release it to the public before cleaning it up and taking care of licensing.
2) Currently it uses a zip container(might change in the future to support streaming).
Inside the .zip file there is a ogg-vorbis encoded audiofile and a textfile in my own format containing the replay.
I didn't use sgf internally since sgf didn't seem suitable to record the time based changes to the game tree. But since the format isn't completely stable yet it's too early to support it elsewhere. And the time based content probably requires a code structure a bit different from what a normal sgf editor uses.

If the tool could allow to record an audio comment from KGS, it'd be paradise

Also Sgf can't cope with a stone or label being added and removed in the same node.

Also Sgf can't cope with a stone or label being added and removed in the same node.

If you think you have a reason to add and remove the same stone in one node, I'm pretty sure you're confused about how the SGF format works. If you add a black stone at tengen, and remove it at the exact same time, what exactly are you hoping will display on the screen?

That is the point: a lesson does not simply follow the SGF nodes, it jumps around and perhaps even changes them. Therefore, it is conceptually not possible to incorporate such a lesson into an SGF file. Instead, you need a format that describes the actions; this format can operate on an SGF file.

The alternative is of course to have prepared slides, but this means that the teacher has more work before the lesson.

If you think you have a reason to add and remove the same stone in one node, I'm pretty sure you're confused about how the SGF format works. If you add a black stone at tengen, and remove it at the exact same time, what exactly are you hoping will display on the screen?

If I add it, and remove it 0.5s later I expect the stone to be visible for 0.5s.

Of course I could follow CarlJung and create a new node each time. But is annoying for two reasons:
1) It creates a lot more nodes than a normal sgf editor would create (each click of the user=new node)
2) I need to copy all decorations(Labels) from the previous node which inflates the file and is annoying to work with.

I think an action sequence is more appropriate to achieve video like behavior. At each point in time I have a game-tree which basically corresponds to a normal sgf-file.
I'll add a export function for the format you suggested, but the export probably loses a bit of information.
But if other coders think that this export is useful I can add it as a non authoritative version into the zip file.

IMO the most important features to add ATM are KGS recording and sgf import.

Did you read my earlier post? You put multiple timestamps in the node, so that it says "display this at 15 seconds in, 75 seconds in, and 92 seconds into the audio stream."

EDIT: you may have a similar (but quite understandable!) misconception about the SGF tree. An SGF node does not equal a game move. An SGF node is simply a unit of logical delineation which may have any number of attributes associated with it, one of which MAY be a game move. So when the lecturer adds a label to an existing position while recording the audio commentary, it would create a new node with no additional moves, but a label (and audio timestamp) only.

I was talking about the conceptual level. Yes, it is possible to do it with time stamps mangled into the SGF file, but it has to be compared to the alternative, which is much easier to parse and write (example syntax):



This format describes what is actually supposed to happen, and seems much more flexible to me. Anyway, what I am aiming at is that the teacher's actions are orthogonal to the SGF tree. You might be successful in trying to press them into the tree itself, but I think that the way I show above is much easier to understand and implement. Still in other words: the SGF file is contained in the lesson, not the other way around (there may even be more than one SGF file in a lesson, as shown above).

Li Kao seems to use a similar approach.

It's more flexible in terms of what you can do with it, for sure - I was just saying he could get SGF import and export "for free" this way and if his file structure on disk is in a similar format (of course the memory structures should be as you describe when loaded from disk, which is also what I said in my earlier post with the example) then his entire file-processing function set becomes pretty clean. I like reusable code.