[ 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