Hi Guys, I got this problem:
I wanna compress digvoice.bun with scummvm tools and I always get this result:
Running compress_scumm_bun
- len=23806, ch=1, rate=22050, 16bits
Fatal Error Occured: Error: Invalid bitrate parameters
Tool ended with errors
My setting for Vorbis is:
Min.Bitrate: 64
Nom.Bitrate: 128
Max.Bitrate: 128
Quality: 10
I use The dig cd version. I wanna use Vorbis, because I wanna get ogg sound files.
Any help please?
ScummVM TOOLS problems!
Moderator: ScummVM Team
- ezekiel000
- Posts: 443
- Joined: Mon Aug 25, 2008 5:17 pm
- Location: Surrey, England
-
- Posts: 6
- Joined: Sun Sep 28, 2008 12:06 am
Using the GUI version of the compression tools, it seems you can't choose to set either bitrate OR quality, you can only supply values for both bitrate AND quality, which makes no sense to me.
Also, I can reproduce this issue trying to compress The Dig, if I set the nominal bitrate to anything above 88 (regardless of the other values, it seems).
Also, I can reproduce this issue trying to compress The Dig, if I set the nominal bitrate to anything above 88 (regardless of the other values, it seems).
Please file a bug report about this, or it'll be forgotten/lost. Check our FAQ entry on reporting bugs:
http://www.scummvm.org/faq.php#question.report-bugs
http://www.scummvm.org/faq.php#question.report-bugs
The encoding tools conserve the sample rate, the sample size and the number of channels of the original files (usually around 11kHz or 22kHz in 16 bits and 1 channel). There is no sense increasing them since the additional precision we would get is missing from the original files anyway.
These parameters can be used to compute the number of bits per second for uncompressed data. When compressing in ogg, they also define a maximum bitrate that makes sense. For example for a 22 kHz sound file, you can use up to about 90 kb/s. For 11 kHz the limit is lower and for 44 kHz you can go up to the maximum we accept, which is 160 kb/s. These are the limits in the vorbis encoding library, not in our code.
This also means that a bitrate of 88 for mono 22 kHz sound is actually as good a quality as you will get. It would not improve the quality to increase the bitrate (if the vorbisenc library accepted it).
Note that the compression tool never use both the quality and the nominal bitrate parameter. What it does is use the nominal bitrate if defined and use the quality otherwise. This means that in the GUI tool it actually never uses the quality currently since the nominal bitrate is always defined. This is a bug imho. What we can do is make the minimum, maximum and nominal bitrates optionals in the GUI (and undefined by default). This is already the behavior of the command line tool, so it would be consistent with it. Also we should give the option to either select a nominal bitrate or a quality value but not both. I have very little time to work on the tools currently, so as md5 wrote a bug report on that issue is indeed welcome, otherwise I am sure it will be forgotten.
By the way a quality of 10 does not mean a bitrate of 500 kb/s. As for the maximum bitrate accepted by the encoding library it depends on the sample rate and the number of channels. For mono 22 kHz sound it will mean a much lower bitrate. This is why this quality parameter is easier to use than specifying a nominal bit rate. We don't have to worry about the sample rate and number of channels of the sound we encode.
I hope this clarify some points (and that I didn't write complete bullshit).
These parameters can be used to compute the number of bits per second for uncompressed data. When compressing in ogg, they also define a maximum bitrate that makes sense. For example for a 22 kHz sound file, you can use up to about 90 kb/s. For 11 kHz the limit is lower and for 44 kHz you can go up to the maximum we accept, which is 160 kb/s. These are the limits in the vorbis encoding library, not in our code.
This also means that a bitrate of 88 for mono 22 kHz sound is actually as good a quality as you will get. It would not improve the quality to increase the bitrate (if the vorbisenc library accepted it).
Note that the compression tool never use both the quality and the nominal bitrate parameter. What it does is use the nominal bitrate if defined and use the quality otherwise. This means that in the GUI tool it actually never uses the quality currently since the nominal bitrate is always defined. This is a bug imho. What we can do is make the minimum, maximum and nominal bitrates optionals in the GUI (and undefined by default). This is already the behavior of the command line tool, so it would be consistent with it. Also we should give the option to either select a nominal bitrate or a quality value but not both. I have very little time to work on the tools currently, so as md5 wrote a bug report on that issue is indeed welcome, otherwise I am sure it will be forgotten.
By the way a quality of 10 does not mean a bitrate of 500 kb/s. As for the maximum bitrate accepted by the encoding library it depends on the sample rate and the number of channels. For mono 22 kHz sound it will mean a much lower bitrate. This is why this quality parameter is easier to use than specifying a nominal bit rate. We don't have to worry about the sample rate and number of channels of the sound we encode.
I hope this clarify some points (and that I didn't write complete bullshit).