2015-02-06, 09:54 PM
If there's a constant asynchronization between audio and video, it may be a lag in the emulator you're using.
About the event audio, the simplified version is that there's no way to restore the sounds without destroying the text display. The long version is that the events work like this:
The problem arises if the "audio duration" in the "header text-box definition" is shorter than it takes the player to read the text. You can not extend the "audio duration" or it will play into the next sound clip. Even if the audio duration provides enough time to read through the English text, you would have to go through the entire text and add the "% duration" tags for each text box. There are thousands of such tags so manually editing them would be a nightmare.
The only places it would be relatively simple to restore the audio is when the clip uses only a single text box and the audio is long enough to give the player time to read the text. Such text boxes don't have a "%TAG" embedded in the text (since the one box uses 100% of the duration) but only have "audio location/duration" tag from the header. Restoring audio for those text boxes would be simpler because you could just restore the original header data over the "blank tags" I inserted. Still, sorting through all the text to find which boxes meet that criteria would be a large job. I had to program my own auto-tool to strip the sound tags from the header, and then I manually added back any audio clip I found that was essential and/or wouldn't interfere with the text display. Even if these "1-box" clips were restored, people would likely find it annoying to have some text auto-next and the rest require a confirmation button press.
About the event audio, the simplified version is that there's no way to restore the sounds without destroying the text display. The long version is that the events work like this:
Quote:Header text-box definition:
[Portrait, Text location, Audio location, Audio duration]
Text location:
Box1:
[TAG = % of "audio duration" to display this text before auto-next] "Text text text."
Box2:
[TAG = % of "audio duration" to display this text before auto-next] "Text text text."
The problem arises if the "audio duration" in the "header text-box definition" is shorter than it takes the player to read the text. You can not extend the "audio duration" or it will play into the next sound clip. Even if the audio duration provides enough time to read through the English text, you would have to go through the entire text and add the "% duration" tags for each text box. There are thousands of such tags so manually editing them would be a nightmare.
The only places it would be relatively simple to restore the audio is when the clip uses only a single text box and the audio is long enough to give the player time to read the text. Such text boxes don't have a "%TAG" embedded in the text (since the one box uses 100% of the duration) but only have "audio location/duration" tag from the header. Restoring audio for those text boxes would be simpler because you could just restore the original header data over the "blank tags" I inserted. Still, sorting through all the text to find which boxes meet that criteria would be a large job. I had to program my own auto-tool to strip the sound tags from the header, and then I manually added back any audio clip I found that was essential and/or wouldn't interfere with the text display. Even if these "1-box" clips were restored, people would likely find it annoying to have some text auto-next and the rest require a confirmation button press.