AGS 3.3 chopping voice OGG files?

[Crimson Wizard]

I built the engine with libvorbis-1.3.4, but have same results.

Meanwhile I learned that the file was encoded with "Lafv" (which stands for "libavformat" coding library). Is it possible that this codec writes the file in a slightly non-standart format?
I noticed that while Media Player Classic and Windows Player play this file well, the VLC player, for instance, don't (although it plays other OGGs I have) - the sound stutters, and few file parts play in different order (!).

It seems I would need to dedicate some free time for this... Maybe ask around on the web.

[SpeechCenter]

Perhaps open a bug for at xiph.org for libvorbis (https://trac.xiph.org/). They'll probably be able to tell if this file is encoded incorrectly or if it's a software bug.
By the way, the file does play correctly on my VLC, but there's a problem to have it play from a different location than the beginning.

Regardless, it's a good idea to update the library, the current one is very old. It would also help building all dependencies from source, if one would like to do that.

[Crimson Wizard]

Mods, do we have a right to use your speech OGG as an example in public? I mean, it contains some in-game lines which may be considered spoiler. Maybe you have something more generic between the files that fail to play?

[m0ds]

It's ok CW to use that one. If someone takes the entire plot for the game from that one line, Kudos to them

Also, it's interesting to see both your points. Unfortunately I don't seem to get much choice in what kind of OGG to convert it to (ie choose any different kind of encoder), other than a basic "OGG Vorbis" choice. But I can understand why "Lafv" might be a cause of the issue.

[Crimson Wizard]

I am back to this again, and my situation changed. I wrote a test based on ogg vorbis example, which simply decodes the ogg file and writes progress into a text log. I found out that my test program parses the file just fine to the very end.
I write parameters I send to ov_read, and the resulting values.
I made AGS write similar log, and then compared them. They appeared to be identical, until the moment when ov_read failed.

Then I noticed that the ALOGG (an Allegro-based library which works with OGG for AGS) has its own callbacks for reading, seeking etc the data.
So now I am questioning if it is ALOGG that has a bug inside.
What I found so far is that AGS uses version 1.0.3 of ALOGG, which is as old as august 2002 .

The latest version I could find in the web is ALOGG 1.3.7 of 12 december 2005. The problem is that I can't use it out of the box, because its program interface has changed absolutely.

Searching through the change-log, I found these entries:

Fix stream stopping and some occasional pop sounds
Fix the encoder not setting the end of stream properly
alogg_stream now avoids cutting the stream too early when adding echo

etc, so who knows, may be one of them bug fixes is related.

Problem with ALOGG is also that it's very old, and many links that supposedly reference its download pages are not working anymore. I found only versions 1.3.4 and 1.3.7, and both are way too different from the one AGS is using to make a quick update.


EDIT: I will make some more tests to see if I can at least find a difference between standard vorbis stream reading and ALOGG's one (thankfully both sources are open).

//-------------------------------------------------------------
UPD: Okay, I practically found the case when ALOGG's callback finds out that the provided source buffer is emptied and returns EOF value to OGG Vorbis library. So ALOGG is the culprit after all. Question is, why didn't it asked for another piece of data in time...

[Crimson Wizard]

Ehhh... alright, I take all my words about ALOGG and OGG vorbis back.
It looks like I did not properly understood how this thing works from the beginning.

Basically, it is a problem in AGS that it does not handle the "buffer underrun" case.
In short, it is the situation when OGG vorbis needs N bytes of data to make correct parsing, but buffer has less. So it returns error code, which signals that program must add more data to already existing buffer. But AGS does not care about such things...

Probably I am on the right tracks now.

[Crimson Wizard]

Mods, I have this patched acwin.exe here:
http://www.mediafire.com/download/d2jbi88jdufibav/acwin_3.2.2_ogg_fix.zip
It is based on AGS 3.3.2 (though I believe you can use it in pair with 3.3.0 editor).

It is not fixed to the end, there's a noticeable "jump", maybe a fraction of second in length. I think a very small piece of sound gets lost when the error occurs. But at least it plays to the end and does not "hangs up" the speech forever. You may use this at least for a test, if you like.

I would need more time to investigate how the library works and if it is possible to fix this. Unfortunately, at the first glance, the sound lib AGS is using is not meant for handling situations like this itself, so may be I'll have to hack it too.

[Crimson Wizard]

Mods, here's another try, now it seems fine, but I can't be 100% sure. The library code is very old and frankly I do not want to dive too deep into it. Maybe if you could test this with more varied examples, we'll know better.
http://www.mediafire.com/download/d2jbi88jdufibav/acwin_3.2.2_ogg_fix.zip

If you say this works I'll add the fixes to upcoming AGS 3.3.3.

[Dualnames]

The same issue has been reported with primordia as well. It has been around forever, i can find you posts where i reported it and everyone just nodded and did nothing.

[Crimson Wizard]

Alright. Current situation is following: my fix is not perfect, it makes a tiny piece of sound get lost (not played) which results in a quick "scratch"-like effect (something similar to what happens when the phonograph needle jumps). The speech continues to play as normal after.

I spent some times trying to figure out a better fix, but my conclusion is that the library AGS uses as an intermediate between itself and OGG Vorbis is written incorrectly and does not provide any means to solve situations like this. And I have no interest in hacking it further, because I have little clue about how much I'll have to rewrite.

My intention is to use this fix for now (in AGS 3.3.3) to at least let the speech play to the end without freezing; for the future we might look into using a newer version of this library, or another library.