Theory on MONSTER.SOU differences re: compression

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

Post Reply
marzipan
Posts: 301
Joined: Fri Nov 25, 2005 4:10 pm

Theory on MONSTER.SOU differences re: compression

Post by marzipan »

While trying to get FOA's MONSTER.SOU down to the smallest size possible for the N64 port (as I'm assuming there's a max cart size limit somehow), I've noticed how difficult it is to get the data files, the ogg'd speech file and the N64 binary all under 64Mbytes.

Yet I had no problems at all with DOTT, which surprised me considering it has the biggest speech file out of FOA/DOTT/S&M.

So my question is this: how is DOTT - with the bigger MONSTER.SOU - able to compress down into size much better (under the same ogg setting of "q 1") than FOA - with the smaller MONSTER.SOU - can?
User avatar
bobdevis
Posts: 567
Joined: Fri Jan 16, 2009 10:52 am

Post by bobdevis »

Could it be that that the FOA's .sou is less wasteful with space to begin with?

I can fully imagine LA not bothering to be efficient as in those days a CD-ROM was basically as good as infinite space.
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin »

Different data does compress differently, and some data is better suited for audio compression than other. An audio file containing only silence compresses to a very small size, while one with a high dynamic range of say concerto music may compress quite badly.

The .sog files have the additional disadvantage that they replicate the Ogg Vorbis file header for each compressed sounds; I recall that at one point in the distant past somebody reported that this might lead to an overhead of up to 30% -- mind you, I never verified this, so this might be quite exaggerated... Anyway, this means that you could either try to use MP3, or use a lower bitrate for Ogg Vorbis.
User avatar
LogicDeLuxe
Posts: 411
Joined: Thu Nov 10, 2005 9:54 pm

Post by LogicDeLuxe »

Indeed, Ogg Vorbis isn't well suited for a bunch of short samples. I got bigger file size at about the same perceived quality on a monster.sou file as well. For CD audio tracks, it works great and usually needs less space than MP3 at the same quality.
Thus, using both is the best thing to do, given it is available on the target platform.
bobdevis wrote:I can fully imagine LA not bothering to be efficient as in those days a CD-ROM was basically as good as infinite space.
I guess, they didn't spent a though on that at all. They could have used 22050 Hz with ease, instead of 11025 Hz only. Still without any compression.

Same thing with Simon the Sorcerer II (where I worked on the remastering), Beneath a Steel Sky, Flight of the Amazon Queen, Star Trek Judgement Rites and probably quite some more games which were enhanced or specially made for CD. All those would have fit one CD with ease. A pity, they didn't thought of that.
marzipan
Posts: 301
Joined: Fri Nov 25, 2005 4:10 pm

Post by marzipan »

I see. Thanks for the info everyone.

Another thing I just discovered: with compress_kyra at least, SVM Tools doesn't properly acknowledge variable settings when setting up the encoding bitrate. Say I wanted to manage a constant bitrate of 20kb/s when compressing an AUD file - I input "-m 20 -M 20", but the tool will set up either 16 or 24 instead, having apparently been configured to only acknowledge specific levels of bitrate numbers. In the end I had to resort to making a custom batch file that invokes the MP3 encoding option at first (but which will fail because of no lame.exe), then oggenc the tempfile.raw that's left behind afterwards.

Perhaps the ability to properly use any bitrate you so desire could be implemented in future? Pretty please?

On another note, LibVorbis was updated quite recently if anyone wanted to update the code. Not that I've checked the current SVN tools build just yet, but hey.
User avatar
criezy
ScummVM Developer
Posts: 765
Joined: Sat Sep 23, 2006 10:41 am
Location: West Sussex, UK

Post by criezy »

marzipan wrote:Another thing I just discovered: with compress_kyra at least, SVM Tools doesn't properly acknowledge variable settings when setting up the encoding bitrate. Say I wanted to manage a constant bitrate of 20kb/s when compressing an AUD file - I input "-m 20 -M 20", but the tool will set up either 16 or 24 instead, having apparently been configured to only acknowledge specific levels of bitrate numbers.
The current code round the bitrates entered by the user on the command line to the nearest multiple of height that is smaller or equal to the given one (so 20 would be rounded to 16). This was a change done during GSoC 2007 and there is no explanation in the commit log.

I can remove this rounding and it will probably do what you want, but I am reluctant to do it without knowing why it was introduced in the first place.
Post Reply