[ scummvm-Feature Requests-786569 ] OGG: Fix for codebook waste
SourceForge.net
noreply at sourceforge.net
Mon Sep 15 20:26:39 CEST 2003
Feature Requests item #786569, was opened at 2003-08-11 13:19
Message generated for change (Comment added) made by fingolfin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=418823&aid=786569&group_id=37116
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Marten van Wezel (puntloos)
Assigned to: Nobody/Anonymous (nobody)
>Summary: OGG: Fix for codebook waste
Initial Comment:
A detailed discussion thread about both issues is here:
http://sourceforge.net/forum/forum.php?
thread_id=912776&forum_id=115756
In a nutshell:
--- Codebook waste:
Every ogg file has a codebook of 4-12kbyte. On vorbis
files of (say) 1 second of (say) 32kbps that would mean
around 20% wasted space.
The way to fix this is to compile one huge source .wav
file (or at least not one for every sample!) and encode
this into one big vorbis file. After that all that's left is to
implement some code to seek the right spot to play.
A useful side-effect is that people interested in the
actual samples can just drag the resulting file into
winamp and play.
--- Resampling issue:
As I've come to understand it certain Lucasarts games
use a strange frequency of 11111Hz instead of the usual
11025. When fed to vorbis, vorbis resamples and
encodes, and appearantly vorbis isn't very good at
resampling. 2 solutions present themselves:
1/ Use some other resampler before feeding the file to
vorbis, Im sure there's opensource stuff out there.
2/ (my preferred solution). Just force/fake and write the
temporary wav files as being 11025Hz. The result is that
the samples will be played back sliiightly slower (0.7%)
but unless this gives unfixable timing problems in the
game I very strongly doubt anyone will notice. (or just
make it optional, so the purists can choose to resample
and lose a ton of quality :) )
----------------------------------------------------------------------
>Comment By: Max Horn (fingolfin)
Date: 2003-09-15 20:26
Message:
Logged In: YES
user_id=12935
One potential way to tackle the issue *might* be to first concat all
the raw data, taking care of the *sample* (as opposed to byte)
offsets/lengths of each sound. Then, we encode that single huge
RAW file. Finally, seeking in that file would be done by using the
VorbisFile methods which do PCM sample based seeking. The
problems with that
1) New format means people will have to re-encode their files
2) The above scheme has the drawback that we get "gap" effects
at the start of the sounds (because the previous sound is coming
right before the current sound in the file, and the encoder will
"interweave" them to a small degree... I lack the words to
properly explain this in english ATM, but I think anybody familiar
with the way MP3/Ogg work will understand what I mean)
----------------------------------------------------------------------
Comment By: Marten van Wezel (puntloos)
Date: 2003-09-06 15:23
Message:
Logged In: YES
user_id=673712
OK good to hear the system doesn't resample anymore.
As for the codebook thing, hmm thanks for allowing me the
freedom to write a patch, though I think it's more likely I'll first
take the freedom to learn japanese and become an astronaut.
:(
----------------------------------------------------------------------
Comment By: Max Horn (fingolfin)
Date: 2003-09-06 12:13
Message:
Logged In: YES
user_id=12935
No, LA games don't use 11111 khz. This is just a "wrong" number
caused by the fact that the VOC format can't encode arbitrary
frequency values, so you have to round your freq to the nearest
available VOC freq value, which is 11111. The data is still 11025,
and newer versions of extract support that appropriately. So that
should cover your second question.
As for the "codebook waste": feel free to write & submit a patch :-
).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=418823&aid=786569&group_id=37116
More information about the Scummvm-tracker
mailing list