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?
Theory on MONSTER.SOU differences re: compression
Moderator: ScummVM Team
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.
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.
-
LogicDeLuxe
- Posts: 432
- Joined: Thu Nov 10, 2005 9:54 pm
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.
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.
Thus, using both is the best thing to do, given it is available on the target platform.
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.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.
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.
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.
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.
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.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.
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.